Weeks 4–9: Product Studio Guide

Weeks 4–9 are your Product Studio — eight weeks to go from a project idea to a working, validated product. This guide covers the professional practices that separate a student project from a professional product development process.

Week 4 focus: your first sprint

This page covers the whole development phase. In Week 4 specifically, you will set up your workflow, prioritise your features, and deliver your first end-to-end working feature. Pathfinder Checkpoint 1 happens between Weeks 3–6.

---

What Is a Sprint?

A sprint is a short, focused period of development — usually 1–2 weeks — at the end of which you have something working to show.

The idea comes from Agile development, a way of working used in almost every software company in the world. Instead of planning the entire product upfront and building it all at once, teams work in short cycles:

Plan → Build → Test → Review → Plan again

Each cycle, you learn something. Each cycle, you improve.

Why it matters for you: In 8 weeks, surprises will happen. Scope will be larger than expected. Features will break. Team members will fall ill. Sprint-based working gives you a structure to absorb those surprises without the whole project falling apart.

Discovery prompt

“Explain Agile development to someone who has never worked in software. What problem was it invented to solve? Use an analogy to something non-technical.”

---

Setting Up Your Kanban Board

Before you build anything in Week 4, set up a Kanban board. This takes 20–30 minutes and will save hours of confusion throughout the project.

What is a Kanban board?

A Kanban board is a visual way to see what your team is working on. It has (at minimum) three columns:

To Do	Doing	Done
Tasks no one has started	Tasks someone is actively working on	Tasks that are complete

Every task lives in exactly one column. At a glance, anyone on the team can see: what needs doing, who is working on what, and what is finished.

Choosing a tool

Tool	Best for	Access
GitHub Projects	Teams using GitHub for code	Free, linked to your repo
Gitee Projects	Teams using Gitee (common in China)	Free at gitee.com
Trello	Simple boards with drag-and-drop	Free at trello.com

Pick one tool your whole team will actually use. The best Kanban board is the one everyone opens every day.

Discovery prompt

“Show me how to set up a basic Kanban board for a software project in [GitHub Projects / Trello / Gitee]. What columns should I create, and how should I write the task cards?”

How to write a good task card

A task card should be specific enough that the person who picks it up knows exactly what “done” means.

Too vague	Better
”Work on login"	"User can log in with email + password and see their dashboard"
"Fix bug"	"Fix: app crashes when user submits empty form on registration page"
"Design screens"	"Design Figma mockup: homepage and product detail page — ready for user testing”

---

Team Roles: Who Does What

Before you start filling your Kanban board with tasks, agree on who is responsible for what. In a 7-person team, unclear ownership is the most common reason things fall through the cracks.

Roles in a product team

Role	Primary responsibilities	Assessed through
Product Manager	Sets sprint goals, runs standups, owns the product vision	Dev Log quality, Pathfinder Checkpoint preparation
UX / UI Designer	Figma mockups, user flows, visual design decisions	Evidence links in Dev Log, usability test results
Frontend Developer	Builds what users see — screens, buttons, interactions	GitHub commits, working features
Backend Developer	Data storage, APIs, server logic	GitHub commits, Technical Documentation
User Researcher	User interviews, usability sessions, analysis	Validation Report, interview notes in Dev Log
Technical Lead	Architecture decisions, code quality, GitHub management	Technical Documentation, code review
Documentation & IP	Dev Log quality, Technical Docs, IP Strategy section	Dev Log entries, Week 11 documentation

Roles overlap — and that is expected

This is a team of 7, not 7 separate contractors. One person might do both UX Design and User Research. A backend developer might also be the Technical Lead. What matters is that every role has a named owner — not that each person does exactly one thing. The Dev Log records individual contributions by name, so there is no hiding behind “the team did it”.

If you did not assign roles in Week 2

Do it now, at the start of Week 4. Take 10 minutes:

1. Read the roles table aloud together
2. Each person picks their top 2 interests (what do you want to learn? what do you do well?)
3. Assign the 7 roles — overlap is fine, gaps are not
4. Record the role assignments in this week’s Dev Log entry

Role assignment prompt

“I am joining a product development team. The available roles are: Product Manager, UX Designer, Frontend Developer, Backend Developer, User Researcher, Technical Lead, Documentation & IP. I am most interested in [your interests]. Which role would help me develop most professionally this semester, and what specific tasks would I own?”

---

MoSCoW: How to Decide What to Build

You have more ideas than time. MoSCoW is a simple tool to decide what to build first.

Letter	Meaning	Ask yourself
M — Must have	Your product cannot work without this	”If this is missing, the product fails?”
S — Should have	Important, but you could launch without it	”Would users notice and care if it was missing?”
C — Could have	Nice to have if time allows	”Is this a bonus feature?”
W — Won’t have (this time)	Deliberately cut — might come back later	”Is this out of scope for 8 weeks?”

How to use it in Week 4

1. List every feature your team has discussed
2. Each team member independently labels each feature M / S / C / W
3. Compare labels — discuss disagreements
4. Agree on your Must have list — this is what you build in Weeks 4–6
5. Everything else goes into Should / Could / Won’t — revisit in Week 7

Common mistake: too many Must haves

If everything is a Must, nothing is. A product with 3 Must haves that all work well beats a product with 10 Must haves where 7 are half-finished. Be ruthless.

Discovery prompt

“Explain MoSCoW prioritisation to someone who has never used it. Give me an example using a food delivery app — categorise 10 features into Must / Should / Could / Won’t.”

---

Your First End-to-End Feature

In Week 4, you build your first end-to-end (e2e) feature.

What “end-to-end” means

An end-to-end feature is one that works completely — from the moment the user starts the action to the moment they get a result. Not a button that doesn’t connect to anything. Not a screen that doesn’t save data. The full flow.

Not end-to-end	End-to-end
A sign-up form that looks nice but doesn’t save anything	A sign-up form where the user’s account is created and they are logged in
A product listing page with fake data	A product listing page that shows real data from a database
A Figma prototype that clicks through screens	A working app where screens actually respond to input

Why does this matter? A Figma prototype is not a product. Wireframes are a design tool. Your tutors assess a working product. The sooner you have one real thing working end-to-end, the better you understand what is actually hard about your project.

Week 4 target

By the end of Week 4, at least one feature should work end-to-end. It can be simple — a user can sign up, or a form submits and saves data, or a sensor reading appears on screen. Real, but minimal.

---

Pathfinder Checkpoints

You have two structured pathfinder checkpoints during the Product Studio:

Checkpoint	Window	Focus
Checkpoint 1	Weeks 3–6	Is your project on track? Is the scope realistic?
Checkpoint 2	Weeks 7–9	Are you Demo Day-ready? Is documentation progressing?

What to bring to a checkpoint

At least 24 hours before the session, submit a written agenda to your pathfinder with four things:

1. What we did since the last checkpoint (with links to evidence)
2. Where we are blocked (specific problems, not general frustration)
3. A link to our work (Dev Log, GitHub, Figma — something live)
4. One specific question for the pathfinder

This format is a professional practice. At a real company, this is how you prepare for a status meeting with a manager or client.

What pathfinders do — and don’t do

Pathfinders provide process coaching: helping you plan, review your methodology, resolve team issues, and verify progress. They do not debug code, fix hardware, or architect your system. Bring process questions — “Are we validating correctly?”, “How should we structure our Dev Log entry?” — not technical questions.

---

The Development Log: Keeping It Real

Your Development Log should be updated every week, not retrospectively. Here is a template for each entry:

Week [N] — [Date range]

🟢/🟡/🔴 Status: [On track / At risk / In crisis — one honest sentence]

This week we:
- [Name]: [what they did, specific and verifiable]
- [Name]: [what they did]
  (add everyone who contributed)

Evidence links:
- [GitHub commit or PR link]
- [Figma file link]
- [Interview recording or notes]
  (aim for 3–5 real links)

Key decision: [One choice your team made and why]

Next week's plan: [What you intend to complete — be specific]

Individual contributions (written by each person):
- [Your name]: [30–50 words about your specific contribution this week]

Traffic light system

Status	Meaning
🟢 On track	You are doing what you planned. No blockers.
🟡 At risk	You are behind or facing a significant problem, but have a plan
🔴 In crisis	You are stuck with no clear path forward — flag this to your pathfinder immediately

Being honest about 🟡 or 🔴 status is not a failure. It is professional. Teams who hide problems until Week 9 end up with nothing for Demo Day.

---

Week-by-Week Focus

Week	Main focus	Key deliverable
4	Sprint 1: first e2e feature, Kanban setup	First working feature + Pathfinder Checkpoint 1
5	User validation + AI integration	3–5 user sessions documented
6	Sprint 2: second e2e feature	Second working feature
7	IP research + Sprint 3 self-directed	IP section draft + continued validation
8	User testing at scale + quality control	10+ documented user sessions + fixes
9	Iteration, pitch rehearsal, portfolio prep	Pitch deck draft + Pathfinder Checkpoint 2

---

Common Mistakes — and How to Avoid Them

Mistake	What it looks like	What to do instead
Building without testing	6 weeks of code, then testing once in Week 8	Test with users every 2 weeks from Week 5
Weak Dev Log entries	”Made progress on the app this week” (no names, no links)	Name every contributor, link every piece of work
Scope creep	Adding features in Week 7 that weren’t in the Must list	Freeze scope by Week 6 — finish what you started
Hidden blockers	Not telling pathfinder you’re stuck until Week 9	Use 🔴 status and message pathfinder immediately
Wireframes instead of working features	Presenting Figma screens at Demo Day	Build a working prototype — even a basic one

---

Resources

Resource	Link
Product Development Glossary	reference/product-glossary
User Testing Guide	Weeks 4–9: User Testing
Assessment rubric	Assessment Brief