Escaping the Build Trap: How Effective Product Management Creates Real Value

By Melissa Perri

11 min read

Why does it matter? Because shipping faster doesn't fix building the wrong thing.

Picture the quarterly planning meeting you've sat through a dozen times: three hours of debate over which features make the roadmap, which slip to Q3, whether the dashboard or the notification redesign takes priority. Everyone leaves with a Gantt chart and a commitment. Nobody stops to ask whether any of it will change what customers actually do. That's not a scheduling problem or a stakeholder problem — it's a structural one. Your organization has been quietly optimized to produce features on schedule instead of outcomes on purpose, and your instinct to plan better, prioritize harder, and ship faster is exactly what keeps the machine running. Most of them are spending almost no time on the work that determines whether anything they build is worth building at all. This book is about reclaiming it.

You Probably Have a Product Owner Job With a Product Manager Title

How much of your week do you spend in discovery — talking to customers, testing assumptions, questioning whether a problem is even worth solving — versus in delivery mode, writing specs, running ceremonies, and moving tickets through the board?

If the honest answer tilts toward delivery, you might have a product owner job with a product manager title, and that gap explains why teams ship things nobody uses.

A product owner keeps the engineering pipeline fed and moving: requirements written, backlog ordered, ceremonies running. That's a delivery job. A product manager's job starts upstream (discovering customer pain points, analyzing competitors, setting strategy, defining a roadmap) and only acts as product owner once there's something worth building. Scrum formalizes this distinction. One role assumes the right problems are already known; the other goes looking for them.

Most organizations have quietly collapsed these two roles into one while keeping the PM title. The numbers make the problem concrete: the average PM spends less than 20% of their time on discovery and more than 80% on delivery. That inversion isn't an accident. It's the natural output of a delivery-optimized system, and the result is predictable: features that seemed justified in planning land quietly in production, used by almost no one.

Running that pipeline is a full-time job. It crowds out the upstream work. Discovery leaves no sprint artifact. Shipping a feature does. So organizations optimize for what they can see, and discovery disappears.

The question worth asking isn't whether you have the right title. It's whether anyone at your company owns the upstream work: identifying which problems are worth solving, validating whether a proposed solution will actually address them, understanding what competitors are doing. If that answer is unclear, discovery probably isn't happening. Nobody made a decision to stop doing discovery. The system just stopped making room for it.

A Vision Nobody Uses to Reject a Feature Request Is Just a Slide in a Deck

A budget that nobody checks before a purchase goes through isn't a budget — it's a spreadsheet. The same logic applies to your product vision.

Most teams treat vision as an aspirational statement: something to craft carefully, present at an all-hands, and then leave in a slide deck. But there's a simpler test of whether a vision is functioning: can someone invoke it in a meeting to say no? If a stakeholder asks for a new dashboard and the vision has nothing to say, if nobody even reaches for it, the vision isn't directing anything. It's ambient decoration.

Among the qualities of a compelling product vision, "focusing" is listed last but matters most in practice. A focusing vision gives teams a specific question for when requests arrive: how would this feature bring us closer to what we're trying to achieve? That question is a veto mechanism. If a feature can't answer it, it shouldn't move forward. A vision that can't reject a bad idea in a meeting has no power, regardless of how well-worded it is.

Three questions make this diagnostic concrete: Does everyone on the team know the vision? Do they all understand it the same way? Is it ambitious enough to generate sustained daily effort? Most organizations fail at least one. When people carry different interpretations of the same vision statement, it can't arbitrate anything — it becomes a Rorschach test that confirms whatever the speaker already wanted to do.

The same logic extends to strategy. Gibson Biddle, former VP of Product at Netflix, offers a three-part test for whether a strategic bet is defensible: does it delight customers, is it hard to copy, and does it improve margin? A streaming service investing in offline downloads satisfies all three: it's a genuine experience improvement, replication requires expensive licensing and infrastructure, and it reduces churn. Proposing a social feed satisfies none; anyone can copy it, it adds complexity rather than cutting cost, and it doesn't improve unit economics. A strategy hitting two of those three is doing real work. One hitting none is a preference dressed up in slides.

Vision and strategy are different artifacts, but they have the same job: saying no on your behalf. If they can't do that in a meeting, what you ran was planning theater.

The Feature Roadmap Is a Contract to Build the Wrong Things on Schedule

The feature roadmap with dates is not a planning tool — it's a promise-generating machine, and what it promises is almost always wrong.

Here's what happens when you put features and deadlines on a timeline: stakeholders read the dates as commitments. Engineers calibrate their work to hit them. PMs spend the quarter defending the schedule rather than questioning whether any of those features should be built at all. By the time the due date arrives, the team has delivered exactly what was planned and discovered, often quietly, that it wasn't what users needed. The roadmap worked perfectly. The product didn't.

The problem is structural, not motivational. A timeline forces you to commit to specific outputs at the moment when your confidence in those outputs is lowest — before discovery, before validation, before you've learned anything. You're writing checks against knowledge you don't yet have.

The alternative is a theme-based roadmap. 'Reduce checkout friction' and 'close the retention gap at week two' are themes: user or business problems you intend to solve in service of your current objectives, your OKR translated into a direction. Under each theme sit initiatives, specific opportunities to address that problem. An initiative early in its life might be a discovery question ('how might we validate whether users actually want this?') rather than a delivery commitment, which keeps the roadmap honest about what's known. You're not promising to ship a feature you haven't validated; you're committing to learn something.

Instead of dates, initiatives live in one of three time buckets: Now (being worked on in the next one to three sprints), Next (up within roughly three months), Later (on the radar but not committed). When a stakeholder asks when something will be ready, the answer is a bucket, not a date: 'We're in the Next bucket on that; once we finish the two initiatives currently in Now, it moves up.' That shift alone removes a whole category of stakeholder misalignment from your calendar.

Prioritizing what goes where requires the ICE formula: Impact times Ease times Confidence. Itamar Gilad, former product director at Google, points out that practitioners routinely overestimate impact and underestimate effort, so your initial scores are probably optimistic. The formula's real function isn't to produce an accurate number; it's to create a defensible reason to say no to most initiatives. Before you allocate anything to the roadmap, subtract at least 20% of engineering capacity for maintenance, bugs, and the unexpected work that always materializes. Teams that plan to 100% capacity don't ship what they planned. They just disappoint stakeholders more officially.

What you get is a roadmap that tells everyone what problems the team is solving and why, without painting a target on every release date. The conversation with stakeholders shifts from 'why is feature X late?' to 'are we solving the right problems?' That's the only question a product roadmap should ever be answering.

OKRs That Name Features Are Just Roadmaps With a Quarterly Expiration Date

If your OKR for next quarter reads "launch the premium onboarding flow," what have you actually committed to? A feature. You've named a solution before anyone has validated it will move any needle. That's not a goal — it's a delivery ticket with an expiration date.

Product strategist Tom Lombardo draws the line cleanly: an output is a concrete deliverable; an outcome is a measurable change in the world. "Launch premium onboarding flow" is an output. "Get 10% of existing free users to upgrade to paid accounts" is an outcome. Both live in your quarterly OKR document, which is why they look identical, but they operate completely differently. The output closes the question of what to build before your team has done any discovery. The outcome leaves it open: the team still has to figure out which solution gets 10% of free users to convert, so discovery stays alive inside the goal itself.

It's the same trap operating one layer up — premature commitment to solutions, now dressed as quarterly accountability. A feature-based OKR is just a roadmap with a quarterly expiration date.

The practical rule: write key results that describe user behavior you want to change, not artifacts you plan to ship. If you can complete the key result without learning anything about your users, it's an output. Limit yourself to three goals per team per quarter; more than that and you're not focusing, you're listing. Aim to hit 70 to 80 percent of them; consistent perfect scores mean the goals weren't challenging enough.

Once you know what behavior you're trying to move, you still have to understand the person you're trying to move it in.

Never Ask Users What They Would Do — Ask What They Actually Did Yesterday

Imagine a doctor who, instead of asking what you ate this week, asks what you plan to eat next week. The patient describes balanced meals, reasonable portions, plenty of vegetables. The doctor nods, pronounces them healthy, and sends them home. That conversation produced no medical information, only intentions, optimistic by design and shaped by whatever the patient thinks the doctor wants to hear.

Most user interviews work exactly this way.

The clearest demonstration is almost embarrassingly simple. Ask someone whether they'll eat a healthy breakfast tomorrow and they'll say yes. Ask what they ate for breakfast this morning and you might hear: cold pizza. The gap between those two answers isn't dishonesty; it's the predictable failure mode of asking people to forecast their own behavior. Future-tense questions produce aspirational answers. Past-tense questions produce evidence.

That's why "would you use this product?" is banned from good user interviews entirely. Not because users lie when they say yes. They're genuinely trying to be helpful — that's the problem. Helpfulness produces data that looks like validation and functions as noise. The right question asks about something that already happened: "Tell me about the last time you tried to solve this problem. What did you do?"

Once you've asked the right question, the next trap is contaminating the answer before it arrives. Most interviewers do this without noticing — a nod, an encouraging "great," a sympathetic "yeah, I get that." Each of those signals shapes whatever comes next. The mirror technique is the antidote: when a user answers, repeat the last thing they said, exactly. User: "I just stopped using it after the first week." You: "So you stopped after the first week." Pause. No warmth, no approval, no judgment. It sounds mechanical and works because silence and repetition leave the user's next thought uncontaminated by yours.

There's a third move worth having ready. When someone says "I always do X" (always check my email first, always compare prices before buying), don't move on. Ask: "Can you describe the last time you did that?" The word "always" is a generalization, and generalizations are unreliable. What you need is the specific incident: where they were, what happened, what they actually chose. Specific recalled events are harder to confabulate than stated patterns, and the gap between "I always compare prices" and "last Tuesday I just bought the first thing I found" is often where the real product insight lives. From there, asking why, then asking why again, is how you get from the symptom to the root problem.

Three instruments: past-tense questions, mirror technique, "describe the last time." None require special training. All require discipline, which turns out to be the harder part.

An Experiment That Can't Kill the Idea Isn't Validation — It's Theater

Most teams design experiments to feel good about a decision they've already made. They run a usability test with five friendly users, get warm feedback, and call it validated. But a test that can't produce a "stop building this" result isn't validation. It's permission theater.

The tell is simple: if no realistic outcome would lead your team to drop the idea, the experiment is a ritual confirmation, not a real test. Meaningful validation requires specifying, before you run anything, what a negative result looks like and what you'd do about it. If you can't answer that, you're not testing a hypothesis; you're collecting ammunition for a decision you've already made.

Before you design anything, three questions force you to be honest about what you're actually testing. What kind of hypothesis is this: qualitative (why do users behave this way?) or quantitative (how many would actually pay?)? Conflating them produces expensive usability studies for demand questions and large surveys for behavioral ones. How much uncertainty exists? High uncertainty means cheap, fast experiments first: something that burns a day, not a sprint. You want directional evidence before committing real resources. And when is the next decision milestone? An experiment that finishes after the gate produces information nobody can act on.

The backoffice validation technique shows what a genuinely falsifiable experiment looks like. Your sales team calls existing customers and describes a hypothetical future product on the call — no prototype, no engineering, no demo. If it resonates, customers engage. If it doesn't, they don't. A flat response kills the idea without a single line of code written. Compare that to building a click dummy, running users through it, and proceeding anyway because the feedback was "mixed but promising." That's how teams protect ideas they love from evidence that might threaten them.

When the data comes back negative, stop. Not pivot slightly, not reframe the hypothesis, not run one more test with a friendlier segment. Drop the idea entirely and investigate something new. Stopping at validation is the success state: you saved months of building something users don't want. That's not failure. The experiment worked perfectly — it just happened to tell you no.

Shipping a Validated Feature Is Not the End — It's When the Real Hypothesis Begins

When a feature ships and the early numbers look good, what's left to do? The natural answer: move on. The idea worked, the team delivered, the backlog has new items. But Cagan calls this one of product management's deepest errors — the second inconvenient truth (the first: most ideas don't work at all).

Even when an idea proves valuable, usable, and technically feasible, it typically takes several more iterations before the implementation actually delivers the expected business value. The first release confirms the idea has merit. It doesn't confirm that your particular execution of that idea works well enough to matter.

Shipping is the beginning of a different kind of learning. A first release is the first moment you have real users generating real behavior instead of simulated behavior in a prototype. The data from actual use is categorically different from anything you gathered in discovery — acting on it isn't a sign that discovery failed. It's the mechanism.

Henrik Kniberg, Spotify's former engineering coach, offers a vocabulary shift: call your first release the "earliest usable product," not a finished MVP. The name signals what it actually is — the opening move in a learning loop, not a completed deliverable. Notion is a useful illustration: it shipped in 2016, struggled to explain what it was, relaunched in 2018, and only found its audience after several interface iterations. The initial idea was sound; the execution needed time to catch up.

The delivery principles that follow are empirical: treat each release as a test of whether this specific version solves the problem, cut what isn't working, and break large features into smaller releases so each carries a testable assumption. You're not iterating because something went wrong. You're iterating because that's how good ideas become great products.

The 20% That Changes Everything

That 20% number is worth sitting with one more time: less than 20% on discovery, more than 80% on delivery. The question isn't how to invert it. It's why your calendar looks that way at all, and whose interests are served by keeping it there. Every stakeholder update, every sprint review measuring success in shipped features, every deadline that makes discovery feel irresponsible — those aren't personal failures. They're a system working exactly as designed.

That's what the whole framework is actually for: not a better planning ceremony, but a vocabulary for finally naming what's happening and why. Once you have OKRs that measure behavior not outputs, roadmaps built around problems not features, and experiments designed to kill ideas not confirm them, iteration stops feeling like failure and starts feeling like the mechanism it always was. You're not escaping the build trap by working harder. You're escaping it by finally being able to see it.