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.

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.

In the first 30 days get to know the user you are building for, the problems that they have and how your product or feature solves that. Get to know your team and how they deliver solutions for that problem and what is getting in their way. Ask a lot of questions and take a lot of notes. Use the next 30 days to get to know your product, you should be able to demo it and do so often. Help out by testing any new functionality, write bugs when you find them and keep asking questions. Get in front of customers when you can to demo or just to listen, what are they saying they like and do not like about the product? Now you can get in and improve or write new requests. Start small, make sure it solves a real customer problem and that you know how to measure the impact.

There is a lot to learn from your new team when starting and it can be tempting to jump right into what they can help you build first or what their problems are and you will get to that soon enough. Before that I like to start building processes and systems so all of those groups can self-serve information as much as possible without you becoming a blocker to them doing their jobs. So asking what kind of information they need/expect/want from Product Management and how they want to get that information. Making this self-serve also lets you create a single source of the information so everyone is getting the same answer all the time and you only have one thing to update when it changes. When I am meeting folks for the first time I like to establish what they have been working on and why, what problems they are having they need help with even if I cannot solve them. I also like to ask them who their go to person is when they need questions answered or something done. I have found that this answer is often the same and you find out a natural source of information within the company, a key stakeholder who may not be obvious or someone who just knows how to get things done.

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.

When thinking about the user input when prioritizing (amongst many inputs) there are some questions to answer. Here are some, but not all, of the ones I think about when new requests come my way. * What is your customer (the person or group using the platform) trying to do or solve for and why? * How is that thing your customer is building solving the end user need? * How does that contribute to the overall goals for the company? With these in hand for all the requests coming your way you an prioritize amongst those for what really will impact not just your internal users but the end customers and drive business results. You may even find that there are efficiencies and improvements you can drive for the end users that your customers have not surfaced to you.