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

You'll sign in first, then come straight back here.

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

You'll sign in first, then come straight back here.

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

You'll sign in first, then come straight back here.