Week 3: Project Planning

Today’s goal

By the end of this session your team has chosen a project, sketched your first screens, and started your Project Brief. The 8-week Product Studio begins.

Project Brief — how it works

When	What
March 27	Submit your first version on LMO. Same deadline for all sessions.
Until April 10	Update it any time. Use feedback from your pathfinder.
April 10	Locked. No more changes.
Week 11	Submit it again as part of your Portfolio. That is the graded version (5%).

The March 27 submission is not graded. It is a checkpoint — your pathfinder uses it to see where you are. Write your best draft now. Update it as your project develops. The grade comes at the end.

Smart Product Challenge video — deadline extended to Week 6

Friday March 20, 2026 → Friday April 10, 2026, 23:59 Beijing Time — one MP4 per team via LMO. Hold the file until your team is confirmed.

---

What can your Product Studio project be?

Weeks 1–2 were shared orientation — Product Studio starts now.

Type	Good if your team…
📱 Mobile app	Wants something on people’s phones — social tools, campus utilities, productivity
🌐 Web platform	Needs a dashboard, booking system, or anything browser-based
🎮 Game	Has Creative Tech students and wants to build something interactive
🔌 IoT / Hardware	Enjoyed Weeks 1–2 and wants to continue building connected devices
🤖 AI / data tool	Has Engineering or Business Analytics students keen on working with data
📊 Consultancy + prototype	Wants to solve a business problem with a strategy and a working demo

You do not have to use M5Stack hardware

Any of the project types above is valid. IoT / Hardware is one option — not a requirement. If your project is a mobile app, web platform, or AI tool, no hardware is needed. M5Stack components are available on loan if your project calls for them — see the Hardware Request page.

Product Studio is 90% of your grade

Pathfinders assess process — user research, iteration, and documentation — not technical complexity. A narrow project done well scores higher than an ambitious project done poorly.

Full assessment criteria →

---

Before You Arrive

Item	Why	Notes
Laptop + charger	You will set up GitHub and SharePoint	4-hour session — most batteries won’t last
Paper and pens	Design Thinking uses paper sketches	Provided in the room, but bring your own as backup
Phone	Photograph your wireframe sketches	Any camera will do
XJTLU SharePoint login	Setting up your Dev Log	Test at xjtlums-my.sharepoint.com before the session
Project ideas	Week 2 stretch section asked you to note 2–3 ideas	Not required, but saves 20 minutes

---

Your Session at a Glance

Block	What happens	Who leads
First ~35 min	Think individually — find signals, explore a problem, sketch an idea	You alone
Next ~25 min	Share with your team — frame the problem, vote on a direction	Your team
Next ~30 min	Gallery walk + stress test + pathfinder check	Your team
Next ~30 min	Sketch your product concept	Your team
Next ~20 min	Choose your Product Studio project + start the Project Brief	Your team
Remaining	Dev Log + GitHub setup	Your team

Do not skip to AI

Every semester, some teams open ChatGPT first. The AI generates something. The team builds it. In Week 5, they discover real users do not have the problem the AI described. They start over.

Work through the missions in order. Paper and thinking first.

How to use AI well today

The prompts throughout this guide are starting points — not scripts. After any AI response, keep the conversation going:

• “What am I missing?” — surfaces blind spots
• “What would a real user actually complain about?” — grounds the idea
• “Is this scope too big for 8 weeks? Be honest.” — reality check
• “Play devil’s advocate.” — stress-test before you commit

Short back-and-forth works better than one long prompt.

---

What is Design Thinking? (background reading, optional)

Design Thinking is a method developed by IDEO and Stanford d.school for solving real problems. It starts with the person, not the product. You will apply it again in Weeks 5–8 when you run user testing.

Quick video intro:

• Search “IDEO Design Thinking” on YouTube — the 5-minute explainer is widely used
• Search “设计思维 Stanford” on Bilibili for a Chinese-language introduction

Reading (excerpt): Future Ready: A Foresight Playbook for Innovators — Bogdan Marculescu. Chapter 1 covers Signals, the method behind Step A of Mission 1. A short excerpt is available in the Resources & Links section.

---

Mission 1 — Think First (~35 min)

Work alone. No group discussion yet.

Use paper and post-its — you will stick your observations onto the team’s A1 poster in Mission 2. One idea or observation per post-it. Write big enough for others to read from 50 cm away.

---

Step A — Find a signal (~8 min)

Think about daily life — yours, your family’s, people around you.

• What frustrates people regularly?
• What wastes time, costs money, or causes stress?
• What do people do manually that a digital product could handle?

Write 3–5 specific observations — one per post-it. Not general ideas — real situations you have seen or experienced.

Example post-it: “Flatmates argue about shared bills — WeChat notes, always out of date”

AI prompt — Step A

“I’m a university student looking for real problems worth solving with a digital product. Ask me 5 questions to help me notice genuine frustrations and unmet needs in daily life around me. After I answer, help me identify 2–3 signals worth exploring further.”

---

Step B — Go deeper (~8 min)

Pick the observation that interests you most. Explore it further on paper.

• Who specifically experiences this problem? Describe one real type of person.
• What do they do today to deal with it?
• Why is that current approach not good enough?

Write 4–6 sentences. The more specific, the better.

AI prompt — Step B

“I noticed that [describe your observation]. Help me understand this problem better. Who experiences it most? What do they currently do about it? What’s missing from existing solutions?”

---

Step C — Your idea seed (~8 min)

Sketch a rough idea for a product that could help. This is a starting point — not a final answer.

• What does it do?
• Who uses it?
• What is the one thing that makes it useful?

Write 3–5 sentences on paper, or draw a quick sketch. Then summarise your idea in one sentence on a post-it — this goes on your zone of the A1 poster.

AI prompt — Step C

“Based on this problem: [describe it]. Suggest 3 different digital product ideas that could help. For each: what it does, who uses it, and one realistic risk. Keep scope achievable for a team of 7 students with 8 weeks.”

Before Mission 2: Every person has 3–5 observation post-its and one idea-seed post-it ready to place on the poster.

---

Mission 2 — Find the Problem Together (~25 min)

Now share. Go around the table — each person shares their Step C idea in 1–2 minutes.

---

Step 1 — Hear everyone (~10 min)

No criticism while sharing. Write each idea where everyone can see — on your team’s A1 poster if you have one, or a shared document on screen.

One rule: listen first, questions after.

---

Step 2 — Frame the problem (~10 min)

Pick the idea with the most energy. Write a How Might We statement together:

How might we help [type of person] [do something better] so that [desired outcome]?

Example:

“How might we help international students in shared apartments split expenses fairly, so that no one has to be the ‘money person’?”

The HMW statement becomes the foundation of your Project Brief.

Common mistake

Do not write: “How might we build an app that…”

The HMW is about the person and the problem. Not the product.

---

Step 3 — Team vote (~5 min)

Everyone votes for the idea they most want to pursue — dot stickers on the poster, or a show of hands.

Highest votes wins. If it is genuinely tied, the team leader decides.

Before Mission 3: One HMW statement written and agreed by the full team.

---

Mission 3 — Gallery Walk + Stress Test (~30 min)

Your pathfinder is your team’s TA — they coach process, not technical problems.

Leave your poster on the table and walk to see what other teams produced. Then stress-test your own idea before returning.

---

Step 1 — Walk and react (~10 min)

Visit two other teams’ posters. Read their HMW statements and M2 ideas silently.

Leave post-its in their stress test zone using this format:

Post-it	What it means
I like…	Something specific that is strong about their idea
I wish…	Something you think is missing or unclear
What if…	A provocative question or wild extension

One post-it per team is enough. Be specific — “I like the HMW framing” is more useful than “good idea”.

---

Step 2 — Stress test your own idea (~10 min)

While you are away from your poster — or when you return — use this prompt on your own concept:

Stress test prompt

“Our concept is: [describe in 2 sentences]. Stress-test it honestly: 1. What is the single most likely reason this prototype fails at the demo? How do we prevent it? 2. What if a company like ByteDance or Tencent built this tomorrow — what would we still do better or differently? 3. What if this technology became free and available to everyone in 2 years — does our product still matter? Be honest. Short answers only.”

Write 1 key risk and 1 key strength on two separate post-its. Stick them on your poster. You will use them in Mission 4.

---

Step 3 — Pathfinder check-in (~5 min)

Invite your pathfinder to your poster for a 2-minute conversation:

• “Does our problem feel real to you?”
• “What would you challenge us on?”

Before Mission 4 (Sketching): Post-its on your poster, 1 key risk identified, 1 key strength noted, HMW still agreed.

---

Mission 4 — Choose Your Product Studio Project (~45 min in session)

This is the most important decision of your semester. The project you choose shapes everything from now until Demo Day (Week 10).

Read all the post-its on your poster from Mission 3 before deciding. The key risk you identified is your first constraint — your project choice should address it, not ignore it.

---

Step 1 — Choose your direction (~15 min)

Look at the project types at the top of this guide. Which type fits your team’s backgrounds and the HMW statement you wrote in Mission 2?

For each idea still in the running, ask three questions out loud:

• Can you build a working version in 8 weeks with your team’s actual skills?
• Is there a real user you can interview and test with?
• Does this excite at least most of the team?

Highest energy + most realistic = your project. If it is genuinely tied, the team leader decides.

---

Step 2 — Sketch it (~20 min)

Before committing in writing, sketch your product visually. Paper is faster than Figma — you can redraw in seconds and mistakes cost nothing.

Agree on the one core user action — the single most important thing a user does in your product.

Example: “User adds a shared expense and sees the updated balance.”

Sketch three screens:

• The first screen the user sees
• The screen where the main action happens
• The screen after the action is complete

Each team member sketches independently for 5 minutes. Compare, combine the best ideas into one shared version, and photograph it. This photo goes in your Dev Log.

These sketches will change — that is normal

A wireframe is a thinking tool, not a design spec. Its purpose is to make you think about the user experience before writing a single line of code.

---

Step 3 — Validate your problem assumption (before Friday)

Before finalising your brief, check that the problem is real. Choose one path:

Path	What you do
A — Talk to users	Ask 2–3 people about their real experience with the problem
B — Reuse ENT207TC research	Review your previous user findings (if your topic is related)
C — Competitive benchmark	Find 3–5 apps solving this problem and read their user reviews
D — Secondary research	Find Weibo, Xiaohongshu, or news sources confirming the problem
E — Assumption mapping	List your assumptions. Rank them by how confident you are.

One path is enough — for now

This week, you need enough evidence to commit to a direction. Structured usability testing (with tasks, observation, and iteration) starts in Week 5. But problem validation — confirming the problem is real — should be complete before Week 5 begins. If you only do a quick check today, aim to talk to 3–5 people total by the end of Week 4. See the Validation Guide for how.

For Path A, ask backward-looking questions about real past experience — not imagined futures:

• “Tell me about the last time you experienced [the problem].”
• “What did you do to deal with it?”
• “Why was that not good enough?”

If 2 out of 3 people confirm the problem — you have something worth building. If you only spoke to 2–3 people today, expand to 3–5 in Week 4 to complete Stage 1.

---

What is NOT a valid project

Not allowed	Reason
Report with no working prototype	This module requires something functional
Unethical product (gambling, misinformation, harmful content)	University policy
Trivial scope — no real user need	Not enough to validate over 8 weeks
Project that requires instructors to debug your code	Pathfinders coach process, not technical problems

---

Project acceptance criteria

Your pathfinder reviews your Project Brief in Week 3. They check four things:

Criterion	The question
Real problem	Can you name 2–3 real people who have this problem?
Achievable scope	Can your team deliver something working in 8 weeks?
Testable	Can you run user testing sessions with real people?
Process-focused	Does the project let you practise research, iteration, and documentation?

If your pathfinder asks you to reduce scope — do it. A narrow project done well scores higher than an ambitious project half-finished.

Viability check — do this as a team before writing the brief

Answer out loud. If any answer is “not sure”, that is the thing to fix before Friday.

1. Can you name 3 real people who have this problem right now?
2. Can your team ship something working in 8 weeks?
3. Can you run user testing sessions with real people during the semester?

If stuck on any of these: “We want to build [X]. We’re unsure whether [your specific question]. What are the risks and how would you reduce them?”

---

If you want to continue your ENT207TC project

You may continue a project from Digital Startup Lab — but understand what this requires.

ENT207TC rewarded speed. ENT208TC rewards rigour: validate before you build, document every decision, test with real users.

Before your team decides, answer these three questions individually — then compare:

1. What did your users specifically say was not working? (Quote actual feedback if you have it.)
2. What assumption did your team make in ENT207TC that turned out to be wrong?
3. If you were starting that project fresh today, what would you do differently in the first two weeks?

If you cannot answer Question 1 with specific user quotes, you did not collect enough user evidence last semester — which means your starting point is weaker than you think. New user research is not optional.

The recommended approach — what large companies do — is to start fresh. Use your ENT207TC user research and learning as inputs. Rebuild from scratch. If you decide to continue, these requirements apply without exception:

Requirement	What this means in practice
Rebuild from scratch	Do not submit the same codebase. Treat Week 4 as a new start.
New user research	ENT207TC findings can inform your brief. You must run new formal user sessions in Weeks 5–8.
Fresh documentation	Dev Log, Technical Documentation, and Validation Report must reflect this semester’s work only.

Continuing is at your own risk

Your pathfinder assesses ENT208TC process quality — not last semester’s work. Starting fresh with a clear scope almost always produces better results.

---

Need inspiration?

Check the Syntegrative Project list on LMO — the same resource from ENT207TC. It lists validated challenges from industry partners and university stakeholders. Real problems with real users already identified.

---

Start your Project Brief in session

Do this before you leave today

Open a Word document. Write one sentence for each of the four sections below. Finish the full draft before Tuesday. Starting now takes 10 minutes and saves your team a panicked Sunday night.

The Project Brief is a 2-page Word document (5% of your grade).

AI prompt — draft your brief in session

Use this after reading all your M3 post-its. It incorporates your gallery feedback and stress test into the brief in one go.

“We are finalising our project based on this concept: [describe in 2 sentences] Feedback we received from other groups: [list the key I like / I wish / What if post-its] Help us write a crisp project brief: 1. One sentence: what it does and who it is for. 2. List exactly 4 must-have features for a working prototype. 3. Category: App / Game / IoT-Hardware / AI-Data / Web Platform — which fits best? 4. If IoT or hardware: list every sensor or component you need — be specific. 5. What will your prototype demonstrate at Demo Day?”

Section	What it answers
Problem	Why does this matter? Who is affected?
Target Users	Who exactly are you building for?
Solution	What are you building?
Success Metrics	How will you know if it worked?

Writing each section:

Problem: Start with the situation, not the solution. Describe who has the problem, how often, and why their current workaround fails. Do not mention your product in this section.

Target Users: Be specific. Not “university students” — describe a type of person with observable characteristics and a real situation.

Solution: One paragraph. Start with “We are building…” Describe what the user experiences. Do not describe your technology stack here.

Success Metrics: List 3–5 specific, measurable outcomes — things you can actually observe or test.

Common mistakes

• Starting Section 1 with “We are building…” — that is the solution, not the problem
• Vague users: “our users are students” — too broad to be useful
• Unmeasurable metrics: “users will love it” — how do you test that?

→ Full template with word counts and examples: Project Brief Template

If your scope feels uncertain, message your pathfinder before Friday:

“We’re considering [X]. Does the scope seem realistic for 8 weeks?”

IoT or hardware project?

If your project needs sensors or components beyond the standard kit, you can submit a hardware request. Budget is limited and not guaranteed — loans only, returned at end of semester. M5Stack components only.

→ Hardware Request guide

---

Mission 5 — Dev Log + GitHub

---

Development Log

The Development Log is a shared document your team updates every week from Week 3 to Week 9. It is worth 20% of your grade. Start it today — do not wait until Week 4.

What it is

A Word document on XJTLU SharePoint where your team records:

• What you did — with names (“Ali interviewed 3 users”, not “we did interviews”)
• Links to your work (photos, GitHub, Figma, notes)
• One key decision your team made and why
• Each person’s individual contribution (30–50 words, written by that person)

Why it matters

The Dev Log is your primary evidence of individual contribution. Your pathfinder reads it to know what you specifically did. Entries written weeks later are obvious. Write them at the time.

Set it up — 5 steps

1. Go to xjtlums-my.sharepoint.com and sign in with your XJTLU email
2. Create a new Word document
3. Title it: ENT208TC Dev Log — [Team Name] — 2026
4. Set sharing to: “Anyone at XJTLU with the link can view and comment”
5. Copy the full template from ↳ Dev Log Template into your document — fill in the header with all team members’ names and student IDs
6. Paste your link into the Dev Log Link section of your Project Brief before submitting
7. Send the link to your pathfinder and the module leaders — contact details on LMO

→ Dev Log Template — open this in a new tab and copy the content directly into your SharePoint document.

Do not use Google Docs

The final submission requires an XJTLU SharePoint document with full version history. Google Docs does not produce this. If you start in Google Docs, you will need to move everything later.

Your Week 3 entry

Write your first entry this week. It counts toward your grade.

Week 3 entry template

Week 3 — [Date]

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

This week we:
- [Name]: [what they did — be specific]
- [Name]: [what they did]
  (list everyone who contributed)

Evidence:
- [Wireframe sketches photo — required this week]
- [Architecture sketch — see below]
- [Any other links: notes doc, Figma, GitHub]

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

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

Individual contributions:
- [Your name]: [30–50 words about your specific contribution this week]

Add your architecture sketch

Draw three boxes and connect them:

[What the user sees]  →  [Logic / backend]  →  [Data storage]
   (app / website)                               (database)

Add any extra services your project needs (AI API, payment service, third-party data). Photograph the sketch and add it to your Week 3 entry. It will change as you build — that is expected.

---

GitHub

Start a repository now, even before you write any code.

1. One team member creates a new repository on GitHub (or Gitee if preferred)
2. Add all team members as collaborators
3. Create a README.md with: project name, one-line description, team names
4. Add the link to your Dev Log

If your project is a consultancy + prototype, GitHub holds your documentation — that is fine.

New to GitHub?

“Explain GitHub to someone who has never used version control. What is it for? What are the 3 most important things a new team needs to know to start using it for a collaborative project?”

---

Complete by Friday March 27, 23:59

Task	Due	Where
Wireframe sketches photographed	In session	Add to Dev Log
Architecture sketch done	In session	Add to Dev Log
Problem validated (one path)	Before Friday	—
Project Brief (2-page Word doc)	Friday March 27, 23:59	LMO Turnitin — update until April 10, graded in Week 11
Dev Log created on XJTLU SharePoint	Before Friday	Share link with pathfinder
Week 3 Dev Log entry written	Before Friday	Your shared document
GitHub repo created	Before Friday	Add link to Dev Log
IoT / hardware teams: hardware needs flagged	Before Friday	Message your pathfinder
Smart Product Challenge video	Week 6 — April 10, 23:59	LMO — hold the file for now

---

AI prompts for this session — use with any AI tool (ChatGPT, Xipu, Kimi, etc.)

Copy and paste these prompts into any AI assistant you prefer. They follow the mission order. Replace the bracketed parts with your own content.

---

Mission 1 · Step A — Find a signal

“I’m a university student looking for real problems worth solving with a digital product. Ask me 5 questions to help me notice genuine frustrations and unmet needs in daily life around me. After I answer, help me identify 2–3 signals worth exploring further.”

Mission 1 · Step B — Go deeper

“I noticed that [describe your observation in 1–2 sentences]. Help me understand this problem better. Who experiences it most — describe the type of person specifically. What do they currently do to manage the problem? Why is that current approach not good enough? Suggest 3 questions I could ask a real person to validate whether this is a genuine problem.”

Mission 1 · Step C — Your idea seed

“Based on this problem: [describe it]. Suggest 3 different digital product ideas that could help. For each: (1) what it does in one sentence, (2) who uses it, (3) the one feature that makes it worth building, and (4) one realistic risk. Keep scope achievable for a team of 7 students with 8 weeks and no professional development experience.”

Mission 3 — Stress test

“Our concept is: [describe in 2 sentences]. Stress-test it honestly: (1) What is the single most likely reason this prototype fails at the demo? How do we prevent it? (2) What if a company like ByteDance or Tencent built this tomorrow — what would we still do better or differently? (3) What if this technology became free and available to everyone in 2 years — does our product still matter? Be honest. Short answers only.”

Mission 2 — HMW framing

“My team is working on this problem: [describe it]. Help us write 3 different ‘How Might We’ statements that frame the problem from the user’s perspective — not from our solution. Then tell us which framing is sharpest and why. The best HMW is specific enough to guide design but open enough to allow multiple solutions.”

Mission 4 — Evaluate your project idea

“I am planning a project for a university module that assesses process over technical complexity. The project runs 8 weeks with a team of 7 students from different disciplines. We are assessed on: structured user research, iterative development, professional documentation, and teamwork. Here is our idea: [describe it]. Evaluate it against these criteria: (1) Is the user problem clear and real — can we name specific people who have it? (2) Is the scope achievable in 8 weeks by non-professional developers? (3) Can we run at least 3 user testing sessions with real people? (4) What are the top 3 risks, and what is one concrete action to reduce each?”

Mission 4 · ENT207TC continuation — reflection

“In a previous semester I worked on a project: [describe it briefly]. Here is what I remember about the user feedback we received: [describe it]. Help me identify: (1) What the strongest user insights were, (2) What assumptions we made that were not validated, and (3) What a clean restart of this project in a new semester should prioritise in the first two weeks — specifically for a module that rewards structured validation over speed.”

Mission 5 — Understanding the Development Log

“What is a Development Log in a software engineering or product management context? What makes a good weekly entry — and what are common mistakes that make entries weak? Give me an example of a strong Week 3 entry for a team that has just chosen their project, sketched wireframes, and set up their GitHub repository.”