Launch a Working MVP with Real Users

Proof required

Submit: (1) notes or transcripts from at least five user research conversations — real names or anonymised descriptions, specific responses quoted, and dates; and (2) your MVP specification document (minimum 400 words) covering: target user description, three specific user needs with the interview evidence that produced each, core V1.0 functionality list with each feature traced to a user need, tools and platform selected, and a one-paragraph success definition specific enough to be testable.

What gets checked

• User research is documented with specifics — five conversations with real responses recorded, not paraphrased summaries or hypothetical needs invented after the fact
• The specification traces each core feature to a specific user need from the research — for every feature in the V1.0 list, there is a corresponding interview finding; features without evidence are absent
• Success is defined specifically enough to be testable — 'the user completes X in under Y steps without asking for help' not 'the user finds it helpful'

Common mistakes

• User research is skipped and the specification describes what the student wanted to build before the research — the features listed don't trace to evidence from conversations with affected users
• The specification lists features as a wishlist without connecting each to a specific user need — it reads as what the student thinks is interesting rather than what users said they need
• Success is defined so broadly that any engagement with the product would qualify — the success criterion cannot be objectively assessed as true or false

Resources

What a verifier looks for

• Check that five distinct user conversations are documented — not five responses from the same person or from people who haven't directly experienced the problem
• For each core feature in the specification, ask the student to point to the interview finding that drove it — if they can't trace a feature to evidence, it should be removed from the V1.0 scope
• Ask: what would you cut from V1.0 if you had half the time? The answer reveals whether the specification captures essential functionality or speculative additions

Proof required

Submit: (1) a working link to your deployed product or a video walkthrough showing core functionality working end-to-end without the student operating it; (2) a change log with at least five entries (each entry must include: what was planned, what changed, and why — with a citation to specific user feedback or a specific technical constraint); and (3) a user testing record showing at least three real users outside the family tried the product (names or anonymised, dates, and one-sentence note per user on what they did with it).

What gets checked

• The product is functional — it can be used to complete the core task without the student present; a verifier should be able to access the link and complete the core task independently
• Change log entries are specific — each entry names a concrete decision (not 'improved the design') and traces it to specific user feedback or a named technical constraint; cosmetic changes without evidence are not valid log entries
• User testing record shows the product being used for its intended purpose — not just shown to people who expressed approval, but used to attempt the core task

Common mistakes

• The 'product' is a set of Figma screens, a static mockup, or a video of a concept rather than a deployed, working artefact that others can actually use independently
• The change log consists only of cosmetic or aesthetic changes without entries about functionality or user experience decisions driven by real testing feedback
• User testers are described without documenting what they specifically did or encountered — 'my friends tried it and liked it' is not a user testing record

Resources

What a verifier looks for

• Access the deployed product link and complete the core user task without any assistance from the student — if you cannot complete the task independently, the proof does not pass the 'works without the student present' requirement
• Read the change log: are entries specific enough to verify that real feedback drove real changes? Ask the student to explain one entry in detail — what specifically did a user do or say, and what specifically changed in response?
• Confirm user testing involved at least three people who are not family members: ask the student to describe one specific thing a user did during testing that surprised them or revealed something unexpected

Proof required

Submit: (1) usage evidence for at least three real users — screenshots of completed sessions, usage analytics showing task completion, or brief written accounts from users describing what they did with the product (names or anonymised); (2) a signed or written attestation from your faculty supervisor confirming the product is live and has been used by real people; and (3) a 200-word reflection on what you learned from the first real users that the earlier user research phase did not reveal.

What gets checked

• Usage evidence shows the core task being completed by three distinct users — not sign-ups, downloads, or passive exposure, but documented active use of the product's primary function
• The faculty attestation is specific to this product and this launch — not a generic letter of support but a statement from someone who has seen the product and can confirm it is live and in use
• The reflection identifies something genuinely unexpected — a specific user behaviour, confusion, or outcome that the student did not anticipate and that directly informs what V2.0 will change

Common mistakes

• Usage evidence consists of sign-up confirmations, download counts, or social media engagement rather than documented completion of the core product task
• The faculty attestation is a generic recommendation letter rather than a specific statement about the product and its real-world use
• The reflection describes what the student intended users to experience rather than what was actually observed — it confirms the original product vision rather than surfacing what was unexpected

Resources

What a verifier looks for

• Access the product and attempt the core task — verify it is operational and functional without the student guiding you
• Confirm usage evidence shows three distinct users completing the core task, not just accessing or signing up — ask the student to demonstrate what 'completed the core task' means in the evidence
• Read the reflection: does it describe a genuine surprise — something users did or experienced that the student did not predict? Ask one follow-up question about what specifically changed in the student's product understanding after watching real users