Lessons learnt: starting out as a product manager

I came to Co-op Digital as an agile business analyst and relatively speaking, I’m pretty new to product management.

I wanted to take on a product manager (PM) role after working with some inspiring people – Anna Goss, Lawrence Kitson and Charlotte King to name a few. I saw each of these people lead teams to meet user and business needs with design and technical solutions. And I wanted to do the same.

Since then, I’ve had to learn a lot of stuff. And quickly.

The other week at Product Camp Manchester, I gave a talk at on the advice I’d give my less experienced self. This post is about what I know now with the power of hindsight.

1.Context is everything

Yes, it’s the dream to get something in the hands of your users within a couple of months – weeks even – and that might be possible if you’re a product manager in a start-up.

But Co-op isn’t a start-up. It’s a huge, traditional organisation and for the vast majority of stakeholders, the pace digital teams move at can be scary. I understand that worry. Of course, it can take longer to get digital products and services out there when you’re working in an organisation going through digital transformation. And I’ve learnt that that’s ok: you need to take into account the time it takes to communicate what you’re doing clearly, and convincingly, to the right people. That way, you get the credibility to continue.

2.What you work on affects your learning

Many new PMs choose to work on ‘safe’ products or services. I didn’t. Instead, I prioritised working on the most interesting product. I pushed for my first product to be one of Co-op’s new ventures because I was really interested in lean product techniques and working on something new felt like a good way to test them out.

However, there have been times when having more experience would have been useful with a product like this. With experience comes confidence and with that comes the willingness to make decisions more quickly (granted, not always better ones). With the power of hindsight I’d be in a better position to be able to weigh up working on something that has more structure because it already exists and the challenge of shaping and influencing the direction of a product from inception.

Although I’m glad I stuck with the product, having the right people in place (an excellent community of practice and a supportive team) has been essential.

3.Influence team morale

Part of a PM’s role is to be in tune with the team’s morale, and sometimes to influence it. I’ve found that keeping these 3 things in mind is helpful.

‘Failing’ is just part of the process

Occasionally, things won’t go to plan. That’s unavoidable. We’ll make the wrong assumptions; we’ll test the wrong thing; a user will interact with a prototype in a completely different way to how we expected, and there’ll be times when we don’t do everything we set out to in a sprint.

As a PM you need to make sure the team knows that all of those things are ok and that making mistakes is fine as long as we’re learning. Letting them know gives each person autonomy, it shows you support them to get on with their job and that you trust their expertise.

The best bad decision is better than no decision

Sometimes, you won’t have enough information to make an informed decision. In those instances, accepting a sensible amount of risk, taking a punt and learning is more beneficial for the team because it keeps things moving. It’s always a good idea to explain a ‘best bad’ decision and the options to the team.

Hand-drawn doodle. A man standing in front of a sign post choosing to go in the direction of 'bad decision' rather than 'badder decision'

Any compromise warrants a thank you

You’re undoubtedly working with some very skilled and knowledgeable people and sometimes you’ll be in a position where you need them to compromise in the name of progress. Nobody likes compromise so if someone does it, showing your gratitude is essential.

4.Learn from doing, not just reading about doing

So much of the role is about how you interact with people, how cooperative they are and how much confidence they have in you – a lot of this can only be learnt through experience, through doing the job. You can read as many PM books as you like but the only way to learn properly is practically, by being on a team. Applying theory to deliver something valuable is the hard part.

5.Empower the team by being clear on your mission

Teams always say they want autonomy. But, if a team has complete autonomy but no mission they might end up building something super impressive and, unfortunately, completely useless to the problem they’re trying to solve.

They might end up building a rocket and not know why.

Hand-drawn doodle of 3 people looking at a very impressive rocket. One says: We built a rocket! Another says: Why?

Autonomy only works if the team is aligned. Creating a mission and communicating it to the whole team will give a clear purpose and empower each person to get on with delivery.

I’ve learnt a lot in a really short time. And as long as there are problems to solve, the learning won’t stop. We’ll be hiring product managers again very soon. Keep an eye on our jobs page and follow Co-op Digital on Twitter to stay in the loop.

Anthony Wilson
Product manager

Illustrations by Maisie Platts

 

 

The Membership team is maturing, and so are our ways of working

On the Membership team we’re switching up how we organise ourselves to help us be more effective. Here’s why and how we’re doing it.

Evolving with the product

As teams mature, ie, they get bigger and the scope of work widens, it’s not hard to figure out that they’ll need to reorganise. American investor Ben Horowitz famously wrote about this in the book ‘The Hard Thing About Hard Things’. He said he believes that every time a team doubles in size, it should review its ways of working.

We’re doing something similar in the Membership team. Back in September, the product management team was just one person, Derek Harvie. Since we relaunched Membership, the scope of work has been getting larger so the team needs to scale up. The product team is now 4 people to reflect the change. One of those newbies is me.

Realising we’d outgrown stuff

When I joined, we had 3 teams: Blue, Orange and Pink. They were named after the colour of the post-it note that corresponded with what they were working on in the backlog. And that all made sense when the team was starting out; being lean and nimble negated the need to be aligned. But as our ambition for Membership grew, the team became more and more thinly spread and it became more difficult to properly focus on one thing, and really do it well.

Clarity around where we’re going (and how to know when we’ve got there)

We’ve introduced OKRs (objectives and key results) to make sure that everybody is moving together, in the same direction and aiming for the same things. Now, each team has a set of objectives and has agreed on a set of results that will show when it’s achieved what it set out to.

We looked for natural ways to split up the work so teams don’t have competing objectives. It means they can be in control of their own scope of work without lots of dependencies.

4 teams, 1 direction

At this point we naturally fell into 4 teams. This time, we’ve named them in a (slightly) more self-explanatory way. There’s:

  • More members (recruiting more members)
  • Member trading (looking at how our members shop with us)
  • Member engagement (engaging with Membership, causes and community)
  • Member services (managing the membership platform, ie, the backend infrastructure)

With clarity comes better prioritisation

Now we’re all on the same page we’ll find it easier to prioritise. Before, it was hard for the team to understand what to work on next because the tasks in the backlog fell into different areas.

Prioritising will be much simpler now we have the 4 teams working on different areas. Tasks are compared against other tasks from within that area so now it feels like we’re comparing apples with apples rather than apples with pears!

Better for us. Better for stakeholders

Working in this way is also really good in terms of how we’re working with stakeholders. The old way of working meant we had 30 plus stakeholders all wanting the tasks that fell under their area to be the priority. Hopefully, things will be calmer now each team has around 10 stakeholders to work with and include in decision making.

In a few more weeks we’ll be able to see if we’re achieving our targets and back it up with data, but at the moment it just feels like the right way to be working.

The team will continue to grow. Keep an eye on our work with us page.

Adam Warburton
Head of Membership Product