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:
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.
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.
