Ideas Must Haves

Why Most Ideas Die Before They Start

I spent three years working in product strategy at a mid-size fintech company, and I watched more good ideas get killed by vague documentation than by bad code. The thing that separated ideas that shipped from ideas that vanished into Jira tickets was a simple checklist I started using on a whim. I called it Ideas Must Haves. It wasn't elegant. It worked. The core principle is this: before any idea gets serious attention, it needs five concrete elements documented in one page or less. Not a pitch deck. Not a PRD. A single page. I learned this the hard way after we spent six weeks building a feature nobody asked for because the original idea had never specified who would use it or what problem it solved.

The Ideas Must Haves Framework

Here is what every idea needs to have before it leaves the brainstorm phase. These are the five elements.

1. The Problem Statement (one sentence, no fluff)

This sounds obvious but most teams skip it or write it as a feature wish. "Users want faster checkout" is not a problem statement. "Merchants lose 23% of mobile cart value to checkout friction averaging 4.2 minutes per session" is. The difference matters because it tells you whether you are solving something real or something imaginary. I keep a running list of problem statements from our customer support logs. The best ideas come from reading those, not from executive whiteboard sessions.

2. The Specific User (named, not demographic)

"Not small business owners" is not a user. "Maya, who runs a 12-person e-commerce store on Shopify, checks her dashboard at 6am before her kids wake up, and loses sleep over payment reconciliation errors" is. When you name a real person, you start making different decisions. You stop building for "everyone" and start building for Maya at 6am. I once spent two sprints building a report feature for users who, as it turned out, didn't have permission to access the underlying data. Naming the user catches that early.

3. The Success Metric (number, not adjective)

"Improve user satisfaction" is not a metric. "Reduce time-to-first-transaction from 8 minutes to under 90 seconds for 80% of new signups within 30 days of launch" is. The metric does two things. It tells you when the idea is working. It tells you when to kill it. I have killed more ideas by watching metrics than by any other method. A good metric is specific enough that you can measure it weekly without a data team.

4. The Minimum Viable Scope (what you ship first)

This is where most teams fail. They write a feature list instead of a scope. "The app will include user profiles, social sharing, push notifications, analytics dashboard, and dark mode" is a feature list. "The app lets Maya reconcile her daily payments in under 3 clicks from her phone, with no login required for the first transaction" is a scope. The scope defines the smallest thing that delivers the core value. Everything else is post-launch. I use the "one screen" test: if you can't describe the primary user interaction on one phone screen, the scope is too big.

5. The Kill Condition (when to stop)

This is the element most people omit and regret. "If Maya's reconciliation time doesn't drop below 2 minutes for 60% of test users within 4 weeks, we shelve the idea and revisit in Q3" is a kill condition. It sounds pessimistic but it saves months of sunk cost. I have seen teams spend 8 months on ideas that failed their own success metric because nobody wrote down what failure looked like upfront. Writing the kill condition makes it easier to pull the plug when the data says so.

How I Actually Use This in Practice

I keep a shared doc called "The Must Haves Queue." Every idea goes in there with all five elements filled out. If any element is blank, the idea stays in the queue and nobody works on it. This is not a suggestion box. This is a gate. We get maybe 3 to 5 ideas per month through this gate. The rest die in the queue, and that is fine. Most of them were never good enough to pass the test. The process takes about 20 minutes per idea. A product manager fills it out, a designer reviews it for the user specificity, and we discuss it in a 15-minute standing meeting. If all five elements are solid, the idea moves to the backlog. If not, we send it back with specific gaps noted. Nobody argues with the framework because the framework is not opinion-based. Either you have named Maya or you have not. I started tracking this after we shipped our first proper product in year two. Before that, we had no system and we shipped nothing useful for 18 months. After implementing the Must Haves process, we shipped our first real feature in 6 weeks and our second in 9. The quality was lower than what we would have aimed for with unlimited planning, but the speed was 10 times faster. That tradeoff was worth it.

A Real Edge Case I Ran Into

Last year we had an idea that passed all five elements perfectly. The problem was clear, the user was named, the metric was specific, the scope was tight, and the kill condition was written. We shipped it. It hit 40% of the target metric in week one. By week three, we were at 12%. The kill condition said we should shelve it at 20%. We didn't. We kept going for another month, convinced we were close. We were not close. We lost another 4 weeks and about $80,000 in engineering time. The workaround I built after that was a "metric trajectory" check. Before any idea hits the kill threshold, we plot the weekly metric against a linear trajectory to the target. If the line is flat or declining, we kill immediately regardless of how close we think we are. Human optimism is a known variable. The trajectory check removes it. Since adding that guardrail six months ago, we have killed 3 ideas at the right time instead of clinging to them.

When This Framework Breaks

Ideas Must Haves does not work for exploratory research. If you are doing discovery work where the point is to learn rather than to ship, forcing a kill condition or a specific metric upfront defeats the purpose. I use a separate "Research Log" for those ideas where the only requirement is a question and a date. It also struggles with platform-level ideas that need ecosystem buy-in before they can succeed. A payment standard that requires three other companies to adopt it before it has value cannot be measured by a single user metric. For those, I add a sixth element: "The Dependency Map." Who else needs to ship first? What do they need from us? How long does that typically take? This adds about 10 minutes to the documentation but prevents the common mistake of building in isolation. The biggest limitation is that the framework favors incremental ideas over radical ones. Maya at 6am is a real person with a real problem. She is also a person who probably cannot imagine a solution she has never seen. Some of the best ideas in history came from people who solved problems their users did not know they had. I accept this tradeoff. We are not trying to build the next iPhone. We are trying to ship useful features without wasting a year on dead ends. For that purpose, the framework is accurate about 85% of the time.

Getting Started With Ideas Must Haves

You do not need special software. A shared Google Doc or Notion page with five columns is enough. I recommend starting with a template that has the five headers pre-filled and a note at the top saying "If any column is blank, this idea is not ready." That note alone changes how people submit ideas. They self-edit before they ask you to review it. We have been running this for 14 months now. We have processed about 47 ideas through the gate. 12 shipped. 8 are still in development. 27 died in the queue or were killed mid-flight. The 12 that shipped generated roughly 3.2x the ROI of the ideas we would have built without the framework, based on engineering hours spent per feature. That number is rough but directionally correct. The framework does not make good ideas. It filters out bad ones fast enough that the good ones get the attention they deserve. I still use a paper notebook alongside the digital queue for ideas that feel too fragile to put through the gate yet. Some ideas need to sit for a while and mature. The digital framework is for ideas that are ready to be tested. The notebook is for ideas that are ready to be waited on. Both have their place.