Product Discovery Case Study: From User Interviews to a Tested Prototype
A product management final year project where you run a full discovery cycle on a real problem for a group you can reach, such as students booking lab slots or shops tracking credit sales: interviews, problem framing, a competitor teardown, a short spec, a clickable prototype and usability tests, published as an honest case study.
Beginner
Achievable by one student in a semester with familiar tools.5 to 7 weeks · 1 or 2 students
8 to ship
3 optional extrasSuggested stack
What you should ship
- An interview guide with non-leading, past-behaviour questions and anonymised notes from at least 8 user interviews
- An affinity map or theme table linking each finding to the interviews it came from
- A problem statement with its evidence and the three assumptions you are least sure of
- A teardown of one existing product that tries to solve the same problem: what works, where users struggle, and why
- A prioritised list of at least 6 solution ideas scored with a method such as RICE, plus a critique of where the scores misled you
- A one to two page product spec: problem, users, goals, non-goals, success metrics, open questions
- A clickable prototype of the core flow, tested with at least 5 people, with a log of changes made because of the tests
- A public case study page that tells the story honestly, including what you got wrong
If you have time left
- Build a no-code or simple coded version and measure real usage for two weeks with PostHog or similar
- Compare two onboarding messages with a small test and report the result with its limits
- Present the case study to a working product manager and record their feedback
The problem: product skills are hard to show without a job
Many CS students are drawn to product management, but product work is decisions, not code, and a CV line saying "interested in product" proves nothing. At the same time, plenty of small groups around a campus have problems nobody has looked at properly: students fighting over lab slots, a family shop tracking customer credit in a notebook, a clinic front desk juggling walk-ins and calls.
A discovery case study solves both problems. It shows that you can interview people without leading them, turn messy notes into a clear problem, choose between options for stated reasons, write a spec an engineer could act on, and change your mind when a test proves you wrong.
What already exists and the gap
- Maze is a product research platform for unmoderated usability tests, surveys and prototype testing.
- Dovetail is a research repository for tagging and analysing interview notes across projects.
- The Mom Test by Rob Fitzpatrick is a short, widely recommended book on asking customers questions that do not produce polite lies.
- roadmap.sh's Product Manager roadmap lists the skills a PM is expected to have.
Tools and advice are easy to find. What is missing from most student portfolios is a complete cycle with evidence. Typical "case studies" are UI redesigns of famous apps with no users, no interviews and no tests. The gap you fill is a small, real, traceable piece of discovery where every decision points back to something a user said or did.
What you build
The output is a documented process plus a prototype:
- Users: a group you can actually reach, such as classmates, a family business, a society committee or a local clinic's front desk.
- Artefacts: interview guide, notes, theme table, problem statement, teardown, prioritised ideas, spec, prototype, test notes and the case study.
- Main flow: choose problem, interview, frame, tear down, prioritise, spec, prototype, test, fix, retest, publish.
Pick a problem you can observe, not one you can only guess at. Get consent before every interview and anonymise names from day one.
The technically interesting part
The hard part is traceability of reasoning. Build a simple evidence table in a spreadsheet: each row is an observation (quote or behaviour), tagged with participant ID and theme. Your problem statement, each prioritised idea and each spec decision should cite rows from that table. Evaluators can then follow any decision back to evidence, which is exactly how strong product teams defend choices in reviews.
The second hard part is writing questions that do not lead. "Would you use an app that..." produces useless yes answers. "Tell me about the last time you..." produces facts. Show your supervisor your first guide, the pilot interview, and the revised guide with the leading questions removed.
How to evaluate it
- Interviews: at least 8, with a count of how many mentioned each theme.
- Usability: at least 5 test sessions on the prototype; record task success rate, time on task and where people hesitated, before and after your fixes.
- Spec quality: ask a developer friend to estimate the spec; list every question they had to ask you, which reveals what the spec left out.
- Honesty: a section on the assumptions that turned out wrong and what you would test next.
Suggested plan
- Week 1: choose the group and problem, write and pilot the interview guide.
- Weeks 2 to 3: run interviews, build the evidence table, frame the problem.
- Week 4: teardown, idea list, scoring and critique, spec.
- Week 5: prototype the core flow.
- Weeks 6 to 7: two rounds of usability tests, fixes, write and publish the case study.
Path to a product
The first "customer" is a hiring manager for an associate PM, business analyst or UX research role, and the case study is your work sample. If the problem proves real, the prototype can become a small tool for the group you studied: the family shop or the society is your pilot user, and a second similar group tells you whether it generalises. Many founders start exactly this way.
Scope warning
Do not build a full app before you have tested the prototype. Do not interview only friends who will be kind. Do not pick topics touching health records, money details or minors unless you keep them fully anonymous and simple. Do not claim metrics you did not measure.
Learn what you need on Sefism
- The Mom Test : how to ask questions that produce facts instead of compliments.
- Inspired by Marty Cagan : how product discovery works in strong product teams.
- Product Manager Roadmap : the wider set of skills this project starts to prove.
- Figma Learn : enough Figma to build a clickable prototype.
- Nielsen Norman Group Articles : how to run and report small usability tests.
- Personal branding roadmap : how to publish the case study so the right people see it.
Get help with this idea
A mentor can help you pick a problem that is reachable and small enough, review your interview guide for leading questions, and check that your evaluation will convince examiners. You do the research; the guidance is on scope and method. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.