The Ghost in the Machine: Why We Still Build Things Nobody Wants

Imagine, for a moment, a high-end restaurant where the chef never tastes the food. Instead, the owner provides a list of ingredients and a strict timeline for when the soufflé must leave the kitchen. The waiters are measured by how many plates they carry, and the dishwasher is evaluated on his "velocity." In this kitchen, the goal isn't a satisfied diner; the goal is a cleared ticket.

This is the state of modern software development for the vast majority of companies. We call it the "Project Model," but Melissa Perri, in her seminal work Escaping the Build Trap, has a more evocative name for it: The Feature Factory. It is a place where "success" is defined by hitting a release date, and "value" is an afterthought that someone in Marketing is supposed to figure out later.

We have long argued that there have always been at least two major ways to develop product. The most common way—the one that persists even as LLMs write our boilerplate code—is the project model. It is a world of output over outcomes. In this world, a stakeholder or an executive, often miles removed from the actual user, comes up with a prioritized roadmap. This roadmap is a list of "solutions" to problems that haven't been fully validated. A Product Manager (or, more accurately, a "Feature Team PM") then writes a thick Specification Document—the dreaded PRD. Designers skin the spec. Engineers build the spec.

But here is the dirty secret of the software industry: at least half of the ideas on those roadmaps will fail to deliver any business value. According to Marty Cagan in Inspired, some of the most successful companies in the world find that only 10% to 20% of their ideas actually achieve the desired result. If you are operating in a Project Model, you are effectively gambling with your company’s capital, and the house always wins.

The Pivot: From Output to Outcomes

The alternative is the "Product Model." This isn't just a different way of working; it’s a different way of thinking. It’s the difference between being a carpenter who follows a blueprint and an architect who first asks, "Why are we building this house, and who is going to live in it?"

In the product model, we don’t start with a feature; we start with a problem. Product leaders identify a strategic objective—perhaps increasing retention or expanding into a new demographic—and then they empower a cross-functional team to find the solution. This team doesn't wait for a PRD. They engage in "Product Discovery."

Discovery is the process of reducing uncertainty. As Cagan notes, the goal of discovery is to provide evidence that a solution is worth building before we ever commit a single line of production code. This is where the "Build to Learn" philosophy takes root. In the project model, you build to "earn" (or at least, you hope you will). In the product model, you realize that you cannot earn until you have learned.

The Evidence: Why the Build Trap is a Death Spiral

To understand why this shift is mandatory, we have to look at the data. In Escaping the Build Trap, Perri highlights that many organizations become so focused on "shipping" that they lose sight of the "value exchange." A company provides value to a customer (by solving a problem), and in return, the customer provides value to the company (usually in the form of money or data).

When you focus solely on output, you break this exchange. You might ship 50 features a year, but if none of them solve a customer’s pain point, your retention will continue to bleed. You are essentially building a bridge to nowhere, but doing it with incredible "Agile" efficiency.

The industry is littered with the corpses of companies that were "fast" but "blind." They mistook movement for progress. Research into high-performing technology organizations (often cited in the DORA reports) shows that the best teams aren't just faster at deploying; they are better at deciding what not to build. They use data-driven decision-making to prune their ideas long before they reach the "Earn" phase.

The Four Horsemen of Product Risk

When we move into the "Build to Learn" phase of the Product Model, we are specifically trying to kill the "Four Horsemen of Product Risk." Every PM should have these tattooed on their inner eyelids:

1. Value Risk: Will the customer buy this or choose to use it?
2. Usability Risk: Can the user figure out how to use it?
3. Feasibility Risk: Can our engineers build this with the time, skills, and technology we have?
4. Viability Risk: Does this solution work for the various aspects of our business (Legal, Sales, Ethics, Finance)?

In the old Project Model, these risks weren't addressed until the end of the cycle. You found out about Usability Risk during the Beta test. You found out about Feasibility Risk when the engineers missed the deadline by six months. You found out about Value Risk when the product launched and… crickets.

In the Product Model, we address these risks upfront. We might build 15 to 20 prototypes a week. This sounds like a lot, but in the age of tools like Figma and Generative AI, it’s actually the most cost-effective way to work. If a prototype fails a value test on Tuesday, you haven't wasted three months of engineering time. You’ve only wasted 24 hours of "Discovery" time. That is a massive ROI.

The Psychology of the Interface: Why "Common Sense" Isn't Common

Humanizing the product means understanding how humans actually work. We often think we are building for rational actors, but as Jon Yablonski details in Laws of UX, we are building for brains that are hardwired with specific biases.

Take Jakob’s Law, for example: "Users spend most of their time on other sites." This means users prefer your site to work the same way as all the other sites they already know. If you are in "Project Mode," you might try to reinvent the wheel to be "innovative." In "Discovery Mode," you test your interface against mental models. You learn that by breaking standard conventions, you are actually increasing the cognitive load on your user, which increases Usability Risk.

In Discovery, we "Build to Learn" about these psychological friction points. We use prototypes to see where users get stuck. We don't guess; we observe. This is the hallmark of a journalist-PM: they don't trust the press release (the PRD); they interview the source (the user) and look for the "why" behind the "what."

The AI Revolution: Collapsing the Cost of Being Wrong

We are currently living through a tectonic shift. For decades, the bottleneck in software was "Delivery." Building things was hard, slow, and expensive. This is why the Project Model felt necessary—we had to plan everything perfectly because we couldn't afford to get it wrong.

But AI has changed the math. Tools like Claude Code and Cursor are making the "Building" part of software almost trivial. The cost of delivery has dropped through the floor.

This is a double-edged sword. If you are in a Feature Factory, AI just makes you a "Turbo-Charged Feature Factory." You can now produce more bad products, faster, than ever before in human history. You can ship 100 useless features a month instead of five.

The real bottleneck has shifted from "Can we build it?" to "Should we build it?" This is why Product Discovery is more critical than ever. AI doesn't just help with delivery; it is a godsend for discovery. We can now create "Live-Data Prototypes"—functional, data-rich simulations of our product—in a fraction of the time. We can put a working model in front of a customer, let them play with it, and see the actual data they generate.

This is the "Build to Learn" sweet spot. We aren't just making pretty pictures in Figma anymore; we are building functional experiments.

Build to Learn vs. Build to Earn: The Great Divergence

Jeff Patton’s distinction is the compass every modern PM needs.

Building to Learn (Discovery): The purpose is knowledge. The artifacts are prototypes. The audience is a small, hand-picked group of users. We don't care about "scale." We don't care if the code is messy. We don't care about internationalization or SOC2 compliance. We care about Value and Usability. We are trying to fail fast and fail cheap. If a prototype breaks, it’s a success, because it taught us something.

Building to Earn (Delivery): The purpose is revenue and reliability. The artifact is a commercial-quality product. The audience is the entire market. Here, we care deeply about everything we ignored in Discovery: performance, security, fault tolerance, accuracy, and privacy. This is where the engineers shine, turning the "validated solution" from Discovery into a robust fortress.

The tragedy of many organizations is that they try to do both at the same time with the same process. They try to "learn" while they are "earning," which usually results in a product that is too buggy to earn and too rigid to learn.

The "Product Sense" Gap: Why Faciliators are Failing

As we move into this golden era of the "Builder PM," many people are struggling. If your entire career has been spent managing JIRA tickets and facilitating meetings, you might feel the ground shifting beneath you.

The reality is that "Facilitator PMs" are a dying breed. When AI can manage a roadmap and summarize a meeting, what is left for the human? The answer is Product Sense.

Product Sense is the ability to look at a mess of conflicting data, user feedback, and technical constraints and say, "The real problem is this, and the most elegant solution is that." It is a blend of market research, data science, and design intuition.

In the book Becoming a Data Head, the authors argue that the most valuable person in the room isn't the one who can run the regression analysis; it's the one who can ask the right question of the data. A PM with high Product Sense uses data not as a drunk uses a lamppost (for support), but as a navigator uses a lighthouse (for direction).

Strategy is Not a To-Do List

Richard Rumelt, in Good Strategy Bad Strategy, makes a devastating point: most "strategies" are just lists of goals or "fluff." A real strategy identifies a challenge and provides a coherent set of actions to overcome it.

In the Project Model, the roadmap is the strategy. But a roadmap is just a list of features. It’s a "Bad Strategy." A "Good Strategy" in the Product Model looks like this: "Our challenge is that users find our onboarding too complex (The Diagnosis). We will focus on a 'Zero-Config' discovery phase (The Guiding Policy) and run 10 parallel experiments to find the most frictionless path (Coherent Action)."

Discovery is the "Science of Strategy." Every prototype is a hypothesis. Every user test is an experiment. We are not "shipping features"; we are "testing hypotheses."

The Parallel Revolution

In the old days, we iterated sequentially. We’d try Approach A, see if it worked, then try Approach B. It was slow.

Today, the top-tier teams work in parallel. Because the cost of prototyping is so low, a PM can work with their team to explore three different ways to solve the same problem at the same time.

Imagine you are trying to improve "Search" on your platform.

• Prototype 1: A traditional keyword-based UI.
• Prototype 2: A natural-language AI interface.
• Prototype 3: A "Recommended for You" feed that eliminates search entirely.

By testing these simultaneously, you aren't just finding a solution; you are finding the optimal solution. You are triangulating the truth.

The Hard Truth: Not Everyone is a Builder

I mentor many PMs, and there is a hard truth we need to address: Not everyone wants to be a builder. Some people like the "Management" part of Product Management more than the "Product" part. They like the status of being "The Decision Maker." They like the order of the Project Model.

If that’s you, the future is going to be difficult. The "Glue PM" who just passes information between departments is being replaced by the "Creator PM" who can hop into a prototyping tool, analyze a dataset, and deeply understand the technical trade-offs of an API.

But for those who love the "Eureka!" moment—those who love the thrill of discovering a solution that actually changes a user's life—this is the best time in history to be in product.

The Path Forward: How to Become a Master of the Product Model

If you are currently trapped in a Feature Factory, how do you escape?

1. Stop Writing PRDs, Start Testing Risks: Instead of a 20-page document, write a one-page "Discovery Plan." What is the biggest risk? How will you test it this week?
2. Fall in Love with the Problem: In Inspired, Cagan emphasizes that the team must be missionaries, not mercenaries. Missionaries are obsessed with the customer’s pain. Mercenaries just want to hit the deadline.
3. Build Your Technical Foundation: You don't need to be a Senior Engineer, but you need to "Speak Tech." Understand the difference between a client-side and a server-side limitation. Understand how LLMs actually work so you can design for their strengths and mitigate their hallucinations.
4. Embrace the "Fail to Learn" Metric: If every one of your experiments "succeeds," you aren't experimenting—you’re just validating your own ego. A healthy discovery process should have a high failure rate.
5. Master the "Live-Data Prototype": Move beyond static mocks. Use no-code tools or AI-assisted coding to build things that actually move and breathe. The feedback you get from a user interacting with real data is 10x more valuable than feedback on a "Click-Through" mock.

The Renaissance of the Skilled Product Person

We are entering a golden era. As the "commodity" work of software development—the literal typing of code and the moving of pixels—is automated, the human element becomes the premium.

The "True Master" of product management is an alchemist. They take the lead of raw data, technical constraints, and customer complaints, and through the rigorous process of "Build to Learn," they transmute it into the gold of a product that customers love and that builds a sustainable business.

The Project Model is a relic of an era of scarcity—an era where we couldn't afford to be wrong. We now live in an era of abundance—where we can't afford not to be wrong, as long as we are wrong quickly and privately in Discovery.

The choice is yours. You can stay in the Feature Factory, polishing the widgets on a sinking ship. Or you can embrace the Product Model, pick up the tools of the builder, and start creating the future.

Just remember: Don't build to earn until you've built to learn. The market is a cruel judge of those who skip their homework.

Evidence-Based Appendix: The Literature of Excellence

This isn't just theory; it’s a synthesis of the industry’s most rigorous thinking. If you want to dive deeper into the evidence supporting this shift, I recommend the following "PM Bible":

• On the "Build Trap": Read Melissa Perri’s Escaping the Build Trap. She provides the framework for moving from output-centric organizations to value-centric ones.
• On Discovery: Marty Cagan’s Inspired and Empowered are the definitive guides on how to structure "Product Discovery" and why the "Feature Team" model is failing.
• On Strategy: Richard Rumelt’s Good Strategy Bad Strategy will teach you how to tell the difference between a real plan and a list of hopes.
• On Human Centricity: Jon Yablonski’s Laws of UX will show you the psychological evidence for why certain designs work and others fail.
• On Technical Fluency: Vinay Trivedi’s How to Speak Tech is essential for the non-technical PM who wants to address "Feasibility Risk" with confidence.
• On Data: Alex Gutman and Jordan Goldmeier’s Becoming a Data Head will give you the statistical literacy to run valid experiments during your "Build to Learn" phase.

The transition from the Project Model to the Product Model is the single greatest lever you have for your career and your company. It is the difference between being a manager of tasks and a creator of value. Welcome to the "Build to Learn" revolution. Let’s get to work.