Product Discovery Before Development: Evidence Over Assumptions

Begin with a credible experiment, not a feature list

A request such as “automate returns”, “add an AI assistant” or “replace the merchant portal” often arrives already framed as a solution. For a founder, that framing can be necessary to obtain attention. For an enterprise product lead, it can make funding discussions easier. It is still a weak basis for committing a delivery team. The central question is not whether the proposed feature can be built. It is whether changing a specific part of the current journey is likely to produce a worthwhile operational or customer outcome.

In retail and commerce, a manual cycle normally crosses more than one system and more than one team. A customer service agent may receive an enquiry, an operations colleague may check a stock or order system, a manager may approve an exception, and the customer may then be contacted through a separate channel. A polished interface cannot shorten that cycle if the real delay is an unclear approval rule, unavailable data, or a hand-off that has no accountable owner.

The smallest credible experiment targets the most consequential uncertainty rather than attempting to simulate the whole future product. It may be a review of workflow and support data, observation of staff completing the task, a prototype tested with representative users, or a limited technical check of whether required information is available and reliable. Its purpose is to make a decision safer: proceed with a bounded scope, change the approach, or avoid development that has not earned its cost.

• State the operational outcome in plain language, such as reducing the time needed to resolve a stock exception.
• Identify the user, operator and business owner affected by the current journey.
• Choose one assumption whose failure would materially change the investment decision.
• Define what evidence would support, weaken or invalidate that assumption.
• Keep the experiment narrow enough that its result can change the next decision.

Myth: discovery delays delivery

The myth treats discovery as a preliminary documentation phase that sits outside delivery. Evidence points to a different role: discovery is a decision phase. Public service guidance describes it as work to understand the problem, users, constraints and opportunities before deciding whether further investment is justified. It also makes clear that stopping after discovery can be the correct outcome when the evidence does not support moving forward.

For commercial teams, the relevant comparison is not discovery versus immediate delivery. It is discovery versus building on untested beliefs. A narrow discovery can reduce rework by identifying what should not be in the first release, which dependency needs an owner, or which existing process should be changed before software is introduced. It can also uncover a smaller intervention that addresses the business goal more directly.

Discovery should not become an open-ended research programme. It needs a decision owner, a clear question and a definition of sufficient evidence. The team should be able to explain at the outset which decision the work will inform and which artefacts will be used to make it. If no decision could change, further discovery is unlikely to be useful.

Myth: stakeholder agreement is evidence of user need

Agreement among commercial, operations and technology leaders is valuable, but it is not proof that customers or staff experience the problem in the same way. Stakeholders may see aggregate commercial symptoms: rising contacts, slow onboarding or abandoned orders. People completing the work can reveal the detail that turns those symptoms into an actionable problem: duplicate data entry, an exception path, unclear terminology, accessibility barriers, or a workaround outside the main system.

Evidence should combine what people say with what they do and what existing records show. Relevant material may include analytics, search behaviour, call or chat logs, order-exception records, fulfilment workflow data, earlier research and observation of staff work. The aim is not to accumulate every possible data point. It is to understand the current end-to-end journey well enough to locate the high-friction step and distinguish a frequent issue from a merely memorable one.

Research should account for the people who support the journey, not solely the eventual customer. In commerce, this can include store staff, contact-centre teams, catalogue specialists, fraud reviewers, warehouse colleagues and partner administrators. A proposed self-service change may simply move work to one of these groups unless the full service path is examined.

Myth: a detailed backlog is a defined scope

A backlog can create a false sense of certainty. It lists potential outputs, but it does not necessarily show the problem each item addresses, the dependency it requires, or the evidence that the item should be prioritised. Discovery converts a collection of requests into testable scope by setting boundaries: the target journey, user segment, outcome, known constraints, assumptions and non-goals.

For a manual-cycle objective, define the baseline before selecting a solution. Map the current route from trigger to completion. Record the hand-offs, decisions, information sources, rework loops and escalation points. Then identify the event that marks completion. This is more useful than relying on a broad aspiration such as “improve efficiency”, because it allows the team to choose an outcome measure appropriate to the process.

A useful scope is small enough to test yet complete enough to function in its real context. For example, a first intervention might support one order-exception type for one operational team, while explicitly excluding every other exception category. That boundary is not a weakness. It gives the team a way to learn whether the proposed approach works before it becomes entangled with every policy, integration and regional variation.

• Problem statement: who is unable to do what, in what context, and with what consequence?
• Outcome measure: which cycle-time, completion, quality or avoidable-contact signal will indicate improvement?
• Hypothesis: what change is expected to help, for whom, and why?
• Constraints: which policies, contracts, legacy systems, data conditions and operational rules are non-negotiable?
• Non-goals: what will the first scope deliberately not solve?
• Decision rule: what finding would lead to proceed, reshape or stop?

Criteria for a build decision

Before moving from discovery into delivery, assess the proposal against a consistent set of criteria. The purpose is not to manufacture certainty; it is to make uncertainty visible and assign a practical way to reduce it. A proposal may be desirable but not ready because data quality is unknown. Another may be technically feasible but not worthwhile because the affected process is rare or already has an effective workaround.

First, assess problem strength. There should be a specific user or operator need, a clear current journey and evidence that the issue matters. Second, assess outcome credibility. The team should be able to explain how the proposed change could shorten the manual cycle without merely displacing effort elsewhere. Third, assess operational fit: ownership, training, exception handling and support must be considered alongside the interface.

Fourth, assess feasibility and data readiness. Identify source systems, access routes, data quality, integration limits and the consequences when information is missing or contradictory. Fifth, assess risk early. Security-by-design guidance emphasises considering product context, users, data and trust boundaries from conception, rather than treating protective measures as a later retrofit. A short security design note can make assumptions about authentication, authorisation, sensitive data and critical integrations reviewable before they are embedded in delivery.

Finally, assess economic and strategic fit. The expected benefit need not be expressed as a precise forecast at this stage, but decision-makers should understand the likely value, the cost of continued manual work, the delivery and operating implications, and viable alternatives. The decision can then be explicit rather than being implied by the existence of a roadmap.

• Proceed when the problem, first scope, operating model and evidence plan are coherent enough to test in delivery.
• Reshape when the need is real but the proposed solution, target segment or dependency is wrong.
• Pause when a prerequisite such as data access, policy clarification or accountable ownership is unresolved.
• Stop when the problem is insufficiently evidenced, the expected improvement is not credible, or a non-product change is better suited.

Decision scenarios for retail and commerce teams

The following scenarios illustrate how the criteria can change a proposal. They are not universal prescriptions; each requires evidence from the relevant customers, staff, systems and operating context. Their common pattern is to test the narrowest meaningful part of the journey first.

Scenario one: a retailer wants an AI-assisted tool to shorten catalogue enrichment. Discovery may show that specialists spend most of their time locating approved source information rather than writing descriptions. The first experiment should therefore test retrieval, permissions and review flow against representative catalogue cases. If authorised source data is incomplete or inconsistent, investing first in a generative interface would not address the governing constraint. The scope may shift towards source-data readiness and a human review workflow.

Scenario two: a commerce business wants self-service returns to reduce contacts. Journey research may reveal that customers contact support not because the form is difficult, but because return status is unclear after the parcel is handed over. A prototype or limited status-notification test can assess whether timely, comprehensible updates reduce uncertainty. The first scope should include failure states, such as delayed carrier events, rather than only the ideal path. Otherwise the manual workload may continue exactly where it is most costly.

Scenario three: an enterprise team plans a new order-exception console. Observation may show that staff need a reliable consolidated view, but only a small number of exception types cause most of the delay. A viable first scope could focus on one exception type, show the required data and record a decision. Discovery should also establish who owns rules when policies change and what happens when source systems disagree. This avoids treating an operational decision as a purely front-end problem.

Scenario four: a marketplace wants to reduce manual seller onboarding. The evidence may show that the bottleneck is not form completion but document review and inconsistent eligibility interpretation. The appropriate discovery outcome may be a clearer policy, structured evidence requirements and a test of reviewer workflow, rather than a broad seller-portal rebuild. If the process contains sensitive information, access controls, retention needs and audit expectations should shape the first scope from the beginning.

What discovery should leave behind

A strong discovery leaves decision evidence that can be reviewed by business, product, operations and technical stakeholders. It does not need a large set of polished documents. It needs a shared, traceable account of the problem, the evidence, the key uncertainties and the recommended next move. This enables delivery teams to start with intent rather than reverse-engineering the rationale behind a backlog.

The core outputs are a current-state journey, prioritised user and operational needs, a baseline for the manual cycle, a hypothesis-led first scope, an assumption and risk register, a view of technical and data constraints, and a measurement approach. Where the product processes meaningful data or connects to critical systems, record security-relevant design decisions early, including trust boundaries and the authentication model. This makes trade-offs discussable rather than implicit.

Discovery is not the end of research. Once a team begins to design and build, it should continue testing ideas with likely users and assessing whether the service meets the identified need. The initial decision evidence is a starting point for learning, not a substitute for it.

Decision scenarios

• Choose a focused discovery when the commercial goal is clear but the user problem, workflow bottleneck or best intervention is uncertain.
• Move towards a bounded build when research supports the need, the first scope has clear non-goals, core dependencies are understood and success can be measured.
• Reshape the initiative when evidence reveals a process, policy, data or ownership issue that software alone will not solve.
• Stop or defer when the expected benefit is weak, the relevant users do not experience the assumed problem, or a critical constraint cannot yet be addressed.

Risks and limits

• Treating a sponsor's preferred solution as the research question can bias evidence and preserve the wrong scope.
• Testing only the happy path can hide the exceptions that create most manual work.
• Measuring adoption without measuring cycle time, quality or displaced workload can overstate improvement.
• Leaving data access, permissions and security questions until delivery can make a prototype appear viable when it is not operationally viable.
• Assuming discovery must end in a build encourages teams to defend sunk effort instead of making the best decision.

Practical next steps

• Name the manual cycle to improve and appoint one decision owner for the discovery outcome.
• Map the current end-to-end journey with the people who perform, support and experience it.
• Write the highest-risk assumption as a testable hypothesis and select the smallest credible experiment.
• Review operational, data, legacy-system, policy and security constraints before defining the first delivery scope.
• Hold a decision review that explicitly records whether to proceed, reshape, pause or stop.

FAQ

Related Cubicfox pages

• Product discovery
• UX and product design
• AI-first web development
• Selected work
• Request a quote

Sources

1. L_202402847EN.000101.fmx.xml - EUR-Lex (2026-07-20)
2. ENISA Security by Design and Default Playbook (2026-07-20)
3. Guidelines - ESMA - European Union (2026-07-20)
4. [PDF] implementing guidance | enisa - European Union (2026-07-20)
5. THE EU CYBER RESILIENCE ACT – TOWARDS A SAFE ... (2026-07-20)
6. [PDF] EUROPEAN COMMISSION Brussels, 3.2.2025 C(2025) 618 final ... (2026-07-20)
7. TECHNICAL IMPLEMENTATION GUIDANCE - ENISA (2026-07-20)
8. prEN 40000-1-2 Cybersecurity Requirements for Digital Products - (2026-07-20)
9. Cyber Resilience Act (2026-07-20)
10. The Cyber Resilience Act - Summary of the legislative text (2026-07-20)

Related Cubicfox pages

• Product discovery
• UX and product design
• AI-first web development
• Selected work
• Request a quote