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.

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, and for whom? Write that down in plain language.
• What is the outcome we want users¹ 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

• 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.

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.