Roadmap Planning: Users First, Features Second
We’ve been putting together our product roadmap for the next release recently, and I wanted to share a step-by-step thought process that helps me think through what makes it into the roadmap.
TLDR: Start with the user you want to target, figure out what they want to do with your product, and then decide what features will enable them to do so. Flipping this order around and starting with features makes it harder to think holistically about the entire experience users have with your product.
Step 1: Start with the User
Ok, I know this seems obvious, but because it is so obvious, it is sometimes implicitly, rather than explicitly addressed when developing the roadmap. The reason why it is important to reconsider who the user is every time you revise the roadmap is because the target user persona is always subject to change. Roadmap planning is usually scheduled on a consistent basis, so it is a good time to revisit how well you understand your user.
Particularly at startups, target user personas change over time for several reasons: 1) the assumptions on which the original user persona was based upon were wrong, 2) new data gathered over time provides new information about the user persona, 3) the product has matured and now attracts a different type of user persona, 4) the user has changed due to some market shift, industry change, or competitive shift, thus changing how he/she makes buying decisions, 5) the business itself has decided to focus on a different user. Reasons 4 and 5 apply to larger companies as well, whereas 1–3 are less likely to change with a large, established company with a mature product. As product managers, we need to be constantly calibrating and re-validating who we believe to be our users.
For this first step, I keep this user definition high level. How would this user introduce themselves at a networking event, or at the beginning of a talk? What would be on their business card?
Step 2: Wrap in business goals and segment, segment, segment again!
Having a job title isn’t enough to help with driving feature prioritization decisions though, so it’s time to whittle down the user definition. This is the point where I usually start thinking about the business goals that I’m supposed to make an impact on. Am I trying to drive adoption? If so, what kind of users have been adopting us, are they still the type of users we want, and what characteristics define them?
At the end of this step, I try to get to a point where I can empathize with how the user I want to focus on makes decisions. What drives them to do what they do, and how is that different from the users in segments that I omitted? What are their goals? What are their concerns?
Step 3: List out the major steps in your target user’s experience, from start to finish
In this step, I map out the major steps a user takes with our product from start to finish. This helps me identify gaps in the user journey reactively vs proactively (when a customer complains about it). Although I may not address most of these issues in the roadmap going forward, it’s good to at least have thought about the trade-offs I had to make and question whether or not those trade-offs made sense.
Step 4: Underneath, write down what you expect the user to do during each of these major steps
This is where defining the user actually begins to impact what you decide to build. In this step, I typically write underneath each major experience what I expect a user to do, and why they are doing it. This gets you to thinking at a high level about epic user stories that can be turned into flows.
Now that I’ve mapped out what type of user I want to target, the journey that user takes with the product, and the actions the user takes to accomplish those goals, I can move on to Step 5.
Step 5: Identify what areas you want to focus on based on customer feedback and business goals
This is when I typically tie things back to business goals and come up with a portfolio allocation that covers how much time I want to spend on each of the actions I expect a user to want to do. This helps explicitly cut things out that don’t fall under the category of improving the experience of our current target user.
Step 6: Map feature to user flows and prioritize
Only after accomplishing the first 5 steps do I move onto actually thinking about features. I try to make sure that the key user stories that I wanted to cover are adequately covered by the features planned for the next release, and that they are scoped to meet a target user need.
It’s important to note that this process isn’t a hard step-by-step process. Sometimes I start with Step 1, move onto Step 2, realize Step 1 was incomplete, and go back to thinking about Step 1. However, I do in some form or fashion think about all of these discrete steps when considering roadmap prioritization.
Don’t Forget!
- It is very important to leave time to address technical debt and discuss internal feature requests. Engineers working on the product have a clear perspective on what needs to be done, so their opinions should ALWAYS be considered.
- This is just the beginning of the process — typically, I use this thought process to come up with a proposal that I then share with the team as a rough draft. It never makes sense to decide on features in a vacuum, since you never know who else on the team has more insights about a specific topic.
- Roadmaps change! If certain items on the roadmap need to be tested, embrace the uncertainty. If it turns out that the feature is no longer needed, don’t be afraid to choose not to do it. One of the most powerful tools you have is “scope.” Many features are important, but they might not be important now, or they might not need to be as robust as they could be. For features like that, I tend to scope things down dramatically to strongly meet the use case we want to tackle, without putting the nice UX polish we would typically put onto other features that have had a longer period of user feedback.
- Finally, be cognizant of your assumptions. I fall into the trap of making assumptions a lot and am actively trying to observe myself when I make those assumptions, and consider how I would disprove or prove those assumptions going forward. That being said, you’ll never know for sure whether or not a feature will succeed or not before you get started on it, so at some point, you’ll have to make a decision with limited data.
I’m sure as I continue to do this, this process will change over time. Regardless, the first principle of focusing on users never changes!
I would love to hear your thoughts on how you approach roadmap planning. Find me @dianasaur323
