Over the years I’ve managed several product teams, always from first principles, and as I’ve matured as a product manager I’ve written a few memos to myself. Things that got us over a hump or feedback I received from colleagues. Every so often I’ll glance back at these memos to remind myself how to do things well. These are the must-haves and key things to remember which help me start or join a product team and hit the ground running, which I use in conjunction with this list of things to do as a new product manager.
This is a living list, so it might change. Check back every now and then.
The foundational principle
As product manager, you look after the environment that the team needs to succeed, making sure we all have a clear view of what success looks like and how we’ll get there. Give them space to collaborate and facilitate them in making decisions.
Start with the basics
- What is the product or service?
- What problem does it solve? Write that down in plain language.
- What is the outcome we want users1 to reach? What is the outcome we want users to avoid?
- What are the pain points preventing users reaching their outcome?
- Which of those points is most painful and needs removing first? Which one next?
- What are the unknowns (discovery)? What are the knowns (delivery)?
- Where’s the documentation? You’ll need to update it each week, if someone else doesn’t do that already.
Working in a team
- Set up a regular check-in with your delivery manager, twice a week if possible.
- Make sure pre-planning is 2 days before planning, giving ample time to refine cards and user stories.
- Pre-planning should involve tech lead, design lead, and delivery manager (at least).
- Don’t risk doing the classic retro mistake of trying to change everything after one sprint.
- Figure out your team’s skillset, particularly what they’re not good at, and their development objectives. Try to base the work on that as much as possible.
- Create psychological safety and build trust by being open about your mistakes. Explain how you hope to improve things.
- UCD people work with well ambiguity; developers prefer clear cards.
- Get Show & Tell lined up early, and sing people’s praises.
- We need to know how big the problem is, it’ll help us work out when we’re done.
- Reach, impact, confidence, effort, and urgency are universal prioritisation criteria.
- Try not to rush cards through: take time to gather context and understand the problem holistically.
- Start small, test risky assumptions, iterate and grow.
Working with stakeholders
- Be open about how the team expects to achieve its objective. Be open about not yet knowing how to achieve that too.
- Don’t give senior stakeholders a problem, give them a solution or how you expect to move forward.
- Use senior people to twist arms when you need something from another party – you can’t do it all yourself.
- Present the risks and show your working to get buy-in.
Do these resonate with you? What would you add or change? Let me know on Twitter, it’d be great to hear from people.
At GDS we tend not to use the term ‘customers’ but it’s still applicable if you’re running B2B or platform products. ↩
These are some things you can do in your first 30 days as a product manager which help me hit the ground running.
It's a change in mindset for leadership to manage outcomes or results, instead of the traditional way of managing effort and output. Here's how I turn 'Build this' into 'Realise that' on GOV.UK at the UK's Government Digital Service.
Areas of responsibility are assigned to people so that when someone asks ‘Can anyone tell me what X is supposed to do?’, there is someone who can give a clear answer.