AMA: Chainguard Senior Director of Product Management, Julian Dunn on Product Roadmap & Prioritization

To answer this properly, it's critical to know what your product or product line's goals are. What is the lifecycle phase of the product? Is it in its initial growth ramp, maintenance and retention, or God forbid, being replaced? For example, my current company (a startup) has an overall goal of acquiring new logos across all of its business lines. Thus, the majority of the roadmap is going to be laser-focused on that objective; new product and feature introduction, features to reduce on-boarding friction and create faster time-to-value, and so on. On the other hand, if your product is well-established but you are facing problems with churn or poor customer satisfaction scores, then an objective you might set is to reduce these factors and thus more of your roadmap will consist of items tailored to existing customers.

I try to focus a product team on the most pressing areas that only PM can do. Our job is to create unique leverage for the company, not try to do everyone's job. So for example, while it might be tempting to play junior engineering manager, it's not a good use of time for PMs to project-manage every single engineering story and deliverable (IMO). If I or my team have to flex into a role temporarily to fix a problem, I will make it clear to all stakeholders that it is a temporary fix. An example is: sometimes sales teams don't know how to sell or position the product. That will obviously be a huge impediment to the success of a product, so I will commit to something like "we will sell the product until there are at least 5 opportunities in stage X or greater". But I will ask that the sales team follow along, and when we get to opportunity 4 or 5, I'll ask them to pitch and we watch (switch roles). In my experience, the greatest value product can add is: 1. Prioritizing roadmaps by business value (not just "is it a cool feature" but "is it going to be ROI positive") 2. Longer-range product strategy (size of range depends on stage of company) 3. Debugging anything in the business that is an immediate impediment to making the product successful, and flexing into those jobs to unblock them (but leaving as soon as the people who are supposed to be doing those jobs are doing them better)

My preference is to focus a roadmap on "big digs" or themes of investment. Customers (and your sales team) generally want to see a roadmap not because they care about each individual line item, but to understand your general direction and whether that aligns to their own strategy. The roadmap is a tool for you to tell your story, and the more wiggle room you can buy yourself (i.e. staying away from very granular investments), the easier it is to tell that story. Roadmaps are as much marketing instruments as they are representations of product investment. Now, I recognize I've always had the luxury of working at a Series B or later company, but I am also an investor and I've read enough pre-seed and seed-round pitches to know that this holds true even for earlier stages. The only difference is that at earlier stages, you are likely to pivot your roadmap eight ways till Sunday; if you are pre-revenue, nobody is going to take those roadmap items as commitments. They merely want to understand that you've thought logically about where your company could be in a year.

This is a tough situation, similar to one in which a C-team won't clearly articulate a company's strategy or its short-term objectives. A mistake I've seen some PMs make is to wait for a strategy to be delivered from on high, when it's clear from surrounding circumstances that this is a fool's errand. I prefer to look at this as an opportunity: you are the product leader that knows both the product and its customers, so you should take control of developing a strategy and a roadmap to match it. It's better for you to craft a strawman for both and put them in front of your C-team as a point of discussion, because at least you can get things moving in some direction. At worst: C-team barfs all over your strategy/roadmap, but you've forced them to articulate their viewpoints and you know where they stand. At best: C-team says, you know the product and customers better than we do, so go forth and execute -- and you get what you want.

This depends a lot on whether it is materially causing problems for the business. (There are an awful of legacy products out there with legacy UX, but there few motivations to improve them because cost of market entry is high, for example, and so there are few new competitors) For the purposes of answering this question, I'm going to assume you are the first creative hire because there is a problem, and they want you to fix it. What I would probably not do is to go into meetings and pitch a new "design system" because that sounds a lot like airy-fairy academic noodling. Rather, pick one or two battles that you can win; investments you can make within a quarter or two that will drive material results. I'm suggesting, in other words, for you to flip the script: rather than "how long will it take to implement a new design system" it becomes "what can we do in two quarters?" This doesn't mean you don't have a long range plan or a design system in mind upon which you are basing these investments. But use the near-term goal to keep you honest and grounded, as well as to pressure-test the design system. And the most critical investment here: find some way to measure the impact of design (changes) on the product and to the business goal you are focused on fixing. Good luck!

The best way that I've found to manage this is to fund these out of separate envelopes. Typically I will work with engineering to agree on the base % allocation of resources for the first set of items. Let's say it's 20%. That leaves about 70-75% of capacity for feature work (you need to leave 5-10% on a team for slack/unplanned work like incidents). Great, now you know how many FTE-equivalents you have in a given period to do features. As engineering estimates (they are estimating, right?!) effort for features, you know which of your features are going to end up above the cutline and which ones are not. This split can be different per team (more mature products might have less KTLO/maintenance/optimization work) and it can also vary per planning period (maybe there is a lot of tech debt that absolutely needs to get addressed next cycle so the % has to be higher). It's really just a rule of thumb and a basis upon which to have a discussion about resource allocation with engineering. Having a default allocation gives engineering both autonomy and accountability to use their time wisely. If they waste their 20% time on science projects instead of necessary maintenance activities, it will create negative outcomes eventually (the system goes down) and that waste will therefore become apparent. Even the possibility of this and the knowledge that such outcomes will land on their heads (no more "product didn't 'give us time' to take care of the system" complaints) is often enough to dissuade them from embarking on unnecessary adventures.

I very much prefer not to use quarterly formats for roadmaps; I am a huge fan of the now/next/later roadmap. If pressed, I will say "now" is 0-6 months, "next" is 6-12 months, and "later" is 12+ months. Use whatever durations make sense for your company and stage. Quarterly labels start to make roadmap items seem like commitments. They are not, but it is an unavoidable consequence that people see a date and believe that is a fixed delivery date. I find it generally senseless to do capacity planning more than one or two quarters out. The exception is if you know you have a multi-year big dig, but those should be very limited.

Yeah -- that seems unnecessary for most day-to-day roadmap changes. In my view, lengthy discussion like this should only happen if one or more of the following is true: 1. The items being substituted are significant enough that they will impact revenue, retention, customer satisfaction, etc. for a meaningful proportion of the customer base 2. You have a belief that the decision is a one-way door (can't easily be reversed) Even for such big decisions, I would write the briefest papers possible to explain to the necessary stakeholders why you recommend making the change. We currently use the RAPID framework for making any kind of big decision and that allows you to identify all the signatories up front and capture their feedback. There is one decider, which also forces accountability. At the end of the day, it should be the chief product officer (or, if you don't have one, perhaps the CEO) who arbitrates and decides whether a big change like this should be made. RAPID allows stakeholders to disagree and register their disagreement without completely derailing the decision-making process.