# Must-haves when starting or joining a product team

> These are the must-haves and key things to remember which help me hit the ground running when starting or joining a product team.

> Last updated: 2020-08-15

## Must-haves when starting or joining a product team

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](/2020/09/06/things-to-do-product-manager-first-30-days/).

_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

- The biggest risk isn’t slow delivery, it’s being wrong at scale.
- What is the product or service?
- What problem does it solve, and for whom? Write that down in plain language.
- What is the outcome we want users[1](#fn:1) 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.
- The biggest risk isn’t slow delivery, it’s being wrong at scale.

## Working in a team

- Establish your team’s shared principles and ways of working early. Refer back to these guidelines often, and iterate where needed.
- Find or map the product development model, and make sure that roles and responsibilities are clear to everyone on the team.
- When it comes to ground rules and ways of working, don’t assume shared understanding or expectations. Make the implicit explicit.
- Set up a regular check-in with your delivery manager (or whoever is looking after delivery), twice a week if possible.
- 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.

## Being agile

- We need to know how big the problem is, it’ll help us work out when we’re done.
- Estimation can be a useful exercise. Be clear on why estimates are needed and how they’ll be used.
- If you’ve got no idea how to build something, start in the middle with a time-boxed alpha. Then re-plan. Progress is better than perfection.
- 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.
- Keep a decision record and update it after each meeting or workshop. If you shave scope, make it clear.

## Doing research

- Don’t make big decisions off the back of one research or testing study. Trust the process and get some more evidence.
- Care less about what people say and more about what people do. Behaviour tells the truth, everything else is noise.
- Confidence is not a substitute for evidence.

## 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 [the socials](/contact/), it’d be great to hear from people.

1. At GDS we tend not to use the term ‘customers’ but it’s still applicable if you’re running B2B or platform products. [↩](#fnref:1)

15 August 2020 · [Product management](/tag/product-management) [Popular](/tag/popular)  

Related posts: [Things to do as a new product manager in your first 30 days](/2020/09/06/things-to-do-product-manager-first-30-days/), [Let’s talk about product](/2021/09/21/lets-talk-about-product-community/), [New course on product management in the public sector](/2024/09/30/new-course-public-sector-product-managers/)

12 replies, 13 reposts, 85 likes