One year ago I made the move from the Scottish Businesses Marketing team and started my new life stepping into the unknown, as a Product Owner in the Export Service Design team. Now, I have one foot in the SDI Trade Service team and the other in Service Design.
Officially, the Product Owner (PO) is “responsible for maximising the value of the product and the work of the development team”. This is a new role for the organisation as Product Owner is essentially a role coined from the agile way to manage a project, usually software development, called Scrum.
I’d always though of myself as a bit of a geek with a passion for web and digital, so I was excited to be able to use my export marketing experience and customer insight to tackle this new challenge and really get up close and personal with our end users.
One year on, I thought I’d share and list the 10 lessons that have stuck with me.
1 Ask questions rather than saying ‘No’
Ideas and feature requests for your product will come from everyone. As a new Product Owner, my first instinct was to say ‘yes’ to everything. While that kept people happy in the short-term, I was soon faced with a massive backlog of stories and no way to deliver them all, with many of them lacking real customer value.
Rather than saying ‘yes’ immediately, responding by asking questions is a useful tool. It helps me understand more about the request. I can dig a bit deeper and learn about why they think something is a good idea. What do they think it will achieve? How do they envisage it working? What are they looking to achieve? You get the idea.
If an idea makes it through this kind of positive challenge, I’ve found that it will actually be useful and valuable for my product. Also, the context and reasoning will help me rank how this new feature compares to existing ones in my backlog and how it should be prioritised.
2 You don’t know what you don’t know
An odd one I know, but while we’re on the subject of questions, as a new Product Owner who’d only really learned about Scrum, Agile, Sprints, Kanban, user stories in theory – there were some questions that I simply didn’t know to ask!
Questions you’ll only know to ask once you’ve launched a product; once you’ve gone through rounds of testing; once you’ve been told your product ‘could be better’; built a roadmap; run a product demo; or delivered multiple Show & Tells. As with any other job, experience next to academic learning is key, and only comes to you with time!
I’m lucky to be part of a small team that have a little more experience than me in the ways of Agile product development, and this has helped me along this journey of experience. They keep me right, but we all recognise we’re on this journey together. We’re developing and / or optimising products and services that are complex in nature. We embrace uncertainty and rely on relationship-building, sense making, learning and adapting and taking notice of emergent directions.
As a result, I feel more confident after having launched a couple of products in my first year and from the many interactions with colleagues across SE and SDI and, of course, speaking to our customers
3 It’s OK to break stuff
Leading on nicely from my previous point, stakeholders have a very useful knack for picking apart my products… in a productive way. Have you thought about this? What if this happens? What are your dependencies? What’s your plan B? A hugely useful process I find (if sometimes frustrating), and it’s turned into a bit of a mantra for me. Break stuff in a safe environment before it goes live to a wider, and more critical and vociferous, audience.
I’m reminded a little bit of my days in Marketing where so much of the activity and campaigns I developed took months in the planning pre-launch (i.e. before a customer even clapped eyes on it), and post-launch you kept everything crossed that your concept, proposition, design and fulfilment all resonated with the target customer and you achieved the desired effect. #fingerscrossed
The goal as Product Owner is to get to a place where you have picked apart your product to such a degree, with the help of your development team, stakeholders and customers, that what’s left fits together, delivers a great customer experience and meets business objectives.
4 Tools & Techniques are there to help
At first I was overwhelmed with the number of tools and techniques available and would question is this the right technique for what I’m trying to do, am I using it right? But in reality, they’re all really practical techniques that really do help. Different approaches to: framing the problem – developing visions statements – user research affinity sorting – impact mapping – user stories – story mapping – roadmaps – backlog prioritisation – personas and much more… The key is using what is right for you at the right time.
5 Communicate, Communicate, Communicate
I didn’t appreciate how much time I would spend talking to people as a Product Owner. Be it refinement or ideas sessions with my team, discussing the nuts and bolts with developers, product demos with individuals, teams, senior management, AND getting to the nub of what stakeholders and customers actually want.
As a Product Owner, I am responsible for my product. I get to make decisions – but I can only make those decisions if I take everyone on a journey with me and everyone understands what the product is about and what it’s meant to achieve. If people don’t understand why I’m making a decision, they likely won’t approve it, use it, or come with me on my product vision journey.
6 So many meetings
A consequence of having so many people to talk to and working in a big organisation like Scottish Enterprise, means that I’m in a lot of meetings and often feel there’s not enough time to actually do any work – this is a tricky one and I don’t think I’ve cracked it yet.
I try and schedule necessary meetings far enough in advance where possible and I also make sure that I have a set amount of time a day blocked to do work. But as Product Owner, I also need to be ‘available’ and sometimes the best discussions; ideas and solutions come from those adhoc meetings. It’s all a balancing act.
7 Paper & Post-its
In this last year as a Product Owner I’ve spent more time sketching and drawing than in my ten years in Marketing. There’s an irony to the simple fact that in order to build a digital product in an Agile way, you’re going to end up using a lot of paper.
8 Every day’s a school day!
I’m continually learning … I was lucky enough to be offered a place on the Department of Work and Pensions (DWP) digital academy Product Owner course a couple of weeks ago in Leeds.
The course helped me understand the digital path in more depth – from building empathy with users in discovery, testing assumptions, to building the working service and pushing into live and beyond. I understood it up to a point before, but now I can explain it with more confidence to other people, which is pretty important when you’re working in an organisation that’s still learning digital.
There was a lot crammed into the course, beautifully illustrated by one of the delegates – you can view these on Twitter: day 1, day 2 and day 3. It made for an intense course, and I’m in no way an expert yet on the techniques we covered like hypothesis testing, impact- and story mapping, but the course helped the ‘penny drop’ even further and provided me with an improved practical grasp of the concepts, which will help me navigate the challenges ahead.
9 Find and use your networks
Following on from the course I mentioned above, DWP are also opening up other support mechanisms, like the Product Owner email group and a buddy/mentor scheme – I’m really looking forward to getting involved in both. This is just one example of the type of network that I’ve discovered is so valuable.
Earlier this year I attended the European Trade Partner Organisations’ (ETPO) Spring conference in Berlin and met representatives from agencies across Europe who are driving innovation in service delivery. It definitely pays off to look further afield than Scotland and the UK to get a feel for how other agencies are tackling similar issues and challenges for their customers from different cultures. Some of these individuals are now not only LinkedIn connections but have become friends, and of course Facebook pals J
I must’ve done something right, as I’ve been invited back to the ETPO Autumn conference at end of September in Stockholm, Sweden. This time, I’ll be demonstrating the latest developments in digital Export service design on behalf of Scottish Enterprise, so watch this space for an update and please – wish me luck!
10 Team spirit and collaboration is critical for Agile delivery
And this lesson, I cannot stress enough. T-E-A-M (Together-Everyone-Achieves-More), cheesy, but true!
Teams are, of course, as old as civilisation, even Jesus had 12 co-workers – teams provide insight, creativity and knowledge in a way that a person working independently cannot, and just once in a while the possibility exists that we will generate magic and produce something extraordinary. And this is how I feel about my team. We trust and respect each other – learn from each other – pick each other up and we have each other’s backs. We’re cross-functional, diverse in experience, but all driving in the same direction. I really couldn’t do my job without them.
… Oh, did I say I was going to talk about the 10 lessons I’ve learned? Sorry I lied! Here’s another …
11 Show & Tells are a great platform to meet new people
If you want to learn more about our developments to date, you can find a recent list of our Show & Tell update summaries here.
Or alternatively, come and see for yourself.
Service Design show & tells
Our Show & Tells take place in the Paisley office, on the first Friday of each month and are open to all. We welcome not only colleagues from SE, but also stakeholders from other public sector agencies and technology providers. Each new attendee asks different questions, provides a fresh outlook and builds, new, lasting connections.
No RSVP necessary.
For more information please contact me on firstname.lastname@example.org