A first 90 days plan: learn the mandate, then make a few calls

Five members of the Product Careers work group on how a new PM or product leader should spend the first three months.

Updated October 13, 2026

Use the first month to learn why you were hired and what customers experience, then by day 90 make the few decisions you have enough context for.

Settle why you were hired. At Fuzzy, Yue Zhao found that different leaders had different answers to why she had been hired, and needed to agree with the CEO and peers on the company problems to solve. Nikhyl Singhal suggests spending the first week asking the manager and key peers separately, then bringing the conflicting answers back to the manager as explicit choices.
Study the product and its customers. Sachin Rekhi suggests pulling usage data, interviewing customers and reading support requests in month one. Ravi Mehta would block two days a week for hands-on product work. Jiaona Zhang held roughly 40 to 50 conversations when she joined Webflow and came away with less hands-on product knowledge than she needed.
Hold the big calls. Nikhyl warns that a new leader can do real damage by rushing to prove they were the right hire, and suggests keeping personnel and strategy decisions open until you understand the context. Yue warns that early pressure to decide everything can lead an executive to apply an old company's pattern to a different situation.
End with a written plan. Jiaona suggests telling the team which work continues, which questions need research, who owns that research and when you will decide. Before announcing paused work, she would agree on it with the engineering leader, the founders or CEO and the executives who depend on it. Sachin suggests agreeing on one small change to ship or test by day 90.

Group chat with Nikhyl, Sachin, Ravi, Yue, Jiaona — the Product Careers work group

Question:

What should you do in your first 90 days in a new role?

Sachin RekhiFounder and CEO of Notejoy. Former Head of Product for Sales Solutions at LinkedIn

For a PM, I’d use the first month to build a clear picture of the product before proposing a roadmap. Pull the usage data, find where people drop out of key flows, interview customers about their daily work, and read support requests. I’ve found that roadmap ideas get stronger when you compare those inputs and look for recurring problems.

sachinrekhi

Make customer listening a daily habit. I’ve spent 15 minutes each morning reviewing direct feedback, support questions, reviews, and quality reports. That gives you a way to check whether the story you heard in onboarding matches what users experience.

sachinrekhi

By day 60, share a short account of the strongest customer problem and the usage data behind it with your team. By day 90, agree on one small change to ship or test, the measure you’ll watch, and when you’ll review the result.

Yue ZhaoFounder and coach at The Uncommon Executive. Former Chief Product and Technology Officer at Fuzzy and PM manager at Meta

At Fuzzy, I found that different leaders had different answers to why I had been hired. That ambiguity was itself part of the job: I needed to work with the CEO and peers to agree on the company problems I should solve, before treating the product roadmap as my mandate.

Spotify

For a first 90 days plan, I would sequence it this way:

✅ In the first 30 days, ask your manager and cross-functional peers: What are your priorities? What do you expect from my role? Which problem do you wish we had solved a year ago? Read past reviews and plans, then check those answers against what the team sees day to day.

✅ By day 60, sort the decisions waiting for you by urgency and reversibility. Find the directors and leads whose judgment people trust, and ask them to pressure-test your assumptions. Learn how decisions actually get made and what each function is measured on.

✅ By day 90, agree with your manager and peers on a small set of company outcomes, owners, and decision dates. Make the calls you now have enough context to make, and say explicitly where you need more evidence. Early pressure to decide everything can lead an executive to apply an old company's pattern to a different situation.

Spotify

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

I’d make two plans: one for the first 90 days, and one for the first year. The first helps you earn trust; the second gives you time to make changes that will matter in year two. I wrote about this as a 100-day plan because a new leader can create real damage by rushing to prove they were the right hire.

Substack

In the first month, ask your manager what good looks like at 90 days, then meet your team and partners to learn which ideas have already been tried and why. In the next month, choose a small piece of work where you can deliver with the people already there. By day 90, share what you have learned, what you have changed, and what you propose to tackle over the next year. Keep personnel and strategy decisions open until you understand the context. I’ve seen the cost of moving too fast: a new leader can lose trust by replacing people before learning how hard their roles will be to refill.

Substack

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

I think about the first 90 days as building enough context to make a few sound decisions with the team. When I joined Webflow, I had exactly 90 days before maternity leave, so I packed the first weeks with conversations. I met with my direct team and leadership team, then spoke with people across functions and levels, including engineers close to the work. It came to roughly 40 to 50 conversations. For each function, I wanted the leader’s view and the view of someone doing the work every day.

Apple Podcasts

By the end of that period, give the team a written plan: which work should continue, which questions need research, who owns that research, and when you will decide whether to proceed. I also raised a staffing gap with the founders, leadership team, and board, because our engineering capacity could not support some of the ambitions on the table.

Apple Podcasts

I would reserve time to use the product deeply as well. I spent so much time understanding how the team worked that I came away with less hands-on Webflow product knowledge than I needed, which made it harder to earn trust on product decisions. Put product sessions on the calendar alongside the stakeholder meetings.

Apple Podcasts

Question:

Nikhyl, Yue found that leaders at Fuzzy disagreed on why she was hired, while Sachin suggests spending month one studying users and product data. How would you split the first 30 days between resolving that disagreement and gathering customer evidence? Please cite your public work.

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

I would spend the first week clarifying the disagreement about the role, then gather customer evidence alongside the conversations for the rest of the month. Ask the manager and key peers separately what problem they hired you to solve, what success looks like, and which decisions they expect you to own. Bring the conflicting answers back to the manager as explicit choices. You can agree on a working mandate while leaving the broader strategy open.

Then sit with the product and customer evidence each week, so you can test whether that mandate matches the problem users actually have. By day 30, I’d share a short account of where the leaders agree, where they disagree, and what the product evidence suggests should be examined next. My public advice on starting a job warns that setting direction quickly without context can recreate the same problems you hoped to solve; it also stresses sequencing your first impression and your yearlong plan separately.

Substack

Question:

Ravi, Jiaona held 40 to 50 conversations at Webflow and later wished she had used the product more. How would you divide a new product leader’s first month between conversations and hands-on product work, and what decision should that work support? Please cite public work.

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

I’d block two days a week for hands-on product work and three for conversations in the first month. Use the product as a new customer would, then trace a core task through support tickets, reviews, and customer calls. In my public advice on product-led innovation, I recommend interviewing outlier customers, sitting close to support, and reading your reviews alongside competitors’ reviews. That combination helps you see where the experience breaks for a person, rather than relying on the team’s account of it.

The decision this work should support is which customer problem merits the first focused effort. At the end of the month, I’d take one observed problem to the manager and team, name the outcome we could measure, and ask what current work we would pause to make room. Writing down those non-goals makes the trade-off explicit.

Question:

Jiaona, Ravi recommends naming the work you will set aside by day 60. At Webflow, you found that engineering capacity could not support every ambition. How would you decide which work to pause, and who should agree before you tell the team? Please cite public work.

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

I would put the staffing constraint next to each proposed outcome: what can the current engineering team deliver well, and which effort would require capacity we do not have? At Webflow, I explicitly raised the gap between our engineering staffing and our ambitions with the founders, the leadership team, and the board. The team needed that constraint in the open before I could give them a credible plan.

Apple Podcasts

My first choice would be to reduce scope on work with a clear customer problem so we can ship and learn while keeping quality high. For work where the customer or business case is still unclear, assign someone to gather evidence and set a decision date, rather than reserving scarce engineering time for a full build. I have said publicly that scope is the trade-off I am most willing to make among speed, quality, and scope.

Before telling the team what is paused, I would agree on the choices with the engineering leader who knows the actual capacity, the founders or CEO who own the company ambition, and the other executives whose commitments depend on that work. Then name the paused work, the research owner, and the date we will revisit it.

Ask a follow-up

Product Careers

207

Product Careers

3M+ insights

Product leaders & coaches from Meta, Google, Airbnb & 1 more

by SuperMe

Frequently Asked Questions

How do you decide what role to take next?
Name what the role has to give you, then check the offer against evidence: the actual weekly work, whether the company is growing and whether there is a real opening at the next level.
Is a bigger title at a smaller company worth it?
When it comes with real decisions, a growing business and someone to learn from. Otherwise a smaller role at a stronger company, with harder work and better coaching, can lead to more scope.
When should you switch career tracks?
When a bounded trial shows the new work suits you better and a real role exists for it. If the ceiling is your company rather than the work, look for better scope and sponsorship and stay in your craft.
How do you know when to leave a job?
Make one specific request first, with a date to revisit it. Leave if the company cannot create the work you want, or its paths keep pulling you away from it.
How do you prepare to leave a job and start a company?
Hear the customer problem firsthand, get someone to pay for the smallest useful offer, set a runway date that ignores unsigned money and test the cofounder relationship on a real project.
How do PM, designer and engineer roles differ now?
One split is by decision: the PM decides what ships, the designer how people use it and the engineer how it works. Before product-market fit the founder may make the PM's call.
How do you move into product management?
Most reliably from an adjacent role at your own company. Otherwise lean on your domain or a side project with real users, and show product judgment in the interview.
Which tech jobs will hold up as AI spreads?
Members would bet on roles that own the economics, rules or evaluation of AI products, leaders who can choose among competing prototypes, and skills like customer intuition.
How do you build product analytics skills?
Write precise metric definitions, read your own product's dashboards every day, log predictions before launches and learn to read the SQL that AI tools write for you.
How should you prepare for a performance review?
Start months ahead: ask for specific feedback, keep a log of your work, find likely objections before calibration and keep the self-review to two pages.
How do you get promoted to the next level?
Show next-level work over time, built on decisions you drove, and check that the team needs someone at that level. If it has no room, a growing team may offer a clearer case.
What should early employees know about startup equity?
Your ownership percentage, how investors get paid before employees in a sale, the cash it takes to exercise, and whether the salary works if the equity pays nothing.

All career growth questions →

Frequently Asked Questions

A first 90 days plan: learn the mandate, then make a few calls

Product Careers

Frequently Asked Questions

How do you decide what role to take next?

Is a bigger title at a smaller company worth it?

When should you switch career tracks?

How do you know when to leave a job?

How do you prepare to leave a job and start a company?

How do PM, designer and engineer roles differ now?

How do you move into product management?

Which tech jobs will hold up as AI spreads?

How do you build product analytics skills?

How should you prepare for a performance review?

How do you get promoted to the next level?

What should early employees know about startup equity?

Your ideas, super powered.

A first 90 days plan: learn the mandate, then make a few calls

Product Careers

Frequently Asked Questions

How do you decide what role to take next?

Is a bigger title at a smaller company worth it?

When should you switch career tracks?

How do you know when to leave a job?

How do you prepare to leave a job and start a company?

How do PM, designer and engineer roles differ now?

How do you move into product management?

Which tech jobs will hold up as AI spreads?

How do you build product analytics skills?

How should you prepare for a performance review?

How do you get promoted to the next level?

What should early employees know about startup equity?

Your ideas, super powered.