The Curious Case of a Designer as Product Owner

Meri Raelahti

Meri Raelahti

Lead Designer

Throughout my design career I’ve worn many hats from marketing to strategy to product and interaction design. But during the last four months I’ve been wearing a hat that used to be a rather unfamiliar one to me or to any designer. In addition of being the lead product designer, I’ve been acting as a product owner (PO) of a yet to be launched digital service. And to my surprise it’s a role that can fit a designer rather well.

But how can one identify the kind of designer to try a PO role out with? Look for someone with experience in the following areas and you’re set to go.

Defining and keeping focus on the vision

The Scrum product owner is typically one of the project’s key stakeholders who owns the vision for the product including understanding of the target groups, marketplace, competition and the trends that apply. These skills also happen to be ones that product designers should either possess or obtain as new technology is continuously shifting people’s expectations toward digital experiences. To be able to lead creation of viable products and be able to empathise with the audience is not enough, but one has to be on top of the business side of things too.

In product owner role designers also get to put their facilitation and planning skills to use. Creating a product requires constant communication with stakeholders and the team on how work is progressing, keeping an eye on the roadmap and on building a product that is true to the defined goal. The PO also often acts as the key advocate for the product itself, and as the lead designer, for me it has been easy to stand behind a product I’ve been part of designing.

Leading creation of viable products and empathising with the audience is not enough, but one has to be on top of the business side of things too.

Evaluating product progress and managing backlog

When designer knows the key motivation as to why a product is being designed, handling also the daily operations like defining features and sorting a product backlog run smoothly. Though Jira is still far from the list of my favourite tools, I have to admit it does have its perks in understanding and managing the big picture as well as each sprint.

Based on this, I argue that it’s wise use of budget to have a designer lead the prioritisation of the product backlog instead of having a manager layer in between the team and stakeholders simply to facilitate prioritisation. Especially now that MVP seems to be more of an industry standard than exception, it’s vital that the team isn’t building just any bunch of random features. As designer has the understanding of the vision, they’re also able to sort out logical sets of features that together form a potentially shippable product that has clear end-user and business value.

Prioritising customer and business needs

One might think that this is the part that came the easiest to me, but here I’d say the learning curve is the steepest. I had to learn what is failover, functional and smoke testing, how much time each type of testing takes, map out dependencies in the system that I didn’t immediately understand, while I was also studying the vast business portfolio of services. In my case, we’re dealing with a product that has a monster of an architecture behind it.

Juggling scope, time and stakeholders, while trying to grasp the effort development takes, and breaking too big features into smaller parts, is when running the process got to me. And sometimes my inner designer was sad due to the constraints my inner PO had to give to myself in the project.

But still being a PO has enabled me to be more present in the development process than ever before. And after a few rehearsal rounds I was able to make more educated decisions for the product based on business and customer needs and available time while protecting a good work life balance for the team.

Being a PO has enabled me to be more present in the development process than ever before.

I like to think what I lacked in experience I replaced with curiosity and the continuous hunger to learn from and empathise with the work of others. And being in team with developers is just oh so fun! Maybe it’s because I used to develop, and I was a math geek at school, but there’s just something very intriguing about the world of code logic with developers who are like wizards that bring design magic to life.

Designer as PO — yes or no?

While we may more traditionally see various managers acting as POs, I’ve yet to find a manual that defines a career or educational background of a fitting product owner, as the role consists of various responsibilities any suitable person can take on and deliver. And while I wont argue that every designer should become a PO or every company should hire designers to act as one, I’m arguing that taking a chance on one can more effectively break down organisational silos and increase the quality and go-to-market time of new products developed using agile methods. Hence I’m predicting a rise of a new kind of PO — the designer.

Nordkapp is an advanced design studio. We wear many hats and together with our customers work to transform organizations into more digital- and customer-centric states of mind.

What kind of transformation are you looking forward to making — cultural, strategic, product or numbers? Ari Heinonen is happy to discuss how to get there and how we can help. Reach Ari at ari@nordkapp.fi or +358 50 386 6348.

And if you’re in Benelux, get in touch with Matti Mölsä at matti@nordkapp.fi or +358 40 727 3094.


The Curious case of a Designer as Product Owner was originally published in Future is Present Tense on Medium, where people are continuing the conversation by highlighting and responding to this story.