Lessons learnt as a new Product Owner

New Thinking 29 June 2020 Mispah Carelsen

A few years ago, I was thrust into the Product Owner role for the very first time and it was utterly nerve-wracking.

Suddenly, people were looking to me to make decisions – whether I wanted a pop-up or tab, decide between light blue or navy, whether the email should send before the transition or after, if we fix the bug and delay shipping to prod or ship and put in a patch. “What on earth have I gotten myself into?”, I thought, albeit with more colourful language.

As a first-time PO, I felt woefully inadequate and under-prepared. Reflecting on the experience, I wondered what support someone going through a similar experience should receive. What would I say if I could go back in time to make that experience a little bit easier and a lot less painful? (If you’re wondering how I got the role in the first place, the answer is… understaffing).

So, if you’re in a similar position, here are three fundamental lessons I learnt that I give to new POs:

Step into it

Don’t shy away from the role. Embrace it and commit to it. Your team and stakeholders are looking to you to make necessary decisions on priority and scope, to balance quality with speed, manage stakeholders, truly represent the voice of the customer. They need you to be the Product Owner and provide direction.

One mistake I’ve made is to tiptoe around product ownership and shy away from it ‘in the spirit of collaboration’. The team was made up of highly-knowledgeable people, well-versed in Agile and, due to politics with leadership, I figured that product ownership would mean stepping on their toes.

I realised my mistake far too late when the wheels started to fall off after being stuck in the mud for too long and the team went into endless wheel-spinning loops. When I woke up and decided to just step into the role despite the politics, the team began to fly.

All that was needed was someone making the priorities clear, creating focus, whittling down the goals, providing direction and clarifying the why to allow the team to focus on execution. Someone to stand up to stakeholders pulling the team in different directions, someone to make the tough decisions and be accountable for them. Not every team needs that, but I’ve witnessed a similar pattern playing out far too often in teams I’ve coached.

Set a vision

It’s easy to assume that everyone is on the same page when you’re constantly engaging in fortnightly planning together. And it’s frustrating when you are then second guessed at every turn, feeling like you constantly have to re-convince the team of your decisions.

I assumed they shared my vision... until I realised that I had never explicitly set the vision. Sure, I spoke about my views and what I had envisioned. But I had never actually created a vision and taken the team on that journey.

When I did, it was like a magical switch had flipped. Suddenly, the team began focusing in a way that blew my mind. They kept each other on track by saying things like “Cool idea, but it’s not in line with the vision.” Self-organisation came to life in a way I hadn’t seen before. All from one deliberate act.

Define what value means

It sounds elementary, but you’d be surprised how many assumptions we make around what value means. Worse yet, we assume what value means to our customers. We prioritise features and user stories according to our own perspective. We push the epics that will bring the most revenue. We deliver quick wins to show that we’re making progress (the low-hanging fruit trap).

We talk about delivering value and creating thin slices of value, but we rarely take the time to deliberately define value. Value is context-dependent – what’s considered valuable in one context can be meaningless in another.

So it’s important to define value according to your product context, and more importantly, to your customer’s context. It’s also probably a good idea to start measuring that value. As a newbie PO, I understood the concept of value but never really defined it. So it wasn’t always clear whether we were actually making the impact we wanted and defining success became muddied as a result.

...Bonus mistakes

Being a Product Owner with no prior experience, training or support was rough. So it goes without saying that I made many mistakes. Here are a few…

  • Shielding the team from the customer: Not everything goes to plan and it’s important for teams to build empathy with customers so they can create better products. And always protecting the team from criticism is probably going to block that
  • Being wishy-washy about using data: The more data you have, the better your decision making. Simple
  • Ignoring road-mapping: I cringe when I think back to it, but there was so much happening at pace all at once that it was difficult to build a roadmap. We took it sprint-by-sprint and winged it most of the time. So there was little strategic thinking and, as a result, our focus was scattered, our stakeholders were misaligned and we weren’t clear on our goals
  • Not creating time for backlog refinement: Working at what felt like breakneck speed meant activities that should have happened, didn’t. One of those was backlog refinement. Planning ended up being painful and always felt like a mad scramble. Creating the time and space to think ahead and work on refining the backlog made a world of difference to our sustainable pace as a team

I could go on, but you get the point. These might sound basic but, as a new PO, support in the basics was exactly what I needed. So don’t feel like you’re in it alone. And if you need any help getting your product delivery back on track, get in touch. We’re launching coaching support specifically tailored to those in the product delivery space who need a bit of help building the right thing, in the right way. Download our PDF to help you on your way.