What to do in your First 30/60/90 Days as a Product Manager
Hey I’m Ant and welcome to my newsletter where you will find practical lessons on building Products, Businesses and being a better Leader
You might have missed these recent posts:
- OKRS ≠ Strategy
- Building Effecive Product Roadmaps
- Breaking Product Discovery into First Principles
My day job is helping companies shift to a Product Operating Model.
My evening job is helping product people master their craft with Product Pathways.
Over the years working in an agency, navigating my own career and today as a Product Coach I’ve probably onboarded to 20+ different companies now.
Over that time, I’ve refined approaching my first 90 days into 3x 30 days sprints:
Sprint 1 (first 30 days) = Discovery
Sprint 2 (30–60 days) = Quick wins
Sprint 3 (60–90 days) = Establishing trust
First 30 days = Discovery
One of the common mistakes that people make when they start a new role is “coming in with all the answers” or taking action too early.
You’ve probably seen this before.
A new manager starts, and all they can talk about is what they did at their last organization.
Worse, they wrongly assume that what worked at their last company will work here.
They apply the same things, and no surprise it goes wrong.
Taking action too early is similar.
Just like in product we avoid shipping something without first doing discovery.
Taking action without being informed by discovery will result in you missing key context and information.
Your chances of success will be low and it doesn’t do well to build trust when you haven’t invested any time to listen and understand first.
Therefore, your first 30 days should be seen as your discovery sprint.
This can be shorter, but I’d encourage you to stick to a minimum of 2 weeks at least.
I find that the 2-4 week mark is the sweet spot between spending too much time learning vs executing too early.
To help structure this, one key activity I get PMs to do in their First 90 Days is to create a learning backlog.
This can be a simple brainstorm or it can be a bit more structured, like the one in my First 90 Days workshop template.
The key questions I like to ask myself are:
What do you need to learn?
Why do you need to know this?
Who might you learn it from?
How do you plan to get the information?
When I coach Product Managers, I often draw this matrix to help facilitate thinking:
4 categories of things to learn in your first 30 days when starting a new Product role
Essentially there's 4 categories of things you need to know:
Product Management Craft (and how product works in the company)
The Product
The Market
The Business
Breaking this down.
Product Management
This is the craft itself.
It's worth being aware of your gaps and blindspots, especially when starting a new job.
This will help you set expectations and ensure you're leveraging those around you where your gaps are.
You may also find yourself in a space where perhaps in previous roles you had an amazing User Researcher so you didn't need to worry too much about leading research but now you don't.
So here you want to be thinking about:
what are my strengths and gaps?
what differences are there between this role and my previous roles?
how does product management work here?
etc...
Product
This is all things about your product.
From its vision and strategy to the technical architecture and how it works.
It should go without saying that you should have a good depth of knowledge about your product.
But it's not the only thing you need to know - hence the matrix - there's a real danger in diving head-first into learning about the product and neglecting other aspects like the market and even the dynamics of how the company operates.
In this category you want to dive into:
the product vision and strategy
the current product roadmap and goals
target customer profile and what their needs, behaviours, etc are
product metrics
customer feedback
etc...
Market
This is all things related to the industry/market that your product is in.
You might be lucky that you’re new job is in the same industry, but that won’t always be the case.
Here you want to learn more about:
your competitors
market trends
market segments
industry data (TAM, SAM, etc)
etc...
Business
Finally, we have the business.
Your product doesn't live in a vacuum. It exists within a larger ecosystem.
You also work within that ecosystem, so learning how things work at your company, who your key stakeholders are, and how the business model works is paramount to understanding how your product fits within the bigger picture.
Here you want to learn about:
the business vision and strategy
how your product fits in and contributes to the business
what the other products are
who your key stakeholders are
company values, policies, governance
etc...
Relationship backlog
In addition to creating a learning backlog I also recommend creating a stakeholder map and a relationship backlog.
Technical knowledge is only half the puzzle for success as a product manager.
We also need to collaborate with others, be influential and build trust.
This all starts with setting the right foundation early on.
A common mistake I see people make in their first 90 days is that they spend it operating in a silo.
This puts them on the back-foot when it comes to building relationships and influence.
Now for some roles this is fine but for product management, and especially product leadership, influence and relationships are a core part of the role!
Therefore, you want to start building that foundation as soon as possible.
I do a similar activity to the learning backlog but for relationships.
Ask yourself:
who are the key people I need to build a relationship with to be successful in my role? and why?
and how will I go about maintaining that relationship?
Relationship backlog from the 90 Days workshop template
Answering these questions does a few things:
you create a “hit list” of people you need to meet in your first 30 days
Allows you to see if you’re going to have a calendar filled with 1-on-1 meetings and whether you need to cut back there.
Helps you establish a rhythm early on - for example if you said I’ll maintain this relationship though a bi-weekly 1-on-1, when you met that person for the first time you can table that idea and get it in the dairy right away.
Bonus: Get the ball rolling before you start
Greg Smith, who recently completed the First 90 Days course, employed a neat strategy: He asked his new manager to schedule as many one-on-one meetings with key stakeholders as possible in his first week.
This meant that he hit the ground running in his new role as a Senior Product Director and didn’t waste a single day.
Now that’s not for everyone I know but it’s a great example of employing this strategy and really taking that principle of building those relationships as early as possible in your first 90 days.
Days 30-60 = Quick Wins
Of course, the ‘rubber needs to hit the road’ at some stage.
As mentioned before, I tend to find 2-4 weeks to be a reasonable amount of time for discovery.
That’s enough time to learn about your context and the organization and short enough that you can reasonably resist requests to take action too soon.
Your second month should be when you transition to executing - if you haven’t already.
Now it’s important that we’re intentional on what we do first.
One of the components of trust is competency.
This is why your second sprint focuses on getting runs on the board through quick wins.
FYI I cover trust and how to build it in more detail in both the First 90 Days course as well as the Stakeholder Mangement course on Product Pathways.
During discovery, you need to be on the lookout for potential quick wins.
There are things that:
should take no longer than a few weeks to complete.
and are important — there’s little value in securing a quick-win on something that wasn’t really a priority or actually a problem for the organisation.
Quick wins aren’t always the most important thing and that’s ok.
There are going to be lots of bigger problems that you would like to tackle but they’ll take several weeks. That’s a long time before you’re demonstrating competency in your new role.
Which is where quick wins come in.
Some examples of quick wins are:
Creating a first version of a Product Roadmap
Building a Stakeholder Map
Documenting current processes
Organising the team files and making things more discoverable
Run a round of user interviews
Run a high value workshop
Days 60-90 = Establishing Trust
Trust is made up of:
Competency
Reliability
Integrity
Empathy
The 4 pillars of trust (adaptation from Rachel Botsman definition of trust and the Trust formula from the Trusted Advisor)
By being intentional with your discovery in your first 30 days you would have demonstrate ‘empathy’ through seeking to understand first.
In your second sprint (30-60 days), you would have demonstrated competency by getting runs on the board.
And therefore your last sprint is focused on building upon that excellent foundation you’ve established whilst transitioning from quick wins to more significant and more strategic goals.
Bonus: Retrospectives & Transparency
Remember Greg from earlier? Another brilliant thing he did was share his plan with his peers and stakeholders.
Listen to why he decided to be so transparent and the impact it had in the clip below.
Now you don’t need to be as transparent as Greg.
But I would highly recommend that you consider at least doing a retrospective and playback (aka sprint review) at the end of each sprint.
Retrospective
This can be as simple as spending a few minutes reflecting on how the month went—what went well, what you struggled with, and what you learned?
Playback/Sprint Review
Is in the form of a playback at the end of each month to your immediate manager (and team and/or key stakeholders).
Simply covering:
What you had learned/achieved that month
Your plan for next month
This is a great way to get feedback, ensure that you’re managing expectations, and remain aligned with your manager.
This doesn’t need to be a meeting. It could be a slack summary, email or another format.
If you’re looking for inspiration check out these 6 weeknote formats.
FAQs
What about if I’m being asked to take action before I’ve done discovery?
Discovery is crucial when starting a new job and I can tell you if you respond to that request with something like:
“hey, I’ve only just started so I’d rather keep listening before throwing in my opinion”
or “I know you would like me to start doing X but can we hold of for another week or two whilst I still get the lay of the land.”
9 out of 10 you won’t get a negative reaction because it’s a perfect reasonable request to suggest that you’re too new and still learning.
I often find responses like this actually helps.
You show humility and curiosity, and people also like it when you take the time to listen and learn about them rather than jumping to conclusions.
What about the things I don’t know about when creating my learning backlog?
Yes, it’s true that your learning backlog will be focused on the known-unknowns, and there will be things that you don’t know yet that you need to know.
Firstly, your learning backlog is like any other backlog - it’s emergent and should be a living document.
So you should be adding to it as you learn more throughout your discovery.
Second, a helpful tactic I use to unearth unknown-unknowns is to ask open-ended questions when I meet with people for the first time.
For example, I like to ask:
“what do you see is going to be my biggest challenge in the role?”
or “is there anything else you think I should be aware of?”
More…
If you are interested, I have a self-paced course that dives deep into these sprints with templates and guides to help you get the most out of your first 90 days.
You can find the course over on Product Pathways here.
Hear more from Greg Smith on his key takeaways from the course and the impact it had in the clip below.
Top Posts
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…