Key Takeaways

  • Product management advice over the past two decades underestimated corporate hunger for predictability, turning agile discovery into rigid delivery.
  • Traditional roadmaps that pair unvalidated feature ideas with hard calendar dates waste most of an engineering team's capacity.
  • Product Requirements Documents (PRDs) become dangerous when treated as lists of requirements rather than summaries of tested evidence.
  • Software teams succeed by building to learn and testing viability before committing engineering sprints to fixed outputs.

The Trap of False Certainty

Marty Cagan spent two decades teaching product managers how to build great software. Looking back at the Lenny and Friends Summit, he confessed his biggest miscalculation: “I honestly had no idea and I just didn't appreciate how powerful and deeply rooted the desire for predictability was.”

Executives want dates. They want feature commitments twelve months out so sales teams can sell upcoming releases and finance teams can model revenue. That demand created an industry of artifacts designed to manufacture certainty where none exists. Roadmaps with quarterly delivery targets give leadership a feeling of control, but they disconnect teams from the reality of how software actually succeeds.

When a team commits to a list of features before running experiments, they operate under the old project model. “If you put a bunch of features that are somebody's idea of what might work and you put dates there, you're going to waste most of your time,” Cagan noted. “You're going to end up wasting most of the engineering capacity.” Engineers spend months building high-fidelity implementations of ideas that fail as soon as real users touch them.

When a PRD Works (and When It Kills Teams)

Cagan pointed out that artifacts like roadmaps and PRDs are not inherently evil. The problem lies in the intent behind them. “Now for a second consider how much of an enabler those artifacts are for thinking that we know more than we really do,” Cagan explained.

When a product manager uses a PRD to tell engineers what to build based on personal intuition or stakeholder requests, the team guarantees waste. “If you're using it because you're forgive me arrogance and you think you know the answer so you're putting it in terms of requirements for your engineers to build that's the project model that's the root cause of so many failed products.”

The tool only works when the order of operations flips. Discovery must come first. A product manager tests value, usability, feasibility, and business viability with quick prototypes and user interviews before handing anything to engineering. Once you have direct evidence that a solution solves the user's problem and supports the business model, the PRD serves a clean purpose. “If however you have learned and tested and gathered the evidence you need to know what's going to be built is going to achieve the outcome then the PRD is just your communication device.”

What to Do With This

Audit your active sprint backlog tomorrow morning. Flag every user story that was written from executive requests or internal assumptions without prototype testing. Cancel the next unvalidated feature and spend three days running customer interviews or paper prototype tests before engineering writes a single line of production code.