Week 03 · Days 11–15
Product Sense & Strategy
Practice writing PRDs and developing product strategy / vision documents.
Portfolio deliverable · A 1-page PRD for a new feature
What makes a good PRD
Lesson: PRD anatomy
A good PRD answers 'what are we building and why' so clearly that an engineer, designer, and exec could each read it and know what to do next. Core sections: Problem statement (the user pain, backed by evidence — not 'we should build X'), Goals & Non-goals (non-goals prevent scope creep — explicitly say what's out of bounds), User stories (who needs what and why), Success metrics (how you'll know it worked), Requirements (functional specs, often split must-have vs nice-to-have), and Open questions (unresolved decisions — writing these down builds trust, it doesn't look like weakness). Keep it to 1 page; longer PRDs get skimmed, not read.
Task: Identify a feature gap
Using your practice app + Week 2 research, identify ONE feature gap or improvement opportunity. Write a 2-sentence problem statement.
Lesson: What's different about an LLM-feature PRD
A PRD for an AI-powered feature needs everything a normal PRD has, plus three things traditional PRDs don't cover. First, a behavior spec for the non-deterministic parts — since outputs vary, define the boundaries of acceptable responses (tone, length, what it should never say) rather than exact outputs. Second, an evaluation plan — how will you measure quality before and after launch (golden test sets, human eval rubrics, automated checks for hallucination/refusals)? Third, a fallback/escalation design — what happens when the model is wrong, unsure, or the user is frustrated (hand off to search, human support, or a simpler deterministic flow)? This lesson turns those requirements into a repeatable PRD structure.
Writing user stories & success metrics
Lesson: User stories & acceptance criteria
The format 'As a [type of user], I want to [do something], so that [benefit]' forces you to justify every requirement in terms of user value, not just functionality. The 'so that' clause is the part most people skip — but it's what lets engineers make smart tradeoffs when edge cases come up. Acceptance criteria turn each story into something testable: 'Given [context], when [action], then [expected result].' If you can't write acceptance criteria for a story, the story is probably too vague to build.
Task: Write 3-5 user stories + success metrics
For your feature idea from Day 11, write 3-5 user stories and define 2-3 success metrics (how you'd know it worked).
Competitive analysis
Lesson: Competitive teardown framework
Feature-by-feature comparison tables are table stakes — the real insight is in positioning and strategy. For each competitor, ask: who are they trying to win (their target user might differ from yours), how do they make money (subscription, ads, transaction fees — this shapes what they'll prioritize), and what bet are they making with their roadmap? Two competitors can solve the 'same' problem in opposite ways because they're optimizing for different things (e.g. one prioritizes simplicity for casual users, another prioritizes power-features for retention of heavy users). Identify the bet, not just the feature.
Task: Teardown 2 competitors
Pick 2 apps that compete with your practice app on the feature you identified. Compare their approaches in a table.
Drafting the PRD
Task: Draft full PRD
Combine everything from this week into a full 1-page PRD: problem, goals/non-goals, user stories, success metrics, requirements, open questions.
Synthesize: Polish & publish PRD
Deliverable: Published PRD
Polish your PRD for portfolio-readiness. Add a short intro paragraph explaining the context (your research from Week 2 informed this).
Advanced Challenge: Write a second PRD for an AI-powered feature
Write a second, shorter PRD (can be 1 page) for an AI-powered version of your feature idea — e.g. instead of a static filter/search UI, a conversational assistant that helps users find what they need. Include the three LLM-specific sections from Day 11: behavior boundaries (what it should/shouldn't do), an evaluation plan (how would you build a golden test set of 10-15 example queries with expected good/bad responses?), and a fallback design. Ground the PRD in real user needs and operational constraints so it feels practical, not theoretical.