Key Takeaways

  • Marty Cagan admitted at the Lenny and Friends Summit that his earlier books made product management sound too academic and gentle.
  • Simply solving a customer problem is no longer enough to survive in open markets; your solution must be dramatically better than existing alternatives to get people to switch.
  • Most software organizations waste engineering time by treating roadmaps as production commitments before testing whether customers care about the feature.
  • Cagan argues that product in competitive markets is a full contact blood sport where over-indexing on process destroys critical thinking.
  • Product teams must divide their engineering and research efforts using the Build to Learn vs. Build to Earn framework.

The Build to Learn vs. Build to Earn Framework

Cagan addressed his top regrets from two decades of product advice, pointing out that teams often mistake execution for learning. “If you want to make sure that what your engineers do build and provide to your customers, you should be building to learn,” Cagan explained. “It's a totally different approach, totally different job.”

The framework separates software creation into two distinct stages:

  • Build to Learn (Product Discovery): Rapidly creating prototypes and experiments to gather evidence, test viability, feasibility, usability, and value risks, and understand what will actually drive customer adoption and business outcomes.
  • Build to Earn (Product Delivery): Deploying full engineering capacity to build scalable, robust, production-grade software only after discovery has proven the solution will achieve the required outcome.

When This Works (and When It Doesn't)

This framework works when a team needs to separate risk mitigation from expensive production engineering. Assigning full engineering capacity to unvalidated feature ideas burns runway, clutters codebases, and wastes sprint cycles. By running fast experiments in discovery first, teams protect developers from building features nobody wants or buys.

The method fails when teams turn discovery into an excuse for analysis paralysis. If product managers spend months running customer interviews and producing endless slide decks without shipping code, the business starves. Discovery must move fast to generate hard evidence. It also breaks down when leadership treats discovery as pure design work without involving engineers early to evaluate technical feasibility and business viability risks.

What to Do With This

Open your team's sprint board tomorrow morning. Review the next three major features scheduled for your developers and evaluate whether each one is truly ready for production.

If an initiative lacks direct evidence proving customer demand and viability, pull it from the delivery sprint immediately. Do not commit two weeks of full-stack engineering capacity to an assumption. Instead, have your product designer and engineer build a quick discovery prototype by Thursday. Put that prototype in front of five real users by Friday afternoon to test value, usability, and feasibility before writing a single line of production code.