A business owner asks a question. "Can this be done?"

The temptation is to jump straight to solutions: what software exists for this, what would development cost, who could build it. Those all become relevant questions at some point — just not first. Between a customer asking for something and a product worth building or selling, there are quite a few steps.

A customer also rarely describes a product problem. They describe what they're missing today. Someone asking for an app may mainly be tired of a process that runs through five emails and three spreadsheets. Someone wanting their own platform is often less interested in technology than in margin, customer data, or control over the customer relationship. And someone naming a feature they recognise from a big platform sometimes means only the effect of that feature — not the feature itself.

Take the requested solution literally, and you can build exactly what was asked for and still solve the wrong problem.

That's why I first pull a question like that apart. What does the end customer actually need to be able to do? What needs to happen internally to make that possible? What has to be real-time, and what really doesn't? And which dependency does the business owner specifically want to get rid of — and which new one are they buying in its place?

Only once that's sharper does technology become interesting. And even then, I find "it can be done" a thin answer. Almost anything can be built if time and budget don't matter. The business question is whether it can be done sensibly. Does something already exist that solves a large part of the problem? Can two existing systems together do what one new system would need to do? Who has to operate it day to day, and what happens when something goes wrong? And does the benefit stay bigger than the complexity you're adding for it?

That's where opportunity validation starts for me: not proving the original idea was good, but trying to find out why it might not be. That sounds more negative than it is. An opportunity that survives serious pushback only gets more interesting. And an idea that dies during that exercise costs far less than one that dies after months of development, vendor conversations and internal expectations have piled up around it.

Sometimes the question changes completely along the way. You start from the assumption that one integrated platform is needed and discover that two specialised systems work better together. Or you read a feature name at a vendor that seems to cover exactly what you're looking for, and on closer questioning find out it means something far more limited. Those aren't details: if that exact property was the reason the research started, the opportunity stands or falls with it.

That's why I trace claims back to what's demonstrable as quickly as possible. "The vendor supports this" doesn't tell you much on its own: who sees what, on which screen, based on which data? And the fact that there's an API only becomes interesting if it gives access to exactly the data and actions needed. A feature list usually tells you less than it seems to.

The same goes for competitive research. That five players already exist doesn't prove an idea is dead. And the fact that no one offers exactly the same thing doesn't mean you've found a gap in the market — maybe the gap is there because no one needs it, or because it doesn't work economically. Maybe there genuinely is room. But that's a conclusion, not a starting point.

That's why product discovery is, to me, a form of business development. Not because something needs to be sold right away, but because you're trying to understand the commercial possibilities before committing resources. Where does the value sit? Who would pay for it? Which existing alternative do you need to beat, and what has to be demonstrably better than it? What can you buy in, and what do you need to own yourself?

The next step can then be a prototype, a vendor conversation, a small market validation, or a financial exercise. Or simply: stopping. That last option gets treated as a result far too rarely. I consider it one of the most useful outcomes there is. Not every opportunity deserves a roadmap; some deserve a quick, well-substantiated no. Others come back after research in a form that's simpler, cheaper, or more interesting than the original idea. And a small group survives all the pushback. Those are the ones I want to keep going with.

A good product question therefore doesn't start with "how do we build this?" but with: what problem are we actually solving here — and what has to be true before this counts as an opportunity?

Update — what this case has clarified since

Since the first version of this piece, the underlying case has moved forward. The broad question — should we build something new for this? — has since narrowed considerably.

Several routes have fallen away. Not because they were bad systems, but because the exact element the research started with couldn't be demonstrated. Marketing terms turned out to be more elastic than what actually sat behind them.

What remains is one much more concrete question: can a combination of existing systems deliver what's being asked for, without building custom software again?

That's a better outcome than an early “go”. Discovery doesn't have to end in a new product. Building, buying, combining, partnering, or stopping are all valid outcomes, as long as the decision that follows is smaller and better substantiated than the question you started with.

The question then shifts from “what's out there?” to: what does this one route still have to prove before we commit time and money to it?