- Startup Lesson 23: How Product Roadmap Prioritization taught me to be Patient
1 hour ago·3 min read
I’m a highly impatient person. I love to move fast, but that can come at the price of introducing significant stress to myself and others. This is the singular trait that I persistently work on at a personal level and is tied to colloquial phrases I silently say to myself, such as “One day at a time” and “Follow the process.”
As Leverage continues to scale and the team grows, we’ve begun implementing must-have workflows that unlock and unblock team members. Along this journey, our framework for prioritizing our product roadmap has also helped me on a personal level addressing the negative impacts of this trait.
While you may not care about my personal growth, the product roadmap prioritization workflow we use may help your team or company.
NOTE: Product Roadmap Prioritization isn’t a novel concept, but below is a quick read on the process of how we implement it.
The very first question we ask is, explicitly or implicitly — will it bring joy to the users? How we determine this is a blend of direct user feedback and empathy-based intuition.
This is actually pretty easy by asking three simple questions like:
- Did the users ask for this product feature?
Is this workflow broken or prevents the user from experiencing a workflow?
Do we think the product feature will reduce workflow friction for users?
If the answer is YES to any of the above, it makes it on the product roadmap board (yes, we use Trello).
The next question is time-bounded and places criticality as it relates to other product features. By creating a guide based on when the users would either expect to, need to, or should interact with this product change, we’re able to create a priority list that ranges from P0 (omg, right now!) to P3 (nice to have).
Now let’s not fool ourselves, there’s a consideration of when and how much customers are paying for a product feature. In good startup practice, this usually supersedes all other considerations and is aligned with the above.
We use t-shirt sizing (XS, S, M, L, XL) to answer this question, but I’ve also used stone-sizing as well (pebble, rock, boulder, mountain). Regardless of the format, this helps align the available team resources since the sizing is directly correlated to the team’s skillsets.
This secondary question can oftentimes be the trickiest to answer as it challenges the natural habit of fixing things that aren’t broken, commonly referred to as technical debt.
We approach this question as a collective on whether this would result in reducing the t-shirt size of multiple cards today, not in the future. If the answer is no, then we live with the ugly baby that’s still making money and doesn’t need to be touched.
- Date of publication:
- Fri, 04/02/2021 - 08:10
Click on the link - it will be copied to clipboard