Sometimes the product is obvious before the path to it is.
You can see the customer problem. You can describe the experience. You may even know the economics well enough to believe the product should exist. Then the organization starts answering a different question: Are we ready?
The answer is often no.
Not because the idea is bad. Because the company that would have to deliver it does not quite exist yet.
The hidden problem behind “not ready”
In mature companies, ambitious products rarely sit on top of a clean greenfield. They depend on a composition of systems, data, operations, contracts, authority, expertise, relationships, and workarounds that were built for earlier jobs.
That composition is the company’s operating Stack.
The Stack may contain nearly everything the future product appears to need and still be unable to support the product reliably. The data exists, but cannot be obtained at the right moment. Operations can handle an exception, but only at low volume. A customer team knows the rule, but the rule lives in one person’s head. Legal approved something similar, but not this decision. A system exposes a field, but nobody trusts it without a spreadsheet beside it.
This is why a readiness checklist can become a trap. One missing capability leads to another. The product waits behind a transformation program that grows faster than anyone can finish it.
Use the product for direction, not scope
Product Path starts somewhere smaller.
The future product provides direction. A near-term business outcome provides scope.
Instead of asking, “What would the entire future product require?” ask:
What result associated with that product would be valuable to improve now, even if the full product never arrives?
That change matters. It turns an abstract transformation problem into a bounded operating problem.
If the future product depends on trusted recommendations, perhaps the first move is not an AI recommendation engine. Perhaps it is one customer segment, one decision type, and one operating routine that can produce a transparent recommendation with current data and a clear owner.
If the future product depends on real-time exception handling, perhaps the first move is not a platform. Perhaps it is an owned connection between two teams that currently coordinate through favors.
The ambition stays large. The operating question gets smaller.
A path move has to earn its place twice
A useful move should do two things.
First, it should create a measurable result now: fewer failed orders, shorter cycle time, lower cost to serve, better conversion, fewer customer contacts, or another outcome worth having on its own.
Second, it should leave behind a durable capability: a rule that is now maintained, a data source that is genuinely usable, a handoff that has an owner, decision rights that are clear, or a service that can survive ordinary staffing.
In Product Path, those are the Business Delta and the Stack Delta.
The distinction prevents two common mistakes: calling every useful project “strategic,” and calling every capability investment a business win before it has produced one.
The destination can change without making the path wasteful
The original product may arrive. It may change shape. The market may move. A competitor may alter the problem. The economics may turn out differently than expected.
A good path can absorb that uncertainty because each move creates value now and leaves the company with more usable options afterward.
That is a different definition of progress.
You do not have to wait for the company to become ready. You can change what “ready” means, one defensible move at a time.
Adapted from PRODUCT PATH: How to Build What Your Company Isn’t Ready to Build by Alex Vale, published by Interoperability Press. Read Product Path.