(for) Headless Chickens
There’s a particular kind of kitchen you don’t want to work in. You know the one. The orders are piling up, the head chef’s shouting, the sous is panicking, and nobody’s quite sure if that plate of ravioli went to table six or table seven. So they just keep cooking. Faster. Sloppier. Throw another sprig of parsley on it and pray nobody sends it back.
That’s how a lot of product teams can end up working. One of the strangest parts of working in service/product is how quickly the mood shifts from “this is a smart team making deliberate bets” to “we are frantically taping wings onto a toaster because someone said it needs to fly by Q3.” The pressure arrives fast, and usually from the top. And even the best teams get swept up. Suddenly, there’s no time for the boring stuff — like asking why we’re building something in the first place.
The excuse is always some flavor of efficiency. “We don’t have time to build a case for this.” “We’ll learn as we ship.” “Let’s not overthink it.” And, sure, sometimes shipping fast is the right move. But most of the time, skipping the hard thinking up front is just a really clever way of creating rework, tech debt, Frankenstein features, and UX that starts decaying before it ever really lives.
The irony? It usually takes less than 30 minutes with your team to build enough of a business case to stop yourself from driving off the nearest cliff. I’m not talking about some 80-page, MBA-flavored slide deck that gets paraded around at All Hands. I mean a simple, honest exercise:
- What’s the problem?
- Who cares?
- What will happen if we do this?
- What will happen if we don’t?
That’s it. In half an hour, you’ve gone from flailing around to having a clear rationale. And with that comes the real gold: measurability.
- You know what you’re aiming for.
- You know what success should look like.
- You know what warning signs to watch for.
- And your leadership gets an actual sense of how bad (or good) this thing might turn out.
I think good product owners always offer a calculated fighting chance to see if things are actually working. The fastest way to do that is to have a clear, measurable, upfront articulation of why you’re building anything at all.
Here’s a simple checklist I’ve used with teams over time — not as a bureaucratic hoop to jump through, but as a quick sense check to get everyone aligned before any real effort gets spent. Whether you’re building a feature, a new journey, or a tiny tweak, this will save you from yourself:
| Section | Why This Matters | Who Can Help | Key Data to Gather | Questions to Ask | Example of ‘Good’ |
|---|---|---|---|---|---|
| 1. Problem Definition | If you can’t clearly say what problem you’re solving, you’re probably solving nothing. Anchors the entire effort. | Product Manager, Service Designer, User Researcher, Support Lead, Sales | User complaints, support tickets, churn data, NPS feedback | What is frustrating users? What’s costing us revenue? Is this a burning problem? | “Churn rate increased 15% after we changed onboarding. 40% of users cite confusion during setup.” |
| 2. Opportunity Sizing | Quantifies the potential impact — revenue, cost savings, or strategic leverage. Helps prioritize vs other work. | Product Analyst, Finance, Marketing, Strategy | TAM/SAM/SOM estimates, revenue models, competitive benchmarks | What’s the upside? How many users are affected? What happens if we don’t fix this? | “Improving onboarding could convert 20k new users annually, worth $2M ARR.” |
| 3. User Research & Insights | Grounds the work in lived user experience — prevents building in a vacuum. | UX Researcher, Customer Success, Designers | Interview transcripts, usability tests, customer interviews | What’s the user’s actual experience today? What do they expect? | “5/7 users failed to complete setup without customer support intervention.” |
| 4. Data & Analytics | Turns gut instinct into measurable evidence. Adds credibility to the case. | Data Analyst, Product Analyst, BI | Funnel drop-offs, time-on-task, conversion rates, support load | What are users doing today? Where are they dropping off? | “Current signup funnel has 60% drop-off at the payment screen.” |
| 5. Proposed Solution(s) | Forces clarity on what exactly you’re proposing. Useful for scope alignment. | Product Manager, Designer, Architect, Tech Lead | Mockups, flows, prototypes, feature descriptions | What does this solution actually do? What else did we consider? | “We propose a simplified 3-step onboarding with guided tooltips, replacing 6 steps.” |
| 6. Value vs Effort Analysis | Ensures you’re not spending $1M to save $100k. Balances ambition with feasibility. | Engineering, PM, Architects, Delivery Manager | Dev estimates, sprint forecasts, capacity planning | How hard is this to build? What trade-offs are involved? | “2 sprints delivery effort for a $500k projected annual ROI.” |
| 7. Risks & Assumptions | Surfaces unknowns early before they become expensive surprises. | Legal, Compliance, Security, Tech Lead | Legal reviews, architectural assessments, privacy impact assessments | What could go wrong? What unknowns exist? Can we test assumptions? | “Assumption: 80% of users will adopt new flow. Will validate with A/B pilot.” |
| 8. Commercial / Business Model | Ensures financial implications are understood. Helps leadership frame ROI. | Finance, Pricing, Sales, Revenue Ops | Pricing models, margin impact, new revenue streams | How does this affect revenue, costs, pricing? Is there a commercial lever? | “New feature creates potential $10/user upsell on premium plan.” |
| 9. Stakeholder Alignment | Identifies who needs to be involved, avoids last-minute blockers. | PMO, Legal, Marketing, Ops, Compliance | Stakeholder maps, sign-off trackers | Who needs to sign off? Who might block? Who benefits? | “Support, legal, and marketing reviewed and approved scope prior to build.” |
| 10. Timeline & Phasing | Sets realistic expectations and staging. Avoids “big bang” failures. | Delivery Manager, PM, Engineering Lead | Roadmaps, sprint plans, release plans | What can we ship first? What’s MVP vs full build? | “Phase 1: soft launch to 5% of users in Q3, full rollout Q4.” |
| 11. Success Metrics & Measurement | Turns vague hope into testable outcomes. Defines what “good” looks like. | Product Analytics, Data Science, PM | KPIs, OKRs, dashboards | How will we measure success? What’s failure? | “Target: increase onboarding completion from 60% to 80% within 90 days.” |
| 12. Recommendation & Ask | Creates a clear decision point. Leadership knows exactly what’s being requested. | PM, Leadership Sponsor, Finance | Business case summary | What decision are we asking for? What support/resources are needed? | “Requesting approval for 2 sprint allocation and $50k marketing support budget.” |
How to Use This Checklist
This checklist is – ideally – a tool, built from hard-won experience of watching teams move fast, trip hard, and wonder later why they didn’t pause for 30 minutes up front. Use it as a quick sense check whenever you’re about to build something new, tweak an existing flow, or greenlight a new idea.
At its simplest:
- Scan the table.
- See what you have, and what’s missing.
- Prioritize gathering just enough to build confidence.
I’ve also also run it as a rapid workshop. Grab your product trio (PM, Design, Eng), pull in whoever owns data, research, or operations, and work through each section. You won’t fill every box — and you don’t need to. The value is in the conversations it triggers. The gaps you spot are as important as the fields you complete.
In reality: most teams don’t have perfect data sitting neatly on the shelf. That’s okay. The goal isn’t to become paralyzed chasing every data point. The goal is to anchor your rationale in whatever real-world signals you can find today.
- If you’ve got support tickets? Use them.
- If you’ve got user interviews? Perfect.
- If you’ve got only gut instinct? Call it out — and treat it like a hypothesis that needs testing.
Watch for patterns in your gaps.
If you consistently find there’s never any support ticket data, or you’re always flying blind on funnel drop-off rates, that’s not just an empty cell — it’s a signal. It means you’ve likely got a wider data hygiene problem that’s worth investing in. The checklist helps you catch those systemic blind spots early.
At its core, this is first principles work.
It’s about slowing down — briefly — to make sure everyone involved can answer the most important question:
“Why are we doing this?”
And better yet, “Why do we believe it’s worth doing?”
Because when you tie your work to real evidence, real users, and real outcomes, you’re not just shipping features — you’re making better decisions. And that’s what separates durable products from feature graveyards.
Bonus tip:
Start a simple folder where you drop every one of these mini business cases. Over time, you’ll build a living archive of the decisions your team has made. It becomes a goldmine for learning: what bets paid off, what flopped, and where your instincts proved right or wrong. It’s also a quiet but powerful artifact of your product leadership — proof that you’re not just building, you’re thinking
Final Thought
That’s how I approach it. But I’m curious — how do you do it?
Do you already have a business case muscle in your team? What’s worked for you? What always seems to trip you up?
Drop me a message if you want to swap notes, trade war stories, or kick around ideas on how to make this faster, better, and more useful in the real world. Always up for a good chat 🙂
Amogh's Field Manual 