Nothing on the desk matches that filter.

Playbook

TPM - Program Planning - Live Class

This is the practice desk for the 20 October class, plus the monitoring handout. Behavioral rounds are most of the loop. The rest is how you plan a program: decision rights, a risk score, and a result you keep watching. Open any section below, or use Next at the bottom of each one to go in order. Stories you type stay in this browser only. Download them as Markdown to keep a copy.

What a TPM runsProject, program, portfolio, and who is allowed to change scope or the date.
The interview loopRecruiter through bar raiser, and which companies ask for system design.
Behavioral methodPick 8–10 projects, map them to leadership principles, and shape each answer.
STAR clockSay one story out loud against the situation, task, action, and result beats.
Defect leakageThe metric story from class, and the gaps the room asked you to fill.
Story bankWrite one story per principle. Download the file when you want to keep it.
Risk registerScore likelihood times severity, then name an owner.
Dependency refusalThe Saturday-style scenario: assumptions, options, then the decision.
MetricsThe handout’s ten measures, the formulas to say out loud, and what a dashboard is for.
StakeholdersCadence, the power and interest grid, RACI, and the three jobs after launch.
This weekThe class calendar and the drills before the next live hour.

Those beats add to about 5:20. The class also wants the whole answer inside 3–5 minutes. Trim the situation before you trim the result. The action is the only long movement, and it is told in “I.”

Before Sat 24 Oct

Risk assignment

Saturday’s review covers the risk behavioral question and the pre-program planning case the class did not finish.

This week

Five stories, timed

Start with Bias for Action, Are Right A Lot, Invent and Simplify, Customer Obsession, and Earn Trust.

If the loop needs it

One system a week

Amazon, Uber, Adobe, and some Google teams ask for system design. Start with a system you used today.

Class notes: TPM program planning and behavioral interview prep. Monitoring sections are from the course handout in week-1, not from the live hour. The transcript tool was unavailable, so wording follows the class notes.

From the live class

What you are actually accountable for

A project ends. A program keeps the same kind of work moving. Say which one the job description is hiring before you tell a story.

Project

Finite scope, timeline, and budget that produce a unique result.

Program, product company

The same team and the same competencies, repeating similar work. Payments projects live inside a payments program.

Program, services or captive

Several projects grouped under a larger initiative. The class used a multi-module program as the picture.

Portfolio

The word captives and service firms use. Product companies usually say “program” for that same altitude.

A FANG day, as taught

56% with people, 30% in focus

Reporting used to take 40–60% of the day. With AI tools the class put it near 5%. In a product company the TPM is also in the room before the program exists (why and what) and after release (A/B tests, feature iteration).

Span of control

The old ratio was 1:25

That was a cross-functional span. The class described the trend as fewer, more senior TPMs owning a program end to end.

Who decides

The TPM lists mitigations, names an owner for each one, and stays accountable. The TPM is not the decision maker by default.

Decision	Who calls it
Scope change	Product manager
Replan inside an approved timeline	TPM
Timeline change	Product manager

Handout · three axes after launch

Program, technical, leadership

Program: direction, quarterly roadmap, goals, stakeholder coordination, impact metrics, and the written artifacts the handout names (HPM, lookback, 1-pager). Technical: domain depth, architecture tradeoffs, requirements broken out of a product initiative, retrospectives. Leadership: trust with senior leaders, negotiation, escalation used on purpose, and the quality of feedback on the team.

From the live class

How the loop is actually built

The hiring manager has to clear you before the loop starts. A bar raiser is not a universal last round.

01
Recruiter screen, sometimes skipped. Role fit, salary, availability.
02
Hiring manager, about 15 minutes on each slice. Program-management fit, leadership-principle fit, technical fit.
03
Loop, after the hiring manager clears you. Program management, leadership principles, and a system-design or technical discussion. Some companies add a written exercise or a slide deck. Microsoft and Indian unicorns often add a product discussion.
04
Bar raiser, Amazon and Uber. Amazon: an external panelist. The class said qualifying takes 500+ interviews, and you need to land above the 50th percentile of peers at that level. Uber: the skip manager can veto.

Company shape	What changes
Amazon, Uber, Adobe	System design is in the loop.
Google	System design is now team-dependent.
Intuit	Slide deck plus a case study.
Flipkart	Culture, technical, and product rounds.
Most other companies	The class put 80–90% of them on technical behavioral questions: influence on a technical decision, judgment under constraints. Domain weighs more at Deloitte, PwC, captives, and service firms.

Three systems, then the model layer

Transactional
Batch
Stream

Agentic, generative, and robotic AI sit on the application layer on top of those three. A TPM design answer still starts underneath the model.

TPM system-design scope

Requirements and constraints
High-level and service design
Database choice
How services talk
What breaks when load grows

From the live class

Build ten stories. Map them onto sixteen principles.

Amazon’s leadership principles are the widest set, so a story that fits them can be retold for Google or Meta. One story per principle. Take the projects from the last five years, and only the ones that were critical to the business.

01
Pick 8–10 high-stakes projects from the last five years.
02
Run a real retro on each one. What was stuck, what you changed, what the number did.
03
Map each story to one leadership principle. Priority set for TPMs: Bias for Action, Are Right A Lot, Invent and Simplify, Customer Obsession, Earn Trust.
04
Write it in STAR. Situation about a minute. Task about 20 seconds, mostly the constraint. Action about three minutes, in “I.” Result about a minute: before, after, business outcome, and the metric you kept watching.

Two checks, every answer

Leadership-principle fit, and role fit. A clean story that could have been told by an engineer or a product manager still fails a TPM loop if the action is not program judgment.

Level is scale, reach, and money

The class separated L5, L6, and L7 by scale, how many kinds of stakeholders you moved, and business impact. If the job is senior, a single-team launch with no second-order effect is the wrong altitude.

Fifteen to thirty seconds up front

Name the principle you are about to answer before you start. Ask one clarifying question when the prompt is ambiguous. Then talk.

The failure was a process

Do not blame a person, a team, or a company. Describe the missing contract, the missing forum, the missing bar.

Other shells collapse into STAR

The class treated SBI, CAR, PAIR, and DICS as the same story in a different frame. Amazon moved from SBI to STAR. For a negative outcome, add STAR+L (what you learned) or STAR+E (what that experience changed in how you run the next program).

Rehearse

Say one story against the clock.

Press start and tell a story from the bank. The copper stretch is the action. If you are still setting context when that stretch begins, the story is too long at the front.

Ready

5:20

Situation: business stakes in one breath. No org chart.

S
Who was affected, and what was at risk if nothing changed.
T
The constraint. Why this was yours rather than a ticket you watched.
A
Three moves: who you aligned, what you decided, what you changed in the system. Each move has an “I.”
R
The number before, the number after, the business outcome, and the metric you still watch so it cannot quietly revert.

Worked in class

A metric that forced a higher bar.

Prompt from class: “Tell me about a time you used a specific metric to identify a need for change.” Primary principle: Insist on the Highest Standards. Also in play: Dive Deep, Invent and Simplify, Deliver Results.

What the story contained

Defect leakage across SDLC gates was high.
SIT was taking 6–8 weeks.
The proposal was a common development environment.
SIT came down to 4 weeks.
Productivity gain cited: 25–30%.

What the room asked for next

Leakage at each gate, dev→QA and QA→SIT, not the word “high.”
Pros, cons, and how buy-in was actually won.
ROI for the extra infrastructure and licenses.
Close the loop on leakage itself, not only on SIT duration.
The new bar, said out loud: zero P0 defects into QA, and a 100% automation-coverage target.
Second-order result: capacity that freed other projects.

Skeleton to fill with your numbers

Leave the blanks empty until you have the real figures. Do not memorize invented leakage rates.

Situation. Leakage from dev to QA was [ ]% and from QA to SIT was [ ]%. SIT had stretched to 6–8 weeks, so the release train was spending its calendar on escaped defects.
Task. I owned getting that leakage down without slipping the committed scope. A shared environment needed infra and license spend I did not unilaterally control.
Action. I measured leakage at the two gates, wrote the cost of a 6–8 week SIT against the license and infra cost, and took the tradeoff to the people who could approve spend. I set the bar at zero P0s into QA and a 100% automation-coverage target, and I kept a single environment so defects were found before the handoff.
Result. SIT moved from 6–8 weeks to 4. Leakage at dev→QA went from [ ] to [ ], and QA→SIT from [ ] to [ ]. The 25–30% productivity gain showed up as capacity for [which projects]. I still review gate leakage [cadence], so the environment change cannot decay into a one-time project.

Your bank · stays in this browser

One story per principle.

Every principle uses the same status: Not started, Draft, or Ready. Draft the five the class named first: Bias for Action, Are Right A Lot, Invent and Simplify, Customer Obsession, and Earn Trust. The word count assumes about 140 spoken words a minute. Land between 3 and 5 minutes. This page does not send your stories anywhere. Download the Markdown file to keep them.

0 ready

From the live class · Saturday’s question

A risk is a maybe. An issue has already happened.

Anything that can knock the program off success: a dependency, a technical limit, unclear requirements, an HR change, legal or compliance. Identification starts at initiation and does not stop.

Critical path

Walk the path that actually determines the date. Risks that sit off that path get a lower score.

Stakeholders in a room

Brainstorm with the people who can see a failure you cannot.

The last program

Past projects are a source of risks, not a souvenir.

What goes in the register

Description, likelihood, severity, one or more mitigations, an owner per mitigation, an ETA, and a category if it helps you sort. Low = 1, medium = 2, high = 3. Score = likelihood × severity. The class treated 9 as the top of the list.

Score a risk

L 1 L 2 L 3 S 3 S 2 S 1

Pick a cell. Score = likelihood × severity.

Response, in this order

Avoid. Change the plan so the risk cannot occur.
Transfer. Move the impact, often by contract or insurance. You still watch it.
Mitigate. Lower likelihood or severity. Name the owner and the date.
Accept. A decision, not a shrug. Someone watches the trigger.

You can plan inside an approved date. A date change or a scope change goes to the product manager. You still leave the room with an owner.

Scenario from class

A dependency team will not deliver the feature.

Say it in this order. The class was explicit about the sequence.

01
State assumptions. Is it on the critical path? Is the date externally committed? Is the refusal a missing contract or a missing priority forum?
02
Restate the problem as a program risk, not as a team’s attitude.
03
Lay out options across time, people, scope, and process.
04
Take the choice to the steering committee. You facilitate. You do not announce a scope or date change they did not make.
05
Tell the stakeholders the decision and the new critical path.

Time

Replan, phase the release, or run a parallel path.

People

Internal staff, a contract team, a vendor, or overtime. Frugality still applies: say what the extra capacity costs.

Scope

MVP or descope, Pareto cut, tech debt explicitly after release.

Process

Put the API contract in their hands early, prove it with a POC, escalate through the steering committee.

Spoken shape

“I’m assuming this dependency sits on the critical path and that the other team’s roadmap never had this contract, which is a planning gap. The feature misses the date unless we change time, staffing, scope, or the way we integrate. Here are the options and the cost of each. I want the steering committee to pick, and I will publish the decision, the new path, and the single owner for the mitigation the same day. I am not treating this as a failure of that team.”

From the monitoring handout

The numbers a status review cannot hide.

Monitoring and controlling means tracking progress, finding where the plan has to change, and starting that change. On an agile program the backlog is the control list: a business owner orders it, the team estimates and names technical dependencies, and the next iteration pulls from the top by priority and capacity.

One list, not two queues

Change requests and defects go into the same backlog as planned work. A separate change queue loses when the rate of change is high. Short iterations then show capacity, change impact, and defect effort, so the next cost, date, and scope estimate comes from real progress.

Share the trend, not a novel

The handout calls the charts information radiators. They exist to show progress, surface issues, drive a specific improvement, and set expectations. Metrics prove value (on-time delivery, SLA, ROI) and, more usefully, change the next decision, such as slack that is pushing the date.

A project, from class

Schedule variance, budget variance, scope variance
Acquisition, retention, referral
CSAT
Incidents, ANR rate, crash rate
Tech debt and bug rates

A program adds

Cost optimization and ROI
Roadmap delivery at the quarter and the year
Lifecycle: acquire, activate, retain, revenue, referral

The handout’s ten, said correctly

The handout lists these ten as the starter set. Three of its written formulas are inverted or incomplete. Say the interview form.

Measure	Handout writes	Say this
Productivity	Input / output	Output / input. More output for each unit you put in.
Gross margin	(Profit − costs) / 100	(Revenue − cost of goods) / revenue.
ROI	(Net benefits / cost) × 100	Same shape. Benefits can be profit, savings, or more output. Costs include people, training, and overhead.
Earned value	% complete / budget at completion	% complete × budget at completion. Also called budgeted cost of work performed.
Customer satisfaction	(Survey points / questions) × 100	Use that index, and name the source: survey, repeat customers, lost customers, or complaints. NPS is the recommend question.
Employee satisfaction	The same survey index	Same math. The handout cites Gallup Q12 and notes turnover can cost half to twice a salary.
Actual cost	Cost per period × number of periods	The sum of real spend to date. Not the estimate.
Cost variance	Budgeted cost of work − actual cost	EV − actual cost. Negative means over budget.
Schedule variance	Work performed − work scheduled	EV − planned value. Negative means behind. SPI is EV / planned value, the index form the handout does not write out.
Cost performance	EV / actual cost	Same. Above 1 means the spend is producing the value you planned.

How the handout says to choose them

Start from the goal, then the critical success factor, then the measure of that factor. Drop a metric that duplicates another, is not necessary, is subjective, or costs more to collect than it changes.

1
Name the goal: productivity, predictability, margin, customer satisfaction, engagement, or a lower actual cost.
2
Track time, scope, cost, and quality of the deliverable. Keep only the distinct, necessary, measurable ones.
3
While the work is moving, watch actual cost of work performed, planned hours against actual, overdue tasks against tasks done on time, and which risk or change moved the date, the budget, or the staffing.
4
Fix the unit before the first report. Count or percent. Hours rounded the same way. Variance in dollars or in percent. Satisfaction on a named scale.
5
Collect it automatically, in time to act, and the same way every cycle. Manual and subjective entries are the weak source.
6
If the definition or the collection method changes, write that in the report. Otherwise the trend is comparing two different things.
7
Longer, heavier programs need a mid-course read so a bottleneck can still be moved.
8
Debrief at the end: risks that landed, where the budget crossed the line, which resources missed the plan, whether the result met the spec, and the pattern across programs.

Do not manage the number

The handout’s warning: too many similar metrics waste the review, and lowering a target so the chart looks healthy hides the signal. A miss is a reason to find the cause. You are not employed by the dashboard.

Agile, without gaming it

Ask two questions before a new metric: will it speed value, and will it raise trust? Use velocity to slice the backlog and forecast a feature. Pay for a higher velocity and the points inflate until the forecast is useless. Operational: lead time, cycle time, burndown. Output: throughput, defect rate, coverage, feature count. Outcome: morale, CSAT or NPS, business value. Scrum treats velocity as the next commitment. Kanban watches lead time, cycle time, the cumulative flow diagram, and a WIP cap so the team swarms a full column.

Words worth keeping straight

KPI looks backward at whether the organization is succeeding, and can sit inside a key result. OKR is an objective plus the results that show movement. KPO is the objective itself. A goal is a three- or five-year aspiration and often has no number and no date. MBO is Drucker’s short-term goal-setting between a manager and a team.

What the dashboard is for

A dashboard is a live picture of health so someone can decide. It is widgets, not a second status novel: activity, progress and status, milestones with an owner and dates, a personal to-do, task status, team workload, and where the people are actually allocated.

It has to do three things

Gather the sources the team would otherwise hunt for. Show the important number so it can be read quickly. Let the team change the view, because one layout does not fit every program.

Why bother

One reference stops people drifting off the target. The data sits where the decision is made. A red number is only useful if it becomes an action.

Before you build it

What decision, for whom, how long the read takes, which metrics, which tool supplies them, which number matters most, who owns the follow-up, and what action a miss triggers. The handout’s dashboard KPIs are CPI, alignment to company goals, cycle time, ROI, and how much allotted time becomes output.

From the monitoring handout

The right altitude for each reader.

A TPM translates in both directions: technical substance for business readers, business stakes for engineering readers. The aim is alignment on scope, milestones, and timeline, plus a cadence that surfaces risks, defects, and mitigations to leadership. After launch, that cadence includes what you did with feedback.

Choice	Question
Format	1-pager, deck, or email. Match the decision, not your habit.
Audience	Internal and external readers need different stakes.
Detail	The core team can use the burndown. A VP needs the variance and the ask.
Type	Kickoff and a progress update are different documents.
Cadence	Core team often, senior leaders less often, both predictable.

Communication is working when follow-up meetings shrink. Ask the audience. Also use it to ask for help early enough to matter.

Power and interest

High power, high interest

Decision makers. Manage expectations closely.

High power, low interest

Keep them satisfied. They can still swing the program if they are surprised.

Low power, high interest

Inform them. They often know the detail that saves you.

Low power, low interest

Monitor. Do not fill their week.

Then write the plan

For each person: what you need from them (a decision, ownership, or feedback), what they actually care about, and the note that follows. There is no single cadence. Fit format, audience, detail, type, and frequency to the program, the size of the room, and the company. The core team hears scope, milestones, and timeline. Leadership hears risks, defects, mitigations, and what you did with feedback after launch. Use the note to ask for help while the help can still change the date.

Ownership

Put names on a RACI: responsible, accountable, consulted, informed. Leadership in the handout is a style that fits the culture and makes the team feel supported, a look around the whole program for the next risk or the next improvement, and a target the business can see you miss.

It worked if the questions stop

Effective communication shows up as fewer follow-up threads asking what the program is doing. Ask the audience whether the note met the need. Anticipate the question and put the answer in the first send.

After launch

Stand up a place for defects and enhancement requests. Find the root cause, the severity, and the business impact. Prioritize with a matrix across money, safety, operations, and reputation. Tell the requester yes or no, and when it moves.

Program

Set direction and the strategy in one sentence. Scope the work, publish the quarterly roadmap, and set goals the team can execute. Coordinate the room toward a predictable outcome. Pick the impact metrics. The handout’s formats are an HPM, a lookback, and a 1-pager.

Technical

Hold a domain: machine learning, privacy, computer vision, payments, or APIs. See the feature the change creates, and who in the audience it hits. Take a side on the architecture tradeoff, write the recommendation, and break the initiative into technical requirements. Run the retrospective.

Leadership

Earn enough trust that senior leaders believe you can move people. Use the relationship to extend reach, settle the conflict, and escalate only when the path is blocked. Hold the hard conversation, organize the engineers, and ask for feedback in the moment rather than at the next quarterly review.

Calendar from class

What to do before the next live hour.

When	Session
Tue 20 Oct	Program planning. This desk.
Sat 24 Oct	Assignment review: risk behavioral question, and the planning case left unfinished.
Sun 25 Oct	Program execution.
Sat 31 Oct	Assignment review.
Sun 1 Nov	Monitoring and reporting. Read the handout before you walk in.
Diwali week	No Saturday review. Next one is 14–15 Nov.

Three more behavioral classes sit on the course: introducing frameworks, TPM motivation and core values, and cross-functional collaboration. Sundays are the four-hour class. Saturdays are a case plus three mock questions.

1
Put five priority stories in the bank and run each one on the clock.
2
For one live program, write a register of at least five risks. Score them. Give every mitigation an owner who is not “the team.”
3
Speak the dependency scenario in under four minutes, with assumptions first.
4
If Amazon, Uber, or Adobe is on your list, design one everyday system this week: requirements, which of the three system types it is, services, data store, how they talk, and the 10× failure.
5
Book a 20-minute AMA with Pradeep or Ishwar for resume review, a job-description match, or transferable skills. Bring a story, not a general question.

Technical behavioral prompts, for loops without a whiteboard

A technical decision you changed without owning the architecture.
A time you disagreed with a design and then committed.
A metric that changed an engineering plan.
A date-versus-reliability tradeoff you facilitated, and who made the call.