I have no doubt that you want a great app. That’s goal number one. You also want to meet your delivery deadline. That’s goal number two. If you’re like most of the people I’ve worked with, getting started means whiteboarding out your ideas and then dashing off to start working.
And there it is.
You’ve only just crossed the starting line and you’ve already made the mistake that may prevent you from meeting one or even both of your goals. Sadly, this approach to product dev is not uncommon. But it is doomed.
We think we don’t have time or budget to collaborate and plan properly up front — and of course, then we have to find the hours to redo what we did, or spend twice as much time and money on revisions than we needed to.
You can allocate a reasonable amount of time to being strategic now, or you can jump into execution mode and regret it big time when the bill comes due.
To help you on your way, I’ve laid out the case for planning collaboratively and created a set of guidelines around the common questions about planning that I’m frequently asked.
The Cost of Not Planning 💸
Still skeptical? I hear you. Whatever it is you are trying to do — whether it’s to get a viable product out there, start collecting real data, or even fail fast — taking a moment to plan can feel like it’s putting you into slo-mo.
But in the bigger picture, planning is actually speeding you up. Here are a few things that happen when planning conversations come too late:
If you didn’t give your team the opportunity to gather the information they need to provide accurate estimates, you’ll find yourself working with completely bogus numbers. You can’t force accuracy. Planning collaboratively reduces the variance between your estimates and actuals.
Because you’re not working to a published plan, with a clear purpose shared by the whole team, you often find members of the team chasing shiny objects down rabbit holes and potentially working at odds with one another — all thinking they are on track. Planning means defining what is to be built and what isn’t. Roadmaps prevent creep and bloat.
Tear-down and rebuilds
Because you didn’t plan holistically for features and functionality, you didn’t lay a foundation for expansion or evolution. You run the risk of having to rebuild your product from scratch in order to add anything. Rather than just building on each prior release, you’re going to need to rip and refactor — which is going to inflate the cost for each feature.
I won’t unpack technical debt here because others have done it better, but in a nutshell it’s inefficiency in your code that compounds over time as you make unplanned additions and edits. It’s a cluster. No one wants it, and lack of planning is its biggest cause.
The Benefits of Planning 🤗
The previous section should stress you out. It makes me queasy when I read it, because we’ve all been there. But here’s the good news about what building a roadmap and planning collaboratively can do for you.
Stick to a budget
Your CEO and the members of your board will be really happy when you are able to provide a realistic estimate for the scope of each release. You’ll build their trust and confidence in the team when the scope doesn’t double (or triple or… worse) during the course of product development.
Stay on target
This one is for your product marketers. A roadmap means you can agree on the real purpose of the product up front and then stick to it. When you deliver a product that does what you said it would do, you’re aligning with all the hard work your marketers have done positioning the product for your target audience.
Produce better, cleaner code
Engineering and QA will give a big sigh of relief when planning efforts result in more systematic and organized designs. They can then produce an end product with cleaner code and fewer one-off exceptions.
Your team will always go the extra mile to write great code. But it saps their morale to rewrite existing code just to make up for your misdirections.
Sell the vision
Sales, customer success, and marketing adore roadmaps and they will love you for sharing them. Solid, predictable feature releases allow the rest of your organization to properly prepare for their own work in advance of the launch of new features. Help sales win big deals by foreshadowing a future release rather than burdening them with having to justify why the current release doesn’t align to the promises they made.
Let’s Visualize the Benefit
Let’s look at how this works in the wild (and keep in mind, this doesn’t even take into account the scrambling marketing, sales, and QA/QC teams have to do when changes crop up, which can add even more time and cost to the overall impact.)
Say you have a product team that costs $10,000 per each week-long cycle of dev and design. When we invest in planning up front, we define an approach to producing each feature that builds on prior work and adds efficiency. The process of releasing four features will look like Figure A below.
Figure A – Product development that incorporates planning
Including the planning, we can release the features in nine weeks. Does it feel like we can cut out those two weeks of planning and get the job done in seven weeks? Not so fast.
An unplanned project loses the ability to reliably build upon prior work and decreases efficiency. It slows each new feature down and forces us to revise and refactor prior features. If we slowed down by half a week for each new feature and then had to spend half a week refactoring each prior feature, the process of releasing four features looks a lot less enticing — check out Figure B below.
Figure B – Product development that avoids planning
In this example, launching just four features will take weeks longer and cost 27 percent more. Imagine how this can snowball with more complex software or across different devices! By maintaining a product roadmap that plans for releases two quarters into the future, one recent client of ours has seen a 15 percent savings in their annual cost of design.
Creating a Roadmap that Works
Hopefully the numbers in the example above are enough to
terrify inspire you to invest in your planning process and maintain a shared roadmap for product development. I’m often asked about how to create an effective roadmap that includes design. So let’s talk about best practices and ground rules for what those look like, how to use them, and who to share them with.
What does a good roadmap look like?
Creating and maintaining a roadmap isn’t as intimidating as it might seem. You don’t even need special software. (Though you certainly could go wild in Jira.) But the truth is, a roadmap can be as simple as a shared list or Excel doc. What’s important is that it be:
- A living document that is constantly updated to reflect reality
- Comprehensive and thorough (see below)
- Transparent and available to whole team
- Authoritative, but flexible enough to change when it needs to
- Clear and understandable, for other teams who might need to see it
What should the scope be?
Vague roadmaps with no dates are a useless exercise. But a roadmap that is 100 pages long isn’t practical either. Strike a balance. Here’s what should be included:
- A definition of the bottom line purpose of the product to keep you on point
- Broad plans for at least two quarters of releases
- Highly detailed information for at least the next three or four sprints
- A breakdown of those sprints into discrete details, including features, capabilities, assignments, and dates for when each is planned to come
Who should own it?
If you don’t have someone with the exact title of “dedicated product manager” or “keeper of the holy roadmap” it may not always be obvious who should be the owner of your roadmap. Here are our thoughts:
- Choose a product champion internal to the organization who can dedicate time on a recurring basis to planning.
- Make sure the buck stops with this single owner.
- Even in a flat hierarchy, make sure the owner is empowered to hold everyone accountable.
- Make sure that everyone affected or involved has input up front and at points along the way.
- Keep it updated in a public, accessible place and share it with the broader company.
What and when should a designer contribute to the roadmap?
Whether a designer is internal or external, you shouldn’t leave them out of early planning. This is a collaborative effort. By leaving out a designer you’re ignoring the insights gained from user research and the UX design process.
To put it bluntly, if you’re not interested in creating a roadmap with the input of a designer, you’re not ready to work with a designer.
- They should be involved every step of the way.
- They should offer you big-picture context.
- They should offer impact assessments of small changes on overall design, understanding how all the pieces fit together.
- They should help you prioritize their work based on the technical approach outlined by your engineering team.
How does a designer work differently if they understand a roadmap?
Having this roadmap will make big differences in how you work with your designers. Here are a few key ones:
- We can work modularly and design more pragmatic, reusable components for use across the product.
- We can include hidden features — so you can simply flip the switch on them when you want them — while making the current design still feel intuitive and complete.
- We can design a foundation for future growth rather than a single feature. Planning helps us know whether or not to “tape up the box” in an area of the experience or to leave it open for future additions.
A Note from the President
To sum it all up, I’m turning to a fellow with more credentials than myself.
“Plans are worthless, but planning is everything.”
—President Dwight D. Eisenhower
We’re not going into battle, but our journey will have its fair share of triumpths and pitfalls. Creating a roadmap is not about drafting a rigid, dogmatic plan. It is fluid and iterative, just like your product development.
Even a few days of collaborative planning up front can mean tremendous savings in cost, time, and frustration. Your team can be off working on the next big thing instead of caught in an endless loop of refactoring the same old product.
Do you have tips and tricks about your planning process?
Tweet me at @NonfictionUXUI. I’m all ears.