Lessons from TRAC: Articulating a Value Roadmap

Good morning, good afternoon, everyone. Again, my name is Orion Sedam and I believe I’ve met almost all of you. But just to refresh your memory, I’ve been on the Invictus Guild and representing the product discipline for two years now. And in my day job, I’ve been spending the last couple of decades in enterprise B2B software product management and product leadership roles.

And I’m super excited to announce that I’ve also just recently joined an Invictus portfolio company, Novi Labs, to lead their product team. And I’m on my fourth week and it’s been a great experience so far. So, glad to be with you today. The purpose of today’s presentation is to share my observations from the TRAC engagements that we conducted throughout Q3 and to share some of the best practices on the structure and design of effective product roadmaps for future sessions. And I’ve organized today’s presentation along these topics.

Number one, just sort of a refresher, a reminder on what TRAC is. Number two, I will describe basically some of the key takeaways, some of the things that worked, maybe some of the things where there are some areas for improvement. And then I’ll kind of step back and get into this third section around sort of effective product technology roadmaps, kind of what do they look like, what purpose do they serve? And then finally, getting into some best practices for your next TRAC roadmap presentation so you can really nail it.

But before we get into that first topic, I do want to make a comment about the title of this presentation that I’ve chosen, Delivering and Articulating a Value Roadmap. Now, I’ve purposefully made reference to a value roadmap, but in practice, we talk about product roadmaps or technology roadmaps. And at the end of the day, that’s what product leaders produce and that’s what they manage to.

But I’ve chosen this phrasing value roadmap somewhat provocatively to drive the point that our roadmaps have to demonstrate a clear connection to the value that we’re trying to create with our R& D investments. And that can be end user value and that can be enterprise value. And generally, the best investments are going to create both end user value and both enterprise value. So throughout this presentation, I’ll talk about product and technology roadmaps, but the organizing principle for any of our roadmaps has to be rooted in value.

And that applies whether you’re one of the many software product companies in the portfolio or whether you’re one of the services companies that runs on top of a sophisticated proprietary software stack. And we have a few of those in the portfolio too. Because at the end of the day, whether your R& D spend is 20% of your revenue or 35% of your revenue, it’s expected to contribute meaningfully to the generation of enterprise value, which is really no different than our expectations out of our investments in sales and marketing.

So the product leader’s job then is to ensure that the chosen product strategy and its resulting product roadmap are creating value and they have to be able to explain how. And that’s the main topic for today. What I’m not going to be covering in any detail are the nuts and bolts, product planning and the prioritization activities that lead to the formation of that roadmap. If that’s of interest to them, perhaps that’s another session that we can conduct later on this year. All right.

So just to refresh your reminder on what is TRAC. It’s a relatively new initiative that Invictus launched in the second half of last year. And you can certainly be forgiven if you needed a reminder on exactly what that TRAC acronym stands for. But the Technology Roadmap and AI Council, it’s a forum, really, that serves a couple of objectives. Each product leader…

Each product leadership team came in to share their product and technology roadmaps and explaining essentially how it was deploying scarce engineering resources to build a better product and a better business. A second topic in the track forum was around discussions about how the company was leveraging or not AI technologies in particular, either to improve R& D efficiency and effectiveness or, if applicable, discuss how investments in AI capabilities inside your products were going to improve product competitiveness and add value to your end users.

These sessions really comprised about a quarter’s worth of activity. It was basically throughout Q3, we conducted one or more sessions with each company in the portfolio between late June and late September. Everyone participated and will continue to practice in 2026, as I understand it. So we thought it would be a good idea to schedule this briefing to help you get ready for that. So I’ll share some of my general observations. I chose three to focus on.

But before I get into any of that, I just want to express my sincere appreciation for the work that you all put into the preparation of the content and the very candid conversations. JP and I asked a lot of probing questions and maybe questions that you’re not really used to getting from people who you’ve just met over Zoom. But you guys did great and shared a lot of great information, really helped us to understand the business. And I’m the first to admit, we really didn’t provide a whole lot of prescription to you guys on exactly what to prepare.

But that was for a couple of reasons. For one thing, what we didn’t want to do was burden you or saddle you with yet another deliverable that you had to create for this brand new thing just for track. What we were really interested in, actually, was conducting a baseline just to see how companies were thinking about the development of roadmap content, the presentation of roadmap content.

And for us, it was very useful because not only did we get a good understanding of how you guys are handling that, but quite frankly, it gave us a really good detailed understanding of the technologies and the products that you’re building. So very helpful for us. Hopefully, it was helpful for you as well. Now, because the request for roadmap information was pretty open- ended, naturally, we saw a lot of variety in the approaches that you all took.

And I’d like to call out some of the things that were effective and some of the things that were, in some cases, generally missing. So the first one is that it really has to do with effective level setting and specifically level setting on the product line itself. Many of you are product companies selling products. A few of you have proprietary technology stacks that power a larger service offering. But in just about all cases, we on the track team were coming in pretty uninformed about your portfolios and the products.

And so a few teams did very well to step back and first start out with a refresher of the portfolio at large and provide some visibility into the purpose and performance of each product. This was always appreciated. But in other cases, some of the teams skipped right past that step. And that just carries a little bit of risk, right?

Because if you go right into roadmap discussion and you’re presenting that roadmap to your employees, or if you’re a software company presenting a software roadmap to longtime customers, your audience is already going to have a pretty decent understanding of the components of that product line.

But for most every other roadmap presentation context, including presentations with track, where we just don’t have that same kind of intimate understanding of the software, it really is helpful to level set first with a high level overview of the product line of the technology stack or portfolio of your services company. And then from there, we can zoom into specific discussions about specific products, their current performance, the role that they play, and then getting into where you want to take that product with your roadmaps.

So that was the first observation. Again, a level setting action there just to help facilitate those conversations. The next one is.

Sorry, where’s my cursor? There we go. Second observation, you know, across the board, teams attempted to communicate their development roadmaps, and usually those conversations were supported with one or more slides in the form of a horizontal timeline, charts, and roadmap items with feature names that, you know, weren’t necessarily always intuitive or sometimes even acronyms, which, you know, are even harder, really, to kind of understand. But they would be organized sort of by quarter across time, and it makes a lot of sense.

In some cases, roadmaps’ visuals were even organized thematically, where we would see not just time across the horizontal axis, but vertically we might see a listing of, you know, sort of a categorization or organization by different themes. Binary Defense did this, Threat Modeler, Campfire in particular, you know, they’d have themes like automation and governance or frameworks and integrations, AI enablement, data management, modernization.

So these are actually really quite helpful when there are these organizing constructs because it communicates to your audience that there is a larger thought process behind the roadmaps that have been selected and prioritized, and it implies that there’s a larger challenge or there’s a larger opportunity underneath it that warrants multiple projects in service of some common objective or goal over time. And so that’s like really good information.

And, you know, visuals like these really do seem like they should be natural places to start because they’re exactly the kinds of planning artifacts that, you know, teams across your companies need, you know, basically to execute. Your engineers need to know what they’re building in what sequence or what order. If you’re selling software to software buyers, then marketing needs to know what their launch calendar probably looks like.

Your sales and success teams need to understand how the product is evolving over time and how to talk about that with customers and so forth. So again, for internal audiences, these types of visuals are good and necessary actually. But in a track context or board presentation context, and probably most other contexts too, the visuals like these might be helpful, but they’re definitely not sufficient, okay?

Because in general, these kinds of slides with feature names or worse acronyms are fine for internal folks because they already have a decent understanding of the products. They know what the old features were called. They know what the new ones, they’ve probably heard about what some of the new ones are going to be called. And there’s so much institutional knowledge that they have where they can fill in the gaps.

But for most every other situation, timeline slides are pretty ineffective or at least in isolation because they tend to beg more questions than they answer. And it actually has the effect of diverting the more valuable conversation about the forest for the specifics of the trees. So we’ll talk about how to avoid that trap in the next section. But I want to get to the next observation here, which was again, a different kind of level setting issue.

And I would say that actually across the board, the roadmaps that were brought to the track forum kind of failed to explicitly frame how specific R& D investments were meant to drive specific business outcomes that your board cares about. And I’m talking about outcomes like revenue growth, retention improvement, margin expansion, increasing cross- sell, more products per client and so forth. And even the teams that did organize their roadmaps along strategic themes really didn’t show why that theme mattered in the end.

Like what we can expect investments along that theme to really yield. Often there was conversation about end user value, and that’s great. That’s totally appropriate for the track context. And generally for sort of more strategic audiences like your board, they’re looking for more than just an understanding of the end user value. They’re really looking for an understanding of how does this grow the business, right? How does it strengthen the business because of the delivery of that end user value?

So some teams were thinking along in that direction, like we would see some roadmaps where there are presentations where there would be like an investment project that was selected and spotlighted with some articulation around like the problem we’re trying to solve, the opportunity we’re trying to capture, maybe some evidence of the demand for that capability and probably some rough sizing, we know this is a two quarter project or an eight week project or whatever it was.

But the discussion usually stops short of explaining explicitly what does that do for the business and how, much less when. So, generally missing was this content or this connectivity between the specific roadmap investments and business value. And that really gets to the heart of what your board and investors are wanting. I mean, they’re relying on all of us in these leadership positions to make excellent decisions with their capital.

And they can certainly be forgiven for wanting to understand the economic logic of these R& D decisions just as they are interested in the economic logic of sales and marketing investments or G& A investments. So, these product roadmap conversations are less about specific roadmap features and much more about how you’re going to allocate scarce engineering resources to grow or improve certain aspects of the business.

And that’s a conversation that can be handled at a more thematic level with occasional deep dives into select roadmap projects that you’ve prioritized. All right. So, those were the three general observations from the presentations. The first one, again, being a level setting around who’s who in the zoo. What products do we have in this technology stack that power this service company? Or what products do we have in our product portfolio that we then take to market to software buyers?

Second one was around sort of the necessity but not sufficiency of timeline visuals of roadmaps. And this third one, again, around level setting, around company objectives, business goals, and then setting yourselves up to be able to draw a through- line connectivity between those goals and the specific investments that you’ve prioritized. All right. Now, this session is focused on the preparation and delivery of some effective software roadmaps.

But I do want to just round out a few other observations from the 11 or so track sessions that we conducted in Q3. There were several teams who brought forth conversations and description around their product prioritization processes, their product planning processes. They described sort of their often, you know, we heard about sort of agile scrum methodologies being used and sort of like the mechanics around how specific product decisions are made. So, that was good. Nothing there. It was good when it was brought up.

It wasn’t necessarily a problem if it wasn’t brought up, but typically, we would just go ask anyway about kind of what processes you had in place. Track also has an A in it, AI. There’s a focus on AI roadmaps, AI tooling and utilization to improve efficiency and effectiveness of certain operations within the business, often R& D. And, you know, what I would say is that, you know, we heard answers kind of across the spectrum in terms of the adoption of AI in R& D processes.

A few companies are absolutely all in, and they’ve really oriented around a highly AI- centric R& D process. On the other side of the spectrum, we have teams still kind of experimenting, not yet having formalized on one AI tool set, haven’t really formalized on a responsible use AI policy that they’ve published and so forth. And that’s fine. I mean, everyone is kind of at a different phase of their adoption of AI technology. But, you know, that’s probably the last thing I’m going to say in this session around that.

But probably it’s I think there’s a lot more discussion to be had because of this last point where either because we asked or because through the track conversations you asked or suggested that there was a real interest in knowledge sharing and community building across the portfolio, which is great. And we heard a variety of needs, some quite explicit, usually about tech, but not always.

But there was definitely interest in setting up forums to trade ideas in a live setting sometimes to see how other teams are handling certain things, usually around AI practices in the R& D process or identifying unique use cases where AI is being used to solve business problems and so forth. But we also heard interest in QA practices, cybersecurity and so forth. And I know that there was a Guild Summit in, I think it was Q4, I think it was Structured Web, you know, had a focus conversation just around their journey with AI adoption and so forth.

That’s great. I don’t know if there are plans yet to set anything up more sort of like in a community building way for knowledge transfer sharing and so forth. But I just at least wanted to acknowledge that you were heard and for what it’s worth, I think it’s a pretty good idea.

Orion, if you don’t mind me interjecting, just because you’re on this point, I will bring up the two things that we have set up and we’ll have moving forward. Number one, most if not all of you are familiar with Navigator. Navigator is Invictus’s online knowledge sharing and community building platform for creating our connected community. Within that, there are actual forums where all of the technology, product leaders will have access to other group members within their forum. You can ping that forum to request questions, resources, etc.

You can also use that forum to connect with our product and technology guild members who are part of that forum as well. Additionally, we will be setting up, we had them previously, but we will be setting up product quarterly round tables. This is where you can actually jump on with your peers. Mark will help lead us in those, Mark Chamniss. But we’ll help with topics that are really top of mind that you want to get some additional information or how are you focusing on that within your business? How are you thinking about this?

Those are the two areas that we’ve already set up and are in the process of setting up, and then there could be more as well. But just wanted to put that out there that, yes, we did hear you, and we are moving forward with those initiatives.

That’s great, Heather. Great commercial break. Clearly, I need to get more familiar with Navigator. I should have been able to deliver that myself, so thanks for that. I’m going to move on to the third topic here, which is around effective product and technology roadmaps. I want to step back and just revisit what roadmaps really can be about. I define it here, but you’ll go and find lots of other definitions and perspectives on effective roadmaps.

This happens to be the perspective that I bring to the table, but a roadmap I consider to be a living document that first and foremost articulates a business value story. What do I mean by a business value story? When you think about roadmaps, and certainly we saw a lot of roadmaps like this, they can feel like these mechanical readouts of development schedules and engineering deliverables, a tool to manage the factory floor. Yes, roadmaps need to do that.

But roadmaps can also be the vehicle to tell an exciting and inspiring story about your business and how you’re deploying some of your most critical resources in the company to best serve your target markets, your customers, and grow and strengthen your business as a result. As we all know, especially for product companies, there’s a lot of audiences for your roadmap, your board, your employees, your customers and prospects, your technology partners, industry analysts, and so forth.

And, of course, you’re going to want to tune your content and your focus accordingly, depending on who your audience is. But the good news is that for the most part, all these audiences kind of want to hear the same thing. Like, how does your company see the market, the problems to solve, the opportunities to capture, and the choices that you’ve made about the most important paths to pursue and the way that you’re going to go about it. So I’m going to say more about a business value story in the coming slides.

But if you take one thing away from this session, I just really want to encourage you to think about your roadmap presentation as more than just the set of slides, the set of visuals that help your internal teams understand what’s coming when. It’s actually an opportunity to…

I’m going to stop short of saying that it’s a sales tool because I don’t want anyone selling on Roadmap, but it is a it is a tool to communicate a larger story that that will that tell your audience, hopefully your customers and prospects and boards and everyone else, what you think is important, what you’re about, what you’re doing about it. And and, you know, really engendering confidence that the investments that you’re about to explain or at least overview are going to help you achieve those goals. Now, as we know, the Roadmap is a living document.

They are expected to change that typically that happens on a quarterly basis. And of course, there it’s an expectation setting document and what we can expect by when roughly. And, you know, that can that can then also turn into an accountability tool. And it’s a way to keep your internal teams accountable to what we said we were going to do. It’s also a way for customers to keep you accountable for the things you said you were going to do. But this is healthy. OK, this is this is this is healthy management of resources and expectations. All right.

So, you know, I talked about in my general observations, the something that I thought was like really kind of just generally missing from the prepared content. It’s not to say that we didn’t get to some of the answers in the discussion that came up in those tracks forums. But just in terms of the material that was prepared, sent ahead and then used to facilitate discussion. What what can really help with the effectiveness of these conversations is to establish business context.

Now, in order to establish a business value story, you start by articulating your key business objectives for the year. And at best, if you’re connecting to the metrics that matter for your business, you know, an obvious place to start is, you know, if you’ve got a revenue, an AR target, revenue target, billings target, you’ve got a net dollar retention target. These are, you know, good old fashioned metrics that your board definitely cares about. And you as leaders of your businesses and your and your product functions also care about a lot.

It’s a great place to anchor your your roadmap presentation, because ultimately you want to show how the investments that you’re making ladder up. Now, it doesn’t mean that you’re the goals that you choose to establish your business context have to be truly quantitative in nature. They can be more qualitatively stated, especially if there’s a clear connection to some of those metrics that matter.

So some examples, you know, that we might have a 2026 goal to launch a new product, to establish a beachhead in some new market segment, to better enable our land and expand selling motion, to facilitate a new exciting technology partnership that’s right on the horizon. Maybe we’ve got a customer attrition trend in some segment or for some products that we need to reverse. You know, these are all legitimate and, you know, goals that we may have for, you know, within our businesses.

And if there is an expectation that there is going to be contribution from the R& D team to be part of the solution to the problem to solve or the opportunity to capture, then starting out with these quantitative and qualitative company objectives is a great way to frame a larger R& D story that aligns with the segments of this business.

Okay, so once you’ve got your clear understanding of the business goals and the objectives that you have, for which you have a dependency on R& D to achieve, then you can start developing perspectives on the kinds of strategic themes and initiatives that you’re going to be pursuing for the year or for whatever your planning period is. And so what I’m calling an investment theme just simply reflects some aspect of your product strategy.

So, you know, in that product strategy, you’ve identified some critical challenge in the business or some critical challenge with your product or your technology stack, or you’ve identified an opportunity to go capture. And the strategy then is about, you know, describing this overall approach that you’re going to take to cope with whatever obstacles you anticipate in order to achieve your objective. And often it’s going to resolve how you handle the necessary tradeoffs. You can’t do everything.

You actually have to make decisions at the fork in the road, and the strategy is going to help guide you through all of those forks in the road. And ultimately, that strategy is going to include some coherent set of coordinated actions or steps that you’re going to take, not just within the R& D organization, but beyond. None of us believe that if you build it, they will come. You build it, and then you have so many other things that you have to do cross- functionally to get that value out into the market, understood, and then captured. So.

So whether it’s your sales and marketing functions, your customer success, these coordinated steps, they all are a part of some of the strategic investments or these investment themes. But just because this is an R& D roadmap, I’m really just trying to sort of focus on how we frame or organize the R& D or roadmap investments. Now, note that an investment theme is not the same thing as a feature, okay?

An investment theme, you can think of it as like a category of roadmap items, which share in some, they have in common some expected business or customer outcome. And, but the important thing is that like each of these and themes should clearly link to one of the previously stated annual or, you know, just call it annual business objectives. So that way it’s assumed that any of the features that belong within this strategic initiative also contribute to those higher order business objectives. So this is how we start to ladder up.

So here’s some examples. I have a table on the next slide, which I’ll show this better. On the first column here, we’ve got some themes, all right? And these are, these can be investment themes that drive substantial investment throughout the year. And so in this first example, packaging, refresh and trial licensing, but another theme could be around reducing the time to value for your new logos. Another theme could be around improving, increasing your customer stickiness.

Second column is around just basically describing like, hey, what is the challenge that we’re trying to tackle? What’s the opportunity that we’re trying to capture? Then in this third column, we have this notion of, all right, well, what are some of the things that we’re gonna be asking our R& D team to do in service of the theme that we’ve selected? And then critically identifying upfront and making sure that you’re creating measurement structures for certain metrics that can be, you know, a mix of leading metrics and trailing metrics.

So along this theme of just say packaging, refresh and trial licensing, we’re doing that because maybe we had this 2026 annual goal to improve our cross- selling performance. And we think we can do that in a way that puts the power in the customer’s hands. It can be done in a self- service way through some kind of trial experience that we don’t yet have in our products, but we wanna enable in our products.

And we’ve done the work and we’ve identified that there are some epics that really have to be tackled around, you know, a refactor of our authorization engine. And maybe there’s this extension to the licensing scheme that we have to enable time- based, you know, license expiration. And, you know, once customers start doing self- service, you know, trial behavior, we wanna send a signal to the CRM so that the inside sales team can have visibility into that and conduct some outreach or whatever it is. So these are the types of things that you would expect.

They’re, you know, not every feature or investment name can have, well, you know, you only have so much real estate on the slide, so you can’t really, so you have to give them names, try to keep it pretty short, try to keep it intuitive, try to avoid acronyms. But I broke my own rule there by saying CRM, but I think everyone sort of understands what a CRM is. But like, you just wanna give a sort of this mapping between what a theme is and your roadmap investments. And then lastly, on the metrics.

So leading indicators, because what you want is, you know, I’ll just make a point that I’ll make earlier now, which is in our roadmaps, we also wanna be able to report out on investments that we made over the last three months, the last six months. And we wanna be able to report out on the progress of some of these leading indicators that we’d identified up front. Your board is gonna wanna know, they’re not gonna forget basically that, hey, like six months ago, we released this thing, how’s it going?

And you wanna be in a position to be able to provide good quantitative data around that. So identifying that up front, but then also having the tie out to the trailing indicators that, yeah, the trailing metrics that you’re hoping that this investment is meant to influence. And it can be those financial metrics like net dollar retention or gross retention numbers and so forth.

So this is essentially sort of the next layer, down from having identified your annual business goals or business objectives, thinking about these strategic themes, and then from there we can start. Then we can start getting into some of these more classic, you know, sort of horizontal timeline views of what, the sequencing of the investments that we’re gonna make. So, again, staying on this packaging, refresh, trial licensing theme we might have, you know, we might anticipate that this is a four quarter initiative. Hopefully it doesn’t take that long.

But this is how we’ve set expectations and you know a team is gonna work on the refactor of the auth engine first and then do the time based licensing and at least this way, by mid year we can get that going and then in Q3, we’ll get the CRM thing going. So you know, this is a, this is a. By sequencing things in this order, we’re starting to tell a story that says annual objective was to do this on along this theme, which we said was very important.

These are the types of investments that we’re gonna make and we just know that C that when we’re talking about CRM integration version two, we know why we’re doing that and it’s very clear to everyone at this point what the expected outcomes are in that investment. What a really valuable thing to do- and this is not required for every single roadmap item on that prior slide. But pick one investment out of each theme, pick two whatever feels significant and perform a little bit more of a deep dive on really what this is about.

And you know I’ve suggested a few attributes here. This is not meant to be an authoritative template, but what you’re looking for is like, think of it like the baseball card for the one pager for a specific roadmap item, where you are basically describing who it’s for, what kind of costs implications this has, what the next milestones are, the indicators that you’re looking at. You know, any other kind of commentary that you think is important and relevant for your board. So these are the.

It’s useful to have two or three or four of these, you know, if you’ve got three to five themes, you know. Pick an investment out of each of those themes, one or two, be prepared to walk through. Okay, here’s what we’ve chosen to do. Here’s how we’re gonna measure success. That can be quite handy, all right. So that is that’s the. You know there’s so much material out there about effective roadmapping, but I just- and I kind of wanted to keep things simple and keep things like really pretty tightly scoped to the board context, the track context.

So I think, like the big takeaway here is up to this point is the single most effective thing that all of our leadership teams can be doing across this portfolio when it comes to communicating product plans is to really think through the purpose of your roadmap as something more than just a mechanical artifact that directs the traffic inside your company, but it also being the mechanism by which you can tell a broader business story that connects the investments that you’re making with your R& D team to the outcomes that you’re seeking for your business over the course of the year.

Now I’ll finish out with this last section here, just some best practices for your next presentation, and I hope you all nail it, and I’m sure you all will. But it starts by appreciating some realities again. Your board does not have intimate understanding of your products and their features, and they never will, and the roadmap presentation is not the time or the forum to try to educate them. However, your board can immediately grasp with value statements, especially if you connect the dots to the business objectives that we all wanna see realized.

I apologize if I keep hitting that point too hard, but it really is the critical point here. So I, again, I’m stopping short of providing templates or mandating any specific formats or looks and feel. I’m really just kind of more interested in helping you think a little bit more deeply about really the purpose of the document. And I think it is helpful to provide an example outline just to cement some of these points. But in this outline, there’s roughly three sections. There’s the initial context setting or level setting.

Second section is just really around the product strategy. What do we think is important? What are the real strategic initiatives that we’re going to be taking on this year in service of those annual goals? And that third section is the drill down into what are the coordinated steps that we’re going to be taking within R& D. But certainly, it’s relevant to talk about coordinated steps from a parallel or sister organizations like your sales or marketing or customer success to make some of those strategic initiatives turn them into reality.

So on this point about portfolio overview with product profiles, like I said, it really is helpful. And a high- level refresh of your portfolio starts with just describing what’s already in market if you’re a software company or what’s already in production if you’re a service business that’s running on top of a proprietary technology stack. And if you have multiple products serving different markets or buyers, then spend a few minutes profiling each of them. Novi did a really nice job with this. There was a breakout of three products.

And for each of the products, there was just some basic statistics about how long it’s been in market, and what market does that serve, and what’s its TAM, and is that TAM growing or shrinking? Who’s the target user persona? Who’s the buyer persona? What are their high- level value props that the product delivers for each of those personas? Simple statistics on customer count, ARR per product is quite helpful.

And even better is when you can provide a little bit of commentary on your competitive advantage with that product and weaknesses or growth areas. That’s super helpful. When we get to this, I’ve got a statement here about product division. This can be one slide, all right? And it probably should be. If it’s more than one slide, it’s probably not a clear enough vision.

But it’s simply a statement about where you’re headed in the long run, what you believe this market needs, why your company is well served to deliver it, why it’s advantaged to deliver that thing. Again, it just helps to round out the context for why we have made some of the decisions that we’ve made in terms of product strategy and ultimately the projects that we’re going to take on. I’ve covered product strategy quite a bit in the previous section. I do want to make a point about, I want to describe what I mean here by R& D allocation approach.

It’s quite handy to have a viewpoint before any planning cycle. And that can be at an annual level, but more practically, it’s probably something that you revisit on a quarterly basis. It’s quite handy to have a perspective on where you believe you’re going to be or how you believe you’re going to be dividing your R& D spend. I think of it like the allocation strategy in my IRA. I’ve got some percentage on stocks and some percentage in bonds. And maybe I’ve got some other speculative thing or maybe something really conservative like cash.

But in a software R& D context, those slices or those investment buckets might be strategic initiatives and tactical issues that come up, like support tickets and so forth. A third one might be infrastructure or tech debt. Actually, Boost did a really good job with this. They were the, their presentation did exactly this. And they had this notion of four different investment categories called strategic initiatives, cost of doing business, tech debt, and keep the lights on.

And they had this notion of, I don’t remember the percentages, but strategic initiatives. They were going to try to carefully guard at least 40% of their R& D spend on strategic initiatives, 22% on cost of doing business or whatever the numbers were. It’s really handy because then you at least have something else you can point at when you’re in the middle of the firefight and it’s six weeks into the quarter and you realize you’re spending an awful lot on one part of the investment profile that you didn’t expect to.

And you can check yourself and say, do we believe that this was a good investment in the beginning of the quarter? Do we still believe that? Or have circumstances changed so dramatically to justify why all of a sudden we’re spending so much on this new, this, on this bucket?

And at least it, and whatever the answer is, is the answer, but at least it drives the conversation, which I think is a good thing. So you can, and you can always revisit these allocations on a quarter by quarter basis. But I like having that because it should also call attention. If you’ve got this very, very ambitious product strategy and it turns out you can only afford 33% of your R& D capacity just for strategic initiatives, it’s kind of a red flag. You have to resolve that somehow.

So it can be a good sort of like way to sense check some of your decision making. All right. I guess I also just want to make one other point that this discussion throughout this session has been pretty focused on board presentation and track presentation. But this structure really can be adapted pretty easily for customer and market facing roadmap presentations. Now, I think for customer presentations, you probably want to strip out some of the more sensitive material around known weaknesses in your products or concerns around a retention problem.

Obviously, you’re gonna keep sensitive information guarded, but by and large, all of your stakeholders who would be receiving a roadmap are all pretty interested in a lot of the same stuff. So they’re interested in that big picture, the goals of the business, how technology investments are gonna help achieve them and your employees especially. In my experience, small companies usually have these cultures of high transparency, high agency, and usually whatever is presented to the board is pretty safe to present to all of your employees too.

So I think that’s a quite healthy thing, but obviously outside of your company walls, then you apply a judicious pragmatism there. All right, for customers, again, like I said, it’s a different story. You wanna avoid the trap of selling on roadmap, but as I said earlier, there is some salesmanship in a customer roadmap presentation. I mean, it really is your chance and their chance to evaluate if you’re both moving in the same direction, if your viewpoints are closely aligned.

And unless your customer is a really transactional one and they’ve really been agitating for some specific feature or two, the four quarter timeline charts aren’t even the most important thing to them. What they really wanna know is how you think about technology broadly and how you think that technology is gonna make change in their industry and what your role is gonna be in that change. And they may have very different viewpoints than what you have. And then if that’s true, then there may be some work to do in that account.

But by and large, if they were already your customer, there’s probably more alignment there. And so that’s actually where you can really strengthen that alignment instead of arguing about whether feature ABC should be Q4 versus Q3. So if you can keep the conversation a little bit higher level, often you’re gonna find, especially with your buyer personas, that’s really the altitude that you wanna stay in. All right, my very last slide. Thank you for staying with me.

And some of this is just kind of a repetition of some of the things that I’ve been covering up to this point. But again, it’s context setting up front, very important. If you have a multi- product portfolio, if you have a technology stack underneath your service offering that has multiple components, it’s great to provide an overview up front, really kind of explain the role that that product plays within that portfolio, within that broader stack.

And that will help your board, that will help track, that will help people who just aren’t as familiar with your business as you are to keep up and really get maximum value out of the presentation. Investment themes connected to specific business objectives is always great. And it helps you to maintain that higher altitude conversation that your audience actually is more interested in than versus the sort of the specifics of every single project on your timeline slide.

I think a thing that doesn’t happen enough, frankly, in roadmap presentations is when product leaders fail to take the opportunity to, or what doesn’t happen enough is when they take the opportunity to evangelize recent roadmap deliverables. Take credit for it. You’ve done the work and sometimes the message doesn’t get as widely announced as perhaps you thought. And customers appreciate the fact that there is a track record of delivery.

Especially if it’s something that you had forecasted would happen within a certain kind of timeframe and you delivered it in that timeframe. This is the kind of thing that you want to establish that like, yeah, this is our track record. We have a habit of doing this. In a board context, it’s also the opportunity to share some of the early metrics.

I talked about with some of the spotlight investments, being able to identify upfront what those leading indicators would look like, perhaps what your targets were for those specific, and they’re often usage metrics or adoption metrics. Share the numbers, and they’re either below expectation, at expectation, or above expectation. And all three situations are interesting conversations for your board, because then it gets into a healthy conversation around, okay, well, what have we learned?

And what are some things that you might do differently when it comes to either picking the metric, the leading indicator or the target, or perhaps that discussion might reveal that the instrumentation approach in the technology wasn’t sufficient, or any number of things can come out of those conversations, but I think they’re all healthy. Talked about the allocation strategy. When it comes to roadmaps, clearly I’m in favor. I lean more towards high- level roadmaps.

And so I think in terms of boulders, rocks, and pebbles, and pebbles never belong, and pebble tiny projects, they really just never belong on a roadmap. And actually, I ignore the rocks too, unless there’s a specifically tuned roadmap presentation for some customers who really have been quite noisy about a certain capability that they’re expecting, and you’ve committed to, then yeah, put it on the roadmap.

But by and large, you want the conversation to be mostly thematic with some deep dives into a few of the boulders that you’ve selected along those investment themes. And on those spotlight investments, explain the logic. Like, how is the investment going to move which needle? What leading indicators are you measuring on? We’ll be reporting on. What are your expectations? What are your targets?

And then have follow- through with your next presentation, if it’s with the board, or with track, or whoever, about the progress that you made, the things that you’ve learned. I guess this second to last point around delivery confidence levels. I mean, I think we all know this, but it feels like an incomplete conversation if I don’t say it, is that it’s totally acceptable that your confidence in roadmap delivery will decrease as you go further and further out in time.

So it is sort of the danger of a one- year roadmap, especially if you’re in January and you’re already trying to articulate what you think you’re going to be working on in Q4. We all know the world moves fast and changes happen throughout the year, and you try to keep a stable roadmap, but sometimes that just doesn’t happen. So it’s okay to, you know, the way that some of the presentations came across, instead of committing to specific quarters, you know, we saw in now, next, to later, I think that’s fine.

But even if you commit to quarters, it doesn’t hurt to just have the spoken narrative to say things change, things will change after that. You know, we feel pretty confident about mid- year, but after that, after the three and four quarters out, a little harder to be so sure. And then when it comes to setting expectations with your board about some of the effects that you’re trying to create in the business, just make sure that, you know, we don’t fall into this trap of, well, just because we released the software, we get immediate impact.

Okay, there are realities around launch execution and then sales productivity around new things, and then customer adoption of new things. So when it comes to actually.

So trying to make predictions around when you think a metric that matters will be impacted by a specific R& D investment, just make sure to factor in those delay effects. All right, well, I have done it. I have finished this in less than one hour. I don’t know if any comments came through or not. I have not been monitoring any chat or questions. So maybe if we have a couple of minutes, then maybe I can answer one or two.

Yeah, I’ll just, Orion, thank you so much. I’ll just heads up stuff that was in the chat.

I think Shane Edmonds was just expressing that roadmapping not as a sales tool, but can definitely be a product marketing tool. So unfortunately, he had to drop off. But that was one of the comments. And then Alex also had to drop off.

Oh, hey. Hey, there you are, Shane. Yeah, oh, I don’t know if you wanted to talk any more about that or questions about it.

No, it just resonated with me when Orion had mentioned about not being a sales tool. So I just mentioned that.

Great. And then Alex had to drop off for an analyst briefing, but was also talking about validation and important input for the roadmapping process.

So those are the only comments in the chat. So I’m just going to open it up to anybody else on the call.

Please feel free to ask Orion questions. Go for it.

Know you had a lot of guidance, prescription. But were there any examples that we could see?

I gave some examples of what I meant by investment themes. I gave examples of features or roadmap projects that might fit within roadmap themes. I gave examples of annual objectives that I think are quite effective in the level setting for a roadmap. I definitely stopped short of saying, hey, guys, here’s the track roadmap format that you need to use from now on. I’m definitely stopping short of that. Because for a variety of reasons, there’s no one that would satisfy all of you. And none of you are served by having multiple roadmap formats.

So I would much, much rather you take the formats that you like and continue to evolve them. But it would be my hope that I have inspired at least one of you to make at least one change, one step in a direction around great framing, really solid business- oriented framing around the roadmap. So you’re already maintaining. And I’m happy to help and engage outside of this call if you’ve given it an honest try and still struggling and not sure you feel like you get stuck. I’m here. The other members of the Invictus Guild are here to help as well.

So real quick, Ryan, and maybe we take it offline. You mentioned confidence in there. And confidence scoring is one of those things where you run a pivotal path. So whenever I do roadmap, I always want to run a pivot path based upon some type of customer need or revenue recognition that we’re driving. Be interested to get your take on that. Because after two decades, I still don’t love exactly the way that that has happened or that I’ve seen.

So if you have any insight there, I’d love to get your insight on that. I have a feeling the first thing that we’re going to find out when we meet up is that we’re both in agreement that some of this stuff is art, not science. But yeah, well, happy to have you.

If you have a great paintbrush, I’m looking forward for you to help me there.

All right. We’ll give it a try.