Discovery is for Killing Ideas

Product discovery is traditionally treated as the pathway to finding what to build, but in an era of cheap, AI-assisted engineering, its true function must be the exact opposite: a mechanism to aggressively prune and kill weak ideas before they consume your team's focus.

When coding becomes cheap, fast, and easy, the bottleneck in software development shifts entirely. It moves from the hands that build to the mind that decides what is worth building. If you do not adjust to this shift, you end up optimizing a pipeline that no longer exists.

Why has the product pipeline fundamentally changed?

Prior to AI coding tools, the bottleneck in software development was R&D - the actual building of the software. Because building was the limiting factor, our entire industry's methodologies (like agile and scrum) were structured to optimize development velocity. We focused on how to build faster, iterate quicker, and test smaller.

But once that bottleneck becomes obsolete, the entire pipeline must be restructured around the new bottleneck: the decision layer. If you just build everything because it is cheap and possible, you create so much noise that your chances of understanding what is actually important drop to zero. Cheap building without sharp deciding just means shipping the wrong things faster.

Why is traditional discovery a risk to real innovation?

Traditional discovery is designed for narrow optimization. It is a good pathway to narrow success in stable markets. But when we are living through a massive inflection point where base assumptions are changing, sticking to traditional discovery is actually an idea killer.

Real vision does not come from running a standard discovery template on a random idea. It comes from a deep, first-principles understanding of a specific market and its reality, combined with the drive to take a leap of faith. When you rely only on traditional discovery to optimize parameters, you end up building highly researched, beautifully designed ghost towns because you optimized a solution to a problem that did not matter.

How do we build for the new decision bottleneck?

When the limiting factor is the decision of what to build, we have to build a pipeline that enhances and slows down the thinking process. Human beings are naturally lazy; whenever we can find a shortcut to avoid mental load, we take it. We need pipelines that hack this tendency and force us to confront the hard questions.

Today, we see an absurd disparity in product teams:

• Product managers still spend 4 to 6 calendar weeks turning ideas into dev-ready plans.
• Developers can implement those same plans within a single week.
• The historical 1-to-6 ratio of PMs to developers is no longer sustainable when building velocity shifts so dramatically.

The only way out is to introduce a deliberate friction point: forcing teams to think deeper before they build. It is the classic proverb: if you give me 6 hours to chop down a tree, I will spend 4 of them sharpening the axe. By slowing down to think, you accelerate everything that happens downstream.