Build All You Want — But If You Can’t Answer These 3 Questions, Nobody’s Buying
Who decides what to build?
How is it decided?
How do we know it will be useful?
These 3 questions look simple on paper — but they separate successful products from those that quietly die after months (or years) of passionate work. And yet, in all my years coaching product teams and leaders across industries, these questions are either skipped entirely or answered with assumptions, opinions, and gut feelings.
I’ll never forget a startup founder I met years ago in Palo Alto. Brilliant guy. Huge passion for solving a specific problem — he truly believed his product would change the game. He secured Series A funding, hired a small but talented team, and built a beautifully designed product. It had all the bells and whistles. The engineering was solid. On paper, it was perfect.
Two years later — the company folded.
The product wasn’t flawed. The idea wasn’t bad. The founder wasn’t lazy.
The problem? No one wanted it. There were no buyers!
There was no real user research. No discovery process that validated actual pain points. No conversations with real potential customers to even understand if the problem they were solving was important enough for someone to pay for. The founder was solving his problem — not his customer’s.
The worst part is the engineering team — the people closest to the technology and often the first to spot feasibility risks — were brought in only after everything was decided. They were there to build, not to think.
This is not just a startup problem. I’ve seen the exact same anti-pattern play out in Fortune 100 companies. The process looks a little different, but the dysfunction is the same.
=> A product idea is pitched — usually by someone high up, a key stakeholder or a Sales head
=> A business case is created — complete with speculative cost estimates and fantasy revenue projections, all before a single user interview has taken place.
=> A few PowerPoint slides later, leadership buys in.
=> The loudest voice — often the HIPPO (Highest Paid Person’s Opinion) — determines what gets funded and prioritized.
Here’s my question:
When you don’t know the actual user need…
When you haven’t built even a rough prototype…
When you haven’t tested if people will use it, let alone pay for it…
How in the world can you confidently estimate costs or predict revenue?
This is how teams end up wasting months (sometimes years) building products that nobody wants. And then they wonder why Agile development didn’t save them.
Here’s the hard truth: Agile delivery can’t rescue broken product discovery.
The product life cycle itself has to be truly Agile — starting from discovery, not just delivery.
One of my most successful coaching engagements was with a large enterprise where this very problem was rampant. The product management team worked in isolation, building roadmaps based on leadership directives, not validated user needs. The engineering teams — full of brilliant minds with years of experience solving real user problems — were handed fully-baked backlogs and told to execute. No room for discovery. No seat at the table.
We changed the game by integrating discovery and delivery.
Product Owners didn’t just write stories — they worked with users, developers, and designers upfront to validate needs before committing anything to the backlog.
Developers weren’t just handed work — they participated in user research, technical spikes, and product experiments, bringing their insights to shape the product early.
Senior designers, compliance experts, and architects were looped into discovery efforts from day one — not called in at the last minute to rubber-stamp decisions.
This wasn’t a one-time exercise. It became part of how work flowed.
The company culture changed which resulted in:
Features that solved real problems, not imaginary ones.
Less rework and fewer late-stage surprises.
A true sense of shared ownership — because the whole team co-created the product vision.
Product discovery should not be some optional ‘nice to have’ random activity. If your discovery is broken, your delivery is just a faster way to build the wrong thing.
And here’s the important piece — this isn’t just for startups. Big companies with deep pockets and decades of history fall into the same trap when they disconnect discovery from delivery.
In the end, product success is not just about how fast you build.
It’s also about whether you’re building something worth building at all.
Conclusion:
The best product leaders I’ve worked with embrace radical humility. They know their gut instinct might be wrong. They trust evidence over assumptions. They actively seek out dissenting opinions from the very people closest to the work — the engineers, designers, and support teams who engage with real users daily.
Great products are rarely born in a conference room. They’re born in conversations with users, in prototypes tested early, in collaboration with the very teams who will build them.
If you’re not starting there, you’re not really doing product management — you’re just playing business theater.
Note: Our ChatBot AgiNomi helped polish my thoughts and ideas on this topic. – Author