Starting a ✨ new ✨ product manager role
Joining a new team in the same organisation is hard, nevermind joining one in a new organisation. Product managers are expected to have breadth and depth - to know every nook and cranny of their domain. It’s commonplace - and very normal - to feel out of your depth.
“It normally takes about two to three months of dedicated work for a new product manager to get up to speed." Marty Cagan, Inspired 2nd edition (2018)
As a new product manager, you rarely have two to three weeks to get up to speed, let alone two to three months. To get your product pointing in the right direction as soon as possible to give you the best chance of success, and also to give confidence to your peers and to the higher-ups, here are seven practical tips born out of decades of combined experience:
- Know your team 👋
- Know your product 📲
- Know your users 🕵️♀️
- Know your tech stack 👩💻
- Know your stakeholders 👩💼
- Know your dependencies 🤝
- Know your metrics 📈
Know your team
Book in a fifteen minute one-to-one chat with each team member
Get to know them. What do they get up to outside of work? How long have they been in the team / organisation? What matters to them? What doesn’t? Ask what you can do for them.
Over-attend in general
For the first few weeks, attend as many meetings as possible to help get a vibe for what different roles do. You have an automation engineer in your team? Then see if you can sit in on the automation community of practice catch up. It’ll all provide a useful grounding.
Lean on your experienced team members
Your designer has been with the team for eighteen months? Ask them for their perspective. What matters to the team? Where are the landmines hiding? Ask them to talk you through a meaty piece of work that the team has delivered over the last few months, from start to finish.
Participate and pay attention in ceremonies
Stand-ups, planning, shaping, retros, etc. It’s important that you absorb as much as you can in these regular sessions, where you’ll get a feel for the items in flight, team dynamics, ways of working, as well as the wider team and org context.
Pore over relevant artefacts
Your Miro boards, your Team API, your org chart. The shape of your team’s kanban board and the level and detail of items of work.
Understand work in progress
You’ll probably get this level of detail from stand-ups and from reviewing the team’s kanban board, but there is no harm asking for an overview of what is on the board and what is lined up from your designer or tech lead. It’s good to know why it is being worked on, but don’t feel like you need to cover every blade of grass of half-delivered items - your time is probably better spent on what is to come next.
Know your product
Use it
Ideally in production - as far as you can without spending a large chunk of your own money (like buying a car) or inconveniencing employees unnecessarily (like submitting a complaint).
Non-production environments (e.g. dev, QA, pre-production, staging, feature branch) can also become a product manager’s best friend. Find out what you have, and also what you can do in each without impacting other teams - you might want to be careful not to buy up all of the dummy products on your QA environment if it would block all your other teams from testing their new features. Your tech lead should know. Ask the whole team on Slack if you have to. Know that these environments can be slightly ahead of production, but spend a few days getting familiar with them - go through your whole service as end-to-end as you can, many times, many different ways.
Ask for a demo
Your designer, experienced hands, or your predecessor are good starting points. Someone who can give you a whistle-stop tour of your new domain.
Study your service blueprint / service map
These are typically owned by product or design people, and may live in Miro or Visio or similar. They’re often stale, but can still provide lots of useful context - particularly the backstage stuff that isn’t discernible from just playing with a product. Your team / org doesn’t have a service blueprint? Create your own high level one - often the best way to stamp the core flow of a product onto your brain. See our service blueprinting article for guidance on how to create one using our free Miro template.
Understand your product data
Find out what sources of data exist, who the experts (and gatekeepers) are for each. Get access to as many as possible. Get in on playbacks / Slack channels / mailing lists. If you have a dedicated data analyst / scientist, they may be your best point of contact here. Typical sources would include analytics tooling (Google Analytics, Adobe Analytics), a broader data visualisation suite (Power BI, Metabase, Tableau), technical performance dashboards (Datadog, Kibana). This exercise will more than likely reveal gaps and blind spots.
Study the wider context
Hopefully the above points will paint a picture of where your product sits within the wider organisation, but it can always be useful to deepen your knowledge of the industry in which your product lives, as well as the competition. Use Owler or similar for an overview. Google (or ask) around to find the most relevant industry publications and read a few.
Know your users
Spend time with them
Ask your designer / researcher when the next research session is and ask to attend. If there aren’t any planned, try other teams in and around yours to see if you can sit in on any. Or ask if some can be pencilled in as a priority for your team’s most pressing research need. If you have Hotjar, Datadog RUM, or similar, watch some videos of real users using your product. Ask if there are any historical research recordings or summaries that you can view at your leisure.
Get secondhand feedback anyway
If your customers leave reviews or send you feedback, read as much of it as you can stomach. Ask your team and other product managers what other sources exist and soak as much up as you can. Have a look through social media too.
Distil the above into a product team canvas
A high level illustration of what your users do with your product, their pain points, their high value interactions, all informed from everything you’ve learned about your product and its users. This can prove an invaluable reference point for e.g. prioritisation, bringing new team members up to speed, high level impact analyses. It might be that you do this as part of the wider service blueprint. Learn more in our product team canvas article, which links off to our free Miro template.
Know your tech stack
Go on ‘the tour’
Your tech lead or an experienced engineer probably has some contextual training materials that they step through to bring new engineers up to speed. Ask for a lightweight version of this. Having at least a basic grasp of the technology is vital. Ask questions around levels of tech debt and how this is managed, how automated testing works, what the biggest pains are, whether there are any tech work items looming on the horizon.
Get stuck in
Explore GitHub to see what your repo(s) look like. How often are they updated? Who contributes? Are there any architectural diagrams on GitHub / Miro / Confluence that provide useful context?
Know your stakeholders
Create a stakeholder map
You’ll likely already know some of this on day zero, so start right away. A nice, high level visualisation that can sit on your team miro board or similar is a handy resource. Miro provide some useful stakeholder mapping background info and templates
Study your existing artefacts
As already mentioned earlier - org charts, service blueprints and the like can be very useful when looking to build up a picture of who cares about your work.
Ask your peers
Or your predecessor. Or whoever has held the fort since the last product manager left. What does the release of a feature usually look like? What comms accompanies a new feature? Who can approve / reject a feature? How have they been burned in the past? Where do the complaints usually come from? Where are the disconnects?
Ship something
Risky, but one of the quickest ways to flush out who your key stakeholders are is to get something out of the door and see what ripples it generates. Even if you feel you’ve got a really good handle on your stakeholders and your release process and comms is tight, it’s always a good idea to pay close attention to all the relevant comms channels anyway post-release, to see if there are any unanticipated downstream impacts.
Know your dependencies
Draw them up
If you’re lucky, a Team API or similar will already be in place when you join. If not, you can start by creating your own lightweight view of the outgoing (you rely on them) and incoming (they rely on you) dependencies of your domain. Understanding your product, tech stack, and stakeholders can really help here.
Typical outgoing dependencies include third parties that provide components that your team utilise, upstream teams that provide data or other capabilities, and teams that look after capabilities that sit before you in a linear user journey (so the team who look after a product detail page could be an outgoing dependency for a team that looks after the checkout process).
Incoming dependencies would be the inverse of this e.g. teams that look after a step further down your linear user journey, or consumers of your data or capabilities.
Build up a rapport
Pencil in some time with each of the owners of your inward and outward dependencies, at the very least to introduce yourself and to sanity check your understanding.
Know your metrics
Understand the organisation’s aims
Hopefully there is a clear and well communicated business or product strategy already in place. OKRs are a widely accepted mechanism of documenting such a strategy and aligning it across the different levels of an organisation.
If you happen to be in a large organisation, it might be that the product engineering arm is split into tribes or similar, each of which may have their own OKRs that may also warrant your scrutiny.
Set (or reset) the team’s objectives and key results
At the very least, you’ll want to review what the aims of your team are. If there are no clear objectives or key results, you’ll likely need to rectify this.
Define, visualise, evangelise
For each of the metrics that you believe are worthy of tracking, clearly define each in turn. If you have a data analyst / scientist, their involvement will likely prove valuable here. Read our pirate metrics article to learn out how to quickly draw up and define these.
Secondly, get this data somewhere central as soon as you can, even if this means manually maintaining it whilst you wait for a more automated dashboard.
Lastly, refer to these metrics as much as possible. Anytime you prioritise what you are to work on. Anytime you shape a piece of work. Anytime you talk about what you expect to focus on next. Anytime you demo or assess the impact of what you have delivered.
In summary
As you’ll have seen, there is a lot of crossover between each of the seven areas, so just managing to get through a few of these in your first week or two will stand you in good stead.
It’s also worth noting that this isn’t just for product managers. Whilst an incoming product manager needs to cover all of these bases in order to carry out their role effectively, all of the other roles in the team will likely benefit from the deeper knowledge that these activities provide.
