The Best Product Ideas Are Already Happening Without You
What to build next isn't rocket science.
I’d sharpen the thesis around evidence beating ideation and make the piece less engineering-specific.
Most teams are surprisingly bad at deciding what to build next. They brainstorm, look at the roadmap, ask the loudest customer, copy a competitor, or wait for someone important to develop a strong opinion.
I think that’s backwards. The best opportunities usually aren’t invented in a meeting. They’re discovered by paying attention to places where reality is already putting pressure on the product.
If you’re responsible for deciding what gets built next — founder, CTO, product manager, engineering lead, or anyone else — your job is less about having ideas and more about building a good sensor network.
Your system is already giving you clues
Production failures are the obvious place to look. Postmortems expose brittle assumptions, missing abstractions, and recurring patterns that deserve more than another patch.
But crashes are also dangerous inputs to strategy. They’re lagging indicators, and they come with enormous recency bias. Something exploded on Tuesday, everyone spent Wednesday talking about it, and by Thursday it somehow became the company’s most important architectural priority.
Money is often a better signal. Look at the cloud bill, P&L, API usage, vendor contracts, support costs, and infrastructure that scales badly. A buy-vs-build decision that made perfect sense at 10,000 users can become ridiculous at a million, and a feature that looked marginal at launch can quietly become one of the most expensive parts of the business.
Your own operational pain matters too. If people repeatedly babysit the same process, manually repair the same data, or maintain increasingly elaborate internal workarounds, there is probably something worth fixing. Just don’t confuse internal convenience with customer value: eliminating toil can dramatically improve the economics of a business without making the product noticeably better.
Users are better at revealing problems than designing products
“Talk to users” is good advice that is frequently implemented badly. Asking customers what features they want often produces a backlog of locally rational solutions to problems you haven’t actually understood.
The useful information is usually elsewhere. Watch for spreadsheets, exports, scripts, copy-paste rituals, weird workflows, and combinations of features that nobody intended. The hack is often more valuable than the feature request because it shows what someone cared enough about to solve themselves.
My favorite signal is the overloaded use-case: customers using your product to do something it was never designed to do.
That is incredibly valuable evidence. The customer has identified the problem, assembled a solution from the pieces you gave them, tolerated the friction, and continued using it anyway. Instead of pitching you an imaginary feature, they are effectively running a prototype in production.
Those are the situations I’d investigate first. Sit beside the customer, understand the job they’re actually doing, and build the smallest version that removes the ugly parts. You’re no longer testing whether the problem exists; you’re testing whether deliberately supporting it makes the behavior meaningfully better.
Your organization is another sensor, but a noisy one
Some signals come pre-qualified. If something has made it into a serious OKR process, much of the argument should already exist. There is little value in rediscovering why the work matters.
More interesting are concerns that keep resurfacing without becoming explicit priorities. If the same issue appears repeatedly in planning meetings, customer conversations, leadership discussions, or support escalations, pay attention. Repetition often means the organization can feel a problem before anyone has articulated it well enough to put on a roadmap.
I’d call this the manager-repetition heuristic, but I wouldn’t trust it blindly. Repetition is a clue, not validation. Organizations are perfectly capable of repeating the same misconception until it sounds like strategy.
Migrations create another underrated source of information. Once the big migration is “finished,” look at who didn’t migrate. The laggards often expose exactly where the new system fails: missing capabilities, unexpected switching costs, strange edge cases, or assumptions that worked beautifully for the median customer and terribly for everyone else.
Being late can be a competitive advantage
There is also an enormous sensor network outside your company: everyone else.
Technology culture massively overvalues being early. Companies spend fortunes experimenting with new architectures, interfaces, AI workflows, pricing models, and organizational structures because nobody wants to look like they’re behind.
Sometimes being behind is exactly where you want to be. Let other companies pay the tuition. Watch what survives contact with production, see which assumptions fail, wait for tooling and talent to mature, and then adopt the pieces that actually worked.
Lag can be arbitrage. You sacrifice some first-mover advantage in exchange for dramatically more information and dramatically lower experimentation cost.
One surprisingly effective way to find these opportunities is simply to document how your current systems work. Descriptive writing forces old decisions back into view, and you often discover that something everyone considers a fundamental constraint was actually a perfectly reasonable compromise made four years ago because some database, API, vendor, or organizational limitation worked differently.
The world changed. The assumption didn’t.
Don’t prioritize by volume
The biggest mistake is treating all these signals equally. They aren’t.
Crashes are loud. Executives are loud. Competitors launching things are loud. Angry customers are extremely loud. None of that automatically makes them strategically important.
I’d evaluate signals on two dimensions: how much of the argument has already been made, and whether the signal is leading or lagging. A speculative idea requires you to prove almost everything. An overloaded use-case comes with a customer, a problem, a workaround, observed behavior, and evidence that the outcome matters enough to tolerate friction.
That’s why I’d put overloaded use-cases near the top of the list. The experiment is already running in production; your job is to notice it.
At the other end are ideas generated primarily by authority, fashion, or recency. “Our competitor launched this,” “we need an AI strategy,” and “the CEO mentioned this three times” may all eventually lead somewhere valuable, but they start with remarkably little evidence.
The goal, then, isn’t to become better at brainstorming. It’s to become better at observing.
Build a sensor network across your systems, customers, organization, and industry. Then look for places where people are already spending money, tolerating friction, inventing workarounds, resisting migrations, or bending your product into something you never intended.
That’s where I’d look for what to build next, because the strongest ideas are often the ones reality has already started building for you.