Beginning with the end in mind
Agile killed Big Design Up Front, and most teams never replaced it with anything. Here is the two-page discipline I ask of every product investment before it starts, with the pivot points that let you change direction, double down, or stop before the money is gone.
Written in 2022 for the product organization I led at the time. Company references removed; the discipline is unchanged.
Most companies moved to agile and did away with Big Design Up Front, and rightly so: it was waste. But in the process they never learned how to begin with the end in mind. Those are not the same thing. Beginning with the end in mind is about maximizing the effectiveness of an investment by starting with an outcome, and with pivot plans, at the right level of detail. The right level is hard to call up front. It becomes apparent as you see what the work touches and sketch what the end should look like.
Why it matters in product management
Simply put: to maximize market impact while reducing uncertainty about the product or feature investment.
The diagram below is the cone of uncertainty, and how the investment grows as the work moves through it. The goal is not to reach the end before finding out whether something is valuable or whether to pivot. The goal is to embed pivot points throughout the investment that let you change direction, enhance along the same direction, or cancel the effort and focus on something else.
Knowing the following before you start reduces uncertainty, leads to better conversations, and makes the case for the work stronger than the one next to it.
What to know before the first sprint
Financial planning and analysis. Look at the expected adoption-rate range against expected cost, price and the other financials. Think about how you gain market share without hurting operating free cash flow, or, if you do hit it, when the product replenishes it. There is more to it than that, but the depth of the financial analysis should match the effort, expense and complexity of the product. Delivering card-present terminals gets an extremely thorough model; a white-label offering may not need as much.
Go-to-market: the initial adoption target. Take the enormous TAM and break it down to who is most likely to adopt on day one, then go talk to them. If you have a named customer working with you during development, the work is far easier to justify and you get feedback throughout the build and through market introduction.
Go-to-market: pricing. Go back to the FP&A work and shape the pricing around how you will actually win adoption. Maybe the product is free to the first ten merchants at a software partner. Maybe you offer buy-now-pay-later terms that cost you some cash flow but win adoption and make the customer happy.
Pivot points. When you begin a piece of work you should hold three possible outcomes in mind:
- Failure (common). The product flops: no adoption, nobody paying. You want to find that out fast so you can move to something worth your time. A product manager who spends as little as possible on something that fails is a success. One who lets it linger for years is not.
- Keep investing, no changes (rare). Most initial targets assume the greatest market adoption ever. Very few products hit high success rates, and fewer still need no adjustment to market or positioning along the way.
- Keep investing, with changes (most common). Most products miss the initial target or deliver partial value, then find their niche once the customer, partner or marketplace has given feedback.
With those three in view, it is essential to embed pivot points using KPIs and customer feedback so you can adjust direction as you go. Target insights, learnings and outcomes instead of deliverables. Use what you learn to make conscious changes along the way, and share that information freely.
Positioning and marketing. Identify where your pilot's target customers discover the products they are willing to pay for and adopt. If the target is healthcare software vendors, where do they shop? Outbound calling (high failure rate for software vendors), LinkedIn, email, paid leads, existing banking relationships?
Operational considerations. What operations have to be in place, how much will the effort increase operational support, and what internal training has to be delivered?
Technical considerations. Will adoption be controlled through feature toggles? Is easy rollback through blue/green deployment needed so the business is never impacted? Does tier-2 support need training?
KPIs. Which indicators will measure the outcomes and drive the pivot decisions, and what will be reported to leadership to keep them informed and reduce their uncertainty?
Customer experience, adoption and delivery. How does this change the overall customer experience, and how do we keep the experience optimal across every product? Are customers more likely to adopt a widget first and an API later?
All of that, and likely something I am forgetting, in two pages. That is the point: enough to begin with the end in mind, not so much that you have designed the whole thing before you have learned anything.
Where it leads
Four years on, this is the shape of the first three phases of the agentic operating model I run now: the initiative carries its business case and ROI from the first draft, epics are cut as measurable chunks of value with an exit after each one, and the KPIs are what move the work forward or stop it. The agents do more of the drafting. The discipline is the same.