Product strategy, discovery and development evolve together

A product vision sets direction. Working software, research and observed behaviour should be able to change that direction.

Why this matters

Product plans frequently start as a collection of assumptions: which problem matters, which users have it, which alternatives they consider, and which features might make the product worthwhile. A development team can execute that plan well and still deliver the wrong product.

When a useful slice of implementation can be produced rapidly, discovery no longer needs to be concentrated in the period before engineering begins. A team can compare an idea to the market, build enough of it to experience real behaviour, and use what it learns to change the product while that change remains affordable.

The key outcome is better decisions, not a higher rate of feature creation.

How the cycle works

Start with a position you can challenge: a target user, a problem, an expected advantage over alternatives, and a reason to believe the product will be chosen. Make its assumptions visible. Build the smallest credible capability that can challenge the next important assumption, then test it using the most relevant evidence available.

Evidence is not always the same thing. A usability session can show whether an interaction works; it cannot establish market demand on its own. An interview can expose unmet needs; it does not prove that people will pay. Competitive comparison informs positioning, but is not customer validation. Production usage shows behaviour but still needs interpretation.

The cycle should be capable of subtracting scope. Keeping a feature merely because implementation has started is a cost, not a strategy.

Illustrative example

A small operations product proposes a sophisticated automatic prioritisation feature. Early working software shows that users are much more concerned about whether a request has an owner. The team drops prioritisation from the initial product and strengthens the assignment experience instead. The foundational request storage remains reusable. The product becomes simpler because the feedback loop is fast enough to act on the discovery.

This is an invented teaching scenario, not a claim about an observed market.

Evidence worth keeping

• The current product hypothesis and its assumptions.
• What was compared with competing approaches and where the evidence came from.
• What was actually tested, by whom and under what conditions.
• The decision taken: keep, improve, defer or remove.
• How that decision changed scope, design, and the next experiment.

Trade-offs

Not every experiment needs production-quality foundations, and not every fast prototype should become production software. Conversely, endlessly rebuilding disposable prototypes can prevent useful learning from becoming a sustainable product. Choose the level of engineering needed for the risk and the evidence sought.

See the worked example: product hypothesis → positioning → a feature removed.