Build to Learn vs Build to Earn
We have long argued that there have always been at least two major ways to develop product.
The most common way, even today in the age of AI, is the project model, which is all about output. This is where stakeholders or executives come up with a prioritized roadmap of features and projects, then for each feature or project, someone called a feature team product manager creates a specification (e.g. a PRD) of that feature or project, and then a designer creates designs to meet that spec, and then engineers build that spec.
The other way is the product model, which is all about outcomes. There is where product leaders (or stakeholders) identify an important problem to solve, and an empowered, cross-functional product team works first to discover a solution worth building (where we have evidence we can deliver the necessary outcome), and then we build and deliver that solution. It is not unusual in the product model for the product team to create 10-20 (or more!) prototypes per week, and this has been true long before generative AI, and with prototyping tools like Figma, this was actually not difficult.1
But even though these two models of work have long existed, and still exist, much has changed.
Today, because the cost of delivery has dropped so dramatically, actually building the feature or project is no longer the bottleneck. Much of the product world now recognizes the project model as a turbo-charged feature factory, capable of producing more bad products, faster, than ever before.
Now, it’s clear that the real bottleneck is in discovering a solution that’s worth building. A solution that solves for both the customer and your company. A solution that generates the necessary outcome. A solution that not only solves the problem, but solves it sufficiently better than the alternatives that the customer chooses to switch.
AI still helps with discovery, but in very different ways than it helps in delivery. And most importantly, product discovery is where a product manager’s knowledge is critical.
The reason for this article is that as product teams move from the project model to the product model, many product managers are struggling to understand their contribution going forward. They know that their old role project managing and facilitating does not provide the necessary value, but they’re not sure what would.
Some product managers have realized that with the capabilities of the latest generation of engineering tools (e.g. Claude Code, Cursor), they could actually lean into the building of the product, and take on more of the engineering personally. For those with the technical foundation, they can certainly do that, and there’s nothing wrong with that.
But what the best product managers realize is that while they are definitely product builders and creators, they are actually building for a very different purpose than the engineers.
Years ago, product coach Jeff Patton (the author of User Story Mapping: Discover the Whole Story; Build the Right Product), coined the phrase, “build to learn vs build to earn” to describe the difference between product discovery and product delivery.2
Lately I have found that Jeff’s phrase resonates especially well with product teams learning the product model in the age of generative AI.
We are building in both discovery and delivery, it’s just that we’re building with a very different purpose (to learn vs to earn), and normally using different tools and different techniques. Moreover, while the concept of “testing” exists in both discovery and delivery, the concept means very different things in each.
In product discovery we are building to learn. We are trying to discover a combination of technology, functionality, user experience and business constraints that address the key risks in discovery: value, usability, feasibility and viability. Today, 10-20 prototypes (or prototype iterations) per week is easy for just about anyone, and you don’t have to depend on help from your product designer or engineers in order to create these prototypes. The main purpose of creating the prototypes is to test against the risks; “testing” means testing for value and usability with users and customers; testing for feasibility with engineers; and testing for viability with our company’s stakeholders.
In product delivery we are building to earn. We are building a commercial quality product that we can sell, service and support, and that our customers can run their business on. There are very different risks when building to earn. We need to worry about scale, performance, fault tolerance, reliability, accuracy, privacy, security, operations, provisioning, internationalization and more. “Testing” in delivery means ensuring the product addresses this long list of demands, and actually works as advertised.
There are a couple of important differences today in practice.
First, while the four major types of prototypes are still in use today (more than ever), the new generation of tools has changed the relative cost of these four options, and today we can create live-data prototypes dramatically faster and cheaper than ever before. This lets us put functional prototypes of our product in front of select users and customers, and collect the data their actual use generates, much sooner and much less expensively. This is a game changer for build to learn.
Second, thanks to the speed of the gen ai-based prototyping tools, we can often test multiple approaches in parallel. We used to iterate largely sequentially – we started with what we hoped was our best approach, and then kept iterating until we had the evidence we should proceed to productization, and then we’d declare victory and proceed to delivery (building to earn). However, today it’s not unusual to quickly create several prototypes each exploring several different approaches to solving the problem, that we can then test simultaneously, and then continue to improve the most promising sequentially.
This discussion is focusing on the prototyping in product discovery, and the productization in product delivery, and while those are not the only activities going on, the essence really is building to learn vs building to earn.3
Today, many of the top companies have evolved their product management interview process to assess if the candidate understands the nature of the job as building and testing prototypes.
What are the skills and knowledge that are required for strong product managers working to build to learn? Becoming proficient with the prototyping tools and the discovery techniques is the easy part. The hard part is building the product sense necessary to evaluate the learnings and guide the direction.
I meet, coach and mentor a lot of product people, and in truth, not everyone is excited about building to learn, or really any type of building. Some people prefer to see themselves as serving a different purpose, usually some form of facilitator or manager or “glue” for the product team. For these people, I believe they are increasingly at risk.
But for those that embrace the builder/creator nature of the product manager role, and focus on developing their product sense and their build-to-learn skills, I believe that we are entering a golden era for skilled product people.
Note: in response to many questions, we have published a Build To Learn FAQ.
- For those that didn’t realize this model of work existed before generative AI, check out the first and/or second editions of INSPIRED from 2007 and 2017. ↩︎
- There are many different phrases out there meant to capture this critical concept of the product model. For example, Y Combinator is famous for advocating “building things that don’t scale vs building things that do scale.” ↩︎
- It’s important to realize that what we’re describing here is not a process; it is a conceptual model. There are many different discovery and delivery processes. It’s also important not to think of discovery and delivery as phases, as in practice these are both continuous, and of course we learn from delivery as well (especially once the product has been deployed at scale). But the principle is to fail (learn) in discovery, rather than exposing our bad ideas to all of our paying customers. ↩︎