You might have progress totally backward

How much does roadmap scope change?

A few weeks ago, I had a challenging run.

It was hot and humid, and after the sixth mile beeped on my Garmin watch, I walked to a coffee shop to reward myself for showing up. One of my friends tackled me with a hug while I waited on my order. ☕️

“How was your run??” she asked.

“Hard,” I said. “I thought it’d be easier by now.”

As a trained counselor, she stood still and thought for a minute before responding. “I’m not sure progress works like that,” she said. 🤔

How we imagine progress 🏆 #

Most of us (including me) picture progress working something like this: 👇



In the face of everything we’ve attempted before—learning a new language, trying to build a deck (or career)—we imagine that this time, hoo boy, it’ll be straight uphill to glory. 👑

But as my friend pointed out, that isn’t how progress works, is it?

What progress actually looks like 🙇‍♀️ #

In reality, progress for 99.999% of anyone doing anything looks more like this:





There’s an overall positive slope. But it’s punctuated by downturns, u-turns, and roundabouts. It’s more like how reaching a mountain peak often involves losing the trail, finding the trail, sitting down for a breather, and crossing creeks. 🏔

You’re getting somewhere, but goodness knows it doesn’t always feel that way. 😬

What this all has to do with your startup and app #

Building a SaaS startup looks and feels like that second picture of progress.

And while we work hard to minimize downturns and u-turns, building an app isn’t a perfectly linear trajectory either.

That’s something we help our founders plan for. We structure our contracts to account for change, build in 15-30% buffer time, use flexible project management tools, and kick off every project with an in-depth Roadmapping Session. These all smooth out the trajectory.

But one good question our founders ask is:

“Does scope change from the initial roadmap?” 🗺

The answer is yes. Scope does (and should!) change from the initial plan.

On some projects, the scope shifts very little. Maybe we start designing and realize, “oh, in order for the app to work this way, the navigation needs to function differently.” Or maybe we add an animation to make part of the interface more clear. 👏

On other projects, the scope change is more substantial. A founder may discover that, actually, customers are only trying to solve 1 of 2 pain points through the app. So we swap building a now-useless feature for a more valuable one. ✅

Helpful vs. unhelpful scope changes #

However, we don’t make changes willy-nilly. Consider these two types of changes:

Unnecessary and doesn’t add value

This type of change includes 3am feature ideas and “oh, I just realized it’d be nice to have...” add-ons. These extend the project timeline, increase price, and add complexity...without increasing the value of the product. This type of change works against the founder’s goal of getting a loveable product into customer’s hands quickly, so we steer clear of them.

Vs.

Necessary and adds value

This type of change comes from new information we uncover in design and development or insights the founder discovers about customers. These are the animation, navigation, and feature-swap adjustments we described above. They increase the value of the product and can be incorporated without increasing complexity, timeline, or cost. (We stick to our quotes.)

In both cases, we take changes seriously. They’re always a conversation, and we never spring them on clients.

Why some scope change is a very good thing 🙌 #

Even the necessary type of change doesn’t always feel good. Sometimes it feels pretty uncomfortable. Scope changes require candid conversations, adjusting plans, and occasionally reworking what’s in place. But uncomfortable doesn’t mean bad. In this context, uncomfortable is very good.

And we’re not talking “make the best of lemons” kind of good. 🍋They’re really, actually good.

Why? Because every time you uncover a good, data-backed reason to adjust the roadmap, what you’re actually doing is answering important questions and solving key problems.

As we’ve talked about on the blog and in previous newsletters, a lot of early-stage startup development is educated guesswork. 🤷🏼‍♀️You should have some evidence for what you’re doing but, especially before you have a product with consistent paying customers, that evidence isn’t overwhelming:

  • You may know the problem you’re solving exists, but you’re still sussing out whether the way you solve it is valuable.
  • You may have a rough idea who your customers are, but you’re still figuring out where they hang out and how to reach them.

And many other scenarios. But each time you build a clearer picture of what problem you solve, or how you solve it, or who your customers are...you’re making real progress. 🚀

So, if you’re building your own roadmap: 🔨

  • Admit there’s a lot you’re still figuring out and don’t know
  • Build your initial roadmap in a template that’s easy to update, like our Airtable one
  • Recognize the different categories of change
  • Build in a buffer to account for small changes, and try to leave enough space in your budget to account for larger changes if necessary (think of this as a rainy day fund)
  • Revisit your roadmap whenever you make a breakthrough in customer, problem, or niche understanding. Better yet, go ahead and schedule a recurring meeting to review the roadmap once a month.
  • If you need to make changes, don’t get down and out about it—celebrate your progress 🎉

And if you’re working with developers: 🖥

  • Communicate what you’re learning about your problem, niche, and customers to your technical team
  • Schedule frequent conversations so communication lines stay open
  • Recognize the different categories of change and which type helps you meet your goals
  • Keep in mind that some scope change can and should happen
  • Celebrate when you uncover new key facts about your customer, problem, or niche 🎉

And remember, progress will always involve some change. 😉