3 exercises — communicate with product managers about timelines, scope changes, and technical feasibility.
0 / 8 completed
1 / 8
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 / 8
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 / 8
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]
4 / 8
Alex, the junior developer, has just submitted a pull request with a complex refactoring of the user authentication module. The product manager, Sarah, comments: 'This looks great! Can you merge it?' What's the best response to ensure Sarah understands the potential implications?
This scenario tests communicating technical risks to a non-technical audience. Simply saying 'yes' doesn't adequately address Sarah's question. Option 1 demonstrates proactive communication by highlighting potential impacts and initiating a discussion before merging – crucial for maintaining quality and compliance. Options B, C, and D are insufficient because they either avoid the issue or assume understanding without providing context.
5 / 8
You're in a Slack channel discussing a critical bug impacting user login. The lead engineer, David, writes: 'Just deployed the fix!'. The QA team immediately reports that the issue is *still* present. What's the most appropriate follow-up message to David?
This assesses communication in a reactive situation. David's initial statement is premature and potentially misleading. Option 1 doesn't acknowledge the ongoing problem. Option 2 demonstrates accountability by requesting information about the issue's status, showing you are actively monitoring the situation and demanding an explanation. Options B and C are dismissive or simply confirm the deployment without addressing the core concern.
6 / 8
Maria, a product manager, asks you: 'Can we integrate with Stripe for payment processing?' You respond with: 'The API is well-documented and relatively straightforward to implement. We can get this done in a week.' What's the most effective way to further communicate this?
This focuses on providing realistic estimates and acknowledging potential complexities. While 'easy' might seem reassuring, it lacks crucial detail. Option 1 is vague. Option 2 offers a more precise timeline by incorporating testing and highlighting potential challenges (rate limits), demonstrating a deeper understanding of the integration process – essential for managing expectations. Options B and C are overly optimistic or delegate responsibility without providing sufficient information.
7 / 8
During a standup meeting, Ben reports: 'I'm working on the user profile update feature. I've completed the UI changes and am now implementing the API calls.' The engineering manager asks, 'What are the next steps?' What's the best response?
This tests providing concise updates during a standup meeting. Ben's initial response is incomplete and doesn't convey his progress or planned next steps. Option 1 indicates unresolved issues. Option 2 provides a clear estimate for the remaining work. Option 3 confirms completion, which is good, but doesn't answer the manager's question about *next* steps. Option B offers a succinct update on the current task and a reasonable timeframe.
8 / 8
You are writing a pull request description for a change to the database schema. The product manager, Chloe, asks: 'Can you explain why this change is necessary?' What's the most effective way to respond?
This scenario focuses on providing clear justification for technical changes. Simply stating 'because' is unacceptable. Option 1 offers no explanation whatsoever. Option 2 provides a business-oriented reason – improved performance – which directly addresses Chloe's question and demonstrates the value of the change. Options B and C are either evasive or lack context, failing to explain the *why* behind the technical decision.
This exercise, "Explaining to Product", tests your understanding of tech-to-business vocabulary and phrasing through 8 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 8 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Tech-to-Business exercise for?
It's designed for IT professionals and learners who want to sound natural discussing tech-to-business topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Tech-to-Business exercises?
Browse the full Tech-to-Business exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.