Week 08 · Days 36–40
Technical Fluency
Build confidence working with engineers: APIs, agile ceremonies, and writing technical specs.
Portfolio deliverable · A technical spec / engineering handoff doc
How APIs work (PM-level)
Lesson: APIs explained for PMs
An API is a contract: your app sends a request (e.g. 'give me this user's order history') to another system, and gets back a response (usually structured data in JSON). For PMs, the practical implications: every integration or third-party data source involves an API, and APIs have constraints — rate limits (how many requests per minute), required fields (you can't get data the API doesn't expose), and latency (response time, which affects perceived speed). When scoping a feature that 'just needs to pull data from X,' check the API docs first — sometimes the data you assumed was available simply isn't exposed, which changes your entire approach.
Task: Find and read an API doc
Find the public API documentation for your practice app (or a similar one) and identify 3 endpoints relevant to a feature you'd want to build.
Agile & scrum basics
Lesson: Agile ceremonies & PM's role
In Scrum, work happens in sprints (usually 1-2 weeks). Sprint planning is where the team commits to what they'll build this sprint — the PM's job is to bring a prioritized, well-defined backlog so the team isn't guessing at scope. Daily standups are brief status syncs (15 min) — PMs attend to stay informed and unblock things, not to micromanage. Backlog grooming is ongoing refinement of upcoming work — PMs write/clarify tickets before they're needed, not the night before. Retros are team reflections on what went well/poorly — PMs should participate as a team member, not just present findings. The common thread: the PM's job in ceremonies is providing clarity, not chasing status.
Task: Write sprint-ready tickets
Take 2-3 user stories from Week 3 and break them into engineering tickets with clear acceptance criteria, ready for a sprint.
Technical tradeoffs & estimation
Lesson: Understanding technical debt & tradeoffs
Technical debt is the accumulated cost of shortcuts taken to ship faster — like a loan with interest: it speeds things up now but makes future changes slower/riskier. A 'simple' feature can take longer than expected because it touches a part of the codebase with existing debt, requires changes to several systems instead of one, or needs new infrastructure (e.g. a new data pipeline) that isn't visible from the user-facing side. As a PM, you don't need to evaluate code — but you should ask 'what does this touch?' and 'is there existing debt here?' early, and trust engineers' estimates more when they explain the 'why' behind them. Productive conversations frame scope as a dial, not a binary: 'what's the smallest version that still solves the core problem?'
Task: Write 'what could go wrong' for your feature
For your tickets from Day 37, write out 3 technical risks or edge cases an engineer might raise, and how you'd respond.
Writing a technical spec
Task: Draft a technical handoff doc
Write a 1-page technical handoff doc: feature summary, API/data needs, edge cases, tickets, and open technical questions for eng.
Synthesize: Polish technical spec
Deliverable: Technical Spec
Polish your technical handoff doc for portfolio. Add context linking back to your PRD from Week 3 to show the full PM workflow.
Advanced Challenge: Write an LLM feature architecture brief
Write a 1-page technical brief for your AI feature PRD from Week 3, covering decisions a PM should understand even without writing code: Where does context come from (RAG/retrieval from your data, vs relying on the model's training knowledge, vs both)? What's the fallback chain when the model is uncertain (ask a clarifying question → escalate to search → escalate to human)? What needs human review before launch (a golden test set of prompts + expected good/bad outputs, reviewed by the team)? What's logged for evaluation post-launch? Use REST API integration language from your background — frame this as you would for engineers who'd be building on Claude or a similar model.