Five Elms Roundtable on Using Vision-Led Product Management to Build a Balanced Roadmap

All right. Well, we’ve got a good group. We can go ahead and get things started, and I’ll continue to let people in over the next couple of minutes. I’m sure all of you guys know Kristen from 5M’s. She usually facilitates these, but is out today, so I’ll be stepping in. Really excited to put together this event today. I wanted to welcome Sarah Zalewicz. She’s the managing director and senior advisor slash coach at Prodify.

Sarah’s two decades in product leadership include being Rent the Runway’s first chief product officer, the VP of product for WeddingWire, and VP of digital innovation at Marriott. Over the past four years with Prodify, Sarah has coached approximately 20 clients on the topics that range from vision slash strategic planning through roadmapping execution in order to help organizations achieve outcomes. So at this point, I’d love to turn it over to you, Sarah.

Great.

Thank you. Hi, everyone.

I’m excited to be here. I’m going to go ahead and share my screen, and we’ll jump right in, but I’m definitely going to pause along the way, make sure we have time for discussion. I want to answer any questions, and please feel free to also interrupt. If I don’t see it, we have other eyes on to monitor, and I appreciate monitoring the chat. So with that, I will go ahead and share my screen. Let me just slide so I can see. Can everyone see my screen? Is that great?

Great.

So today we’re going to be talking about building a balanced roadmap, and I’m going to share a little bit about vision- led product management and how that can help you achieve it. But again, want to open it up for discussion. I’ll quickly just kind of do intros. We’ll jump into some discussion because I really want to hear from all of you on what some of the challenges you have are so that I can make sure that I’m accounting for that as we talk through this.

We’ll go over what vision- led product management is, and then we’ll dive into talking about building this balanced and outcome- oriented roadmap, and then we’ll make sure there’s time at the end for questions and discussions. So with that said, I will jump into my intro. You heard a little bit about me, but just to kind of give you the broader context of my product management journey, I’ve been in product for over 20 years at this point. I started at Accenture.

I started actually more on the engineering side and evolved more into what has now become product management, and my experience really varies from early stage, so when I was at Rent the Runway, that was a much earlier stage at the time, to growth as well as large enterprise organizations. So I’ve really seen product from its infancy, like creating the team, to growth, and all the way through to varied matrix teams.

And now at Prodify, I’m working with organizations, like typically B2B SaaS as well, to focus on anything from vision and strategic planning down to roadmap and execution and really everything in between. And then just really quickly about Prodify, who we are, in case you’re not familiar, we essentially work with organizations to help them become more product- driven in order to achieve those outcomes. And many of our team members have similar backgrounds to me.

I mean, I won’t go into detail here, but you can just kind of see a little bit about us and our background. But that’s just a quick overview, but I wanted to just jump right into a discussion. I would love to hear from all of you, what challenges are you faced with when it comes to roadmapping, balancing the time, and prioritization as a whole, because I want to make sure I can hear from all of you, and then I’ll make sure to apply some of that conversation into the topics that we’re talking about today.

So feel free to either raise your hand and chime in or, you know, in the Slack, I would love to hear. And I’m going to, for a moment, stop sharing my screen for this, just so I can see your faces or any comments that you all have.

Yeah, this is Tom Graham over at Smart Warehousing. Can you hear me?

Yeah.

Yeah.

I mean, it’s a broad topic, right? And lots of challenges there. I think when you just specifically around, I think your question was around roadmapping and that kind of thing. So if you’re building like maybe a product from scratch, maybe the roadmap is a little easier to maintain if you’re supporting existing applications and changing priorities as soon as you start getting things roadmap, the challenges is there’s, you know, maybe a shift in direction or a new customer demand that pulls you in a direction.

So it’s you’re kind of in a perpetual state of roadmapping rather than, hey, I’ve laid out 12 months and I’m good to go.

Yeah, absolutely. That definitely resonates. And we’ll cover a lot of that today of like once you’re in some ways, it’s a luxury when you’re starting from the beginning, because it’s like, okay, this is what we’re building. And that’s our only roadmap, but what happens when everything else comes into play. And that’s definitely a big focus for today. Thank you for sharing that.

Sure. Let’s see, we’ve got some in the chat.

Balance decency bias and opportunities with prioritizing items towards a long term vision. Yes. Balancing longer term roadmap features with reasonable estimates to build a calendar lots of work to get good estimates. Yes. Yeah, that’s great. These are all great topics and lots of things that that will absolutely discuss. Great.

Got one more here.

Love to hear about best tools pack practices for tracking client feedback to drive roadmap discussions with the product team. Great.

Just put some of these aside so I remember to cover. Wonderful.

Great. Well, I can I’ll jump back in. But feel free as we’re going through if you start to have more questions, just raise them or thoughts but just wanted to kind of hear from you all to make sure that that I’m addressing some of the hot topics. Yes, I’m putting time dates. Great.

So back to sharing my screen. Hopefully you guys all see it again. Wonderful.

Okay. So, before we get into jumping into the roadmap, I just wanted to take a step back and give a little context into vision led product management. Because I think this sort of will set the picture, at least right into the roadmap.

So let me start with first an exercise.

So let’s imagine we are in Austin, and you’ve got good barbecue football good weather right and all of a sudden we’re, we’re in downtown Austin, and a bus pulls up, and we’re all there.

And the question is, who wants to go down the bus.

So who would you know from just being in downtown Austin, you know, raise the hands, would you consider jumping on this bus kind of daredevil not sure where it’s going yet. Let’s jump on the bus. I don’t know everyone’s reactions yet but I’d say typically, not many people are willing to do that you know we want a little bit more context right.

So okay, now let’s give some more context where are we going so maybe there’s a bus going to San Francisco, maybe there’s one going to DC, perhaps some of you might start to be a little bit more interested and knowing a little bit where you’re headed. So think about, you know, I can’t say everyone’s hands but you know think about, you know, which one, if you’re ready to get on the bus Are you willing to go to one of those locations versus the other. Okay, so now let’s think about the route.

Well, you know, if we’re going on the California route it’s going to be more rugged so it’s going to be outdoorsy we’re going to go camping. We’re going to be roughing it a little bit doing some hiking things like that till we get to our destination. Versus if we’re going to DC route it’s going to be a little bit more luxury will have fine dining will do some sightseeing but you know we’re going to stay in nice hotels it’s just going to be a little more luxury.

So kind of think about you know if you’d be interested in the rugged path knowing it’s going to California, or you know which path would you go if you’re if you’re interested in DC does the luxury path sound good to you. So think about that. So why am I explaining this what does this have anything to do with product management or vision my product management well let’s connect the dots. So if you imagine your bus is actually the product, and the passengers, those are your customers they’re getting on.

And the final destination is your product vision right so your customers need to know where you headed for them to make a decision with your product, where’s the end goal. Is this something that’s going to achieve their needs. And then the route is your product strategy those are really kind of where we’re headed the stops that we have along the way that are going to get us to that destination.

And then lastly, your daily itinerary that is the product roadmap right that’s okay, we’re waking up at a certain time we’re going to stop and get coffee here, we might take pictures here, you know and so that’s really kind of when you think of that’s the the roadmap, if you try to put it in that context. And so when you put it in context of the roadmap were many times in a place where there’s different options that we could take.

Well, if you don’t know where you’re going, which is ultimately the vision, any road will get you there right all ideas are good in isolation if you don’t know the direction of where you’re headed. And so that’s really kind of like how it all fits together and that’s why I just wanted to lead with that thinking about knowing the direction where you’re headed starts to set that context for how do we really prioritize what are the right decisions to be making within our roadmap.

And so to tie that into vision led product management, the way that we think about things as you know there’s a point in time there’s today and some point in the future, let’s call it three to five years. And we’re looking to understand what are we trying to accomplish from our customers lens what what are the outcomes that our customers are looking to achieve.

And that point of time in the future from three to five years is like what is that vision for them what is the customer journey that we’re going to take them on to get them to this future point where they’re now able to 10x their outcomes.

The strategic plan, those are the milestones along the way that we’re gonna measure, we’re gonna learn. Are we on our way to our vision? Are we on our way to helping our customers achieve outcomes? And then the roadmap are those steps in between the strategic milestones, the strategic plan. And so, you know, it’s ultimately a way of how are we measuring along the way to ensure we’re helping our customers achieve their outcomes, which are ultimately helping us as a business achieve our outcomes in order to achieve that vision.

So I just kind of wanted to set that context a bit before I jumped into the roadmap and this will just lay out the framework a bit more and then I’ll pause for any questions before we jump into the roadmap. But really, so, you know, within vision- led product management, it really starts with understanding what are the outcomes that we’re looking to achieve for the business and for our customers? Leading with that, what are we trying to achieve? How do we now help customers 10X that outcome?

How do we break that down into a strategic plan to realize the vision? So how are we identifying what’s important now, next and later? And then how are we creating that roadmap and balancing the work? We’re going to have the strategic work, but we also have near- term work, right? And so how do we balance that and how do we think about that based on the stages that we’re at? And then lastly, the execution, right? How we’re empowering our team to execute the roadmap, bringing the right people in the right places.

So all of these could be topics on their own. We’re focusing in today specifically on the prioritization piece. And so I’ll pause there just to see if anyone has any questions or comments on that before we get into starting to talk about the roadmap and prioritization. Okay, I will move on and then we’ll make sure to have more opportunities for dialogue.

So when we think about creating a balanced and an outcome- oriented roadmap, the reality is, and one of the questions was sort of alluding to this, the reality is there’s really three categories that every product team is juggling. One is innovation. So these are the features, the kind of the bold leaps that we’re looking that are helping us build towards that vision. This, it could be going into new markets, it could be new features, it could be maybe large- scale integrations or things like that.

But these are the things that are those bolder leaps to help us achieve the vision. But then there’s also iteration, right? We have an existing product, we can’t ignore it. We wanna make sure we’re making those incremental changes. So that we can deliver value. It could be anything from funnel optimizations or making incremental work to lift a KPI or one- off requests, things like that. But that is maintaining the product.

And then the last one is operation, which are these are things like tech debt, they’re bugs, these are things that we know, no one loves to do these things, but they are things that are important and things we need to maintain. And the reality is all three of them are necessary. Sometimes, some of them might feel like a pain, but the reality is they are all categories that need to be put into a roadmap. And so really like a key discussion is, how do we think about it? How do we balance across these?

And how do we prioritize within each of these buckets? And they all really have different approaches for how to prioritize. So, and when it comes to allocation, it really does depend on the product lifecycle. And so what I’m gonna walk through are more kind of like guidelines and tips, but obviously, you all adjust based on your needs, you know your business the best. But if you think about kind of the S curves of innovation, like once you reach that, the top of it, you’re starting to identify your next wave of innovation.

So we start with kind of, you’re in alpha mode, where maybe you have like a core, you have a product, but you still have some time that you need to innovate on it while you’re iterating versus once you’re in beta and you’re getting ready for general availability, you’re probably focused more on iteration. General availability is probably more operation at this point, because now it’s scaled, it’s rolled out. You have a lot of tech debt, you have bugs, things like that. And then there’s the time where you’re mature.

And this is now where you’re looking for that next wave of innovation. So you might kind of increase. And so just to kind of, this is again, a sample of what this could look like. And this could be for your product as a whole, but you could also think about it for features within, like you might have certain features that are in alpha phase versus beta, et cetera. But the idea is really…

it is very challenging to be able to compare an iterative item from an innovation item from an operation item. And sometimes that’s where I find a lot of the struggles with the roadmap are. We’re looking at things together as if it’s the same resources and the same allocation, but there’s a huge benefit to upfront starting to identify where are we and what percentage of time should we be allocating? Because you can’t compare innovation iteration. That’s comparing apples to oranges at the end of the day.

But if you’re actually isolating the time and putting aside resources to spread across them, then you can start to prioritize within those buckets so that you can actually ensure that you’re building towards where you’re headed. So I’ll just pause there before we go into some of the details.

And I have some questions here, but I would love to hear if these categories resonate with you all, if there’s any other categories that you feel are missing that’s maybe causing you challenges or any other difficulties you all wanna raise or just questions in general, I’m happy to answer before we go deeper.

Hi, Sarah. I have a question around, I think just everybody hates the word tech debt. And you had on a couple of slides ago, the definition of innovation and you wrote down architectural changes to support future end states. And I love that that was classified under innovation because one of my challenges is that it’s classified here under tech debt. And it’s really hard to sell a vision when I’ve got to spend a couple of months or like a couple of people to put some of the bigger backend changes, non- visible changes in place.

But then obviously they pay off if people can be patient. So anyway, I just would love your thoughts on that.

Yeah, absolutely. I think that’s a really great point and I’m glad you raised it because there is a difference between the quote unquote tech debt that has to happen to like fuel the growth versus tech debt that maybe has to happen because we have security issues or maybe we’re slow to release things. And so we need to optimize and things like that. But absolutely, as you look at your innovation items, which are typically the items that are helping you meet your vision, you need to start asking yourself, well, what do we need to make this happen?

Many times there are predecessors that are very tech related and may not be future or may not be visible to a customer or to someone internal, but it’s a necessary step. And so I think within that, like listing out those items and starting to space them and say, what do we need to do first, second and third? And then also, what do we need to learn from each? It doesn’t necessarily mean that that means all of a sudden tech has to work on something for six months to a year in order to enable it.

Maybe there’s a version that they can create that they can also learn and say, well, we’re not at scale yet with this feature. So I don’t need it to work to the point where our ultimate goal is let’s get it enough where we can get 20 users on it, whatever the right number is, right? And they can also kind of build theirs in an iterative way so they’re learning along the way. And there’ll be times where they can do that and times where they can’t and that’s where a lot of the discussion happens.

But absolutely, there are times where like you need to invest in that in order to support what the future vision is.

Great. And Sarah, we had another question pop up in the chat. How does the product life cycle take product market fit into consideration?

Yeah, absolutely. So product market fit is certainly, here, I’ll go back, sorry. Yeah, so with product market fit, I mean, you’re still in a phase where you’re consistently iterating and many times innovating as you’re learning new things. So that can very commonly be within like alpha and beta, I would say. So just based on where you fall within that, you’re gonna kind of figure out like how far off are we from product market fit? What are the needs? Is it something where we’re really doing, adding in some brand new features?

You may not be at the point, if you’re pre product market fit, you may not be at the point where you have that three to five year vision because you’re still kind of figuring out and learning where is this product resonating? And then from there, you can start to identify that vision. But yeah, I’d say you’re probably somewhere in between one and two, or you could almost be leaning in more to innovation. It really just depends on what you’re learning from your customers, your segments, et cetera.

And that’s why I was trying to, these are examples and I’d say common ways to approach the balance, but you know best based on your customers, your needs, your users, et cetera, like where you need to lean in and where the gaps are for you to appropriately be able to kind of spread that.

Another thing that maybe I would bring up that commonly comes up when I ask the question of do these categories resonate? A lot of times there’s questions- and I think this was one of the questions that came in early on when you guys had sort of signed up- was: how do we handle sales requests? Is that something that resonates? I see some head nods, and so I’ll try to address that as well- where many, if I sorry, go back to this line. So I certainly commonly hear of we’re getting a lot of requests from sales.

Certainly the ideal is that you want to be able to take those requests, figure out where do they fit in with our going back to the vision, going back to our goals, and figuring out where do they fit in and prioritize them within one of these buckets, typically one or two.

I also certainly recognize it doesn’t always fit in that cleanly and sometimes there are- hey, listen, we have to make this change, given there’s a high- paying customer or we’re at risk, and so I have seen teams do it where they’ll put in another bucket for sales requests and they put a percentage of time and they put guardrails around. When are the times where we would actually kind of allocate time to sales? Is it based on a certain dollar value?

Is it based on a certain risk where you can kind of create those guardrails so it doesn’t become every single thing has to be done- let’s drop everything- but that there’s alignment on what are those guardrails. And if there’s call it 10% of the time, it’s sort of a conversation with sales so like, is this worth our 10% of time? Is this how we’re going to utilize that? And that helps kind of guide the conversation more. And it doesn’t.

Even with that, you will still get requests that might fit into innovation and iteration and make sense to prioritize in those buckets. But it’s when you’re in the case where it falls outside of that. Sometimes it can make sense to have that bucket and say, like this is the bucket that I have with you sales. We need to discuss together how do you want to utilize that time and is it really worth it and how are we going to measure the success of it.

So that’s kind of another way to think about how you can handle some of those crests when it really falls outside of this. But you also know that it’s probably something that needs to get done, tara, what happens if your stakeholders don’t agree with. Yeah, this is the. Can you just go back to that slide? You just showed the allocations like what, if your folks are like, I want you to be 80% innovation at all times? Yeah, yeah, and so this is. It’s a great question, because this should not be done in a bubble.

This is definitely done in a collaborative way, having these conversations with stakeholders, with the executive team, and getting alignment. If you do find that you’re in a place where you’re completely far off, where you’re saying we need to be 60% innovation and they’re saying you need to be 80% innovation, that, to me, would start to question: are we aligned on where we’re headed and how far off we are from the current state where we are today versus where we’re headed?

Because usually when I hear that, it’s like okay, they think the current product is working perfectly.

If we’re only, if we’re basically at this stage, where now, all of a sudden, we’re only looking for the next wave of innovation, and I think that’s where bringing to the table, where are we with the current product and what are the gaps that our customers are seeing that are more iterative versus one of the things that we’re doing that are really going to be more for the future vision and having the dialogue around that and probably taking a step back and making sure everyone’s aligned on the vision and strategy, on the goals.

That is absolutely collaborative. But it’s a really good point that you bring it up because if there is not alignment at that level, that’s where a lot of the tough conversations start happening in roadmaps and you start getting like, well, wait, I really feel this needs to be done. And if you’re saying, well, we only have 30%, then obviously there’s going to be a gap in what stakeholders are expecting. So that is absolutely critical.

And getting alignment on it, communicating it to the team- everybody’s aware this should be said to not just product, to everyone in the organization, so people kind of understand what those guardrails are. But it can also be evaluated every so often. Right, maybe every quarter, that might be a bit too much, but at least twice a year you’re looking at this and saying: does this feel right? Are we still in the right direction? And I say a quarter sometimes might be, it could be appropriate.

But sometimes you’re still sort of in the midst of what you’re building to then all of a sudden stop and reallocate. But obviously it’s always worth having the question and saying: are we still aligned on this? Is this the right approach? Is this the right direction?

Yeah, one of the things that I’ve done in the past is to slightly change the names of these categories to make it a little bit more sales or customer focused. And so like I’ve called innovation, like market or customer acquisition or new customer acquisition, and I’ve called iteration, you know, you know, customer experience, so like existing customers and, you know, a request that there. And then I have another category for just market expansion in existing existing markets.

So and then obviously, you always have your operation, your cost savings, your modernization category. So I have also done it like, where it’s Yeah, customer experience, market expansion and customer acquisition categories.

I love that. And I think, yeah, customizing it to the needs that you all have individually is really important. Like you all want to be saying the same language. And if that’s how you know that, absolutely, I think that’s great. And I’ve also seen it, and many times I recommend it, you know, focused on KPIs, and what percentage of our time are we spending across these KPIs? And maybe within those KPIs, you say, okay, how much are we then going to allocate within that KPI to innovative versus iteration? Like I’ve seen it that way as well.

I think really, the key is like having that alignment of what are the kind of categories that we’re going to identify as our priorities? And how are we spreading our time across? Because without that, it is like, like I was saying, it is really challenging, because you end up being these conversations where people are raising two roadmap potential items that are complete and focusing on completely different goals, completely different levels of work. I mean, iteration tends to be something you can do within like a sprint, commonly, innovation.

Yeah, you want to be learning each sprint, but you know, to see the full value might take some time, those are the riskier things. And so really trying to identify that compare those two is really impossible. And I mean, I’m sure I’ve been in that situation before. It’s just not comparing the same thing. And a lot of times what happens, it’s iteration wins, because it feels quicker, and you’re seeing the result, but you can’t iterate your way to innovation.

So then you’re going to look back and in a year from now and say, well, we got a lot of quick wins. But did we actually change the product dramatically? Did we, you know, whatever our goal is, if we’re looking to acquire, you know, a new market or etc. Like, did we get there? You know, probably not. And so that’s why it’s so important to think about it up front. Any other questions or comments before we’re going to go in talking about ways to actually prioritize within these categories as well.

Okay, so let’s talk about okay, now that we have the categories, which may be these are another version that aligns with with your companies. There’s really different ways to prioritize within each. And so I’ll, I’ll just pull them all up. But in it, so when you think about innovation, this is really where you’re pulling from your vision and your strategic plan.

So like we were talking about before of like, you know, if we know that there are certain features that we are looking to achieve in order to meet our strategic plan, you start to map out well, what does this mean? There’s could be new features, but then there’s going to be the predecessor work, whether it’s capturing data in a certain way, or some tech work that needs to happen.

And this is it’s very, it’s a very collaborative effort, I would say at this point between product, tech and design, where they’re sitting and mapping this out and starting to organize what needs to happen for second and third, while also identifying, and I have listed here the upcoming milestone. So making sure that you have a way to measure along the way, are we achieving what we’re looking to achieve? Or like, what, what’s our learning goal within each of these?

Because many times in innovation, like there’s a lot of learning to be had, what are we learning? What are we exploring? And did we learn that to know that it’s time to like continue on? Within iteration, I’m definitely a big fan. If you all are familiar with rice, which is basically looking at like rice type of rice, right? Reach times impact times confidence over effort. But really any sort of like, that’s like one version, I’ve created many like customized versions as well.

But the idea is like, how do you have a way that you can base on your KPIs, start to actually score the work and the iteration items that you have? So it’s not just who’s ever screaming the loudest, how are you kind of pressure testing that against, you know, in this example, reach impact and confidence, and then considering effort as well. And how are we scoring that to be able to say, this is what rises to the top, not that it’s perfect, no calculation is ever going to tell you exactly how to prioritize. But it’s a conversation starter, right?

It starts to help you ask the question of, does this feel right? Does this actually align to where we’re looking for the product to head like it starts the dialogue and then you might change things around based on it. But it at least gives like a fair way to look at things and I can I’m happy to jump to the appendix where like I have an example of it. But these are very common for things again, the iteration, the smaller changes, it might be usability issues.

It could be tweaks, it could be experimentation, those types of things, and kind of prioritizing those by your KPIs.

And then the last is the operation. And so this is where, you know, all of this is really a collaborative effort with engineering and with design as well. And then in operation in particular, this is where I lean very heavily on my engineer counterparts. And we start to talk about what are the operational metrics that we’re looking to focus on and let’s map those out. And what are, you know, this might be a quarter by quarter basis where you’re saying, what are we focusing on as our priority for this operation bucket this quarter? Is it performance?

Is it security? Is it uptime? Maybe there’s some operational efficiencies where we need to help and support tools or people are doing things manually, like things like that and pick each quarter. What are those priorities? And then align around that. And, you know, that’s where the work can start to get prioritized. You know, and there’s always times where bugs come, you know, you always have to allot time for things like that as well within. But that’s kind of, you know, the key is like it’s not a one size fits all for how you prioritize.

And it’s all about measuring along the way as you’re starting to roll these out. I’m curious if anyone has any other tips or thoughts around prioritization or if any of these resonate or maybe you guys are trying some of these.

I don’t think we’re using necessarily the same names, but I think it’s the same functions that we’re wrestling and balancing along the way. So I mean, this resonates pretty well.

And this just kind of gives an example of how it all comes together. We have lots of different templates and versions, but this one tends to resonate with me and resonates with our clients quite a bit, where this is an example where it’s actually more, I’m a huge advocate of ensuring no roadmap would ever go public without having goals included, you know, at least internally, to make sure that we’re very clear on why are we prioritizing these items? What goal are we looking to hit and how are we allocating the time against that?

And then within that, you can see there’s kind of color coding for innovation, iteration, operation, like within each. So that way, anytime there’s the next conversation of, you know, a stakeholder says, hey, I really want us to focus on X, you can bring it back to this and say, oh, interesting, let’s take a look. What goal do we think that that’s helping us achieve? And then with that, you know, let’s talk about what’s currently being done, because if you’re adding something, you’re removing something.

Let’s talk about that and see whether this is a higher priority or not. If not, great. We can assess that when, you know, we’re kind of taking the next look at our roadmap. And sometimes it does. Sometimes it’s like, wow, that actually is a great idea. And we started talking with the customers about it and we’re getting great feedback. We think that would trump something. And so here’s what we’re going to move off to the, you know, sooner or later type roadmap.

But you can also see this is very much, you know, instead of being, we are launching on this date, you know, especially for the soon and later. At this point, you don’t know dates at that point, because it’s still being researched. It probably hasn’t been estimated at that point. The now is when you start, as you’re in the work, you start to get a better sense of the timelines. So as you get closer, you might start to identify that, but this is very much a, here’s what we’re doing now, which typically means this quarter.

Soon is probably the next two quarters and later is, you know, further out in the future. Does anyone have roadmaps that look similar or does this spur anything for you all?

This roadmap is just something that, I’ve tried roadmaps like this, but it’s, you know, it’s hard to give roadmaps without dates. And one thing, I recently went to a conference and they had suggested multiple levels of roadmaps, you know, where, you know, maybe you do, like your now roadmap or your now plus soon roadmap is a little, you know, can be a little bit more executive friendly and sales friendly.

And because people do, you know, people, I think it is a fair request to ask for, you know, what can I expect to see in the product, you know, but balancing that with like, I don’t really know dates and there are a lot of unknowns here. And so, you know, any date I say today, you know, may shift once we know a little bit more. So I feel like that for me, like that’s one of my biggest roadmapping challenge, you know, is sort of assigning, you know, not wanting to put dates on it, but also wanting to tell people what they can expect.

Yeah, absolutely. And it’s honestly, it’s like a very common challenge. And I think it’s been sort of an evolution where some organizations are more accepting and you know, some are still very focused on wanting like, I need to know a date. I think my general recommendation is, I don’t like to if if there’s not a high confidence in the date, I don’t like to list it because I believe that that’s just giving a false sense of confidence.

And the reality is, I think there’s a level of training that, you know, as product leaders, we are looking to provide that, you know, if we don’t know a date, and the reason that we don’t know the date is not necessarily we don’t know the estimate, although sometimes that’s the case. Sometimes the item that’s now is doing so well, we decide we’re going to double down on it, and we’re not going to do the next item. So there’s so many things that can happen in a roadmap that it’s really hard to be able to say a date for the sooner or the later.

But then now I do agree, like there is a point in time where like, we, we should have a sense of the date. And so, you know, I could have put that as an example here is like, there are times where then you would include the date within something like this. So like, and that’s the indicator that we have the higher level of confidence, certainly things can change as we learn.

And like the key is, you know, sometimes we it can start to feel so much pressure around the date where you don’t want to be in a situation where you’re delivering based on the date, and therefore not the goal. Oh, I said I was going to deliver the state, I need to hit it. And then we’re actually leaving out things that are meant to achieve our goal. But once you do, and this is certainly a higher level roadmap as well.

In fairness, this is like a strategic roadmap item, there’s probably even deeper levels that the product team would have themselves where there’s even some more concrete time. But I’d say like my general recommendation is to try to reserve a date for when you have the higher level of confidence. I typically the soon and later you do not have that higher level of confidence. And I think sometimes it can be really hard when you put the date on when you don’t have that confidence.

Because even though you say it, someone’s going to see that date, and they’re going to, they’re going to repeat it, they’re going to tell someone they’re going to promise it. And so that it’s kind of like a balance within your organization to figure out another approach that I’ve seen people take is where like there is really a need to hit the date or write the date down, they’ll write it, but they have an indicator at the top of the roadmap, it’s like their level of confidence.

And like it just shows that and they almost put the date in gray, like they color code it different so that you can actually see. So that’s another approach to think about. But for me, I’m all about just being transparent and honest, and making sure that we’re not setting a false expectation or all of a sudden, a customer has promised something because maybe you gave this presentation and you talked about the nuance of that, but then someone saw it and didn’t hear that nuance. And all of a sudden, they start committing to it.

So it’s kind of just a balance across that. Is that helpful at all? Or does that resonate? Any other questions? Or I mean, I would love to hear to just any struggles that anyone’s having with their roadmap, or the communication aspect? Or the prioritization? Some questions here for this for us? Any questions? No.

Well, my customer success director, who I think is on this call, and I have been talking about different ways to prioritize customer feedback. And we were wondering if there’s a tool that anyone knows about that can, you know, if we gather product, you know, customer feedback, and that, you know, could we score it against, you know, the value of the contract of that customer?

You know, we were just wondering about, you know, how do we get additional metrics, you know, without doing a lot of manual work, and we were wondering about tools that people use. I wondered if you had used anything like that.

Yeah, good question.

I know there are some of the roadmapping tools out there that allow you to also insert what the requests are, and then you can set your fields for prioritizing as well. I’d have to look back and see which ones do it to that level that you’re asking. So I can certainly follow up on that. But I know there are some roadmapping tools that have a whole level of prioritization within them. ProductBoard, I believe, is one of them.

Perhaps ProdPad as well.

But I would have to take a deeper look to see if it does it to that level. But I also do think that, to me, can also be like a modified version of, I was talking about Rice, but just what is the prioritization score? What’s the rubric that we’re creating for how we’re picking and prioritizing? And even starting with a spreadsheet might be helpful just to pressure test what is that rubric. So if sales contract, size of the contract is one of them. But then you might also have one that says, what’s the reach?

In terms of are others experiencing the same problem and need?

And you could give a weight to each of those.

So yes, maybe you want to consider the size of the contract. But then you also, perhaps at a higher rate, want to consider, is this something that’s going to meet the needs of many or just meet the needs of one? And then is this something that, what’s our confidence that we can actually deliver on it? And the estimate doesn’t have to be an exact estimate. But do we think this is small, medium, or large estimate? And that can all create a score for you.

And I have some of these templates that I’m happy to share if anyone’s interested, after if anyone wants to follow up, where you can just start to identify what is that rubric that starts scoring on it. And then from there, start to see if there’s tools that support it. But I personally love trying to create a score out of your prioritization.

Again, it’s not perfect.

And I wish you could just have a spreadsheet tell you exactly how to prioritize. But it really starts the dialogue. And it also makes you, with your stakeholders, challenge, why should we be doing this? You really start to score it against the things that you have isolation from this request, the things that you have said are important for us to pick and choose. And it’s just such a helpful dialogue and conversation.

And I can just give you, I have a few in the appendix.

This is focusing on rice. But just an example of how you’re scoring things, it comes up with a score. And then it just starts a dialogue. Again, like I said, it’s not perfect. But it starts that dialogue where now you say, oh, OK. It’s telling me I should be prioritizing these reminder emails. Does that feel right? And then we’re going to send out the deck after. But there’s a list of questions that you should start challenging. Because again, it’s not perfect. But does this align with our beliefs?

If we swapped a few items above the line, could we group more work together? Those are conversations to think about. But at least it starts a dialogue. So it doesn’t feel like you’re just getting all these requests and they all feel an equal weight. And this is an example where you could modify your own and put in, you could put in sides of contract and give it a score, things like that, to help weight it. And then you could put your own weight. You can have a whole other line.

I have, like I said, templates with this where you have a whole other line with just a weight where then you’re accounting for how important is this particular field for me in deciding this. And then, yeah, like I said, the appendix has tips for prioritizing innovation further and tips for operation, kind of like the questions to be asking. And like I said, we have templates for these as well that I’m happy to share if anyone has any questions.

Any other questions or comments? Well, here, like I said, you guys will all get this deck. So there is on our site, we have some tools for you to optimize your roadmap process.

It includes some of these templates that I mentioned, but also feel free to email me because I have some additional like prioritization ones that give you like a bunch of options for how to consider prioritizing that might be helpful.

And here’s my email and you could visit our website.

I think that’s it.

Thanks, Sarah.

If we have a couple of minutes left, we had a question come in on how to best test concepts slash products. I know that wasn’t the focus of this presentation and you mentioned we could go really deep into that topic, but perhaps if you had one or two tactical nuggets or a framework that could help someone approach that question briefly.

Yeah, so how to best test like new products.

I’ll just stop and share.

Yeah, no, absolutely.

I mean, yeah, like you said, I think this could be its own topic. And I could talk about it for an hour on its own. But yeah, I mean, when you’re thinking about launching new products, and this like typically falls within the innovation bucket, there’s a lot of risk, there’s a lot of unknowns, you’ve likely done the best you can to do some research up front and some discovery, but obviously, it’s not perfect. So like, one thing that I always recommend is don’t, don’t over invest your resources higher than your confidence level.

And so your goal along the way, as you’re testing and trying to learn, then these products is to grow your confidence level. So you can determine, like, should we be adding more resources. So in the beginning, you might be starting with like smaller teams who are really trying to learn along the way. And I’m a huge fan of focusing in on, you know, learning without a lot of development upfront.

So that means you can be, you know, you can start with a concept where you have a prototype, or you’re getting eyes on it, you’re getting feedback, you’re bringing customers, and you’re bringing users in, or you’re doing it virtually, and you’re getting feedback. And you’re trying to understand, like how this would help accomplish their goals. And then from there, you know, I’m, I’m a huge fan of where you can to, you know, start, if it’s like, you know, obviously, we can go into nuances of like the different types of products.

But like, I can give you I know, it’s not a B2B example, but I can give you like a B2C example, when I was at Rent the Runway, when we were looking to launch our subscription business. And, you know, we had a good sense, like from research that this was something people were interested in. But like, it would have been a huge investment for us to just all of a sudden jump all the way, I mean, huge warehouse changes, etc.

And so what we did is once we got some of that initial feedback, we did some prototyping, we put a page up for people to sign up, and we actually didn’t have the feature live. So we just put the page up, we tried to see how many people would sign up for it. And from that, we got a waitlist of people who were interested that that was gold, because now that was our waitlist of prospects. And we were able to talk with them. And they kind of helped us along the way build, so that we could learn along the way.

And then when we once we first rolled it out, we rolled it out on a very small scale, it didn’t accommodate for all products that accommodated for a very small amount of products that we knew we could operationally handle, we got feedback, we then opened it up to more people and more products. And we kind of slowly rolled it. But along each step of the way, we had a measurable goal that we were looking to achieve. And so we knew once we hit goal X, that we can move on to step two. Once we hit that goal, we can move on to step three.

And sometimes it took longer than we thought it would. And that kind of goes back to why it’s sometimes hard to hit dates. Or to set a date too far in advance, because you don’t know how the work before might take longer, because you’re learning along the way. And all of a sudden, a resource that you thought was going to work on project B is still working on project A, but for good reason, right.

And so, you know, translating that to the B2B world, there’s, you know, definitely things that you can do in similar ways, where you could have certain features, all of a sudden show up as available and see if someone clicks on it, and then say, Oh, this is coming soon. And now all of a sudden, you have a new contact that you can reach out to. There’s things like that, that you know, but I’d say the biggest advice is find the measurable pieces along the way. Make sure you’re very clear on the goal that you’re looking to achieve.

Measure it before you determine going on to step two and involve your users and customers along the way. Any other questions or comments?

I say I thought I didn’t realize I was on mute. But um, yeah, thank you so much for answering that question. I just launched the poll. We’d love to hear your feedback on the session. Additionally, about future topics of interest as we help 5M’s planned out future roundtables. But we did have 10 minutes. So I’d really like to turn it over to everyone in the room. If you have any questions that can be, you know, very specific to you, that you’d like Sarah to answer.

I don’t really have a question. But the new role, you know, discussion was, you know, kind of reassuring that, you know, we’re not the only ones that face all these, these same challenges. And there are different ways of sizing them up and approaching these things with stakeholders and business and customers is pretty universal, but it’s, it’s good to see different frameworks and ways to approach it, which was really helpful.

No, I’m glad to hear. Yeah, you’re definitely not alone is very common. It’s, I think the key is that alignment up front, because there’s so many different conversations and people have different perspectives, making sure that everyone is aligned up front. And however, whatever those categories of buckets are, that makes sense for you, are we aligned with our stakeholders, because you they need to be communicating to that team, just as you’re communicating to your team. And that that is definitely critical.

Great. Well, thank you, Sarah, for your time, we can end a couple minutes early, if there’s no other questions. Everyone will also receive an email with the event recording slides, Sarah slides, as well as a way to get in contact with her if you have any other follow up questions.