AMA: GitLab Principal Product Manager, James Heimbuck on Product Management 30/60/90 Day Plan

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.

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.

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.

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.

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.