AMA: Splunk Sr. Director, Head of AIOps and IT Ops Products, Kara Gillis on Product Roadmap & Prioritization

I typically advocate for using full-time engineering talent on the most innovative features, hardest problems to solve and outsource to third party services for things that I can depend on, not require a ton of updates to, and save me money. Your dedicated engineers are there because they're your most valuable resources - keep them engaged and excited by working on the most fun challenges!

I think you say exactly that! "We're pivoting our product. There are a lot of unknowns. It's hard to plan our roadmap too far out. We're resetting expectations on how much we can communicate..." THEN, I would add this... "We are focusing on these 3 themes in this priority - 1... 2... 3...Our goal is to deliver these X, Y, and Z customer outcomes by pivoting our product. We plan to have an update on these themes in ABC timeframe." It's ok not to have all the answers in times of big change and ambiguity. If you did, you'd probably be guessing at best! And that's the fun - figuring it out.

Prioritization is more art than science. My goal is to actively listen to all stakeholders and help communicate how I make tradeoffs and how that impacts timeline to deliver a requested feature. But as a rule... Customers have the most impact on roadmap. Then engineering (especially on tech debt, architecture, compliance, and quality improvements needed). Then, I weigh any influence from market trends and changing competitive landscapes. Here, I consult with analyst relations, product marketing, and competitive intelligence. Then sales/CSM/support to learn trends/issues they're experiencing directly with customers or issues selling. And sometimes, executive input will trump everything else - but that doesn't happen as often as you'd think unless you work in very top-down work culture. Ultimately, as the product manager, it is your job to make the final call on the roadmap prioritization. It is your primary responsibility!

Executive alignment on your roadmap is pretty key to getting funding and resources to deliver on your roadmap. Your executive team probably cares about customer success, growth, and potentially things like margin/security/compliance. Tie your roadmap to these outcomes very clearly. If you can communicate very clearly HOW your roadmap item helps achieve more than one of these outcomes / benefits, you are more likely to get buy-in. What happens when you disagree with the executive? Well, that depends on whether the exec is challenging your roadmap prioritization to understand where you're coming from as a mechanism for providing feedback OR if the exec is communicating a mandate to accommodate a strategic initiative. There's a difference. For the former, you can make sure to communicate how your roadmap helps achieve those desired outcomes. If the latter, accommodate away.

In a perfect world, you want at least 80% of your roadmap to be applicable to both! But, we don't live in a perfect world, do we? Some startups focus on a small number of customers and really customize the product to the desired features of those early users, but I like to first go broad in appeal, and then deep into a few features that are highly impactful to as many users as possible. If you want to reach a new type of user, solve a new use case, or enter a new market, you will have enough of a reason to build something exclusively for prospects. This is a strategic decision to expand your business or market footprint. A great way to determine if your roadmap is mostly applicable to both prospects and existing customers is to build a way for existing customers to submit ideas for the roadmap, and let your entire customer base upvote their favorite ideas. The more votes, the more likely both existing and new customers will benefit from the roadmap idea. Sometimes, however, you'll have a big customer needing something specific, and there will be many reasons to build something unique, often influenced by the size/revenue impact of the customer. I don't usually let more than 5-10% of the roadmapa focus on one-off, custom features.

I am a huge fan of public roadmaps! But, I think this is depends on: * Organizational cultural preference * Mission of the company / product (are you building a product to help companies provide public roadmaps, for instance?) * What industry you work in * If your product is open source or build products for developers * Whether you serve B2C or B2B - or if your sales motion relies on product led growth While I my career has been almost exclusively B2B focused, I mostly see public roadmaps in B2B software for open source and developer-focused products. Two examples include: * GitHub: https://github.com/github/roadmap * Atlassian: https://www.atlassian.com/roadmap/cloud This makes sense - developers like accessing information without talking to sales, and trying things out for themselves when they become available to determine if they want to use it. Why not make it as simple as possible for your target audience to adopt your new features? Other reasons to have a public roadmap include having a brand that relies on being perceived as transparent, or is directly tied to helping end users access information. If the product builds product roadmaps, for example (like Front Page: https://front.com/blog/why-we-made-our-roadmap-public-and-how-to-build-your-own), it's a great idea to showcase the product in action! However... Highly competitive markets or organizations delivering products for regulated industries may not want to share IP in a public fashion. B2B sales focused companies with direct sales motions rely on highly personalized customer relationships to deliver information, including setting up roadmap conversations. Company culture may operate with more secrecy by choice. A very famous "Fruit Company" relies on the element of surprise for its product announcements and intentionally limits information internally to avoid leaks.

I tailor the product roadmap to the person / group with whom I'm communicating. I often will use Google Slides for a customer or sales facing presentation. With engineering, I'll often use a spreadsheet that lists roadmap initiatives in the order of priority and effort. Communicating with customers: Is this the first time we're speaking? How much time do we have? If it's the first time we're giving a roadmap presentation to the customer, I provide more context upfront to help the customer understand how the roadmap impacts them directly. I will include some slides on the pain points and market trends that I'm solving for, map those pain points to high level overview of the roadmap themes, and then highlight our most applicable major features (and the customer benefits of the feature) in a little more detail, typically one per slide. I also make sure to provide a rrough timeline (3 months, 6 months, 12 months) for any feature I cover. If it's not the first time I've spoken with the customer, I focus on what's changed / newly delivered in the product since the last time we spoke, specific updates to the roadmap that would be applicable to this particular customer, focusing on one major feature area per slide (and including the benefits of the feature!). I will sometimes include success stories of existing customers to demonstrate real world examples. I then welcome questions after major sections of the presentation, for example after each feature or after pain points to make sure we're aligned on the same premise before diving into features. Communicating with non-technical sales: Almost exactly like the customer version, but I spend more time on how the roadmap items impact pricing, packaging, integration with existing products, and updated timelines. I also spend a lot of time on how to communicate the benefits of each major roadmap item in concise and clear language, so it's easier to convey to the customer. Communicating with technical sales: Very similar to non-technical sales, but maybe a little bit more about specific capabilities, scale limits, compliance, or backend updates/updated tech debt that fix internally-known product issues. Technical enablement on new features and roadmap items will also focus on HOW to implement the feature. Communicating with engineering: Usually done as part of planning, it's important for engineers to understand the "why" behind anything they will be decide "how" to implement, and the more context they have about the "why now" reasons behind a feature, and the requirements about "when" - the more likely you'll deliver an accurate roadmap! Engineers care about many things regarding the roadmap, but understanding your priorities and required timelines are paramount to help determine the scope of the work and any dependencies you may have in implementation.

I think it depends on what you mean by "building the roadmap." If you meant "how does product marketing help communicate the roadmap to sales and customers?" - this is a huge benefit to close partnership between product management and product marketing. Product marketing should be involved early and often in the launch of a new product or feature, specifically by learning the problem the roadmap item is intending to solve, understanding the market context and competitor alternatives to your product/feature, and articulating the customer benefit from implementing the product/feature. Product marketing should help product managers more clearly visually and verbally communicate the roadmap in customer facing presentations, blogs, and sales enablement. If you meant "how does product marketing help decide what gets built?" - I think of product marketing as one of the many inputs to consult when prioritizing new features. Often, product marketing is speaking with customers about their use cases to gather their stories for external marketing and sales enablement, so they are learning about customer pain points that product management may not know - or hardships that the sales team is facing when selling or implementing the product for a customer. Other great sources of input are sales reps, sales engineers, customer support/success managers, professional services consultants, etc. Outside of your organization, getting feedback from industry analysts (if you're in enterprise software especially) can also be an interesting source of feedback, based on their following of market trends and volume of conversations they have with end users.