3 exercises — communicate with product managers about timelines, scope changes, and technical feasibility.
0 / 3 completed
1 / 3
A product manager wants a feature in 2 weeks. After investigation, you believe it will take 5–7 weeks. How do you communicate this?
Option C is the professional approach to estimation feasibility disagreement. It:
1. Shows work — breaks down the estimate by system, making it auditable and credible 2. Names the hidden complexity — the existing bug that must be addressed (invisible to the PM) 3. Includes external dependencies — App Store review (often forgotten in estimates) 4. States a range, not a point estimate — "5–7 weeks" (acknowledges uncertainty) 5. Opens a negotiation — "smaller version in 2 weeks?" — collaborative, not adversarial
The last point is critically important: when engineers say "estimates" are just technical statements, they miss that PMs are trying to plan. Offering an alternative ("smaller version") gives the PM something to work with and builds trust.
Estimation language patterns: • "My best estimate is X, assuming [conditions]" • "This has 3 unknowns — let me do a spike this week before committing to a date" • "If we scope down to just [X], we could hit your deadline"
2 / 3
A product manager adds a feature to the current sprint mid-week: "This should only take a few hours — can we just add it?" Which response is most professional?
Option C is the professional response to mid-sprint scope creep. It:
• Says yes to looking at it — not a blanket "no" • Makes the trade-off explicit — "what gets swapped out?" — forces the PM to engage with the constraint • Names currently committed items — makes the conflict visible • Shows flexibility — "if this is genuinely urgent, we can swap" • Requires mutual agreement — "I want us both to be explicit"
This response protects the sprint without being defensive. It re-frames "can you add X" into "should we swap X for Y?" — which is the correct conversation.
Scope change communication patterns: • "What should come out to make room for this?" • "Happy to prioritise this — what does it deprioritise?" • "This would be a scope change; let's do that formally so everyone's aligned" • "I can give you [X] by Thursday if I drop [Y] — is that the right trade?"
3 / 3
The product manager asks: "Is it technically feasible to add real-time collaborative editing to our notes app?" Which response demonstrates effective technical feasibility communication?
Option C is the model technical feasibility response. It addresses all three dimensions product managers need:
1. Feasibility verdict — "yes, this is a solved problem" — instant clarity 2. Precedent — citing Google Docs, Notion, Figma establishes that this is industry-standard, not experimental 3. Effort estimate — "3–6 months" — rough but actionable for project planning 4. Key decisions — CRDT vs. OT, WebSocket infrastructure — the PM now knows what questions to explore 5. De-risking proposal — "1-week spike to validate constraints" — shows engineering maturity
Option A ("yes, we can do it") is dangerous without scope — the PM will hear "yes, we can do it this sprint". Option D ("it depends") is the worst answer — it provides no useful information and frustrates the asker.
Feasibility response template: [Verdict: yes/no/qualified] + [reference to similar solved problems] + [rough effort] + [key unknowns] + [next step to reduce uncertainty]