Why Good Product Ideas Don’t Survive

Good product ideas, ones that create significant value for the business and the users, are rare and precious things. Look at your product and you’ll immediately recognize them. These are the features that are used the most, that drive conversions, that keep your customers onboard. Think Google Search Suggestions, Amazon shopping cart recommendations, or Snapchat Stories.

But the odds of finding such an idea are quite low. A/B-test research shows that the vast majority of ideas deliver little or no value; some even detract value. Analyze feature usage in your product and look at past roadmaps, and you’ll see a clear power law — a small minority of your ideas create significant impact. The reason is simple: in most products most low-hanging fruit have already been picked. The odds of coming up with something novel and truly good are quite slim.

So here’s the key question: is your product process designed to find and cultivate these rare good ideas?

In this article I’ll compare the traditional launch-and-iterate model with the modern evidence-guided development approach and try to calculate the odds of a good idea surviving both.

Classic Launch and Iterate

In this model an idea goes through three phases: prioritization, specification, and implementation (there’s also a fourth – go-to-market that is important, but is not covered here as it’s outside the scope of most product teams).

Let’s imagine you came up with a truly high-impact idea. What are the odds it will survive this pipeline?

1. Prioritization

Your idea enters the prioritization phase with other competing ideas during a planning cycle. As the company wishes to build a roadmap, ”prioritization” means a set of binary decisions — a small minority of ideas are approved to be built in full, while most are parked or killed.

What does it take for our idea to win in the prioritization death match? Depending on the company and the process, it may involve bringing some supporting data, presenting compelling arguments, or creating a pitch deck. The decisions are typically made by managers, committees, and in some companies, the team. They are usually based on consensus, opinions and rank.

Prioritization relies heavily on our ability to discern good ideas from bad. Experience, intuition, and logic play a central role. However, the question “which of these 20 ideas will best achieve the goals” is a very complex one, and often there’s not enough information to answer it. Our brains are definitely not designed to deal with so much uncertainty, and we’re likely to subconsciously revert to mental shortcuts and heuristics to lighten the cognitive burden — risk aversion, halo effects, groupthink and many more. Some of the best ideas are novel, counterintuitive, or unimpressive, so they may not do well here.

Politics is another determining factor. Your idea, good as it may be, needs to compete with the pet projects of executives, with customer requests, with Sales’ “deal-closing” demands, and with team-favorite initiatives. So the prioritization game is somewhat political: whom do you gratify, whom do you disappoint, and who you simply can’t say no to. Many good ideas die just because they don’t have the right backer.

This is very speculative, but I’d estimate that the odds of survival of a good idea during prioritization are at best 20%.

Specification

Now the product manager and designer need to specify how the new idea should behave and look. Managers, stakeholders, and team are likely to be consulted, and they may expect to review the mockups and requirements before signing off. Everyone will have their opinions (with full conviction) about scope, implementation, and timeline. The spec and design will be adjusted based on this feedback.

The implementation of a product idea involves many decisions — there are many different ways to implement the same core idea — but only a small subset of those will be valuable, usable, feasible, and business-viable (Cagan’s four risks). It’s enough to take a wrong turn in the user interface or to remove a key capability for the idea to lose a lot of its impact.

Does the process of decision-by-committee help surface the best implementations? Sadly no. While the review process may surface bad assumptions and design flaws, it can also lead to bad product decisions or a mediocre compromise. The best version of an idea can be unintuitive (consider for example the surprising success of Claude Code with its command-line interface and local markdown files with non-developers). The people taking part in the discussion are rarely true representatives of the target audience and they can’t really predict which versions of the idea will work and which won’t.

Conservatively I’d say that the chances that a good idea stays valuable during the specification phase are at best 40%.

Implementation

Now it’s time to implement or “deliver” the new idea. The team is meeting bi-weekly to scope out the next sprint. The PM is tasked with providing prioritized backlogs and detailed user stories or PRDs. The iterative nature of the work means that the team has many opportunities to test the implementation and course-correct, but sadly almost none of these sprints ends in an experiment. The emphasis is on making progress and delivering the new thing as fast as possible.

You would think our idea is immune from harm during this time, but that’s not necessarily the case. If the project runs long (which is quite common) there may be pressure to cut scope. Do we cut the least-valuable parts of the feature? No, we cut the parts the team hasn’t gotten to implement yet. So the new idea can come out severely crippled from the implementation phase.

But even these ideas are somewhat lucky. Others fall victim to changing priorities or the whims of managers who push to change scope and requirements. The team may miss the intent and context and develop something that misses the mark. Some ideas are simply de-prioritized and canceled mid-project.

Chances of coming out intact out of implementation: 50%

Post-Launch-Iteration

This is supposed to be redeeming part of the process. Here, finally we have a feedback loop with the customers that allows us to learn and improve the feature. That’s the theory, but sadly is rarely fully practiced.

While some companies and teams are willing to take a hard, critical look at the results and iterate on the idea in major ways, most companies just don’t operate this way. The launch may have been celebrated as a success, so challenging its impact is politically risky. Many teams don’t have the instrumentation, data system, or qualitative feedback loops needed to assess how the idea is doing. In many cases, the roadmap allocates no time for post-launch iteration, so the team is expected to immediately switch over to the next project. Some iteration may naturally occur over time through redesigns and bug fixes, but that’s a very slow process and most ideas will never get the attention they deserve.

What percentage of good ideas are improved on to maximize their value? My most generous guess is 10%. Mind you, this number applies only to those ideas that survived elimination during prioritization and specification, and that can be recovered. In practice that’s usually a miniscule number.

The Odds of a Good Idea Surviving

So if we calculate the odds:

20% x 40% x 50% = 4%

Let’s say that through iteration we get another 1% recovered ideas, for a total of 5%.

This number doesn’t mean only 5% of ideas create value. It means that only 5% (1 in 20) of truly high-value ideas will survive the process of launch-and-iterate and manifest their full potential.

You may say that this is an overly pessimistic estimate. Let’s say that your company has 4 times the success rate, or 20%. That still means that only 1 in 5 good ideas (which, to remind you, are very rare) will launch with its full impact. This is still a dismal success rate that explains why you’re mostly launching humdrum changes that don’t make much of a difference.

1a. Launch-and-Iterate with AI

Is AI radically changing the picture? It’s too early to say, but from what I’m seeing thus far the answer is No — the product development process hasn’t changed. AI is seen as a way to “boost productivity” — more PRDs, user stories, designs, lines of code, and PRs, faster (I call this outputmaxing). In other words, AI is used to accelerate the feature factory rather than make it smarter.

There is some good news here because more ideas may be permitted to go through and end in the product, including the odd high-impact idea. But as we haven’t changed the system, the added impact may be drowned by the sea of meiocore and bad ideas the company is producing. Product bloat, user confusion, and maintenance overhead are all going to rise.

AI is causing another change — it is now a new participant in the prioritization, design, and specification discussions. It’s still unclear if for a good idea this is going to be an improvement or a detriment. Will AI help us detect good ideas and extract their full potential, or will it cause us to produce mediocre versions that are based on common wisdom? To riff on an old saying, a tool is only as good as the process in which it’s used.

2. Evidence-Guided Development

I will keep this one short, simply because I’ve written so much about this topic in the past (including an entire book). But I do want to highlight how this process is designed to combat all the shortcomings I mentioned above.

Evaluation

There is still a prioritization phase, but I like to call it Evaluation. It’s different in a few fundamental ways:

• We try to use objective and well structured prioritization methods (for example ICE) that accept people’s opinions as inputs, but counterbalance them with evidence, including research data and experiment results
• Instead of making a build-vs-kill decision, we’re trying just to assess which ideas we want to test and which we want to park. Idea testing (aka validation) is far cheaper, so many more ideas can pass this phase.
• Unlike prioritization, evaluation is not a one-time process. Every time we gain new evidence pertaining to an idea, we re-evaluate it and decide whether to change or park the idea.

Evaluation is not a bullet-proof process, and we may end up parking a good idea. Still, because of the changes described above survival rates of good ideas ought to be very high, say 90%+.

Validation

During the validation phase we test the assumptions underlying the idea in a variety of ways from cheap assessments and data lookups to full A/B tests and partial launches, as depicted in the AFTER model shown below.

Validation helps us in multiple ways:

• Generates a stream of evidence that allows us to re-evaluate ideas, park or pivot those that don’t work, and double-down on those that do. In essence, evaluation + validation create a build-measure-learn loop.
• An idea will typically go through multiple validation phases, up to the point where we feel confident enough to push it to the delivery. This gives us a chance to improve the idea and maximize its potential — we’re iterating prior to the launch. That’s why there’s no separate “specification” phase in the evidence-guided model — we learn what the true requirements are as we go along.

Product idea validation is not a hard science. There’s a definite chance for false negatives — good ideas failing the tests. Assuming you’re not rushing it, and that you use the right practices, I would put the survival rate of good ideas at 80%+

Delivery

The delivery phase, in which we build the product idea in full to the point it’s ready to launch, is on the surface no different between the traditional process and the modern one. But there are some critical changes:

• Because the idea has already been tested and validated, it’s less likely to be subject to the whims of re-planning and last-minute scope changes. Evidence can be a very good defence against those disruptive forces.
• The scope and functionality are much clearer to the team because it took part in the discovery phase (and likely had a hand in shaping the product), so the chances of the devs delivering something that misses the mark are far lower (even with much lighter specification).
• During the discovery phase we get a better estimate of how complicated the implementation is going to be, so the chances of the project significantly running over are slimmer.

We can still manage to fudge an otherwise good idea during delivery, but I would set the odds of the idea coming out good at 90%+.

Iteration

Not depicted in the diagram above, but post-lanch iteration is part of this process too, and in my experience, is more likely to occur in teams that know how to evaluate and validate ideas based on evidence. So the chances of a good idea maximizing its potential through iteration are also much higher: 30%

Odds of a Good Idea Surviving

% of good ideas that launched with high value: 90% x 80% x 90% = 72%
Additional % of good ideas recovered through iteration (guesstimate): 10%

So overall, I’m estimating that roughly 8 out of 10 good ideas will survive the process and will manifest their full value. Still not perfect, but far better than the classic launch-and-iterate process.

There’s a secondary, but very important effect to note. The evidence-guided process not only surfaces and boosts good ideas, it also filters out mediocre and bad one. That’s a massive benefit to your product, business, and users that is often disregarded.

2a. Evidence-Guided Development with AI

As with launch-and-iterate, AI hasn’t significantly changed this model. But I see it having a very positive impact in one area — adoption. Proper Evaluation and Validation are not easy and require a willingness and ability to evaluate ideas, map assumptions, conduct experiments, analyze the results, and take action based on the evidence. These are new skills for many companies, and they also require culture changes. As I wrote in the past, I see AI as a major opportunity to reduce adoption friction and cognitive load, which means companies will be able to adopt the new model quicker and more effectively. I see very promising signs, including a host of new AI-based tools that introduce evidence-guided development into product orgs.

Bottom Line

There’s a clear Pareto distribution among your product ideas: 90% of the outcomes come from 10% of your ideas. Some companies are good at finding and cultivating these ideas; most struggle to launch anything that moves the needle. Hopefully this article helps explain the difference. It’s not the full answer — there’s also research, goals, infrastructure and culture (in general the product operating model) — but the development process is at the heart of challenge, and the part you’re most likely to be able to fix as a product person. If you think your company is systematically harming its best product ideas, consider sharing this article with the people that ought to know.