A product roadmap's value is in the planning process and aligning the team on a vision, not in rigidly adhering to a delivery schedule. The co-founder of Artist argues that becoming a feature factory focused on checking boxes off a roadmap is a dangerous trap that distracts from solving real customer problems.

Engineering often defaults to a 'project mindset,' focusing on churning out features and measuring velocity. True alignment with product requires a 'product mindset,' which prioritizes understanding the customer and tracking the value being delivered, not just the output.

To get buy-in for developer experience initiatives, don't use generic metrics. First, identify leadership's primary concerns—be it market share, profit margin, or velocity. Then, frame your measurements and impact using that specific language to ensure your work resonates.

Setting rigid targets incentivizes employees to present favorable numbers, even subconsciously. This "performance theater" discourages them from investigating negative results, which are often the source of valuable learning. The muscle for detective work atrophies, and real problems remain hidden beneath good-looking metrics.

When handed a specific solution to build, don't just execute. Reverse-engineer the intended customer behavior and outcome. This creates an opportunity to define better success metrics, pressure-test the underlying problem, and potentially propose more effective solutions in the future.

Teams often focus on perfectly implementing frameworks like OKRs or Discovery, creating a false sense of achievement. This "alibi progress" prioritizes methodology correctness over creating value in a specific context, leading to lots of outputs but no outcomes.

While intended to improve efficiency, the rise of Agile ceremonies and specialized roles like Product Managers has created layers of abstraction. This often "hides" engineers from direct customer interaction, reducing their understanding of the "why" behind their work.

AI tools can generate vast amounts of verbose code on command, making metrics like 'lines of code' easily gameable and meaningless for measuring true engineering productivity. This practice introduces complexity and technical debt rather than indicating progress.

The misconception that discovery slows down delivery is dangerous. Like stretching before a race prevents injury, proper, time-boxed discovery prevents building the wrong thing. This avoids costly code rewrites and iterative launches that miss the mark, ultimately speeding up the delivery of a successful product.