Who this is for: Startup founders and product owners
Before MVP development starts, write acceptance criteria for the smallest useful end-to-end workflow. Identify the user, starting conditions, action and observable result, then agree how the team will demonstrate that result. Include relevant failure and access scenarios, shared quality expectations and explicit exclusions. A feature name such as approval dashboard is not enough to establish what will be accepted.
This guide is for a founder or product owner who already has a product direction and needs to turn it into a reviewable delivery brief. If the user problem or value proposition is still uncertain, start with product discovery instead. The worksheet below supports a planning conversation; it is not contract wording, a security assessment or proof of product-market fit.
Separate acceptance, quality and business learning
Keep three decisions visible. Story-specific acceptance asks whether a particular user action produces the expected outcome. Shared quality expectations describe conditions that apply across the product. Post-launch learning asks whether the delivered product actually helps the intended users and business. Passing the first two does not establish the third.
For example, a requester can submit an expense category and see its saved status is a behaviour to verify. The team's agreed checks for supported browsers and deployment recovery belong in shared release expectations. Whether users stop relying on email is a learning question to investigate after they have a usable workflow.
The Scrum Guide formally defines a Definition of Done around the quality measures required for an increment. Teams using Scrum should preserve that meaning rather than rename every feature checklist a Definition of Done. Other delivery approaches can still make their shared quality expectations explicit without claiming to implement Scrum.
Write outcomes that two reviewers can check consistently
GOV.UK's user-story guidance connects a user's goal with acceptance outcomes and supporting evidence. Atlassian likewise recommends clear, testable criteria agreed collaboratively before implementation. Apply that principle to your workflow: replace subjective promises with a scenario that the product owner, designer, developer and tester can discuss together.
A useful original planning pattern is: for this role, starting from this state, when this action happens, the user can observe this result. Add the relevant data or environment assumption and the evidence you expect to inspect. The pattern is a conversation aid, not a requirement to document every interaction in a particular notation.
Avoid both extremes. A criterion such as works smoothly leaves too much interpretation. Prescribing every database field and button position can unnecessarily constrain the implementation. Describe the user-visible outcome first; record a technical constraint separately when a real dependency makes it necessary.
- Replace easy to use with a defined task, representative participants and an agreed observation method.
- Replace fast with the action, workload, test environment and response measure the team will evaluate; agree a suitable threshold rather than copying a universal number.
- Replace secure with specified access boundaries and review responsibilities; obtain appropriate specialist input for the actual design.
- Replace integration complete with the expected record, its source, error handling and how the receiving owner will verify it.
Worked example: an internal purchase-request MVP
Consider an explicitly hypothetical internal tool, not a Codersbay Technologies customer project. Its first workflow lets a requester submit a purchase request and an authorised approver record a decision. Supplier payments, purchase orders and accounting integration are outside this example. The business hypothesis is that a shared status reduces uncertainty; that remains a hypothesis even if every acceptance test passes.
Start with the normal path, then examine a missing value, a user without approval rights and an interrupted submission. These scenarios expose decisions that a screenshot alone cannot resolve. Confirm the final rules with the people who own the process; do not silently infer approval authority from a job title.
- Normal submission — a signed-in requester supplies the agreed required fields. After submission, the requester sees a reference and the saved pending status. Evidence: the reviewer follows that reference to the stored request in the test environment.
- Missing information — a required purpose is absent. Submission is prevented, the relevant field is identified and previously entered permitted values remain available for correction. Evidence: a repeatable missing-field scenario, not just a validation screenshot.
- Approval boundary — a requester without approval rights tries the approval action. No decision is saved. Evidence: the team checks the enforced application boundary as well as the hidden or disabled control, with the responsible technical reviewer.
- Interrupted submission — the user loses the response and retries. The team must decide how the user discovers whether a request already exists and how repeat submissions are handled. Record that decision before marking this scenario ready; do not assume a particular technical solution.
- Decision visibility — an authorised approver records the agreed decision. The requester can see the resulting state and the information the process owner has approved for display. Evidence: both roles inspect the same request after the action.
Copy this MVP acceptance worksheet into your brief
Create one record per important scenario using the fields below. These are suggested planning fields, not a scoring model or a standard that certifies readiness. Keep open questions visible and distinguish a proposed criterion from one the responsible people have agreed.
- Workflow and purpose — which user task is included, and what problem should it help address?
- Role and starting state — who acts, what permissions are assumed and which records already exist?
- Action and expected result — what happens, and what observable state or outcome should follow?
- Exceptions — which invalid input, unavailable dependency, repeated action or denied-access case is included?
- Evidence and environment — what will be demonstrated or tested, with which permitted data and operating conditions?
- Quality expectations — which shared usability, accessibility, reliability, performance and security reviews apply, and who defines their scope?
- Dependencies and exclusions — what must the client or another supplier provide, and what is deliberately outside this release?
- Owner and decision — who reviews the evidence, what remains unresolved and what decision allows the work to proceed?
Keep the first release small without cutting the workflow apart
A smaller MVP can reduce the number of user groups, integrations or workflow variations being attempted. It should still let the intended users complete the chosen task. Thoughtworks' product-thinking playbook connects MVP definition with core user value, prioritised goals, dependencies and constraints. That is a better scope conversation than counting screens.
In the hypothetical purchase-request example, a single approval route may be a deliberate first-release boundary. Removing all status visibility, however, could undermine the very uncertainty the product is meant to address. Make the trade-off explicit rather than describing every omission as an MVP simplification.
Leave implementation choices open where they do not change the agreed outcome. If a dependency cannot yet be tested, agree a limited prototype or technical investigation with a specific question and evidence. A successful mock does not establish that a live integration works.
Review evidence and changes before the launch decision
Walk through the proposed criteria with the product owner, delivery team and relevant operations or specialist reviewers before development. Ask whether each scenario can be demonstrated and whether the test data is appropriate to use. Choose proportionate checks: repeatable automated tests help with stable behaviour, while observation and exploratory review can expose different usability or operational issues.
Keep a trace from the agreed criterion to the tested version, evidence and unresolved findings. When understanding changes, record what changed, why, the effect on scope and who agreed the decision. Do not rewrite the original expectation after a failed test simply to make the result appear successful.
The receiving owner should understand known limitations, operating responsibilities and the recovery or support arrangements relevant to the release. These planning suggestions do not define payment acceptance or commercial obligations; authorised parties should agree those separately. After launch, revisit the business hypothesis using real evidence rather than treating a completed checklist as proof of adoption.
Bring a workflow, not just a feature list
Prepare one user journey, draft criteria, an exception you are concerned about and the decisions your team still needs to make. Codersbay Technologies' digital product engineering services include product strategy and discovery, experience design and quality engineering. Use these materials to discuss how a delivery engagement could be shaped; confirm the actual scope, availability and commercial terms with the team.
Share a non-confidential summary in the enquiry form. Do not attach credentials, private employee information or live purchasing records to a general website enquiry. Agree suitable information handling before sharing sensitive examples. The next useful step is a clear decision about what to investigate, agree or build—not a promise that every feature can be delivered within an assumed budget.
Frequently asked questions
What are MVP acceptance criteria?
They are agreed, observable outcomes used to check whether an included workflow behaves as intended. Describe the role, starting conditions, action, expected result and relevant exceptions, then agree the evidence and reviewer. They are more specific than a feature name or a list of screens.
What is the difference between acceptance criteria and a Definition of Done?
Acceptance criteria describe the expected behaviour of a particular story or scenario. In Scrum, the Definition of Done describes the shared quality measures an increment must meet. Keep business-learning measures separate: meeting delivery checks does not prove user adoption or product-market fit.
Who should write MVP acceptance criteria?
The product owner and delivery team should develop them collaboratively, with designers, testers, operations and relevant specialists involved where needed. The business owner clarifies the intended outcome; the team helps make it testable. Name the person responsible for reviewing the evidence.
Can acceptance criteria change during development?
Yes, when learning or circumstances justify a change. Preserve the previous expectation, record the reason and scope implications, and obtain the appropriate decision. Do not quietly change a criterion merely to make a failed test pass.
Does passing acceptance criteria mean an MVP is ready for every user?
No. The evidence applies to the agreed scope, conditions and version. Review shared quality expectations, unresolved risks, operating responsibilities and the intended rollout separately. A successful bounded release does not prove untested integrations, workloads or future market demand.
Sources and further reading
Technical references supporting the topics discussed above. The decision frameworks and recommendations are Codersbay editorial guidance.
