Listen to the article

This is an edited and abridged transcript from our ‘In the Ring’ podcast series about discovery. 

For the next six weeks, we’ll be sitting down and talking with Melissa Curra, SUMO Heavy’s Director of Strategy to break down the entire process. 

You can also listen and subscribe to the podcast on Spotify, or wherever you get your podcasts.

John Suder: In the briefest of terms, can you explain what exactly a Roadmap is, and what that looks like?

Melissa Curra: A Roadmap looks different for a lot of different projects, and can look different depending on who’s giving you the Roadmap. But, it’s generally a really nice outline of the different parts you and your team will need to accomplish in order to succeed in this whole idea, this whole feature or site. It’s different from a timeline, I think people get really attached to due dates and the date associated with it, and they’ll kind of go from that. They’ll build a Roadmap dedicated to those times. That’s the timeline. That’s understanding where the features and the project itself stands. However, a Roadmap really should indicate to your team and to anyone who’s going to be responsible for delivering things. If that’s design, content, SEO strategy, or if it’s something way more complex, like an architectural solution, software, solutions, all of those types of things Roadmaps are going to cue all of those players into not only the timeline, the timeline is just a portion of that Roadmap, it’s going to tell them how to get there, and how to achieve those things. 

Usually, when you go through Discovery, with SUMO or other agencies, the Roadmap will be a high-level look into how you’re planning on making this overall timeline work for you. It’ll be split into specific documents that touch on the things within that Roadmap itself.

John: How is the Roadmap document prepared and what does it look like? I’m asking that from the point of view of the client, who might get this thing and say, ‘Oh, this is too dense, I can’t go through it’. Do we break it apart in an easily digestible way that people can jump to different parts and understand what’s happening and understand what’s going on? Or is it just a dense document that spells everything out?

Melissa: That’s a good question. Again, it could look different depending on what exactly you’re trying to accomplish. Obviously, if you’re going to a branding agency, a purely creative place, the Roadmap and timeline and the way they measure the success of their deliverables and the success for your RFP, essentially, over time, is going to look very different than if you go to someone like SUMO or an eCommerce consulting agency. So it’s going to be way more dense and technical and word-heavy. However, it can be super visual and linear. It can look like a simple table with dates filled in, it can look something like a Gantt chart, there are a lot of tools, especially in the software world, where they try to avoid Gantt charts sometimes because it’s a little siloed, a Gantt chart.

John: The thing about the Gantt chart is if you miss one milestone, then it spoils the rest of the project. So we don’t we try not to lay it out in those times in a Roadmap, is that what you’re saying?

Melissa: In our Weigh-In it’s just not conducive to the way we’re planning. However, some Roadmaps might look like that because the team you’re working with and your team works that way. You might work with sprints, where that is exactly how you’re thinking and how you’re handling your day-to-day, it’s like two week at a time mindset. If you can’t finish certain things within two weeks, you need to re-approach that at the end of your two weeks and figure out how to not only finish, what might have been missed, or what might have gotten too complex for that due date. Again, a timeline is a timeline. A timeline is just points on a calendar, where you’re trying to fit work in a Roadmap allows you to take that timeline, and understand if you’ve built something realistic here because it’s going to help your team understand how long it takes to get stuff done. And from there, you’re able to actually realistically build a timeline.

John: I know you’ve covered some of this in the first question, but let’s spell this out what exactly are Roadmaps for, besides being a plan for the project. Why else is it important to have a Roadmap as part of your Discovery?

Melissa: Usually, if you’re going with a Discovery, or what we call a Weigh-In, that Roadmap tends to be really this introductory, and MVP, a simplistic version of what’s needed. So it’s this bedrock level plan. That Roadmap is obviously important for getting the project built, getting the site up, and getting the feature out. The reason why is good Roadmap habits. When you do things like build a route Roadmap alongside a specific timeline, especially with stakeholders, and C-levels, who are selling these dates, they’re selling these features and the stakes are high. A lot of people are trying to raise money, they’re going to people with this plan. So Roadmaps themselves are, are super valuable. When you’re going through Discovery or a Weigh-In, and we try to practice really good documentation skills, some best practices in process, having your team members understand where they get involved with the project and the site and the features, what they’re meant to deliver to developers. 

Long term, good Roadmapping makes your sales team better, which makes your marketing team better, which brings in more clients, which helps your project teams, good road mapping is key, especially in eCommerce. If you could plan a few quarters ahead and be three, four quarters out with your planning, think of how much time you’re freeing up strategically. You can really start to build out all these really dense and meaningful specification documents, and fulfill all the dates you set out. So the better and earlier, you can improve your documentation and road mapping skills, the earlier you can stay on top of the way your team makes decisions, how you guys come up with those due dates, and that timeline that leads to your Roadmap in general. That’s always better because it’s going to give you a lot of insight into what exactly needs to be done, not only just to get this thing launched, but to make it successful over time.

John: You made a good point there about talking about a solid Roadmap being useful. It sounds like it’d be useful also in the sales process. Whereas, if you’re trying to look for other investments or other investors, a solid Roadmap lays it all out rather than something that’s just a wish list of hopes and dreams that may or may not happen.

Melissa: And of course, every industry that we work with, it’s a bit different. It has its own nuances. But overall, absolutely, yes.

John: Would you say people have very different approaches to building and developing realistic Roadmaps without a discovery?

Melissa: I think I can always tell when someone has worked with an agency before and has gone through a diligent form of Discovery in one way or another, and when someone has not, I think, again, there’s a really big change happening in the digital industry, ubiquitously, where a lot of people are home. They’re working a lot. So there was a lot of time to think of stuff that you can use to sell or fundraise or things you might be able to do to your existing site or the site you’re cooking up that hasn’t been built. I think it’s really easy to add to timelines and add to Roadmaps and you see a little break, and you’re like, we could do that, we could just stick that thing in there. Some people really lean into that. Their approach is to come to the table with everything we want. We’re going to pack this RFP full of stuff for your timeline. 

That’s one approach to building a road map. Another approach is the absolute opposite, which is, all I need is this functioning product, all I need is this thing to be real and in the ether, and then I plan to iterate or consolidate this timeline. I consolidate this Roadmap and follow up on all these goals and stuff. That’s another approach. People have wildly different methods to building out what they expect and what their team expects, just like they have different methods of internal communication, and the way they measure themselves and their goals. However, at SUMO, we do try to make it consistent, while we’re working with our clients so that they understand what they’re getting from us, what we expect when people are throwing out dates, and what they expect by those dates. We take that very seriously and try to keep it really measured.

John: There are a couple of different types of clients that you’ve just described there. You have one who comes with every hope and dream and wish they’ve ever had, and then you have the other who just wants to do the MVP. They just want to get something launched. Does the MVP client say to you, ‘Alright, we just want to get this built’, and then we’ll come back and do a full Discovery later? Or is it all treated pretty much the same in terms of process? 

Melissa: We definitely have both that come to us. I think it’s a matter of the level of team evolution in that case. We have a lot of clients with really knowledgeable tech staff. Usually, in those teams, you’ll see way more defined goals in the long term, because they’ve been doing this a long time. They know the site, the product, the features really intimately, they’ve built it. So those Roadmaps, those timelines tend to be a little denser. And then on the other end of that, where you have this really simplistic, that’s more of a Weigh-In and a Discovery process where we would be building together, right. So while you have that evolved, Roadmap that’s full of stuff, our effort, there would be to understand the reality of this, it looks like a lot of stuff, let’s break this down, perhaps we re-scope, we understand what’s necessary, what’s not necessary, and we go from there. 

However, on the opposite end, where it’s this bare-bones type of thing. That’s the team that might not have that rich of a tech staff, which is totally fine and valid. They might not have been at this very long. For them, they know what they need, it’s that they need help building this first go have a Roadmap in the first place and to understand what they’re going to be launching with. That’s way more of a building initiative there.

Brittany Blackman: Once we have our Roadmap all settled and set up is Discovery over? 

Melissa: That’s a good question. So for SUMO, once the Weigh-In is over, or when you start the Weigh-In, ironically enough, we give you a Weigh-In Roadmap. We give you what to expect as you go forward. Some of our Weigh-Ins are as long as 10 weeks. When that process is over, and you have this Roadmap for your product site beat or whatever it is, technically, yes. The Weigh-In the Discovery process has ended.

Here at SUMO, we gift that Roadmap along with some other stuff. We record meetings, there are tons of one-off meetings with staff that can last an hour. Again, especially if you’re looking to fundraise or gain money for this thing you’re building, a lot of people take those recordings and they like to build their presentations upon those. So you get to keep that, you get to keep the Roadmap and all this documentation we’ve prepared. The Roadmap then gets turned into all of these items that we’re going to pick up and build this thing for you. But you could take that and take it with your own internal team, build it out yourself. Maybe you had another dev shop in mind. So technically the Weigh-In and Discovery have ended. But that Roadmap should be used in perpetuity, it’s still a valid Roadmap to get you where you need to go. 

John: Any tips for teams that are considering going into Discovery, they’re trying to build a Roadmap – but they’re not quite ready for the Discovery process?

Melissa: I think if your team or your organization is at the point where you’d like to engage with an agency and start some sort of Discovery process, it is best to head in with your own type of internalized Roadmap that goes along with the timeline. I’m sure most teams have some semblance of this like RFP, which is this grouping of needs in bullet point form, essentially. Break out each of your high-level ideas, understand where they fall for you. If you had to rank the level of effort you think it’s going to take for each of these things to get done. Be realistic, how much have you already planned? How much have you already designed and documented? Really figure it out with user flows and diagrams and user types, the more information you can give to an agency heading into Discovery, the better. So if you’re struggling to build like your first kind of go at a Roadmap before you start, really just jot down high-level needs, and think about how exactly, you’re going to be able to accomplish those things. 

Only your team knows the urgency of these things. The agency is only able to help you plan and help you implement, it’s up to you and your organization to intrinsically understand what you’re working with. So the more you can bring to the Discovery, the better. If it feels like it’s a little intimidating to start with this white page, and this idea, visit some sites and products that are just like yours, and what you’re building or what you have, and use their user journeys. Go on the journey with them and plan it out that way. It has to start somewhere. Just start with writing as much writing as you could do in normal writing. 

John: Start with writing, document everything you have. I like to say there’s no such thing as a stupid question.