Product Manager Interviews Module 5 – Execution, prioritisation and technical rounds
Deadlines, scope cuts and launch readiness
Handle a slipping launch in a product interview: pick the lever, cut scope with MoSCoW, set launch criteria and roll out in stages behind a feature flag.
What you will learn
- Choose between cutting scope, moving the date and adding people when a launch slips
- Define launch criteria and make the go or no-go decision against them
- Plan a staged rollout with a feature flag and a rollback trigger
Before you start
What you’ll learn · Before you start
What you will learn
- Choose between cutting scope, moving the date and adding people when a launch slips
- Define launch criteria and make the go or no-go decision against them
- Plan a staged rollout with a feature flag and a rollback trigger
Before you start
On this page
Five weeks before an announced launch, the team behind an invented food-delivery app’s group ordering finds 28 engineer-weeks of work left and 20 to do it in. An execution question about deadlines asks what you change: the scope, the date, the people or the quality bar, and how you will know the launch is ready.
Below, you choose a lever for that slip, make scope cuts with MoSCoW, write launch criteria that turn launch readiness into a check, and plan a staged rollout behind a feature flag, with a rollback trigger.
When a deadline slips, four levers can move
Group ordering is two weeks late on paper: 28 engineer-weeks of work, 4 engineers, 5 weeks. Cutting scope ships less on the date. Moving the date ships everything, later. Adding people puts more engineers on the same work. Lowering the quality bar ships with less testing.
The levers are not equal. DSDM, the Agile Business Consortium’s method, fixes time, cost and quality and negotiates the features. For fixed deadlines, that makes scope the first lever. Adding people pays off slowest: Frederick Brooks observed that adding people to a late software project makes it later, because newcomers must learn the work before they help and every extra person adds communication. Answer the questions about your own launch:
Answer the questions above: the table then marks what fits your case and says why the rest does not.
| Lever | Time it saves | Risk to users | Cost | Trust it keeps |
|---|---|---|---|---|
| Cut scope What changes: less work ships on the date | Good Whole requirements go: two Could Haves fit 28 engineer-weeks into 20 | Good The Must Haves ship as planned; what is missing was optional | Good No new cost: the cut work moves to the next release | Mixed The date holds; whoever wanted a cut item needs to hear when it comes |
| Move the date What changes: all the work ships, later | Good As much as needed: the full scope ships, later | Good Nothing ships half done | Mixed Every week late is a week of value lost | Poor An announced date that moves costs credibility with partners and users |
| Add people What changes: more engineers on the same work | Mixed Only when added early: new people need weeks before they help | Mixed More people working in code that is new to them | Poor Their time, and the existing team's time spent helping them | Mixed Keeps the date only when enough time is left |
| Lower the quality bar What changes: less testing, known bugs shipped | Mixed Saves the testing time, once | Poor Users meet the bugs the tests would have caught | Poor Fixes after launch cost more and come too late | Poor A broken launch costs more trust than a late one |
How the answers decide
- “Is the date fixed by something outside the team, such as an announced campaign?” Yes, it is announced or promised: adds a caveat to Move the date and Lower the quality bar. An announced date costs trust when it moves, and shipping known bugs to keep it trades a late launch for a broken one. Cut scope first.
- “Is the date fixed by something outside the team, such as an announced campaign?” No, it is the team's own target: rules out Lower the quality bar. A date the team set itself can move, so there is no reason to ship below the quality bar.
- “What kind of work is late?” Only Must Haves are left: rules out Cut scope. When only Must Haves are left, cutting scope ships something people cannot use. The date and the team are the levers left.
- “How much time is left before the date?” A few weeks or less: rules out Add people. New engineers need weeks before they help, and the team loses time helping them. With a few weeks left they rarely save the date, and near the end they make it later.
- “Could new engineers take separate parts of the work without much help?” No, it is one tangled piece: adds a caveat to Add people. Work that cannot be split makes each new person a cost to everyone already on it.
Checkpoint
Check: The four levers of a slipping launch
Scope cuts keep the date by removing what users can do without
MoSCoW turns scope cuts into a rule agreed before any slip: Could Haves are the contingency and go first, then Should Haves, while the Must Haves, the minimum usable subset, stay. Group ordering was sorted that way:
| Requirement | Priority | Engineer-weeks |
|---|---|---|
| Add dishes to one shared basket | Must | 6 |
| One person pays and orders | Must | 4 |
| Invite friends with a link | Must | 2 |
| Each dish shows who chose it | Should | 4 |
| A spending limit set by the host | Should | 4 |
| Split the bill in the app | Could | 5 |
| A group chat | Could | 3 |
Cutting both Could Haves leaves 20 engineer-weeks, exactly the capacity, with nothing spare for a surprise. Cutting the spending limit too leaves 16: four weeks of work and one spare. Good scope cuts come with a date for what was cut.
Key idea
Cut scope before you move a date: drop the Could Haves first, keep the minimum usable subset, and give every cut item a place in the next release.
Checkpoint
Check: Scope cuts with MoSCoW
Launch readiness is a check against criteria written in advance
A launch is ready when it meets launch criteria: The limits a launch must meet, written before it starts: quality bars such as crash-free sessions, guardrail limits, support, legal and privacy checks, and a tested way back, each with the stage it must hold by. that the team wrote before anyone had a favourite answer. Google’s SRE book notes that checklists are used to “reduce failure and ensure consistency and completeness”, and keeps one for launches in which each question must earn its place, ideally from a past launch that went wrong:
| Criterion | Limit | Before |
|---|---|---|
| Crash-free sessions | At least 99.5 % | 1 % |
| Payment errors | None known | 1 % |
| Privacy and legal checks | Done | 1 % |
| Turning the feature off for everyone, tested | Done | 1 % |
| Accessibility check against WCAG 2.2 AA | Passed | 1 % |
| Orders cancelled | At most 0.5 points above users without it | 10 % |
| Help articles and trained support | Ready | 10 % |
| Time to place an order, 95th percentile | 3.0 seconds or less | 50 % |
With criteria like these, launch readiness stops being a debate: the go or no-go call reads each number against its limit. Each criterion also names the stage it must hold by, so a launch can start before the last one is met.
Checkpoint
Check: Launch criteria and the go or no-go call
A staged rollout behind a feature flag keeps a way back
A feature flag: A switch in the code that turns a feature on or off for chosen users without a new release, so a launch can start with a few users and be undone in seconds. lets code ship switched off, so turning a feature on becomes a separate decision that can be undone in seconds. The SRE book describes flag-guarded changes that grow to a limited group, “usually between 1 and 10 percent” of users, and can be reverted “immediately in the event of serious bugs”. A staged rollout: A launch that turns a feature on for a growing share of users, such as 1 %, 10 %, 50 % and then everyone, checking the launch criteria at each stage before the next. repeats that step until everyone has the feature. The week the scope cut saved is the week this rollout needs:
- Before day 1
Shipped, switched off flag off
The code reaches every phone with group ordering switched off by a feature flag. Engineers turn it on for themselves first, so the release and the launch become two separate decisions.
- Day 1
1 % of users
The flag turns group ordering on for 1 % of users. The checks: crash-free sessions, payment errors and the time to place an order, each against its launch criterion, before the next stage.
- Days 2 to 4
10 % of users
A larger group shows rarer problems. The orders of the 10 % with group ordering are compared with those of the 90 % without it, cancellations and refunds included.
- Days 5 and 6
Half of all users
At 50 %, the busiest dinner hour tests the load on payments and on restaurants. The time to place an order must stay inside its criterion at that hour.
- Day 7
Everyone launch
Group ordering reaches everyone on the announced date. The flag stays in place for a few weeks as an off switch, then the code that checks it is removed.
- Any stage
The rollback trigger rollback
A launch criterion clearly broken at any stage, such as payment errors, turns the flag off for everyone at once, without a meeting. The team fixes the cause and starts again at 1 %.
The timeline has 6 events, from Before day 1 to Any stage.
Decide the rollback trigger before day 1, so turning the flag off needs no meeting. Teams that run a service to a target add one more rule: while The share of requests a service may fail in a period before it misses its reliability target. A target of 99.9 % successful requests leaves a budget of 0.1 %. remains, releases continue, and when failures spend it, releases are halted for a while.
Checkpoint
Check: Staged rollouts behind a feature flag
Practise: three slips, three levers
Choose the lever for each slip:
Checkpoint
Three slips: choose the lever
After that, the self-check asks first about the lever, criterion or rollout step you answered least well.
Practice that adapts to you
Practise this lesson
13 questions about 6 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.
A slipping launch, decided at three points Pro: opens with a Pro, Premium or Ultimate pass
Group ordering goes from the slip to the announced date through three decisions: a scope cut, a go or no-go call with one criterion still open, and a rollback. Each is made against numbers written down in advance.
In this part:
- Three decision points, on one timeline
- What each lever would have bought in week 0, with numbers
- Why adding people in week 5 makes the launch later
- The go or no-go call, read against the criteria
- A rollback planned before it was needed
- The whole launch, said in an interview in under a minute
1 diagram · 1 runnable example (Python) · about 6 minutes
Opening this part with your pass…
This part opens with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so this part can’t be opened at the moment. The free part above stands on its own. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
Launch-week curveballs, answered Pro: opens with a Pro, Premium or Ultimate pass
Three other surprises could have met the same launch in its last two weeks. Each is answered with a decision table: the options, the call and what the team hears.
In this part:
- The engineer who knows the payment code resigns two weeks out
- The accessibility check fails the day before launch
- Crashes rise on one phone model at the 1 % stage
- What each level adds to a launch answer
about 4 minutes
Opening this part with your pass…Pro part. It opens with the same pass as the part above.
Interview questions
The warm-up is answered in full below. For the other three, say which levers and which criteria you would use before you open the first step and the follow-ups:
-
Fresher to mid · Warm-up
What is a feature flag, and how does it make a launch safer?
A feature flag is a switch in the code that turns a feature on or off for chosen users without shipping a new version. It makes a launch safer in three ways. The code can reach every phone switched off, so releasing it and launching it become separate decisions. The feature can then be turned on for a small share of users first, such as 1 %, and widened stage by stage while the launch criteria hold; Google's SRE book describes flag-guarded changes that grow to a limited group, usually 1 to 10 % of users. And if something breaks, turning the flag off undoes the launch in seconds, without a new release. The cost is some complexity: each flag is code that must be tested both ways and removed once the feature is settled.
-
Fresher to senior
Two weeks before a committed launch, engineering says it will be three weeks late. What do you do in the next 48 hours?
-
Mid to senior
On launch day, one guardrail is just outside its threshold in the 10 percent rollout. Do you continue? Explain the decision.
-
Mid to staff
The day before launch, the legal team raises a consent issue in your sign-up flow. How do you handle the launch and the team?
Flashcards · 6 cards
Recall it, then check
Say the answer to yourself before you look: recalling it is what makes it stick.
-
Which four levers can move when a launch slips?
Cut scope and ship less on the date, move the date and ship everything later, add people, or lower the quality bar. For a fixed date, scope is the first lever to pull.
-
Why does adding people rarely rescue a late software project?
Newcomers must learn the work before they can help, and every extra person adds communication, so people added late tend to make the project later still.
-
In what order do you cut scope with MoSCoW?
Could Haves go first, then Should Haves, while the Must Haves, the minimum usable subset, stay. Give every item you cut a place in the next release.
-
In the group-ordering example, why cut the host's spending limit as well as both Could Haves?
Dropping the two Could Haves left 20 engineer-weeks, exactly the capacity, with nothing spare for a surprise. Cutting the spending limit too left 16: four weeks of work with one week in hand.
-
What turns launch readiness from a debate into a check?
Launch criteria written before anyone has a favourite answer, each with a limit and the rollout stage it must hold by, such as at least 99.5 % crash-free sessions before the 1 % stage.
-
Why ship a feature behind a feature flag and roll it out in stages?
The code ships switched off, so turning the feature on is a separate decision that can be undone in seconds. The rollout grows from about 1 % of users to everyone, with a rollback trigger agreed before day 1, so switching it off needs no meeting.
Key takeaways
- When deadlines slip, four levers can move: scope, the date, people and the quality bar; for a fixed date, scope goes first.
- Scope cuts follow MoSCoW: Could Haves first, then Should Haves, with a date for everything cut.
- Launch readiness is a check against criteria written in advance, each with a limit and the stage it must hold by.
- A staged rollout behind a feature flag grows from 1 % to everyone, with a rollback trigger decided before day 1.
Terms in this lesson
- feature flag
- A switch in the code that turns a feature on or off for chosen users without a new release, so a launch can start with a few users and be undone in seconds.
- launch criteria
- The limits a launch must meet, written before it starts: quality bars such as crash-free sessions, guardrail limits, support, legal and privacy checks, and a tested way back, each with the stage it must hold by.
- staged rollout
- A launch that turns a feature on for a growing share of users, such as 1 %, 10 %, 50 % and then everyone, checking the launch criteria at each stage before the next.
References
- MoSCoW Prioritisation (DSDM) (Agile Business Consortium)
- The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (Addison-Wesley (Frederick P. Brooks Jr.))
- Site Reliability Engineering, chapter 27: Reliable Product Launches at Scale (Google (O'Reilly Media))
- Site Reliability Engineering, chapter 3: Embracing Risk (Google (O'Reilly Media))
- Web Content Accessibility Guidelines (WCAG) 2.2 (W3C)
- The Digital Personal Data Protection Act, 2023 (Gazette of India), section 6 (Ministry of Electronics and Information Technology, Government of India)
- Regulation (EU) 2016/679, the General Data Protection Regulation, Article 4(11) (Publications Office of the European Union (EUR-Lex))
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress