We've built over 100 apps alongside founders, and we have not seen one single project that didn't change through the course of our partnership.

Change comes from a multitude of places - client feedback, business needs, preferences, etc. Whatever the source, it’s inevitable that your carefully laid plan will change.

Considering the inevitable, the farther you plan every detail of your software product into the future, the less accurate you become (resulting in time and money wasted).

So, how are you supposed to plan when change is inevitable?

The secret to planning for change

Look around the space you’re in. The closer you are to something, the more details you see, right?

The things that are farther away are less clear. You know they’re there because you can still see them, but you lose the nuance of the details.

The same goes for software development. The closer you are to whatever you’re developing, the more details you should have defined. The farther away, the less details you need.

Key elements of your product roadmap

There is a hierarchy of information needed when designing your product.

That hierarchy of information includes your product vision, user outcomes, and product features. You’ll eventually need all this information defined, but when you define it will help you save time and money on over-designing things that will inevitably change.

Product Vision

Your product vision is the unifying narrative that encompasses where you are going and what you want your product to become. This product vision is meant to align your team to the direction your product is going, in the same way your company vision does for all departments.

Your product vision identifies what you want to ultimately achieve with your product. This is a lower-fidelity, big goal we want to keep in the forefront of the decisions we make when building your product. At ThinkNimble, we call your product vision your North Star ⭐️ because it is guiding us through the development process.

User Outcomes

User outcomes are what you need users to accomplish when they interact with your product. For example, “Users can compare X and Y.” Notice, we aren’t focusing on how they accomplish it, just what they need to accomplish.

Features

Features are a unit of functionality within your product. Features will detail how users will achieve their outcomes, and are the smallest unit of design in software development.

Our playbook for staying nimble while building software

We use a product roadmap that helps us get in the weeds on the most pressing objectives, while keeping long-term planning in view.

Using the units of information defined above, we prioritize clarity around each at different stages in the product roadmap.

Your next month of development focuses on features you’ll build

Just as the flowers are in focus in the photo above, whatever is closest to you is clearest in your vision. This is how we think about the next month of development, and how it needs to be clearly detailed out by knowing what features you’ll be developing.

This level of detail should come with timeline expectations and can be held with a tighter grip. The goal at the end of this month is to have something you can show to your stakeholders and get feedback on.

Define user outcomes for 2-3 months out

Your plans for the next few months should be known, but held with a looser grip. Like the trees in the photo above, you can see some detail, but not everything, and those details won't become clear until it's time to walk closer.

Your team should still build with what's next in mind, using user outcomes to stay focused. However, the specific details of those features and functionalities don't need to be laid out until you get closer to developing that portion of your product.

Your product vision guides plans 4+ months away

The mountains in the photo above show little detail, because they're so far away. Similarly, your plans for the future should be in place, but held loosely, saving the details for when you're in closer proximity to implementation.

You should never lose sight of your North Star, but you don’t need to get hung up on features that will matter eventually but aren't relevant to your business right now.

Monthly re-evaluations

Check-in on your North Star each month. This gives you a chance to remind the team why you are focused on what you’re building that month. It also presents the opportunity to tweak your North Star slightly if new wisdom from user testing warrants a minor change in direction.

Part of embracing change is recognizing that your original North Star will probably change. It won't need adjustment overnight, but it will slowly drift over time. By being aware of the changing needs of your business, users, and stakeholders, you can control that shift, not be surprised by it.

Your plan for staying nimble while building software

Change is inevitable in software development. But by understanding the hierarchy of information needed to design a product, and by planning for change at different stages of the product roadmap, you can save time and money, and build a product that is more likely to succeed.

Just remember:

The closer you are to something, the more details you see. The farther away, the less details you need.
When designing your product, focus on your product vision, user outcomes, and product features.
The level of detail you need for each of these elements will vary depending on how far away it is from the present.
Your product roadmap should be flexible and adaptable to change.

By staying nimble, you can plan for change in software development and build a product process that is able to stay agile alongside your changing business needs.

How to plan your product roadmap when change is inevitable