Robert: In this episode of The Stretch Goals Podcast, Scott and I are going to be talking about defining your product roadmap. This is The Stretch Goals Podcast, where each week, we’ll share insights and lessons learned, based on our experiences as entrepreneurs. We’ll challenge you to create ambitious goals as you start and grow your business. I’m your host, Robert Dickerson.

Scott: And I’m Scott Davis.

Robert: Scott, I haven’t talked to you in a while, it feels like. You’ve been in Australia, living it up.

Scott: Yeah, man. Yep, I’m a world traveler.

Robert: I want to talk today about defining your product roadmap. What types of features you’re building for your products, how to figure out what’s most important to your customers. I’ve been thinking a lot about and reading a lot about getting your customers involved in the definition of your product roadmap.

I wanted to talk about that a little bit as well that when you’re figuring out the features that you want and kind of prioritizing those features, it’s really important to get the customer involved, so I wanted to talk about that a little bit as well.

Scott: Yeah, absolutely. One thing I want to talk about, too, is how scope creep, and maybe the Agile process can help with some of the definitions of the product roadmap, and how that whole workflow and process works.

Robert: I know with Mapout, I have an idea of features, and different things I want to build out on the product. I’ve kind of internally mapped that stuff out, but it’s still hard to prioritize those things in day-to-day working, right?

You sit down to do some work and you’re like, “What am I going to work on today?”, right? You got this huge list of things in your backlog, of features and stuff. How do you really prioritize those?

One way I try to do it is look at my current customers and customers that I’m talking to, and figure out what features do I need to build to meet that specific customer requirement, to get them on as a customer? Maybe if I don’t have a feature, or maybe I need to improve a feature. How do you go about thinking that, when you’re just thinking about, “How do I start out from this huge set of features? Which ones do I choose to move forward with?”

Scott: Yeah, well first of all, let me comment on what you’re doing. Your roadmap is more-or-less, well, the adjustments you’re making to the roadmap are based on potential sales or customer feedback. I think there’s many different ways to look at the roadmap and how you want to adjust it. It depends on where you are with your business and maybe what your products are.

Like if you’ve got a product you’ve created, like Instagram, per se, for instance, you’ve got millions and millions of users. What’s the next feature that’s going to keep engagement up, drive additional revenues, things like that? Whereas, in your scenario, you’re trying to acquire customers or make existing customers happy, but each customer’s different, right? Each feature you have to weigh against various factors.

There’s always different things to look at when you’re talking about your roadmap. For me, I’m a Certified Scrum Master, so I have a lot of process in my background where I try to keep the workflow and the processes clean as possible. Part of that is understanding that every idea that you may have, every bug, every feature, every thought really just needs to be dumped into your backlog or your roadmap to do items, right?

It doesn’t necessarily mean that they get prioritized and brought in to what you’re working on. That goes to what you’re asking, which is how do you prioritize that? You need to have a process. You need to set some time every couple of weeks to go through and look at everything that you’ve got and re-prioritize based on various factors.

That could be something that’s a new feature that maybe you talked about recently with a customer or something you learned at a conference or something that an existing customer wants or you need to meet for contractual reasons.

At any given time, those priorities will change. It may be priority five on the list this week, but it might be priority one next week. It’s an evolutionary process. It’s going to change constantly, but you need to set aside time to look at it and prioritize accordingly.

Robert: Yeah. I think one point you brought up, which I really liked is it really depends on the stage of your product and the stage of your business as to how you prioritize this stuff. If you’re just starting out, you don’t have a product yet, you maybe have a MVP. Those core features are going to be a lot different, then say if you already have a product and you’re just kind of iterating, trying to get new customers or trying to get a feature set out there that’ll attract new customers.

For myself, it’s really … I try to build features that are focused on customers but also have my own internal ideas of what I think are features that people will want. Sometimes, that’s a good thing. Sometimes, that’s a bad thing, right, because you kind of take your eye just off the customer focus. For myself, I have to be really careful that I don’t go down into a rat hole of a feature that maybe I’m interested in, but really doesn’t pull any new customers in, right? It doesn’t really have a total impact on the product that I’m designing.

I’ve found that over time, you really have to be cut throat in figuring out what features you’re going to go after because while a feature might seem, “Oh, it’s really simple. It’s really easy.” When you start getting down into the details of it, there’s a lot of nuances, a lot of other things that come up that you have to invest time to development, time to educate your customer. There’s a whole kind of workflow that you need to go through to push these things out.

A simple feature can become this big thing, right? If we’re talking about software products, every new line of code you write, you’re going to introduce new bugs and other things into the code that you’re going to have to fix and keep up-to-date and that sort of thing.

Scott: Yeah. I think probably most of our listeners are just most people who are in the startup space, their roadmap sort of ends at MVP. You know what I mean? Like, that’s the reality, right? They get to MVP, they prove a concept, and they either pivot or they move onto something else.

Robert: The problem is, that’s when it just begins.

Scott: Right. You’re absolutely right, but you also have to understand that there’s only a finite amount of work that can be done in a certain amount of time. That depends on the number of resources you have, but just also being realistic. I mean, you and I are senior engineers. We can develop features significantly faster but when we do things faster, there are some trade-offs, you know, in terms of quality and things like that.

The problem is, is that in non-software engineer’s minds, adding features is very easy when, in fact, in a lot of cases, it’s not, right? We also have to communicate when we’re talking about the roadmap, the expectations to those who are involved external to the software side and let them know that, “Hey, these features you’re asking for, they’re going to take time.”

We have to adjust based on our current priorities given the amount of time we have to achieve based on milestones. When you’ve got these milestones or software releases, they also impact the roadmap and how it’s constructed and what’s prioritized.

Robert: I think maybe a first thing to think about is you mentioned like sitting down and thinking about what features that you want to develop. I think it’s a good idea to list those features whether you just write them out in a word document. I use Trello to kind of organize things so I can move stuff around. I also use JIRA for bug tracking, bug management. You can do those with Feature as well.

Sometimes I write down features, I’ll kind of write a user story. That kind of feeds into the ADRO process of how is this actually going to be used. I can kind of flesh out some of the high level details of what pieces are needed that I don’t have. How really big is this feature that I want to add?

After you’ve listed those features, maybe the next thing is to take it out to customers and get their feedback on it and try to prioritize those features, both internally with the resources that you have and also with customers. How do you go about capturing different ideas and things like that as you have them?

Scott: Yeah. I mean, I use a lot of different tools. I’m not a fan of Trello, but I will use it. I’m not a fan of Asana, but I will use it. There’s aspects of JIRA that I hate, but I actually use it the most frequently, but I also really, really, really like ZenHub, which is a Google Chrome plug-in. It sits on top of GitHub.

It basically puts swim lanes and burn-down charts and things like that on top of your GitHub issues. It adds like a layer of intuitiveness to something that was very basic on the GitHub front. All of those tools again, they’re designed to allow you to put all of your stuff in one place, all of your ideas, all your features, all your bugs.

Then, you still have to manually prioritize those, right, and determine how you’re going to do it. Some of these tools, ZenHub, JIRA, even Asana, and Trello, you can create these little buckets where you call that a release. You can plan your releases ahead of time, right? Maybe you’ve got …

There’s a concept of a sprint. A sprint is just a duration of time. One week, two weeks, four weeks, something like that. Each of these sprints is basically a release. The goal of Agile and the roadmap really is to have features that can be demonstrable over time, right? You create these releases that are planned.

This week, next week, the week after. Here’s little features that we hope to get done. Those will change over time as well, but the goal is, just dump them in one place and then, over time, review them, and create your release schedule and then work on them.

Robert: You’ve listed your features, first step.

Scott: Mm-hmm (affirmative).

Robert: You start prioritizing your features by working with your customers to figure out what features will maybe get you more sales or what features your customer is most interested in internally. Which features do you think will push your product forward?

As you prioritize those features, you look at how much is it going to cost to complete? What sort of resources that you’re going to need? What’s the time to complete and maybe go through and sketch out what it’s actually going to look like, the feature in its entirety so you can kind of gauge those things.

Now, you kind of have this list of features. You prioritize those features. Now, you start. Right? You start working on the features. You start developing them. You put some sort of time constraint on how much time.

Now, I want to talk about the scope creep because you mentioned that to start. Inevitably, you start working on a feature and it changes, right? You get into it. You start saying, “Well, if we had this-and-this, it’d be a lot better, right?” Talk a little bit about that and how maybe you can avoid some of those things to kind of make sure that you get the feature done and you’re not just … You keep on building-and-building-and-building.

Scott: Yeah. I don’t think you can ever truly get rid of scope creep, unfortunately. That also applies not to software. I mean, it can be anything. You know, building a house. You change the requirements of the type of marble you want to use on your floors, you know? It changes the scope creep or changes the scope.

The best ways to minimize scope creep is to really, especially if you’re like doing a contract for somebody, right, you have a very specified statement of work, which has these user stories, which have very specific features. You get the customer to agree to it, right? Then, any new feature they add is outside of that scope. It’s additional work and they need to understand that.

Or, the trade-off is, “Okay, I can do this, but this other feature, feature number 23, that one can’t be done because it’s the same level of effort in terms of time.” If you’re just working with a software team or you’ve got your own business and you’ve got a team that you’re building a product for, the keys to avoiding scope creep are just agreeing on what would be worked on within your duration of work.

If you’re doing scrum or Agile and you’ve got a sprint, you say, “This two weeks, we’re working on these features, nothing else.” If a new priority from your stakeholders comes in, let’s say your CEO’s like, “No, we need this new feature. It needs to be done now.” You bring that in, but you take something out.

You can’t keep the original scope as it was and add new features because over time, you will kill your workforce because you’re requiring them to work additional hours and increasing the stress levels. It’s a trade-off.

You have a level of effort for all the tasks and if something new comes in, that level of effort needs to be adjusted to be exactly the same. Bring in this new task with a level of effort of X, and take out something that’s equal to it, so that you can keep that balance the same.

Robert: Yeah, I mean I feel like what I try to do is cut down the features instead of the cost, right? Instead of saying, “Well, let’s just reduce the cost it was going to take to build this feature,” because you probably already have in mind what it’s going to cost you when you start out. Most likely, it’s going to cost you more than what you thought.

Instead of saying, “Well, I’ll do it for cheaper.” Say, like you were saying, “Let’s cut out X, Y and Z feature so we can ship it,” because that’s really the goal, right? The goal is to get this feature out as quickly as possible because most likely what you built is not going to be exactly right.

Scott: Yeah.

Robert: You’re going to have to tweak it, right. There’s going to be this refinement process and this feedback loop where you’re going to go in and you’re going to refine it and you’re going to tweak it. If you spend a bunch of time internally developing this feature without getting it out there, inevitably, when you release it, there’s going to be something that you need to change.

The longer you take to build something, you know, possibly the more off-based you’re going to be from what your customers actually want.

Scott: Let’s be honest about scope creep. Scope creep generally occurs for a couple of reasons. Number one, the feature, or the request, or the bug, hasn’t really been well-defined. They could say, “I want a button that sends something to Twitter.” Okay, cool. Sounds easy. I want to make a button that’s going to send something to Twitter. You start to work on it. Then, you’re like, “Well, wait. What are we sending to Twitter?”

Are we sending an image? Is it just text? Now, you’ve got to wait for the customer to give you feedback and tell you what they want to share. Then, you’re like, “Okay, cool.” Then, you do it. You’ve already added a little bit of time because you’ve had this pivot on the idea of how it’s going to work.

Now, you build it and you give it to the customer and they test it. The customer goes, “No. I didn’t want it to look like that. Oh, and by the way, you didn’t put this hashtag on there.” Guess what? That’s scope creep. Because, it wasn’t defined initially, you hadn’t protected yourself. Now, you’ve already to go a feature for a specific cost in a specific amount of time that now is taking longer.

That’s all on you as the person providing that service to make sure to protect yourself because scope creep will and always does happen. The customer will always want something different then what they originally requested because they haven’t seen it. Even if you have designs, the designs may not feel right. Or, maybe you misinterpreted a task, but you’re always going to add a little fudge factor on there.

I think industry standard used to be like 33%. Add 33% to whatever you’re telling them. I think it’s comes down a little bit. I just recently heard 25%, but it used to be 33%. Always add 33%, protects yourself and allows you to deliver on time.

Robert: Yeah, I know with myself just doing designs and things like that for MapOut, once they were built, I’d start working through them and say, “Well, this isn’t exactly what I wanted.”, right? It looked good on paper, but when you start building it, things don’t actually look right. You have to tweak it.

It’s figuring out, “How much time do I really want to spend?” Really being cut throat about saying, “Well, maybe it’s not perfect, but we need to get this out there?” Right? Where can we maybe cut some corners to get to ship this as quickly as we can so that people can look at it.

Scott: You know, the other thing too, is anytime you’re talking about, especially like mobile or even web, when you do a design or you have a designer work on it, it looks one way on paper, it looks another way on your screen. It looks another way when it’s actually in the device or in a web browser. You always have to keep those things in mind. They will never be exactly the same.

That’s why you have to prototype ideally. If you have the time and you have the budget, you need to prototype. Get it on a device, look at it, maybe you put it in Vision or something like and actually click on it. Make sure the UX feels right because it’s going to save yourself some time down the line. A lot of people don’t see that.

They see the sticker shock of what it cost, what the cost is going to be, to do those prototyping routines, but the fact of the matter is, they’re going to save a ton of time later in the development side because you’ve already gone, “Yes, I like this. It feels good. It looks good. Let’s proceed.”

Robert: Another thing I wanted to talk about is that a lot of times when you’re developing maybe your initial product, you’re thinking of … You know, I’ve talked to people that are just starting out developing things. They think that that initial product is the end goal, right? When I build this thing, it’s done, right? I can launch it. I can ship it. People are going to start paying me, but really when you’re building products, it’s an evolution, right?

Your product is always an ongoing development process where your products always getting better, it’s always being built, and really it’s a long game, right? It’s never done. You’re always building features. You’re always adding onto it. There’s always going to be another idea in the back of your mind of something to build.

You have to think about that as you’re prioritizing things is that I want to build this for the long term. I want to start getting people using the product or I want to start improving the product to get more customers. It’s always going to be evolving. It’s a never end game.

As an entrepreneur, if you’re just starting out your business, sometimes with a limited budget, that can be difficult to figure out. Say, if you burn through all your cash to build the product for the first phase and then you don’t have any money to like keep it going, right, and to iterate and develop on it, that can be really tough.

Scott: Absolutely. I think what you said is true for any number of products. Software, to anything really, an advertising campaign, anything. I think the thing is, is that when it comes to software development, like what you do and what I do is very different. Like you’re building products to be sold to companies and I’m building products to be consumed by users.

You’re more services-oriented and I’m more product-oriented, meaning I want to build a product and I want it to be something that’s out there. Then, I build features on top of that and make people happy. You’re doing more of the, I want to create a service that is a product, but my service is making the product better for you.

It’s two different mindsets but what you said applies to both. You know, scope creep and features and roadmaps, it applies to every single type of product in the world. Building a car, building software, building anything.

Robert: Over time, you’ll get better at kind of figuring out, prioritizing things and figuring out how long things are going to take, but when you start out, everybody has these grandiose ideas of what they want to build. I’ve talked to people that are just starting out that ask me their opinions on their products and things like that.

They have this huge idea, right? It’s going to take years. It’s going to take tens to hundreds of thousands of dollars to build. You just have to say, “Well, this is what it’s going to take to build that. Is that really what you want? Can we build something simpler to get it out there quickly so that you can figure out if this makes sense or not?”

Scott: I do that a lot. I mean, really talking to founders or even corporations and saying, “Look, is this really what you want?” Like you just said, “Let’s trim this down. Let’s prove this idea first.” I think what’s happening right now, the MVP term has been just brutalized and maimed over the years. It’s no longer what the true point of an MVP was.

Now, MVP is have a launched polished product and that’s your MVP, but the whole point of MVP was to like create these very basic set of principles that you could prove or disprove your idea and then make adjustments accordingly. When you start talking with startups, you really have to get them to pare their ideas down because they’re passionate. They’ll throw every idea that they possibly can into this thing.

You’re like, “Okay, that’s six months of work. Not one month.” “Wait! What do you mean?” “Well, you just threw 48 new ideas onto the table.” I mean, that’s the reality, right? The MVP is meant to be very small. We talked about this and perfection versus launching in one of our other episodes. I mean, it’s a constant struggle and you really just have to pare down your ideas and your thoughts.

Robert: Well, I mean, you want to pitch your big ideas, right? You want to show your vision to people. I mean, that’s what entrepreneurship is about. You’re always talking to people pitching your idea. You want to make it sound like it’s a big idea, that it’s an impactful idea, but then you have to build on that idea so then you have to pare stuff way down so that it can be difficult to talk one way and then focus as you’re building another way.

I think the other area I was thinking about too is that when you’re comparing yourself to existing products on the market, because a lot of us are working in spaces where there’s already established players, right?

Scott: Yeah.

Robert: We’re trying to find our niche. You know, if you’re like in a CRM or something, you go look at SalesForce. You go look at HubSpot. You see all this long list of features and you think, “Well, how am I going to compete with that? I have to build all those features too.”

It’s really about finding your niche and then focusing on the features that you need to be successful within that niche as opposed to competing head-for-head because you’re never going to be able to develop all those features …

Scott: Mm-hmm (affirmative).

Robert: … just starting out, right?

Scott: Yeah. It comes to differentiation. Making yourself … which features are going to make you look better. I think the thing is, people look at their roadmap and say, “Yeah, I’ve got all these features, but I don’t need them all at once.” If you instead prioritize the ones that are most important, most impactful, either to your users or to your revenue stream or whatever that may be, get those done first. Then, you can iterate over time.

If you’ve built your product right and identified your target audience, you’re going to have this product for a while. There’s nothing wrong with introducing features over time. You don’t have to do them all at once. Really, that’s what it comes down to. Ask yourself that question. “Do I need this today?” That will help you prioritize your roadmap.

Robert: How do you collect ideas from your users? Like let’s say, you have an app. I know you work on a lot of different apps. Once you launch the apps, I mean, how do you get feedback from those users to kind of prioritize some of the features for some of the apps that you’ve had out there for a while and they’re doing well?

Scott: Yeah. I mean, we could probably do a whole episode on that. I mean, there’s different ways, but I mean, the easiest is like submit like a little Typeform or SurveyMonkey or something. Like, “Hey, guys, if you want to make this part better, let me get your feedback.”

If you make it feel like they’re helping or they’re part of the community and the process and the app, they’re more likely to be engaged and participate versus just some random blank email or push notification that came with no context.

Again, incentivize them and they’ll give you your feedback, but really the hardest thing is, that if you’ve got a community of 100,000 people on an app, they all want different things. If you put a poll out there, your results are not going to be what you expect because everyone wants something different, you know? It’s hard to weigh user feedback when you’ve got a lot of users.

If you’re developing products for companies and you’ve only got ten companies, it’s a lot easier, but you’re still going to find with those ten companies that there’s a difference of opinion. Really, just gathering them. You put them in a spreadsheet. You can use Typeform or SurveyMonkey or any tool. I mean, there’s so many of them out there.

Use those tools. Save yourself some time. Look at the feedback and maybe assign a weight to it. Determine what’s most important.

Robert: Yeah. I found that customer feedback is really helpful because sometimes in my mind, I think things should work a certain way. Then, when other people use it and they give me their feedback of, “Hey, this didn’t make sense.” Or, “I was expecting to use it this way.”

That light bulb goes on to say, “Wow! This is how they want to use it.” This is how they are going to be using it so we need to build a product in that manner so that it helps them with what they’re trying to do as opposed to what I think is the right solution.

A lot of times maybe my ideas or my team’s ideas are a starting point but then we kind of let it evolve and let the customers kind of have their input as well to drive where we’re going to end up.

Scott: Yeah. I agree. I think that’s the best way to do it. Every organization is different. Don’t take anything you read or anything we said. Make sure that it fits your style but the ultimate goal is that you need to look at your roadmap to figure out what’s important now, what’s important tomorrow, what’s important down the line and adjust your current implementation priorities to line up with that.

Robert: Yeah, so I think that’s a good place to wrap it up. I mean, I think you said it well. I think about what stage of your product you are at, what stage of your business, if you’re just getting started, if you’ve got it out there.

Try to go through and list the features out that you’re interested in doing, spend some time thinking about that. Prioritize those features, both internally based on cost, time to complete, get customer feedback and incorporate that in.

Then, really try to define your scope and figure out those trade-offs are you’re building it. Whether you should make this change or whether you should kind of adjust your requirements, adjust your feature set down to kind of keep it with on budget.

You can have big ideas, as we were talking about, but try to fit what you’re doing within those big ideas and maybe pare it down just a little bit so that you can get stuff out there because that’s the whole point, right? We all want to ship features. We want to ship our products and get people using them.

Scott: That’s right. Let’s go build stuff.

Robert: Yeah. Fired up. See you next week. Thanks for listening to this episode of The Stretch Goals Podcast. You can access the show notes for this episode and listen to other episodes by heading over to stretchgoals.fm.