You have three months to make an impact

Adapting the First 90 Days framework for product leadership

“So, what’s your 90 day plan?”

If you’ve interviewed for a product leadership role in the last decade, you’ve more than likely heard this question. If you’ve been hired into one, you’ve probably tried to answer it for real. The question comes from Michael D. Watkins’s The First 90 Days, which remains the standard text on leadership transitions.

One of its most useful ideas is the STARS model, which asks the incoming leader to diagnose the situation they’re inheriting:

• Startup: assembling a team and building a product from scratch, with no existing customers or revenue to anchor decisions.

• Turnaround: the product or business is in trouble and needs to be rescued before the runway disappears.

• Accelerated growth: things are working, but the organisation needs to scale rapidly without breaking what got it here.

• Realignment: the organisation has drifted from its strategy, or the strategy has drifted from the market, and the two need to be reconnected.

• Sustaining success: the business is healthy, and the challenge is to maintain momentum while finding the next source of growth.

The model’s value extends well beyond the interview process. Watkins makes a persuasive case that the first 90 days in a role determine whether a leader will succeed or fail. A strong transition buys forgiveness for mis-steps down the line. A botched one poisons everything that follows.

Product leadership transitions carry a specific kind of complexity that Watkins doesn’t address, largely because he’s writing for general management. In product, you’re rarely entering a clean startup situation. You may be walking into a realignment or a sustaining success situation that’s slowing down and is now seeking accelerated growth in an adjacent market. In a portfolio organisation, you may be dealing with multiple situations at once.

What would a product version of the first 90 days framework look like?

Three slices of 30

The 90 days break naturally into three phases of roughly 30 days each: analysis, experimentation, and execution. Each phase has a different purpose and a different energy. In analysis, you’re listening. In experimentation, you’re negotiating. In execution, you’re asking the organisation to change.

The temptation, particularly for product leaders, is to skip analysis and jump straight to execution. We’re hired to make things happen. The pressure to demonstrate impact is immediate. But a product leader who starts executing without understanding is optimising for speed without context, like jumping into a Formula 1 car without checking whether you’re at the race track or going to the grocery store.

Phase 1: Analysis

The first 30 days are about understanding and synthesis. You’re building a diagnosis of the company, its position in the market, and the system that produces (or fails to produce) value for its customers.

Watkins identifies four pillars for a leadership transition: business orientation, stakeholder connection, cultural adaptation, and expectations alignment. These work well, but I would split the business orientation into business orientation and product orientation.

Business orientation

This is where you understand the business and its competitive position, by asking questions and gathering stakeholder views on issues, such as:

• What kind of STARS situation are you in?

• What market does the company serve, and where is that market heading?

• Is the business profitable, and if so, what’s the shape of that profitability; e.g. is it concentrated in a single product line or diversified?

• Does the company have a DHM (a way of delighting customers in hard to copy, margin-enhancing ways)?

• What is the financial plan, and how does the product strategy connect to it?

• What’s the business’s appetite for risk and how does that affect its current position?

Product orientation

Alongside the business questions, you’ll want to understand how the product organisation itself operates:

• What are the product team(s) currently working on?

• How much of it is connected to a measurable outcome?

• How much is inherited commitments and maintenance?

• How do we embed hypotheses and measurement into the way the business operates?

As you ask these questions, you’ll start to see the gap between the company’s stated strategy and its revealed strategy; the one you can infer from where it actually spends its time and money. Understanding how to address that gap is where you can deliver the most value.

Stakeholder connection

You can use your need to answer your business and product questions to build relationships with the people who matter, inside and outside the building. You’ll need to find out:

• Who are the internal partners to product; who are the key voices in sales, marketing, engineering, and customer success?

• Who are the strategic customers?

You’ll want their help in understanding their perspective on the organisation and its products, as well as finding out the pain points the organisation has already solved, and which ones remain stubbornly unsolved.

This isn’t networking for the sake of it. You are aiming to understand the system of incentives, relationships, and information flows that determine how product decisions get made. Who really decides what gets built, and how? Where does customer feedback enter the system, and where does it get lost?

Consider building a user journey map that captures all the touchpoints between the organisation and its customers. Not as a deliverable for a presentation, but as a diagnostic tool. As you visualise the information you are gathering, it will help you to understand where the most promising experiments can be run in the next phase.

Cultural adaptation

It’s important to understand the way the system operates today, and to gather some insights into what works well and doesn’t. It may be that there are certain cultural shibboleths, which you don’t want to attack too early in your tenure as it will undermine everything else you are trying to achieve. Good questions to ask include:

• How are decisions made?

• How are meetings run?

• How does conflict get surfaced, managed, and resolved?

• What’s the organisation’s actual (not aspirational) relationship with experimentation?

• Is there a culture of learning from delivered work, or does the team ship and move on without looking back?

These questions matter because the most elegant product strategy in the world will fail if it requires a decision-making culture that doesn’t exist yet. You need to know what the system will accept before you try to change it.

Expectations alignment

Among the various stakeholders and the teams, is there a consistent view of where the organisation is heading? Gather information from as wide a range of people as possible on:

• What does success look like in 18 months? Two years?

• Does the organisation have a view of its planning horizons, from the immediate to the speculative?

• Is the current product and engineering organisation structured in a way that can deliver against those horizons, or is there a mismatch between ambition and capability?

These conversations will uncover (regardless of what you were told during recruitment) whether you were hired to execute a plan or to create one. These are very different mandates, and your transition strategy will need to reflect the one you have.

From analysis to strategy

Pulling these answers together in the first 30 days gives you the raw material for a strategy. Richard Rumelt, in Good Strategy Bad Strategy, describes the kernel of good strategy as having three parts: a diagnosis of the situation, guiding policies for dealing with the constraints of that diagnosis, and coherent actions that implement those policies.

The diagnosis has to be honest. If the organisation’s stated strategy is growth but its revealed strategy is maintenance, that needs to be in the diagnosis. If the team structure works against the product strategy, that needs to be laid out. The whole point of a diagnosis is to name the situation as it is, not as anyone wishes it were.

Phase 2: Experimentation

The next 30 days are about testing the hypotheses that emerged from your analysis. Not proving them right, trying to falsify them. The distinction matters. If you approach this phase looking for confirmation, you’ll find it, and you’ll miss the things that would have told you to change course.

Validating the guiding policies

Each of your guiding policies contains assumptions about how the organisation works and how customers respond. Experimentation enables you to challenge those assumptions. For each guiding policy, ask:

• What is the cheapest way to test whether this holds up?

• What would tell us this policy is wrong?

• Where will we see friction first if we try to implement it?

• Do we have the data and instrumentation to measure the result?

Say one of your guiding policies is “transition to a platform-first mentality.” Maybe the cheapest test is running a single cross-team initiative that requires API-first thinking, and observing where friction appears. If a policy is “data beats opinion,” does the organisation have the data capability to support hypothesis-driven decision making? If so, can you test its appetite for it with one team and see whether the culture absorbs or rejects it? If not, you can start thinking about how to build it in the execution phase.

Creating visible momentum

Experiments don’t only produce data. They establish or destroy trust. In the first 60 days, the organisation is forming its opinion of you. Small wins matter, not because they prove you’re a genius, but because they demonstrate that change is possible and that you’re paying attention to things that affect people’s daily lives.

A “Product Experience” initiative is one thing that can help. Think of it as the product equivalent of a Developer Experience programme. Find the frictions that prevent teams from doing their best work, and fix some of them, or, even better, empower the people doing the work to fix some of them. This could be as straightforward as protecting meeting-free time for deep work, or as involved as mapping the decision-making process and removing unnecessary approval gates. The point is to show that you’re serious.

If there are no quick wins available, start by surfacing the invisible frictions:

• Map the actual decision-making process (not the one on the org chart).

• Document the collaboration pain points that everyone knows about but nobody has written down.

• Work out who informally shapes how things get done, because they will have more influence on your success than many of your peers on the leadership team.

• Choose Product Experience champions; people respected by their peers, not only those with senior titles.

Building the roadmap

Using the analysis and early experiment results, start drawing the product roadmap. This isn’t a Gantt chart. It’s a statement of intent, informed by evidence, that connects the guiding policies to specific initiatives with measurable outcomes. Frameworks such as PandA can be helpful in guiding the creation of this roadmap and ensuring that the right people contribute to it, and they can see how it is different to a delivery plan.

The roadmap needs to serve two audiences: internal stakeholders who need confidence that the product organisation has a direction, and external partners or customers who need to understand what’s coming and why. These are different documents with different levels of detail, but they need to tell the same story. Consider what each audience needs to see:

• Internal stakeholders need the strategic rationale, the connection to guiding policies, and the hypotheses being tested.

• External partners and customers need to understand what’s coming, roughly when, and why it matters to them.

• Both need to see how their input shaped the direction.

Metrics that matter

Everything in the experimentation phase needs at least one clear metric attached to it. Every hypothesis needs to be testable, and the data that will prove or disprove it needs to be accessible and reliable. This sounds obvious, but in practice it’s where many transitions stall. Many organisations agree in principle that they want to be data-driven, but often the instrumentation doesn’t exist, or the data is unreliable, or nobody has agreed on what “success” actually means for a given initiative.

Establish the baselines now. Before you start changing things, measure what matters for your specific situation:

• How long does it take to onboard a new partner or customer?

• What are current conversion rates at each stage of the user journey?

• How does the team rate its own collaboration and effectiveness?

• What does partner or customer satisfaction look like today?

Without baselines, you can’t measure improvement, and without measurable improvement, your transition is a story that can be told by anyone in the organisation. The data will ensure it’s your story that prevails.

Phase 3: Execution

The next 30 days are about delivering value while building the habits that will outlast your transition period. This is where the 90 day plan stops being a plan and starts becoming the way the organisation works.

From coherent actions to business as usual

By now, your guiding policies have been tested. Some will have held up; others will need revising. The coherent actions that survived experimentation become the foundation of your ongoing product strategy. The ones that didn’t survive taught you something, and what they taught you informs the next set of actions.

This is the rhythm you’re trying to establish: act, measure, learn, adjust. It’s not a 90 day exercise. It’s a permanent operating model. To embed it, consider:

• Are teams reviewing the outcomes of delivered work, or shipping and moving on?

• Is there a regular cadence for updating coherent actions based on what’s been learned?

• Can every team member draw a line from their work to a hypothesis being tested?

• Are experiments being treated as experiments (with success criteria defined in advance), or are they pet projects with a different label?

The transition is successful when this rhythm continues without you having to personally drive every cycle of it.

The cultural shift

Execution in the third 30 days is as much about culture as it is about shipping. You’re now setting out on a cultural transformation dressed up as a product transformation, and it will meet resistance.

Farm for dissent. Actively seek out the people who disagree with the direction and discover why. Some of their concerns will be legitimate; the diagnosis was incomplete, or an assumption was wrong. Others will reflect the friction that any change creates. Both are useful data. The concerns that reflect genuine gaps in the diagnosis need to be addressed. The concerns that reflect discomfort with change need to be acknowledged and managed, not dismissed.

Transparency matters here. You’ll want to build habits that make the organisation’s learning visible and accountable, for example:

• Share the metrics, including the ones that show where experiments failed.

• Run honest retrospectives that examine what was learned, not who was at fault.

• Publish decision logs that explain the context, the problem, the decision, and the rationale. Treat these as requests for comment while pressing ahead.

• Update the roadmap to reflect what you’ve learned; the organisation needs to see that the plan is a living thing, not a monument.

What success looks like

At the end of 90 days, the goal is not a finished product strategy. It’s a validated direction, a set of practices that connect strategy to execution, and an organisation that knows how to learn from what it delivers. You’ll know you’re in a good place if:

• You have a roadmap informed by evidence, not assumptions.

• Cross-functional alignment comes from shared understanding, not imposed agreement.

• Teams can draw a line from their daily work to the outcomes the business is trying to achieve.

• The people around you describe the change as something that happened naturally, as though the organisation simply started working better.

That last one is the sign it worked. The transition succeeded not because you arrived with a brilliant plan, but because you built the conditions for the organisation to figure out what the right plan was.

The product-specific challenge

Watkins wrote The First 90 Days for leaders in general. The framework holds up, but product leadership adds layers of complexity that the book doesn’t address. Product leaders navigate the tension between sustaining what works and finding what’s next, building strategy while simultaneously delivering against existing commitments, earning the trust of engineering, sales, marketing, and the executive team, all of whom have different definitions of success.

The 90 day framework, adapted for product, is really about establishing an outcomes-oriented culture. Not outcomes as a buzzword in a planning document, but outcomes as the thing the organisation actually optimises for. The diagnosis tells you where you are. The guiding policies tell you what matters. The coherent actions tell you what to do about it. And the measurement tells you whether any of it worked.

“So, what’s your 90 day plan?”

Build the conditions to learn. Then learn. Then act on what you’ve learned. Ninety days isn’t long enough to transform an organisation. It’s long enough to set the direction and prove that the direction is worth following.