Lessons learnt from an accidental Product Owner

(this was originally published on https://sperringjones.medium.com/lessons-learnt-from-an-accidental-product-owner-4ce50ce9ab48 but I wanted to collate all my articles into one place)

When I joined Manifesto in September, I was swiftly given a project with very tight timelines and slightly unclear goals. Having stepped off the public sector treadmill working on high-profile projects for Brexit and most recently covid-19… I felt ready to accept the challenge.

After previous roles where I’d regretted keeping quiet about concerns, in this instance, I used the ‘I’m new here’ card to ask infinite amounts of questions about strategic objectives, user needs and long term vision of the product. 4 weeks into the project, the decision was made to move me into the internal Product Owner role. This, in many ways, felt like my time to shine as I was able to bring all my technical and user-centred design experiences and principles into one role.

I love turning the complex into something simple and the last 2 months have been my opportunity to do just that.

As I write this now, we’ve just smashed our first milestone by creating a learning platform in just 3.5 weeks. I couldn’t feel prouder of the team. Colleagues outside of the project team asked me “How did you help to develop these requirements?” so here are some key lessons I’ve learnt in the last 2 months.

Desktop research

Earlier on in the process I researched what was going on in the online learning space to understand the latest trends. I signed up to online courses, participated, put myself in the mindset of the student and made note of cool things that made the experience memorable.

Write a Product Brief

Saying “minimal viable product” is easier said than done. We need to unlearn that complexity is success…the answer lies with simplicity, we find success through simplicity.

At the very start of the project, I created a product brief (first observed from the great Colin Pattinson in the NHSX days). The product brief summarised the product vision in 2 pages; a one sentence definition, target users, desired outcomes, ways to measure outcomes and constraints for success.

This is a verbal equivalent of an impact map, Miro does a nice template for Impact Mapping if you want to think visually.

The brief provided the backbone to everything we did. I feel the product owner is essential in reminding everyone, through repetition on calls or on Slack of what the MVP goal is. The benefit of this is clear: the team feel empowered that they know what they’re building, most importantly, they feel safe from the worry that a nasty big complex feature is going to give them long working days and sleepless nights.

The product brief was like the Northern Star which we could look up to throughout the process; this stopped us from tripping up on the weeds of complexity and endless features.

Early client workshops to define strategic vision

For the client, this was the first time they were creating an online product of this kind so it was important to prompt big picture thinking early on. I ran a workshop earlier on with a small group of decision makers to ensure we all had a shared understanding of what the product should do.

As part of this session, I setup a Miro board, shared my screen and asked the following questions:

• what must your users know after completing this course?
• what must your users feel?
• what would the perfect student do?

The exercise helped to gather a much clearer and strategic view of what success looks like; it also helped to tighten up ideas around the online syllabus and learning material. Success!

Pick one end-to-end journey, commit to it

Our requirements were dominated with features but there wasn’t a clear narrative around these features. There were some lovely ideas in there, but a set of features without understanding the impact on the user, is, well, just a list of features!

We prioritised one user group and we defined the user stories that this user group would need to do to get from start to finish of their core journey.

The way to work this out for your team: if we didn’t build this journey by x deadline, will we have a functional product?

All of a sudden, had a primary user group, one user journey and a set of stories to complete this journey. We could then do a gap analysis of any missing components or features from our original list. This created a huge amount of focus and created a clear narrative over what we were doing.

Evidence-led requirements

As a product owner, I saw every feature as a chunk of investment but I didn’t necessarily agree with every feature that turned up in our requirements list at the start. I naturally questioned everything.

I was sensitive to build a little rapport and trust before asking the bigger questions, but at the start I made sure to ask:

What evidence and research informed this requirements list?

This really helped to open up the mindset of everyone involved — how do we know we actually need this feature? How do we know it’s worth the investment?

Investment vs Impact

I’m not sure I utilise textbook product owner methods but I definitely always come back to investment vs impact.

Here’s what goes through my mind when looking at a list of features:

• roughly size up the work in no. of days/weeks
• roughly size up the no. of people it will need to make it happen
• work out if this feature is essential for our primary user group to complete their journey
• if post-launch, I’ll consider if this feature will make the experience worth coming back for

What now?

With an imminent launch of the platform in Q1 of 2021, there’s a quiet feeling of excitement to get actual students using the product so we can learn and improve.

The product launch is just a comma in the sentence of this product’s story, there are SO many ideas we’re excited to explore. With clear prioritisation and focus, we’ll eventually get there.