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

 

 

Making product decisions requires us to take risks

Designing a good product – one that meets user needs and is both a viable value proposition as well as technically feasible – requires us to be both gamblers and scientists. When we say ‘gamblers’, we don’t mean we’re reckless and irresponsible. We work in an agile way which massively reduces financial risk and helps us find (or discount) solutions to problems quickly. Gambling for agile teams like ours is about speculating and taking risks in the hope of getting a desired result.  

Reducing the risk of building something useless

User-centred design tries to reduce the risk involved in building a product by focusing on what users do now, or what underlying job they’re trying to achieve. It involves determining who your users are, analysing their needs, and determining likely demand for different possible solutions. It’s as much art as it is science but done well it can reduce the risk inherent in deciding on a thing to build. And from these findings, these informed reckons, you do some research and start to shape a product.

If you gamble on your product decisions early you learn more, and the odds on creating a good product fit for your target user base start to shorten.

When to take bigger risks and embrace the long odds

Taking bigger risks at the start of the product life cycle usually pays off. At the start, you’re unlikely to have much data on your users and their behaviour, so prototypes will have a set of assumptions about your users to test.

Because you’ll probably only have relatively few users to test with, your gambles need to be stark in their differences. Be radical in tests as this helps discount huge swathes of things and sets you in roughly the right direction. As the product matures, you need to gamble less and make smaller, more educated guesses as the graph below highlights.

Graph. Y axis label is uncertainty or probability of being wrong. X axis is tests undertaken to validate product. The line goes from top left to bottom right.

Stakeholders: if we don’t take risks, we won’t win

Researcher Sam Ladner sums up the idea of being both gamblers and scientists in her post Design researchers must think fast and slow. She says:

Design researchers should embrace less structure and more openness at the early stages of product design, and rigour and structure in the mature stages of product sales.

Sam Ladner

The graph below, taken from Ladner’s post, illustrates this. It shows the move towards more structure as a product matures. You could plot the decline in uncertainty around market fit, target users, user journey and experience for example, as the product matures too.

The graph shows the move towards more structure as a product matures.

That’s how it should work.

However, being comfortable with uncertainty and embracing the idea of taking risks can make stakeholders and our non-Digital colleagues a little uneasy. And that’s understandable – this is an unfamiliar way of working to them. The Digital team know this though and we’re keen to work inclusively and show how testing assumptions is relatively cheap compared to traditional business.

How it works in practice

We can see from some of our projects at the Co-op that the propensity to gamble differs hugely from one project to the next. 

The Digital Product Research team moved quickly to test new propositions in the market: things like a white goods subscription service, and a service to ‘scrobble’ (automatically get and process) your utility bills to help you work out how your spending changes, and if it might be cheaper to switch. These were ideas spun out quickly and tested with real users. We learnt from doing the work that as products or services, they were unlikely to provide sufficient return for the investment needed.

Then there’s online Wills. We had more belief in this idea, ie, it exists in the market and is clearly already a thing. Here, it was a case of working out where our proposition would best fit with users and the existing business process. The gamble was on shorter odds, but in many ways felt far harder as we were working with an existing business and its staff, and embedded processes in a tightly regulated market.

Strategies for success

Navigating through product decisions and keeping our colleagues in other areas of the Co-op on board is not trivial. We’ve learnt 2 things which have helped us:

  1. Stay focused on the problem you’re trying to solve. Your experiments are trying to prove that it meets the user’s needs effectively.
  2. Business stakeholders prefer the language of data to qualitative research, so use data and qualitative findings to prove out whether the experiment worked and whether it met the user need effectively.

Good luck 🙂

James Boardwell, Head of User Research
Anna Goss, product manager

Making the General Data Protection Regulation easier to understand

gdpr-rights-posters (1)

The Co-op Data team has been preparing Co-op Digital for the new General Data Protection Regulation (GDPR), which will come into law next year. But we’re aware that the rules it sets out can appear complicated.

Too often, data can seem like a complex and distant subject, but it’s part of everything we do and it’s important to us that the whole business can see what we’re doing. GDPR puts consumers’ rights at the centre of data protection. As we work towards a Co-op that’s trusted with data, we believe this is exactly where they should be. And we will continue to focus on that as we build and develop our data programme.

Making GDPR more accessible

To make colleagues in Digital aware that the regulation is coming, we created posters to explain what it means in plain language. We think they’re a good way to make sure everybody knows about the rules and understands what they mean.

Screen Shot 2017-11-21 at 11.55.22

So far we’ve had a lot of feedback which shows there’s a great deal of interest ahead of GDPR coming in and real appetite to understand it better. The work that Digital has done in this area will help to inform the Co-op’s communications.

We’ve learnt a lot from the comments we received, and wanted to make sure that anyone and everyone can download our GDPR ‘rights’ posters.

It would be great to hear what you think in the comments. Or tell us how you’re making GDPR more accessible to colleagues in your organisation.

Posters: words by Rachel Murray and design by Jack Fletcher

We’re trialling an agile immersion course for all colleagues

Tuesday was the first session of the agile ‘immersion’ course – a free training course, put together and delivered by the team to help colleagues not working in digital experience agile working in a multi-disciplinary team.

The immersive nature of the course helps the team work collaboratively and aims to build on the foundations set by the Digital Skills Masterclasses which are more theory-based.

During the course, the group apply agile techniques and rituals to projects they’ve researched and selected. The course ends with colleagues showcasing their learnings at a show and tell in front of Co-op Digital’s heads of practice.

photograph of 4 colleagues on the course

Co-op Digital colleagues can help

The group is also required to work together outside of the sessions, with additional support provided by Digital colleagues. We’re looking for people across the communities of practice to help out with mentoring. If you have a spare 30 minutes a week for the next 2 weeks, get in touch with me.

Opening up opportunities in Digital

Since being seconded and then permanently employed by Digital last year, I’ve thought a lot about how to open up opportunities for non-Digital colleagues to experience agile ways of working, without taking time out of their day-to day-roles.

My hope is that after experiencing working in this way, colleagues would feel better equipped to:

  • introduce new ways of working to their teams 
  • apply for roles in the Digital team

We’ll listen and observe, then iterate

10 colleagues are enrolled on the trial course, all from our Support Centre in Manchester. We felt it was important to start learning about what works and what doesn’t as quickly as possible so we can make improvements and schedule another course early in 2018.

This time, the course runs 2 evenings a week for 3 weeks which means that it doesn’t interfere with day-to-day roles. Moving forward, the hope is we’ll be able to open it out, have more convenient hours and include colleagues from further afield.

The groups show and tell will be on 7 December at 12pm in Federation. Come along to see what we’ve learnt.

Annette Joseph
Delivery manager

Simon Hurst: life as a user researcher at Co-op Digital

(Transcript) Simon Hurst: I’m Simon Hurst, I’m a user researcher here at the Co-op working on Membership.

So, Membership is key to the Co-op, it’s a lot what the Co-op is. So my role entails sort of challenging assumptions that the business might have about customers or about members. So it’s understanding how people want to engage with the Co-op in the 21st century. I’m a fairly experienced user researcher now so I’ve been through digital transformation in government. I was originally first worked on the first Department for Work and Pensions service that went live.

The ability to go and do that all over again with Co-op Digital and to help a lot of
people who were coming to user research quite new and to help them along. So I think one of the best parts of my job is mentoring people as well, so I’m sort of mentoring someone at the minute and I’ve just trained someone as a user research.

So being able to share sort of things I’ve learned as user researcher with other people and equally we’ve got a good mix of people from different digital backgrounds. So even amongst the community of user researchers, there’s people with different skill sets to me I can learn from as well. So it’s just a really good mix. And stuff we’re trying to do is genuinely trying to improve people’s lives and help people.

The things I’m looking forward to right now are really starting to influence more and more how much user research is listened to, so really getting it properly embedded now. So we’ve got the roots there we now need to build on that and so it’s making sort of links in the wider Co-op to sort of share user research findings as opposed to sort of people directly on the product teams. And trying to find other user researchers to come and join us, who can join in with that and helping to develop user researchers here.

Co-op was the only other job I’ve ever applied for apart from government in 20 years, since I left college, so I have no plans on going anywhere so it’s it’s really nailing it here I think is what I want to do.

Simon Hurst
User researcher

Find out about opportunities to work with us.

Simon Stead: life as a software engineer at Co-op Digital


(Transcript) Simon Stead: My name is Simon. I’m a software engineer and I work on the Digital team that works with Food in Co-op.

So I already knew a few people who worked at the Co-op from my last job and they told me how fantastic it was to work here, how nice everyone was so I thought I’d apply and then I managed to get in.

We’re working on a multidisciplinary team so there’s me, some other software engineers, but it’s lots of user researchers, interaction designers, content designers, delivery managers, everyone is just pooling all of their resources and sharing all of the work and just getting your hands dirty at the same time.

So we’ll all be sat on the same table and I don’t often feel like a software developer because we’re all just trying to solve a common problem together. If that’s data, if that’s design, if that’s dev, if that’s user research we all pitch in and do a lot of the same stuff together.

I think the best thing I like about working at Co-op is that I can just try new things all the time, I get so many new opportunities and I get to engage with so many different people, be that people in Co-op Digital in the Food business, different stakeholders, area managers, store managers, whoever they may be.

I’m autistic, I’ve got Asperger’s syndrome and so one of the really nice things about working at Co-op and Digital is that I know I’ve got a wealth of support behind me so if there’s any problems I’m having I know I can talk to whoever I need to to solve that. If I need flexible working hours or anything like that it’s just all available here.

So we work over here at Federation and we also work over in Angel Square but Federation, the open space, the air, the light, the colour, the beanbags, everything just makes it such a nice open place to work and I feel like that really gets reflected in the digital products and services that we build.

Working at Co-op, I always thought I’d be the kind of person who would just like hop from job to job and never really stick to one place but I honestly can’t see any reason that I’ll be leaving anytime soon.

Simon Stead
Software engineer

We’re hiring software engineers. Find out more and apply.