---
title: Working Together to Prioritize Your Product
teaser: 'How design, engineering, and product management work together to prioritize
  your product.

  '
tags: teams,communication,product
author: Miles Johnson
published_on: 2020-04-23
---

When setting out to build a new or extend an existing product prioritizing 
the right features is key. Each aspect of the team, design, engineering, 
and product have internal expectations of what features are most 
important ranging from:

> What brings the best user experience?

to

> There is pressure from management to deliver X

Designers and engineers are builders by nature. That means satisfaction does
 not come from using what they have built, but rather it comes from providing
 something pleasant that can help other individuals solve problems. For product
 owners there is a dual responsibility to the business and to their users. 
Not to be forgotten are the users, who just need a product to solve their given 
problem.  

So how do we keep these internal motivations in check and focus on delivering 
the right product? Well, unsurprisingly we have some ideas.

## Creating a shared understanding

Step one in the prioritization process is to create a shared understanding 
of what the problem is and what success will look like. With the problem 
identified and a vision of success in mind it makes it easier to know 
when a given feature should be at the top of our list or when it should 
live somewhere in a future discussion.

> Note: Have a backlog to keep track of features - even the far fetched.
 You never know when circumstances might change and a feature will go 
from interesting to essential.

One great approach that we use here at thoughtbot to prioritize features
 are workshops. Workshops typically take place after some initial upfront
 research, such as user interviews to gain a better understanding of the 
challenge at hand. Workshops help level the playing field across the team 
and give everyone on the team a voice.  This is also an opportunity for 
teammates to shed titles and work as a cohesive unit. This is an important 
aspect in ensuring that the team gets all the perspective ideas out of 
their heads and it avoids the traditional hierarchical decision-making 
that can limit ideation and leave teammate feeling undervalued - much like:

![Illustration of a designer, product owner, and a developer running away 
from each other](https://images.thoughtbot.com/blog-vellum-image-uploads/PhECa9TuSgGVeNELTenC_prioritizing-00.png)

## Interrogating Features

> Is this technically feasible?

> What do you think about an experience like…?

&

> Is this really important to the business?

These are all great ways to interrogate a given feature idea. Through
 a continued shared understanding of the business needs and goals the
 team can begin to understand and ideate on the needs of users. In 
this environment the responsibilities, user experience, technical 
implementation, and the business are shared across the team. Whenever 
a feature/idea comes up that proves difficult or complicated to define,
 we split it into two (or more) smaller features that we can then take 
forward to protype, test, and validate. Sometimes all of the sub-features 
are essential and sometimes one will do. Additionally some features may 
be based on assumptions that require further research. 

![Illustration of a designer, product owner, and developer high fiving](https://images.thoughtbot.com/blog-vellum-image-uploads/Slp9tvbHRGqfmLY8g06O_prioritizing-01.png)

## Prioritization in Practice

Once we have a list of features in priority order we can begin the build 
phase. What gave us success in the prioritization process was a shared 
understanding of our goals and limitations. Just because we are now in 
the build phase does not mean that we abandon our flat structure and 
communication. 

We like to use three main processes to manage our priorities during the 
build phase, first are daily standups. These are basically status updates, 
but more importantly these meetings allow issues to be raised quickly so 
we can amend our priorities accordingly. The second process is weekly 
retrospectives - these meetings consist of status updates divorced from 
the product and instead focus on the process that we are undertaking. 
Comments like:

> I think we could do a better job at code review - and here’s a thought how

or

> I am having trouble knowing where to leave feedback

are essential to refining the team’s working process throughout the 
engagement. Finally there is the aptly named planning meeting. These 
meetings are similar to that first workshop mentioned earlier. Basically, 
we get in a room and review our listed priorities and confirm that we are 
happy with the order and if not we rearrange them as a team. Further, 
we can also use this meeting to set up our next sprint by selecting the 
work that is to be completed by the sprint-period (typically a week for us). 

It's helpful to look at each of these meetings as opportunities to pivot 
our priorities. In the standup we are able to pivot quickly to fulfil the 
product-focused needs of today. In the retrospective we are there to pivot 
the team-focused needs of the week and in the planning meeting we are 
considering the longer term impact of our approach. With all of these 
build phase rituals in place the team can be certain that every day will 
take them closer to achieving their goal.  

## Further Considerations - Team Make-up

It is worth considering that product owners come from a variety of 
backgrounds. Each potential background can lead to differences in 
prioritization. In these cases it is important that the team continue 
to stay balanced weighing business, design, and engineering equally. 
Some types of product leads that you might be or that you might run into are:

### The technical product lead

These leads are awesome because they have a deep understanding of 
the technical system we are trying to build. Oftentimes this can be 
the CTO of a business and/or a former developer. With these leads 
it is important for the build team to help close the gap between 
the technical implementation and user needs. The smaller the gap 
between the two, the more likely that the entire team can become 
deep user advocates.

### The non-technical product lead

In this case the technical side of the team (designers and engineers) 
need to play an educational role, while gleaning as much product 
knowledge as possible. Non-technical leads often have an understanding 
of users that can’t be taken for granted. Because of that it may 
be worth the designer over-balancing towards the developer to ensure 
that the technical reasoning for prioritizing features is equally
 well respected.

### The design product lead

As you can imagine this is the inverse of the technical product lead. 
Having a deep understanding of UX is a big bonus, so in this case it's 
up to the engineer to deliver a palatable technical picture as to what 
the potential obstacles are to the potential features. The designer 
again, can take a more facilitative rather than creative approach and 
work with the product owner to shape their ideas.

## In Conclusion

When faced with the prospect of building a new or extending a current
 digital product it is natural to feel tension across business needs,
 technical needs, and user/design needs. The pressure from management
 can be overwhelming and when we humans are overwhelmed we tend to 
dive in the water before taking a look at what's down there. When you
 are next in this position on the build team or as the product owner 
it's important to take some time to get the team’s goals in line. 
While the sight of a 5 hour workshop might appear to be delaying your 
build phase, think twice and embrace the experience. It is much like 
packing for a long holiday. Yes, you can fly across the world and buy 
new clothing and find accommodation in your destination, but it is 
always more rewarding when you research and plan so that you can stay 
in that one hotel that’s across the street from the best local cuisine
 or next door to a magical book shop. 

Finally, remember that team roles are blurry. Team members have diverse
 backgrounds and experiences and the more open and equal the environment, 
the clearer the communication. With a healthy communication structure 
and a shared set of goals prioritizing your new or existing product 
should be as easy as pie.

![Illustration of a designer, product owner and developer running towards a pie](https://images.thoughtbot.com/blog-vellum-image-uploads/wUowwngmRcCbuoyNjweb_prioritizing-02.png)