Your first 60 days leading product on a complex platform

Week 1: check the mandate with the CEO. Your first season is shaped by the mandate you were hired with, as Hambrick and Fukutomi argued, and the CEO's version may not match the job description. Write your mandate in one paragraph, show it to the CEO in week 1 and take the edits. Then have the conversations Michael Watkins suggests with a new boss: how they see the situation, what success looks like and by when, and how they like to work. If the founder still runs the company, ask which product decisions they keep.

Make a rough situation call for each area, not one for the company. Watkins' five situations are a handy lens, not a proven model:

Turnaround or realignment? I ask: is the problem in the board deck, has the CEO said it out loud, do engineers and sales describe the same problem, and is there a regulator, bank or carrier deadline? Write your call down by day 10 and test it in phase 2.

Say your company's US card-issuing product is profitable and stable, while a payouts corridor to Brazil launched last quarter has three customers. The first is sustaining success and needs protecting; the second is a start-up and needs customers and a learning cadence. One plan for both would get one of them wrong.

Learn the domain from real cases, filed under a structure. Beginners learn more from studied examples than from solving problems unguided (researchers call it the worked-example effect). On a platform, the examples are real: a closed postmortem, a rejected registration, a chargeback file, a failed payout trace, an agent run that looped. The structure is the site's ten primitives: file every new fact under one, from entity and identity to liability allocation. My default for the first 15 days:

• Customers: 10 conversations: three won, three lost, three churned or at risk, and the largest account. Recorded calls first.
• Support and incidents: the top 20 ticket categories, 20 recent escalations and 10 postmortems from the last 12 months; note which ones a partner caused.
• Operations: half a day with the team that fixes breaks; ask what they do by hand.
• Money and power: the money-flow map and the power map on one page each, corrected by finance and partnerships.
• Architecture: an hour with the most senior engineer; draw it back and let them fix your drawing.

Use the site's guides as a day-0 test. Read the Field Guide closest to your platform and take its 20-question self-check cold, ideally before your first meeting, then again at day 30: telco and CPaaS, order-to-cash, procure-to-pay, spend management, cross-border payouts, AI agent orchestration. Security and identity don't have a guide yet; see What to learn first.

List the partners who can stop you, with what would set them off, who owns the relationship, and the contract's renewal and termination terms.

US banking agencies expect banks to manage their third parties from start to finish, so a fintech's product team ends up inside its bank's risk programme (2023 guidance). Say your sponsor bank's annual review finds gaps in how you monitor business customers: it can pause new sign-ups the following week, and no sprint fixes that. In August 2025 the FCC removed about 1,400 providers from its Robocall Mitigation Database, so other carriers had to refuse their voice traffic (the site's telco guide covers it).

Build one calendar of external dates by day 15: audits and certifications (SOC 2 period end, PCI DSS assessment, ISO 27001 surveillance, FedRAMP), regulatory effective dates, partner rule releases, model retirements and contract renewals. Some are already fixed: full EU Cyber Resilience Act obligations from December 11, 2027; Canada's NG9-1-1 deadline of March 31, 2027; Ofcom's alpha sender verification on July 15, 2027; FedRAMP's 2026 rules with certification classes A to D. Anything with a date and no owner goes on the list of problems to act on right away.

Meet compliance in week 1, and bring questions. Mine: What licences, registrations and certifications do we hold, in whose name, and which do we rent? Which partner can stop us fastest, and what would trigger it? What open findings or remediation plans exist, with dates? What audit evidence comes from product systems? Which incidents are reportable, to whom, how fast, and who decides? What's the one thing you wish product understood?

Engineers and compliance judge you on the domain first. I can't prove this for product leaders, but the trust research points that way. We trust people on ability, benevolence and integrity, and ability is judged within a domain; a big meta-analysis found all three predict trust, and trust predicts performance. Your engineers will judge you on the rails, rules and failure modes, not your last title. Go to incident reviews in your first two weeks, and keep "at my last company" in a private notebook.

Meet the internal candidate in week 1. At one Fortune 100 firm, people turned down for an internal role were about twice as likely to leave, more so when the winner came from outside, like you. Acknowledge it, ask what they want, give them a real piece of the 60-day work, and tell the CEO what you agreed. Don't promise a promotion you don't control. People close to your predecessor are the other exit risk: they leave more after a succession.

Tell the team how you'll work, and change nothing structural: you're listening first, there's no reorganization before day 60, and existing owners keep deciding. Will Larson's first trap for new engineering executives is changing things before you understand the problem. Sit in every existing ritual once without changing it. Confirm who owns every critical obligation (on-call, attestations, partner relationships) so nothing drops. Fix only what's unsafe or illegal.

Start a private strategy draft in week 2. Gibson Biddle, who was VP of Product at Netflix, suggests a rough strategy within about two weeks, refined over the first month. Treat every line as a guess. It's really a list of what you'll be wrong about, and only the CEO sees it.

Sort the roadmap into five bins. This sorting is mine, but most product leaders would recognize it:

1. Committed to a named customer or partner: in a contract, side letter, RFP answer or sales email. Ask legal for every "future functionality" clause.
2. Mandated, with an external date: a regulation, network rule, registry deadline or model retirement.
3. Reliability or audit work tied to an SLO or a finding (open SOC 2 exceptions, PCI gaps).
4. Revenue bets with an owner and a metric.
5. Discretionary: no owner, no metric, no customer.

Red flags: bin-1 items product didn't know about, bin-2 items with no owner, and a lot of capacity in bin 5 (I'd look hard above about 30%, but that's a guess). Find the commitments before you judge the roadmap. Cutting something promised in a contract or dated by a regulator is the most expensive way to look decisive. Say a bulk payout API sits on the roadmap as a nice-to-have, but a sales email promised it to your second-largest customer for next quarter. That's bin 1, not bin 5, and cutting it can cost a renewal.

Read incidents, not dashboards. Pull 12 months of Sev-1 and Sev-2 incidents: were action items done, which causes repeat, how many did partners cause, what credits did you pay, and does product go to postmortems? Google's example error-budget policy makes follow-up mandatory: an incident that eats more than 20% of a four-week error budget gets a postmortem with at least one top-priority action. If postmortem actions don't close, you've found your first early win.

Agree the metrics, then check what the words mean. Pick five to seven from Metrics by platform type, cut by counterparty, and ask engineering what "delivered", "approved", "paid" and "success" mean in the code. Say messaging reports 98% "delivered", but in the code that means the carrier accepted the message, not that the phone got it. The number you'd show the board may not be the one customers feel.

Go through the platform's debt with engineering. CIOs McKinsey surveyed in 2020 put tech debt at 20-40% of the value of their technology estate. The platform questions I'd ask: where do partner-owned rules live in code rather than configuration? Can you reproduce a past calculation? Who fixes reconciliation breaks? Which external APIs, model snapshots or standards are near end of life? What would a second sponsor bank, carrier route or model provider cost?

List the compliance obligations product owns. You'll find them in the obligations register, security questionnaires, partner contracts, open findings and the last exam or partner-audit letter. Product usually owns consent evidence, disclosures, KYC and KYB (business identity) flows, reportability workflows, audit evidence, data residency, 911 address validation and fields partners require. In the UK, the FCA's Consumer Duty (in force since July 31, 2023) asks firms to show good customer outcomes, which pulls product decisions into scope.

Check customer health and concentration. Under US accounting rules, public companies have to disclose any customer worth 10% or more of revenue. Ask for the top-10 share even in a private company, plus retention by segment, the next two quarters of renewals and signs that customers use a second provider. On usage-priced platforms, I suspect churn often shows up as traffic quietly moved elsewhere. Say one marketplace sends 30% of your payout volume and starts routing a third of it to a second provider: you lose a tenth of your volume, and nobody ever files a churn notice. Check whether a partner's price rise can be passed on within a month.

Write provisional team assessments, privately. Use one public framework or your company's ladder, like the UK government's (five levels, nine skills, updated February 28, 2025) or Ravi Mehta's 12 competencies, which assume no PM is great at all of them. For each PM, read recent specs, roadmap rationale and metrics, and ask their engineering lead, designer and one or two colleagues the same three questions. I separate three things: skill against the level, context (understaffed, fixed roadmap, incident-heavy legacy) and trajectory over six months.

Look at the system before the person: where leadership picks the features, weak discovery may be the operating model, not a skill gap, as Marty Cagan argues. Lower-status people feel less safe speaking up, so the PM blamed for the last outage may be the quietest in the room.

Size the team by load, not by ratio. The familiar PM-to-engineer ratios come from polls and job-title counts, not evidence. I'd ask instead: how many customer surfaces, APIs and partners does each PM own, and how much of their week goes to compliance, partners, incidents and enterprise deals? Too few PMs looks like engineers waiting on decisions, tech leads writing specs and a roadmap set by sales escalations. Too many looks like PMs splitting single teams, lots of strategy documents and little shipped.

Decide the hiring pipeline by day 30. Roles take months to fill, so a backfill opened on day 45 lands well after day 100. Re-scope each open role against what you've found (a platform PM, a PM who's comfortable with compliance) instead of cloning the person who left.

Write the diagnosis down: this is the hinge. Two to three pages: what's true, what's at risk, what can't wait, open questions, and your situation call per area. Test it with the CTO, the head of compliance and a top salesperson before anyone else sees it. Then answer these ten questions out loud to a domain expert, ideally whoever owns that area, and note what they correct.

My own working targets, still to be tested with experts: the vocabulary and top failure modes by day 15, one answer per primitive by day 30, a roadmap trade-off you can defend to compliance and a partner by day 60, and real fluency in six to twelve months. Nobody has measured how long product leaders take to become credible.

Pick one or two early wins the team will share. In Van Buren and Safferstone's data, the new leaders who struggled were chasing a personal win: they micromanaged, jumped to conclusions and took criticism badly. A good early win, as I read their work and the cases, is shared, removes a pain people already feel, is cheap and reversible, and is visible to the CEO and at least one peer team. On platforms it often fixes how work runs: every Sev-1 gets a blameless postmortem with tracked actions; one written rule for who can promise a feature or a date to a customer; a monthly metrics review with engineering, sales, operations and compliance. Say operations hand-fixes failed payouts every morning because last spring's postmortem actions never closed. Getting those actions done with engineering is a win support, engineering and customers all feel.

In a troubled area, make at least one a fix customers or staff can feel: the top ticket driver, a broken onboarding step, a partner escalation nobody owned. Bad early wins: a feature forced through to look fast, a reorganization, a new framework.

Write down how decisions really get made, then fix one gap. Don't redesign decision rights in month one. Map who actually decides roadmap, pricing, deprecations, incident follow-up and partner commitments, and show the gaps; unclear decision rights stall decisions, as Bain's Rogers and Blenko found. Make reversible decisions fast and irreversible ones carefully, as Jeff Bezos put it in his 2015 letter. Fix one painful gap by day 45, and agree what PMs decide alone, what needs you and what needs the engineering manager.

Agree the capacity split with the CTO. Friction with technology leaders over platform investment is a common reason product executives leave, according to an agency's survey. Agree who decides roadmap versus platform trade-offs, who owns reliability and incident follow-up, and the shares for roadmap, platform and debt, and interrupts. Protect a visible share for reliability in writing, and never promise dates to sales without the engineering manager.

Turn the private draft into a strategy memo. I use Richard Rumelt's kernel: a diagnosis, a guiding policy that rules things out, and actions that fit together. Goals aren't a strategy. About 100 days into IBM, Lou Gerstner said a vision was the last thing it needed right then; tough strategies for each business came first.

Show the CEO first, then walk every peer through it one-to-one: the CTO, sales, compliance and finance, before any group meeting. Finance should see it in their numbers. The failure to fear here is a strategy written before you understand where the money and the risk are. I think it's the most dangerous one on a platform, though the research says relationship failures are more common. Ron Johnson rebuilt J.C. Penney's pricing without small tests and misread core customers who loved discounts; Léo Apotheker announced HP's biggest portfolio moves all at once, before the team and the market were on board. Both also failed on alignment. If finance or compliance would first hear about your plan at an all-hands, you're not ready.

Make the hiring decisions, and consider internal moves. At one bank, external hires were paid about a fifth more and took two to three years to match people promoted from inside (Bidwell 2011). Simply interviewing internal applicants, even ones you then turn down, halved how often they later left, compared with rejecting them unseen (Keller & Dlugos 2021). Larson suggests naming at most about three critical roles and closing the top candidates yourself.

Test people and structure calls with HR and the CEO, and announce few. Share themes, not verdicts, with the team. Have a career conversation with each PM. For underperformance documented before you arrived, start the agreed process with HR; for "everyone knows" concerns, set clear expectations and a timebox. Don't reorganize unless the turnaround case is strong, and a team reorganized just before you arrived needs a very good reason to go through it again.

Publish the plan. Here's the outline I'd use for the day-60 memo:

1. The domain on one page: money, rules, partners, failure modes, filed under the primitives
2. The diagnosis per area, with its situation
3. Two or three choices, and what you will not do
4. First bets, each with a metric, an owner and a date
5. Team and structure calls made, and those deferred with a date
6. The operating cadence
7. Risks: platform, compliance, partner and customer concentration
8. What you need from the CEO and peers
9. What your week-2 draft got wrong

Say what stops. In a McKinsey survey, successful leaders were almost twice as likely to say plainly what to stop (2015, cited in McKinsey 2018). Taking over P&G in June 2000, A.G. Lafley ended about $200M of projects and focused on four core businesses and ten countries. Every start in your plan gets a stop: a project, a report, a meeting, a promise made without product. Say the plan adds a reliability push on the payout API; pair it with stopping the custom reporting project one mid-size customer asked for and nobody else uses.

Start the operating cadence, adding before you remove. My minimum: quarterly planning with an explicit capacity split; a monthly cross-functional metrics review; a weekly incident and escalation review with product in the room; a rule for who can change the roadmap and how customers are told; a decision log. Run the existing cadence for a full cycle before changing it, and change one ritual at a time. Mulally added one meeting at Ford and changed its norms before touching the org chart. Amazon's weekly business review and Basecamp's six-week cycles are examples, not recipes. Bring in one written artifact, like a one-page decision record, rather than a whole memo culture.

Commit to first bets you can measure, each with a metric, cut by counterparty where it matters, and a review date. Tell customers and partners only what changes for them.

Make the people moves that were waiting, and date the rest. Go back to your provisional assessments and write down what changed your mind. Make the moves that are ready and fair; schedule the others for day 90. In some countries an exit takes months, so check with HR before you promise a date. Publish the team plan (structure, or "no change" and why; hiring; the competency framework) and pick two or three health signals: regretted attrition, an engagement survey item, how PMs and engineers work together, the share of unplanned work.

Agree how you'll be judged. Ask the CEO what progress looks like at six and twelve months. Boards expect action, but not in weeks: in McKinsey's 599 transitions, underperforming CEOs were twice as likely to leave in year three as in years one or two. Book a day-90 and a day-180 review of your own transition.