Skip to content

From Designer to Product Owner: The pleasures and pains of being given control of the product vision

July 19, 2012

As the UX Design discipline has matured in the last few years, business people have started appreciating the value that our design thinking brings. This has created a growing trend of UX Designers taking on more business responsibility and moving in to Product Owner roles.

As a UXer, I see this as a very natural step in the evolution of our profession.  The constant bane of my usability testing life has been UI issues caused by business decisions that are baked in to the value proposition of a product.  Issues created by the design of a page element are easy to fix in comparison.

By taking on the Product Owner role, a UXer is able to move further up the decision making stream and have an input in to these business decisions.  Here they can help shape the product strategy and avoid choices that negatively impact the user experience – rather than having to compensate for them later in design.

My simplified view of a UXer as Product Owner is that they would bring a different focus to the role. Rather than having someone focus on numbers and project management, you would have someone who is passionate about creating great experiences, as well as possessing the skills required to envision and design it.

The flip side of this is that the UXer as a Product Owner would most likely be weaker in the pragmatic business skills required for the role, such as budgeting and planning.  However, with some support from the business these could be easily overcome.

On my latest project I was given this opportunity to take on a Product Owner role, owning and driving the product vision while building a new innovative product.  Not unexpectedly, it wasn’t the entire UX utopian wonderland that I had imagined in my mind.

Here are some of challenges and lessons that I’ve taken away from having to put down my post-it notes and embrace spreadsheets.

What do I mean by a Product Owner

To start, let’s state a quick definition of a the Product Owner role in an Agile team:

Product Owner – The Product Owner represents the voice of the customer and is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.  http://en.wikipedia.org/wiki/Scrum_(development)

On a day-to-day basis this means that Devs are always talking with the Product Owner about the scope and requirements for stories.  Then, once a story has been developed and tested, it is shown to the Product Owner before being deployed.

This means that the Product Owner is essentially the key stakeholder who sets the direction of the team, prioritises what they work on and signs-off what they deliver. This isn’t so much about authority as maintaining accountability to the product vision.

About the project

At this point I can’t actually share details of the product itself, however I can talk about the team and project setup.  We assigned our own internal Product Owner as the client wasn’t able to spend much time with us in person on a day-to-day basis, nor did they have much experience building software. What they did have was a clear vision for the product.  Therefore we needed someone within our small team to act as a Product Owner and be responsible for understanding and representing that vision. It made natural sense to assign a UXer to this role as we would normally include a UXer in to our teams to design and articulate the product experience, which requires an understanding of what the product vision is.

What was different for me as a UXer in this case was that I had to take control of guiding the strategic decisions of the product for myself, rather than just designing the interface and advising someone else.

Embracing the natural tension between a UX Designer & Tech Lead

What became a key dynamic of the project was the pairing of myself and the Tech Lead and the way we learnt to work together.

As a pair, the two of us we were responsible for leading the team and communicating with the clients, but both of us with a different focus – me on the vision/user experience and the Tech Lead on figuring out how to build something that combined a challenging suite of technologies.

On any project there is always a natural tension between Designers who want to build the perfect product that they can see in their mind and the Developers who have to find a way to practically build something out of code.  This disconnect can easily turn it to friction if there isn’t collaboration (see Waterfall).

In a healthy team, where each person understands and appreciates the other’s priorities, embracing this tension fuels an ongoing negotiation and collaboration – which is required to build a great product.  This is the basis for believing in the value of multi-disciplinary teams.

For myself personally in this context, it constantly forced me to think not just about what the ideal end state should be, but also about the smaller pragmatic steps required to get there. And if I didn’t, it would only be a matter of time before the Tech Lead pulled me back down to earth.

This wasn’t all just one-sided negotiation though. By articulating my ideas and the intent behind them we were usually able to find solutions that met both our needs, or just simply agree that a high-value feature was worth the high-cost it took to build.

Living between worlds – no longer a blue sky designer

This ongoing negotiation led to a subtle yet significant shift in my mindset.

As a UXer it’s your job to advocate for the user and get the best result for them.  Of course this needs to be balanced with business needs and technical feasibility. However, as a designer I’ve still always tried to find ways to sneak in little extra bits of functionality – no matter how much Minimum Viable Product Kool-Aid I’ve drunk.

As a Product Owner I was acutely aware the full backlog of scope and how adding in anything extra came at a cost of pushing out other features. The clients had a clear vision of what the product should be (this was arguably their MVP) and this in itself was an ambitious piece of work.

It became a day-to-day priority to think about what is the least amount of work we can to do to get this product out the door. Whilst as a UXer I wanted to build the perfect product, the business needed to launch it sometime this year and the technology layer meant there was a lot of work just to get anything up and running.

At times it felt like I had the Designer devil on one shoulder and the Product Owner angel on the other – one trying to convince me to sneak in extra features whilst the other reminded me of the timelines and scope.

Designers love constraints. As a designer it became an interesting challenge to design for the most pared back version of the product I could figure out.

I stopped thinking about what is the dream state for this product, but instead, more pragmatically, how can we get this built? I became focused on what stories could be stripped out and deprioritised in the backlog, not on what other cool things the product could do.

I became acutely aware of this shift one Friday when I was sharing my work-in-progress with other ThoughtWorks UXers during a design studio session.  Whilst the other designers were having fun exploring ideas in a lively session I was getting frustrated because everything they were coming up with was adding to, rather than removing scope.

One practical tool it did make me think about is that the next time I’m running a collaborative design sketching session, a great way of setting the design challenges we usually state as ‘How Might We…’ would be to ask both:

  • What is the blue-sky version of this feature?
  • What is the minimal version of this feature that will still meets the user need?

Living between worlds – not yet a pragmatist Project Manager

The part of the job that I didn’t choose to sign-up for as the Product Owner was the project management duties – coordinating resourcing, sequencing of events to get to the end goal, managing clients, etc. In a smaller team these duties naturally come with the role, as it’s hard to justify a dedicated Project Manager resource when it’s not a full-time workload.

This was not unexpected, nor a major problem. The challenge came from me not being a skilled or experienced PM by nature, particularly on non-design related activities. With some support and assistance from the team we were able to share the load and teach me new skills where appropriate.

The problem came from the amount of my time and focus it chipped away.  It all meant less time that I was able to spend doing actual design tasks and communicating the vision.

Finding time for design

The biggest challenge I faced was carving off dedicated design time to perform my other part of my role, that of the UX Designer on the team.

Prioritising, analysing and reviewing stories with devs became an all-engrossing task on a daily basis.  It was one of my most important tasks as it’s where I had real ability to shape the small details. In a team with 2-3 dev pairs, there were always stories needing to be analysed, reviewed, or just needing some informal input from the PO.  As someone supporting the team I had to prioritise these. The last thing I wanted to do was become a bottleneck or discourage the devs from seeking my input.

This meant that I rarely found the dedicated time to do traditional UX work, such as prototyping and wireframing.  In an Agile world it’s not very PC to say that I sometimes need to put on my headphones and block out the rest of the team, but sometimes it’s necessary to focus on a design task without distractions for a full afternoon so that you can get your head in the problem space. Tackling complex problems can be compared to going through the cycles required to get into deep REM sleep or just achieve flow.

Sometimes the content in a higher-fidelity wireframe or design mock is the best input for a dev to build from.  They focus on coding the plumbing that makes the page work and not the exact layout and copy on page.  A typical example of this is web-forms. I’m quite particular about the getting the language right on these for the user, whereas devs are usually focused on capturing the right data and storing it appropriately.  Taking the time to wireframe out the flow and wordsmithing the content is a small upfront investment.  It takes the guesswork out of the dev time and avoids revisions or accruing UX design debt – but it takes some dedicated time to create.

This kind of work also helps towards building and evolving a design wall, which creates a shared vision that is visible to everyone.   I always had plenty of ideas in my head, but it’s easy to forget that everyone else in the team hasn’t had a chance to be part of all the conversions and whiteboarding sessions. I was the only one who had full view of the overall picture vision that I have in my head.  Taking this time to capture it, get it out of my head and on to a wall is critical is the only way to effectively communicate it.

Feeding the devs – Designing based on a pull system

Agile UX involves designing just-in-time. This pull-based system is a different way of thinking for most designers.

I had to learn to be disciplined about focusing on the stories that were in the immediate backlog, not thinking about the full picture for the next 6-12 months. As much as I wanted to consider and design a solution that would support the entire feature set that we could ever build, it doesn’t help you use your precious design time to keep feeding the devs who are building the here and now.

The thing that I’ve learnt to do is to design for the stories that are coming in the next one or two months (or 2-3 iterations). Usually there is a common theme to what stories are coming up in that period. There is usually a manageable chunk of features that can be considered as a one design piece, so that you don’t have to revisit the design every story.

At the same time this allows for emergent design, where you are able to build, test and learn. Starting from a simple design and allowing the details to be built and refined as you learn more.  This does mean that sometimes you need to circle back and change the parts of the interface that have already been built (find the time for this is another challenge in itself).

What this does mean is that you willingly take on UX design debt.

Accepting UX design debt

Sometimes you need to take on a little bit of debt to be able to purchase something.

As a Product Owner I had to learn to let go of control of every detail and accept some things that weren’t perfect in my mind. Otherwise we would never have been able to get anything done. Partly this was just about learning to be patient in seeing the product evolve. Partly is was it was about letting the team figure out some of the details for themselves, even if it wasn’t perfect from my designers point of view. It comes back to thinking about UX as a facilitator, not just a designer.

No product is perfect in it’s first version. Great products take time to mature. Even the sacrosanct iPod/iPhone took a couple of versions to truly hit its stride.

It’s all about the journey, not the destination

The biggest take-away for me about the experience is the shift in the focus from the destination to mapping out a path to get there.

As Designers we’re great at envisioning these utopian like product states where everything has clean smooth lines and plenty of white space.  We can mock that up for you in no time.  What we’re not so good at is thinking about the steps involved in creating that vision.

The Product Owner needs to find a way of guiding a team to develop a product from it’s current state, be that a rough idea or working software, to where it needs to go in the future. This requires patience and understanding the challenges that need to overcome along the way, particularly that of making it profitable/sustainable in the mean time or the destination changing.

None of the products that we put on a pedestal now started like that in their first version, whether it be the iPhone, Facebook or automobiles.  They all started as something far simpler and have evolved over every iteration to what we know and love today.

As a Product Owner you have to start thinking more strategically about how you steer the product along the way.  Having a better appreciation that this journey is taking place going to make me a better, more effective designer.

Advertisements
One Comment leave one →
  1. yarnmeister permalink
    November 7, 2014 7:49 am

    Super insightful piece, love your work Ben!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: