AMA: GitLab VP, Product, Mike Flouton on Product Roadmap Planning

This is a great question. I've been using some variant of cost-adjusted impact scoring to prioritize roadmaps for over 20 years now. Every market, buyer, product and strategic context is different, so there's no one size fits all methodology. RICE is an example of one popular approach, but I prefer something more tailored for the specific situation. Essentially, as an organization we will pick 3-5 outcome measures according to the needs of the business. Examples might be new business growth, churn mitigation, internal efficiency, COGS reduction, etc. The key is to focus on business outcomes here - the what, not the how. So while "system usability" is a great how metric, I'd pick something like churn mitigation or new business impact instead, since system usability would impact either. Next pick your cost measure. It could be FTE weeks. story points, R&D spend, whatever. Put all of your scores into a matrix and trade off the benefits and the cost. You can weight your impacts differently if some are more important than others. That will net out a cost adjusted impact score, and give you an apples to apples view of priorities. A few caveats. This approach is a tool, not a panacea. A good product manager is already doing this work in their head whether they realize it or not, so this is as much an opportunity to "show your work" as anything else. You should go blindly picking up whichever has scored the highest. But it will give you a starting point and help you build transparency and trust with stakeholders.

As a general rule, everyone should have input into the product roadmap. In fact, at GitLab our mission is to make it so that everyone can contribute and we apply the same principle here. A good product manager knows that listening to an idea, asking questions, and truly trying to understand it is in no way a commitment to implement it. So they don't shy away from this dialog, and in fact embrace it. Now, when it comes to doing the prioritization, we need to be market driven and not stakeholder driven. Stakeholders are great for bringing you market insights. As much as we should strive to talk to customers, partners, analysts and prospects every day, there's only so many hours. Stakeholders can round out our understanding of what the market is telling us. It's easy when we all agree on a path forward. In practice, we will have disagreements. This is where it's critical to be transparent and explain why you're making the decisions you are. Having a transparent scoring criteria (see my answer to another question) is hugely helpful here. If your stakeholders can't show with market data why a decision you're making might be incorrect, they need to disagree and commit. If you're in a company where the PM isn't empowered to push back on stakeholders (with data), it might be time to look for another job.

I've always said a good PM and PMM should be joined at the hip. The PMM should be bringing market insights to the table and act as an excellent sounding board for their PM. That should be throughout the lifecycle. Far too often what happens is the PM builds something, throws it over the fence at a PMM, and then the PMM is stuck trying to reverse engineer the "why" behind why it was built. That leads to failed products and poor launches. Engage your PMM counterparts early and often.

I know it's a cliche, but as PM you are CEO of the product. You shouldn't need guidance from the e-group. Their perspective can be useful, and they will bring knowledge and insights that can help you get to the right market driven insights. But you shouldn't outsource your job to them by relying on their guidance. If you're at a company with a new e-group that doesn't want to provide input into the roadmap, consider yourself lucky! This is your time to shine and show yourself as the market and customer expert as they come up to speed. They will contribute soon enough.

This question is impossible to answer in the abstract. It depends entirely on where you are in the technology adoption lifecycle. If you haven't read "Crossing the Chasm" and "Inside the Tornado," go get them immediately and work your way through them. They are relatively short reads and timeless classics you will want to re-read throughout your career. As you will learn, at some points in the lifecycle you might focus 90% on new customers, at others 90% on your existing base (and no, it's not as simple as early=new, late=existing). The real trick is understanding the strategic context of where your product sits in the market at any given time.

I might have given you a very different answer to this question a year ago! I used to be paranoid about hiding my roadmap from my competitors, and would share broadly internally and with customers to maximize feedback, yet lock it down for everyone else. GitLab is the most transparent company I've ever worked for, and for the most part our roadmap is on our public website available to anyone. I can't tell you how liberating it is to be talking to a customer who has an obscure question about an area of the product I don't know and to say "I don't know, let's find out" and proceed to pull up a public roadmap page in an unauthenticated session with them in real time. So I guess I would err on the side of transparency these days, with obvious exceptions for the things that truly do need to remain confidential. I guess you CAN teach an old dog new tricks.