James Heimbuck

When I search the internet for "Product management prioritization frameworks" I get back 3.2M results so the options are nearly limitless of what to choose. MoSCoW, RICE, Value vs. Effort, Kano, etc. find a method that makes sense to you and the data is mostly available to apply to the framework. Now comes the hard part, sharing that list. Start with some friendly faces, share the context of what you knew for sure, what you had a good idea about and what you totally made up to find out where you were wrong. From there you can start to expand the audience to share not only what the priority is but why it is what it is. This turns a list of features you want a team to work on to a list of outcomes they will commit to deliver together because they had input into the priority and know why they are doing the work. Now you can iterate on what worked for data gathering, synthesizing and presenting that data for the version because telling people in and outside of the company what you are working on and why is a daily todo for Product Managers.

For an organization at this stage a product manager was probably brought in to help manage the vision, ensure the variety of customer requests and ideas are being reviewed and prioritized and the development teams are working on the right things. To do that there are a couple of key things you need to get to know quick: 1. Who is your target user and what are the pain points your product solves? 2. Who are the key players in your company who will help you get things done? This goes beyond engineers, think about how the product is delivered and supported as well, your job does not stop when the features ship. 3. What data do you have about product usage? 4. What is the team working to deliver now and over the next quarter and why? With this in hand you can ensure you get alignment on the vision with the founders/executive team who have probably been doing that to date. That vision should match up or answer the "why" question for what the team is working on, if it does not they may be misaligned and you can cut things from the upcoming plan. Any usage data can help triangulate with the go to market and support teams what they are hearing from customers about what is valuable and what is not working in the product today. Now you can set the vision for the next quarter's work that moves the product towards the vision.

The exact metrics you collect and want to move can vary based on your circumstances. For some teams it may useful to count how many transactions are flowing through platform, for some latency in responses to the platform, for others actual money flowing through. No matter what your platform does the hardest parts of tracking KPIs are: 1. Understanding how your work connects to the larger company goals and how the business makes money. 2. Finding a metric that is leading not lagging. If the metric starts to move in the wrong direction it means you will miss your goals but you have time to correct. So take the time needed to understand how the platform connects to larger goals and think about what is a leading metric. Do not worry if it's not quite right the first, second or even fifth time. By continually reviewing and questioning the data you will continue to learn and find the right thing.

It can be tempting when joining a new organization to find something small to ship but you should remember that shipping does not mean a "win", you want to drive a successful outcome. So instead of focusing on finding something to ship, focus on finding a way to improve an outcome. That might be making it easier for the sales team to know what just shipped, giving the support team visibility into the bugs that are being worked on by the team or some other process improvement that makes life better for your customers or your team.

Great question! It's easy to fall into "i'm sure a user would want to ABC and then they would XYZ . . " and expand the scope of your first iteration. The process I have found that has the most success is a couple of steps that focus the use cases being delivered to those that move the business goals forward. 1. Match a product outcome to a business outcome * If you have a business goal of increasing revenue product goals should ladder up to that. So new product line, driving user growth by X% or increasing upgrades by X% might be the product goals. 2. Pick a use case that delivers the product outcome. * Going from that product goal, what is a problem to solve or use case to deliver for customers that moves you towards the goal? If you are trying to drive more Daily Active users and find that a specific action is being taken by your power users driving a higher percentage of users to take that action could be a use case to explore. 3. User story map the use case and cut cut cut * Now that you have the use case you can map the customer journey through it asking questions like "what are the ways a customer would get to this step? What do they have to do before this step to get here? What will they need to complete this step?" and and then cutting until there is a minimal path through. There are excellent resources on the web about User Story Mapping that can guide you throughthisprocess. Going through these steps may seem like a lot of work but if you are in the business of building an MVP it is important to be talking about the "why" as often if not more than the "what" and shipping the minimal "what" to get the maximum "why".

Talk to customers, talk to customers and talk to customers!! Any time you have a chance to talk to a customer or a potential customer take it! I find that mixing qualitative discussion and validating with quantitative research that we are not solving a problem for a loud customer or the most recent account review helps ensure you are working on a problem with real reach and that solving it will have real impact for customers. For me the best signal of a customer with a real problem is one who is already trying to solve a problem with a workaround. A common example of this I have run into during my career is in building simple user dashboards for customers in a product. This shows up in many ways during customer conversations. You may get questions about an API to pull data, rate limits on an API, specific questions about how to get usage data, etc. Those are good hints that customers are trying to get data for themselves to present or analyze so there is an opportunity to provide it for them in a dashboard OR if a data interface is not your core competency provide them a richer data feed so they can get at the data they need. When it comes to measuring reach and impact of a problem I like to mix a quantitative and qualitative approach. For reach once I have validated there is a problem I'll try to extrapolate how many other customers might have this issue. Using the dashboard example above we might look at how many users are also hitting those specific endpoints a customer asking about the APIs for. If there is not enough attempted usage here (or enough conversations) then it may not be the most important problem to solve right now. For impact I like to work with customers to answer this by comparing and contrasting problems to understand the urgency of the problem. This might work by asking them to stack rank against other requests they have made or as simple as "are you trying to solve this now and if not what are you trying to solve?" Using these approaches helps me keep the recency of the most recent conversation from influencing what I prioritize next.

Before thinking about the possible solutions/features we could build it is important to make sure that the problem is the right one to be focused on right now. There may be times that the biggest problems are just not solvable right now, or that the known best solution would take more time than customers are willing to wait for any solution even the best one. The best way I have found to balance this need between big long term improvements and small quick wins for the customers with with a RICE score. You can search the internet to get more information and I will not go into a primer here but will call out some traps I have run into when setting up initial RICE scoring and keeping it up to date. * Make sure you consider the timeframe of the scores. For reach consider a set timeframe of 3 to 6 months after implementation what is the possible reach, not total possible reach ever. * For platform teams consider standardizing on the end user reach and avoid the temptation to say "all our users would benefit". If a team with 1M Monthly Active Users is asking for an improvement for a particular user segment that is only 10K then the reach is 10K not 1M. * Tie the impact to your overall goals. If your goal for the year is to speed up the response time of the platform then consider measuring that as the impact. Projects that have a minimal impact or would slow down the platform have lower impact scores. * The hardest part is the estimating effort. Think really hard about the projects and encourage your team to do the same. Compare and Contrast projects and debate if two things that deliver different impact would really take the same amount of time. * Do not be afraid to update scores when you learn more. If you have low confidence about something figure out how you can gain some amount of greater confidence quickly but know that you will never get to 100% and that is ok. With that data in hand you can make an informed decision about which projects get you a fast ROI and move the platform towards your longer term goals.

Hopefully there are some shared goals and a company or product vision to align your work to and if not you may need to write your own vision for the platform. For example if you were working on a platform that was driving a patient care portal with a 5 year vision to connect users to providers that answer questions within 5 minutes you probably would not focus on a request to integrate with fitness scheduling software but instead focus on how do we build the communication tools that will provide those answers from providers. It is also helpful to keep that list of priorities public and with the reasoning (Why are we doing this?) public as well. This gives visibility to other teams asking for something where their request might land if they have an estimate of the impact it will make.

Platform teams can be very data driven if they have instrumented and are gathering good metrics but you have to get out of the office and get some qualitative data too! Go talk to your customer who is often a coworker. Grab time with developers on those teams to talk about what they are working on and why. What can't they do for their customers and think about how the platform can solve or make those problems go away before they get to them. The only thing to watch out for is over indexing on a small number of users. See if the data backs up the problem being described to you or if it has to do with how that team or user is trying to use the platform.

What is shared on the roadmap is all about who the audience is you are talking or preparing it for review and what incentives they have. Some things I have found success with are: * For the executive team the focus should be on a few large items or themes that have clear ties to business outcomes. If the business focus is on new revenue focusing on the high level items that are intended to drive new sales with high level explanation of how (It serves a new buyer persona, it is a new usage based add on, etc. * For a delivery team the roadmap might need a lot more granularity and may need to be a lot shorter in time horizon. The team cares about what they are working on right now with a glimpse of the future. I find it is really important to remind the team of an overall vision, why it is important we are going there and how the most recent work keeps us moving in that direction to keep them motivated and focused on what we are doing. * For fellow product managers you might focus on how your upcoming deliverables are impacting the larger KPIs or how you are building features they might leverage to improve their own KPIs. There are many other stakeholders you could be building a view for at any time. Unfortunately there is not a one size fits all roadmap format for them because their incentives are different and you want to show them what you are working on as it contributes to those incentives.