Contents
Product discovery should reduce uncertainty around a decision. Start by naming that decision, the people affected and the evidence you need. The output is useful when it changes what you choose to do next, whether that means building, testing a narrower idea or deciding not to proceed.
Define the decision and its limits
Explain what you are considering and why the answer matters. Are you deciding whether to replace a process, introduce a new product or invest further in an existing idea? Identify who will make the decision and what constraints that person must consider.
Set boundaries for the discovery. List the questions it should answer and those that belong to a later phase. Agree the people available to contribute, the material that can be reviewed and the point at which the findings will be assessed. Avoid treating discovery as an open-ended request to investigate everything.
Understand the current work and its users
Ask people to describe and, where appropriate, demonstrate how they complete the relevant task today. Look for handoffs, exceptions and repeated work. Separate what someone does from their suggestion for a new feature; both are useful, but they provide different kinds of evidence.
Include the people who administer and support the process. Identify users with different access needs, devices or working conditions. Record who participated and where the evidence is incomplete so the team does not generalise from a narrow group without acknowledging the limit.
Expose the constraints that shape possible solutions
Map the systems, data and organisational responsibilities involved. Ask which rules are fixed and which could change. Give unresolved constraints an owner who can confirm them. An assumption that an existing system has no usable interface may deserve investigation before it drives an expensive replacement proposal.
Identify commercial and operational conditions as well as technical ones. A solution may need a particular support arrangement, a viable onboarding process or access to information controlled by another organisation. Record these dependencies alongside the user findings rather than discovering them after a design has been selected.
Choose evidence-gathering work for the riskiest assumptions
List the assumptions that could invalidate the proposed direction. Choose a focused activity for each important uncertainty: a user exercise, a process review, an interface investigation or another appropriate test. Explain what result would support or challenge the assumption before running the activity.
Keep the test proportionate. A lightweight representation may be enough to discuss a workflow; a technical feasibility question may require a working experiment. Make simulated behaviour and prepared examples explicit. Record what the activity demonstrated and what remains untested.
Produce a decision record the delivery team can use
Summarise the problem, evidence, constraints and options considered. Explain the recommended next step and its assumptions. If a build is recommended, outline the first useful scope, important dependencies and the acceptance questions that still need refinement.
Keep findings traceable without exposing private research material in general project records. Distinguish observations, interpretations and decisions. A set of attractive screens can support the discussion, but it should not replace the explanation of why that direction was selected.
Make the next commitment explicit
Review the findings with the decision owner and the people responsible for delivery and operation. Decide whether to proceed, change direction, investigate further or stop. Record the reason and the conditions attached to any next investment.
Carry remaining uncertainties into the next phase with owners and review points. Discovery does not remove every unknown. Its value is a better-founded decision and a clearer account of what the team must learn next.
Discovery outputs for a consequential unknown
A fictional distributor asks for a customer portal, but nobody has verified whether the existing order system exposes a usable interface. Give discovery a specific question: can an approved portal order be accepted once, reconciled and corrected through the current system? The answer could change whether the next purchase is an integration, a manual pilot or a replacement assessment.
Expected outputs are a mapped order journey, the actual provider interface and access constraints, a controlled exchange trial, exception examples, a first-release boundary and an estimate with assumptions. Assign the distributor’s operations owner to confirm approval rules and the system owner to arrange test access. Keep an unresolved access dependency in the output rather than claiming a successful trial that used only a mock.
The exit decision uses that evidence. If acceptance and lookup work, commission the bounded integration. If duplicates cannot be prevented or reconciled, investigate an alternative boundary. If access is still unavailable, explain what the next phase cannot promise. Discovery is useful when it changes a commitment; a set of polished screens without an answered consequential question is not enough for this brief.
How this relates to Veda Software’s work
Powerleague’s published account places operating-model mapping before implementation. That is the relevant principle; it does not establish a fixed discovery package, duration or provider test result.