I was recently asked for advice by a someone who was new to the role of being a Product Owner. I decided to write something down which I would be able to share in the hope that others might find this useful. I’ve tried to distill what I’ve learned in my three years of doing the job into these notes.
This is quite Skyscanner-focussed and uses terminology such as tribes, squad, guilds etc which come from the Spotify Model.
This advice is based on my three years as a Product Owner in Skyscanner. They touch on the more textbook Agile responsibilities of being a PO as well as my own personal advice on how to perform them. They might not be completely ‘textbook’ but they’ve served me well so far and if I’m still doing this job in a few years, I’ll be confident in their accuracy!
Be the voice of the customer
Product Owner Manual page 1. You need to be the voice of the customer to your squad which means you need to be aware of who your customers are and how they use your product. You need to understand their problems and their pain points. You need to know how removing certain reliability issues or building new features will improve their life. I like to think about the Modern Agile principle of Make People Awesome. How can we make our customers feel awesome?
This is a real balancing act because you’ll need to juggle their immediate wants with goal work and service ownership, but these asks should ultimately find their way onto a roadmap if they’re important enough.
One piece of advice I’d give on getting to know your customers is to try to find out the guilds they might be part of and attend the meetings and join their Slack channels if they are public. Sometimes the chat might feel like it’s going over your head but ask questions and even though it might not feel like it, you are building out your knowledge base.
Similar to being the voice of the customer, you need to flip that perspective around and be the voice of your squad to the business. Some of this will happen as a matter of fact such as attending governance meetings, but you should also look to celebrate successes publicly whenever you can. Encourage blog writing within the squad and lead by example if you need to. Speak with Tribe Leads and try to find ways of doing demos at All Hands etc. It may seem pretty daunting but it’s part of the job.
Grooming and Backlog Prioritisation
You should set up regular grooming sessions with the squad and do this collectively but ultimately the decision on what to cut and what to prioritise rests with you.
This is my approach to grooming/prioritisation;
The sprint backlog(s) should ideally contain three sprint placeholders for Now, Next, Later with the current sprint being at the top and most detailed. Below that, the next sprint(s) would ideally be starting to take shape.
These cards should be prioritised based on;
- Dependency – do we need to build a cluster etc before development work can happen. Are we able to measure metrics?
- Customer Priority/Impact – it goes without saying we want to work on the highest impact tickets first
- Riskiness – work through risky work as early as possible. Fail Fast/Learn Fast. It’s soul destroying getting 6 weeks into a piece of work then realise you’ve hit a dead end.
Keep your Next sprint pretty loose to accommodate rollover cards from the current sprint, technical blockers or changes in customer demands. If you can see more sprints after Next taking shape, by all means create them but don’t get too hung up if you can’t – you’ve still got a few sprint planning meetings to happen before this sprint takes place.
Involve your team
Involve your team in customer discussions. This is hugely beneficial for a number of reasons;
- The stereotypical role of the PO is to be the go-to person between a customer and the dev team, and be the single wringable neck. This by definition makes you a bottleneck. Don’t be a bottleneck – involve others.
- Your understanding of the problem might be flawed, ergo when you communicate this to your team, their understanding becomes flawed.
- You might not understand a technical requirement that the customer has. Your team consisting of subject matter experts will probably be able to help you in your understanding, therefore it makes sense to involve some of them.
I get frustrated when I read about the stereotypical introverted software engineer that just wants to be coding in a dark room.
Every development team I’ve ever been in had engineers who wanted to know that their efforts were impactful and not a waste of time and craved face-to-face time with customers.
Setting the Vision
One of your responsibilities as PO will be to set the vision at some level – Tribe/Squad etc. A piece of advice I’d give is to really communicate the problem space to your squad then let them decide on how they want to tackle it rather than telling them what to do. This helps give your squad autonomy but it’s up to you to ensure alignment. Your storytelling ability (more on that later) will help you with this.
It’s a bit of a cliché but sell the problem, not the solution.
Foster Alignment to the Vision
To help foster alignment within your squad, I’d recommend having semi-regular roadmap meetings with your squad. I’ve found fortnightly is about right. In these meetings, chat about how your current goal is going. Is it faster/slower than you all thought and why might this be the case? Use this to get a feel for the key milestones you want to deliver over the next few weeks. This helps get people on board with the shorter-term plans (and also negates the need for sprint pre-planning which some squads do).
You should also look at the longer-term roadmap and discuss if it’s still the same or are there new business priorities which might be looming in the next few months that we should be aware of now. The intention is that your squad would be able to give a clear answer on what they will be working on in two weeks from now, two months from now and potentially six months from now.
Arguably, more important than your ability to deliver in these PO responsibilities is your relationship with your squad. Bear in mind the following;
Be a Servant Leader
You need to adopt a servant leader approach with your squad. Ultimately your success as a Product Owner is dependent on the success of the team. Be subservient to your team and do all you can to remove blockers and build knowledge. This siding with the squad can take a bit of getting used to but stick with it. Sometimes you’ll see a PM (and I’m stealing this for PO) being referred to as the ‘CEO of a product’ – this is completely false because as PM/PO, you have no authority over your team – it’s your job to inspire! It’s on you to make your squad get excited about building a solution that delivers value.
Additionally, your squad will contain subject matter experts and it would be folly not to utilise that knowledge.
Fight your Squad’s Corner
You’ll sometimes need to forcibly manage up the way and really fight your squad’s corner. This can be uncomfortable at first but you’ll get used to it. Skyscanner values say it as it is as part of its culture. For example, if you’re given an unrealistic deadline, don’t accept it and push it down to your team with a shrug of the shoulders saying ‘it’s what management wanted’.
Don’t be a Shit-Shield
Don’t be a shit-shield for your squad. Lots of people when I started as PO told me the number one thing to do was protect my squad and let them concentrate on building. It seems pretty sound advice until the time comes when there’s a general feeling that your squad is under-delivering and you’re not communicating that to your squad. Then you take a holiday and can’t control the narrative. Through second hand whispers and rumours, the full extent of bad feeling is communicated in one go and it’s a real shock to the system. The squad will feel bad as their professional pride takes a knock and you’ll have egg on your face for not being honest and transparent.
Be more like a shit-sieve. Filter out the worst bits but make sure the overall message gets through. Your squad needs to know what’s going on around them, so distil any feedback and use it to your advantage to provoke a positive reaction if required. If a difficult conversation needs to be had, have it. It’s not fair on your squad to keep anything in the dark. Always be as transparent as possible. It makes it easier to relax on holiday!
Storytelling is Important
Learn to tell a story. Use this as your method of communication.
Stewart Butterfield, the CEO and founder of Slack once said an interview with Reid Hoffman on the Masters at Scale podcast;
If there was one piece of advice I wish I could phone back and give to myself was just concentrate on that storytelling part, on the convincing people. Because if you can’t do that, it doesn’t matter how good the product is. It doesn’t matter how good the idea was for the market, or what happens in the external factors if you don’t have the people believing.
So, when passing on a directive/piece of work etc to your squad, know the story behind it. Understand the impact of a customer request, ie, building feature x will save customer y z amount of hours each month to focus on growth rather than deciphering reports. Communicate this well to your squad and you’ll get the buy-in. You may need to convince them this story is more important than the story they’re working on but that’s a healthy debate. It’s better than you asking them to work on something that you’re not sure about yourself, which can create a lot of uncomfortable questions.
When you really understand a story and the importance of a request, you can use this to really zero in on working on the right thing. I’ve actually been successful in pushing back on leadership requests in the past because the story they were telling me about a piece of work they wanted done wasn’t compelling enough for us to stop what we were working on.
The last two points I want to give some advice on relate to stakeholder management.
Be a Conduit
You need to become a conduit between your squad and tribe/goal leadership. There are certain communication and ways-of-working nuances that tribe and goal leads have which are different to the nuances that squads have. As a PO you need to be able to translate these and ensure that the correct message is communicated to leads regarding squad delivery cadence, blockers etc and don’t be afraid of delivering bad news. People don’t like bad news, but they hate bad news even more when it’s a last-minute surprise.
When tribe leads know what’s going at squad level and squads know what’s going on at tribe level, life is much better for all involved. It’s the transparency and open communication that enables this.
Enjoy the Theatre!
Finally, one last point and one that I probably shouldn’t be making public is with regards to ceremonies you’ll be attending as PO such as governance.
I’ve seen some people not feel particularly comfortable in these environments. My advice would be to try and enjoy them. Treat it as a bit of theatre. There’s nothing to worry about if you’ve got the answers to the difficult questions because you’ve done your homework and come well prepared.
Use these sessions to celebrate the success of your squad and to build your own personal brand!
Reading List
Here are some books that I’ve found useful. They’re ordered by my purchase date on Amazon – not by any rating.
Ones that really stick out are though are Scrum Product Ownership: Balancing Value from the Inside Out, Strategize, Escaping the Build Trap and Lean Analytics (which isn’t as dry as the title sounds).
I apologise in advance for the poor table formatting – Word Press is not one of my strengths.
Title | Author |
Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series) | Alistair Croll |
The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever | Michael Bungay Stanier |
Escaping the Build Trap: How Effective Product Management Creates Real Value | Melissa Perri |
Validating Product Ideas: Through Lean User Research | Tomer Sharon |
Impact Mapping: Making a big impact with software products and projects | Gojko Adzic |
Strategize: Product Strategy and Product Roadmap Practices for the Digital Age | Roman Pichler |
The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results | Stephen Bungay |
Scrum Product Ownership: Balancing Value from the Inside Out | Robert Galen |
Collaboration Begins with You: Be a Silo Buster | Ken Blanchard |
The Goal: A Process of Ongoing Improvement | Eliyahu M. Goldratt |