Contents
These labels are used differently by different teams, so agree what the proposed exercise will do before commissioning it. A useful working distinction is to use a proof of concept for a feasibility question, a prototype to explore a proposed experience, and an MVP for a limited product offering intended to support learning through use. The question and evidence matter more than the label.
Use a proof of concept to investigate feasibility
Choose a specific uncertain capability and define what a test needs to demonstrate. For example, can an available interface provide the required information under the conditions your product will face? State the inputs, expected result and constraints before building the experiment.
Keep the result within the boundary tested. A successful response from one prepared example does not establish that every record can be processed or that the wider product is viable. Document failures and untested conditions alongside successes. The output should support a decision about the feasibility assumption.
Use a prototype to explore the proposed experience
A prototype can make an idea concrete enough for people to discuss or try. Choose the level of detail needed for the question: a sequence of sketches, an interactive interface or a more functional representation. Explain which parts behave realistically and which are simulated.
Give participants tasks that relate to the intended use and observe where the design helps or confuses them. Record their context and the limitations of the exercise. Positive feedback on appearance is different evidence from someone completing a task without assistance. Decide what the findings imply for the next design or product decision.
Use an MVP to learn from a limited offering
Define the smallest coherent offering that allows you to investigate a product assumption through use. Identify the audience, the task and the learning goal. State any manual support needed and who will provide it, rather than concealing that effort in the demonstration.
Choose how the result will be evaluated. That could include repeated task completion, support needs or another signal relevant to the question. Keep the interpretation proportionate to the participants and trial conditions. A limited release can provide useful evidence without proving that the product will work for every market.
Choose the approach from the unresolved question
If the largest uncertainty is whether an integration can work, a polished interface may not resolve it. If users cannot understand the proposed process, a technical experiment alone may not provide the evidence needed. Identify the assumption that could change the investment decision and choose the activity that addresses it directly.
Combine activities when the questions are different, but keep their outputs distinct. A feasibility test and a user prototype can inform the same product decision without being presented as a complete application. Agree the order so that an early result can stop or reshape work that would otherwise be wasted.
Write a brief with an explicit decision at the end
Record the question, participants, conditions and evidence required. Include what is excluded and who will review the result. Describe the options after the exercise: proceed, revise, investigate a different uncertainty or stop.
Agree how the artefact and findings will be handed over. Preserve useful knowledge about assumptions and rejected options. If the work will lead to a live product, assess that next release separately for engineering and operational readiness. The successful completion of a learning exercise should not silently become approval to launch it.
Choose an experiment from the uncertainty it must answer
A fictional founder wants a service that turns equipment requests into approved orders. If the uncertainty is whether managers understand the journey, use a prototype with representative users and observe where they get stuck. Its output is interaction evidence, not a deployable service. If the uncertainty is whether the existing order API can safely accept a request, use a technical proof of concept against a suitable test environment.
If those questions are settled but demand and sustained use remain uncertain, choose a bounded MVP: one request type, a small pilot audience and an explicitly staffed exception process. Measure whether people complete the journey and whether the operating effort is workable. State the stop or change condition before the trial, such as an essential handoff that cannot be reconciled.
Do not ask one experiment to prove all three things. A clickable screen cannot establish interface compatibility; a successful API call cannot establish buyer demand; a live pilot does not justify every future feature. Use the discovery guide to frame the question, the MVP readiness guide to assess a selected release, and prototype-to-production to estimate the engineering needed if earlier code will be retained.
How this relates to Veda Software’s work
Powerleague is relevant to mapping a real request-to-fulfilment journey. Its case is adjacent workflow evidence, not proof of the demand or technical feasibility of this fictional experiment.