Changing A Tire On A Moving Car (Or How To Improve Product Roadmaps)

This content originally appeared on Articles on Smashing Magazine — For Web Designers And Developers and was authored by Steven Frieson

Companies can often carry their products into the future with a “feed the machine” mentality. To meet customer demands they continually pack more features into a product only to find that it’s making it more and more complicated over time. In the flurry to keep feeding the demand, they side-step prudent measures to help them assess the impact of the changes they’re making.

The Maintenance Cycle (The Problem)

This can eventually lead to a backlog of customer frustration. Inevitably a company can find itself in a situation where working on anything new has to be balanced by addressing technical debt, or worse yet, any improvement they want to make is done in a “bolt-on” fashion adding debt on top of debt. I attribute this to a wide variety of reactionary cultural phenomena.

I liken it to a flat tire on your automobile. For those of us that are experienced or knowledgeable in this area (says the guy who used to be a tow truck driver in a previous life), if you have a puncture on the flat wall of the tire there’s a good chance you can plug or patch it. If it’s on the sidewall of the tire you’re going to need to replace the tire.

So say, for example, a troublesome area of your product is a gash in the sidewall of your tire. If you don’t address it quickly your product (your car… the vehicle that makes the company go) will come to a screeching halt. You’ll need to pull over, stop the car, and get it fixed. Yes, this will mean downtime, and downtime equals lost revenue. Rarely is this the case, but it can happen. Especially if your technology stack has just been hacked and set up for ransom. In that case, you just lost all four wheels and will need to wait for the tow truck.

Or let’s say that you’ve been getting numerous complaints regarding your onboarding/setup process for your product. The car continues to be operational and drive well, but the barrier to adoption is potentially equivalent to a slow leak on your flat wall. Pesky nails! Or maybe, you’ve left this area of your product to carry on without regular maintenance or pruning. You could also compare it to wearing your tire treads down until they’re bald. Again, the car is still operational, but you’re running on borrowed time. It’s only a matter of time before you have a blowout, or worse, you have an accident.

No matter your analogy, these companies can find themselves in situations where they have to keep the product going but recognize that functional and fundamental changes need to be made.

Landscapes, Not Roadmaps

If your product is the car that makes your company go, then typically you would have a roadmap that tells your car where it’s going. It may not detail how it’s going to get there but at least it’s a flattened view of the roads, intersections, and turns that will be needed in the coming future. This might be fine for a sunny afternoon cruise but it assumes many things.

For example, what if there’s construction (technical debt)? How will we reroute without it costing more time? What if we reach our destination way too early because we forgot to pick up some items for the soiree and now there’s no time to backtrack?

From my perspective, roadmaps are generally treated as a series of checkboxes.

“We did that... check!

Then we did this... check!

Now... we’ll do that thing.”

We check the boxes and forget that generally speaking some things got left behind from the desired work. Sometimes an important detail didn’t make it into scope, but we checked the box and moved on. It’s sort of like getting all the lug nuts on your wheel, but we left one a little loose.

“Sorry about that... you should be fine. If you run into a problem, let us know.”

Again… reactionary.

The problem with this approach is that the damage is done. The damage in the relationship between you and your customers is far more important than the lug nut you failed to get on properly for the 1–2pts of work it would have been to ship it a little later.

I have often found that companies do rough estimates for epics and plot those on a roadmap by time duration from the rough estimates. When the work is ready to begin they go through an epic batching process to determine the more realistic scope of the work and what’s a feasible solution within the timeframe defined by the rough estimates. It sounds reasonable, but often the details have been vague until batching. When the details bubble to the surface it turns a desirable solution into something much less which can lead to a watered-down MVP.

Worse yet, once the work is batched they insert user research that should have been done to inform the original work effort to what the real benchmark (MVP) should be. Some companies may insert a design/research spike just before the epic kicks off but it always feels reactionary and ends up being a hack shortcut. It’s like defining how you want the road to look without recognizing the terrain where the road will be built.

If you happen to be one of those companies that do “big-bang-jam-it-in-more feature” releases you may have a mountain/swamp (debt) to contend with. This approach usually assumes that since there’s a deadline you have to meet it and therefore cannot fail.

Anything that does not fit into the deadline then gets added to the backlog which further bloats the backlog and competes with new features to be worked on, i.e. the next part of the road map. Over time, as you can imagine, the wheels on the cart are getting a little wobbly and shaky. If you speed up, you’ll likely through off your car’s alignment and loosen up some other critical parts.

A company will struggle to find time to pull over and fix the wheel because their customers are depending upon them to keep the car moving.

Don’t get me wrong, roadmaps are helpful but they can be rife with barriers toward real change to your product vision.

I’d like to propose an alternative to this approach, or at least a way to change the way we look at it. An approach that Kevin Capel writes about in ‘Ditching Your Roadmap For A Product Landscape’. Roadmaps are good as long as the landscape is relatively clear of any major obstacles. However, if you’ve been feeding the machine and just getting by on those tires that have long outlived their tread life you might need to evaluate some things before you define where the road will be laid on the landscape.

We first may want to assess the landscape. Having some sort of product or “platform radar” is a great way of assessing and tracking the state of the product/platform from a 10,000-foot view.

This, in turn, helps us determine whether our tires are up for the journey or we need to be prepared to repair them or swap them out along the way. Rarely will a roadmap tell you when your tire is flat, nor the best time to fix it. If you knew the landscape you could better identify the best timing. The landscape can also be a huge help for assessing other/related opportunities to meet customer needs rather than always focusing on more features.

Where a roadmap looks at rough estimated blocks of work that are vague in detail, a landscape sees work effort from a frame of “strategic areas for improvement”. These areas are defined by strategic product vision goals, known as customer pains (that generally keep getting skipped due to backlog bloat), or internal input from multiple points of data. These areas are “identified” and not so much defined.

The areas for improvement need to be analyzed, researched, and assessed before they can truly be defined. You may come to find that these areas are very large efforts to fix (massive boulders or expansive swamp). You may find them to be easy wins which you can clearly define their value and scope.

In essence, the radar is helping you assess the landscape in a proactive way to determine the landmarks that support the direction of the roadmap. Because these areas are not “on” a roadmap, they provide you more flexibility to adjust their value and scope as the market changes or your company’s needs change. You’re essentially scanning the landscape, using lidar, to assess the path forward and where to best build the road to prepare your car for the trip.

Maybe you need to repair some potholes. Maybe you might want to pack a second spare tire. Maybe you might need to be prepared to take a detour. It fundamentally helps you plan ahead to reduce risk and reach the destination in a more efficient and effective way.

Assemble A Crew

For the strategic areas for improvement, you should define some order of priority. To help determine the priorities you can look to your company’s strategic plan, customer requests, and/or customer complaints. You don’t get this from any one area of your company so this is where you pull together a pit crew. I’m not referring to people who will actually fix/repair these areas for improvement, but rather inform and guide the process toward sound outcomes.

Some roles to consider: UX designer, UX Researcher, Product Managers, Product Owners, Support Representatives, Architects, and Engineers. You’re trying to cover your bases from the 360 degrees of the customer by finding trusted patterns in these areas and building relationships toward quality outcomes, continuous improvement, and sustainable growth.

This crew, or group of trusted advisors, can help you in a number of ways. Because this discovery work is sort of “off the radar” by being on your radar there’s low visibility to it and so probably not funded with full staffing. Your pit crew should be available for quick, pointed input. You don’t need meetings necessarily but more of a soundboard to bounce thoughts/ideas of a specialist for specifically targeted input.

Maybe you’re considering a solution that you want to run an A/B test for; you might want to bounce it off support to gauge their reaction and identify any missing factors in the design. They may identify a detail you overlooked in your solution. Maybe you’re looking to update a portal but are aware of potentially troublesome tech/plumbing you’ll need to navigate around? You might want to pull in an architect or engineer for that area to provide some guidance. The members of the crew can vary by role and frequency.

One major advantage of having a crew of this type is that you can have a shared strategy and work together toward a “north star” that meets internal and external needs — through ideation, analysis and collaboration.

You’re getting out ahead of the roadmap, connecting the dots. You’re building cases (work bundles) for areas of improvement that can be split up or batched together depending on availability. These are guerrilla tactics and lean methods that are cross-cutting the big picture. Who doesn’t like to be a part of something new or visionary?

I’ve generally seen this take two fundamental approaches. In a smaller company, our crew and approach were smaller, more lean, nimble, and organic. It was bottom-up, but we had key stakeholders at higher levels. In a larger company, we developed a charter and defined the key stakeholders, responsible individuals (RACI) as well as milestones, scope, governance, and so on.

I’ve also worked in a blend of the two approaches. It depends on your company’s situation, drive, culture, and attitude. Otherwise, you can just continue the status-quo and pray that things change by themselves... which they rarely do. Like a real-life pit crew, your crew is standing by (available when time permits) to provide some direction on logistics, fuel you up, or quickly adjust that wheel that’s been giving you some trouble. When that tire is slowing you down on the track, then you need a plan for getting it changed to get back on the track to improve your chances of winning.

One Lug Nut At A Time

So, now we need to put it into practice. We’ve sized up the terrain that’s ahead and have a pretty good idea of what our strategic areas for improvement and growth are. We have a pretty good lay of the land and have plotted a rough course for where the road (roadmap) “could” go.

Before we go further, I recognize that some would argue that in the spirit of “lean” or “agile” we should not be spending so much time analyzing things as opposed to releasing, experimenting, learning, and improving. I don’t disagree with that, and I’m not trying to be at odds with that. That being said, you can be lean and agile in different ways without following a prescribed formula that may not work for every situation or company. I am still proposing to apply lean methods and guerrilla tactics in an agile manner.

Many companies have things they want to improve on even if they have a backlog of new features/things to do. What I am proposing is another way of looking at both: improvements that you want/need to be made as well as the new strategic features you want to build.

Even tech debt is a strategic area of improvement because if you don’t address it, it will slow your car down or cause it to break down altogether. If you’ve been neglecting your product for a while with regular maintenance the roadmap won’t save you unless you plan on regular maintenance.

Many companies don’t and when they assume maintenance in some of the workstreams it may get overshadowed by new work or cut from the scope in order to get the new work completed on time. I’m proposing an incremental way toward pruning and improving your product (design and tech) so that over time the maintenance is being done; chipping away at the whole little by little.

As you assess the areas for improvement you should assess size, effort and complexity:

Can the work be broken into smaller pieces?
Can the pieces be pulled into existing workstreams?
Does this need to be one comprehensive block of work on the roadmap?
Can you lay the groundwork for future work by making small front-end improvements (CSS, HTML) or design tweaks in preparation for future additions (scale)?

We need to get the tools in place and be prepared to take off a lug nut until we get to a state that we’re ready for that quick tire swap. Another way to look at it is from a broad and cohesive user experience approach and the different levels you can approach fixing a broken user experience.

Let’s take a look at some examples of how this has been put into practice.

Building A Crew

In a smaller company where I worked, it had far fewer departmental silos than larger companies have, but it did have physical silos. Engineering was on one floor and Product and UX was on another floor. I believe the physical distancing contributed to reduced teamwork and collaboration needed to drive growth improvements.

For this company, because of the team separation, we needed to assemble a crew of key stakeholders and collaborators first. Part of that effort included leaving my personal space and sitting, physically sitting, near those I wanted to engage and partner with. I also connected with key stakeholders across the organization and began to build partnerships that we could all benefit from.

In parallel, we were working towards a radar. The groundwork had been laid to build upon, but I had moved on to another company. In a very short amount of time, we were able to stabilize the wheels and establish a design system that would be a foundation for future growth.

Landscapes And Lugnuts

For a much larger company where I worked, we were working on a massive undertaking to unify 200+ systems into one comprehensive platform. Because this was a high-profile project, it had a fully funded crew that was needed. The project struggled with establishing and maintaining a clear roadmap but that didn’t prevent us from assessing the landscape and working toward the vision.

Another landscape plus over a roadmap; more flexibility. For this project, we had a dedicated team that defined and built out the core infrastructure and global components. As we began to design and build individual modules in the system and new user scenarios came to light we needed some of our UI components to be extended to improve the efficiency of workflows.

Fortunately, we anticipated some of this with the design system we established so we had a game plan we could leverage. In some cases, we built new components to fill the need with the forward focus that we’d reuse them. In other cases, we allowed a “good-enough” solution to move forward and back-logged an item to uplift the component with the enhancements.

Over time, we were able to fit in the component enhancements and they were released to teams with little to no retrofitting. This allowed us to continue to make incremental gains and not sacrifice the big picture vision. It is important to note that each piece was carefully planned and crafted with a vision toward the whole. It took a lot of teamwork, patience, and coordination but it all paid off in the long run.

For another company I worked for, we were able to put all the pieces of the strategy together. I worked very closely with the Director of Platform. She had great foresight and vision to see the landscape and know where the strategic land markers were that we needed to address. We called it the “Platform Radar”. We mapped out the landscape and would reevaluate periodically to help us stay focused on the priorities and recalibrate the scope as we learned more.

This was also helpful for us to prepare work to be added to the roadmap. Together we forged internal partnerships to connect people and build out a pit crew. We all had a common goal for our customers as well as departmental goals through which we could support each other. Between the Platform Radar and pit crew, we would analyze the strategic opportunities and work with pit crew members to connect dots and build cases to better understand and scope the work that was needed.

Some work was just too large and complicated and required bigger discussions on how to tackle them. Other work was medium to small in size and was easy enough to just schedule it and in some cases slip it into upcoming workstreams. This company had a lot of debt to address from past years and finding creative ways to build strong cases in making large gains or small solutions for minimal gains was all part of the large strategic plan.

Conclusion

Companies with products that have been around for a while typically have some baggage. They have to continually work to improve and enhance the product to keep up with customer demand and their competitors. Over time, they leave behind artifacts/blemishes and feature dust that leave a ripple effect that will eventually need to be dealt with.

Having a loose product landscape offers a flexible way to be strategic and decisive about how to chip away at the big picture. Not dealing with can eventually leave you stranded on the roadside without a spare to keep you going. It is far better to maintain, tune, and prepare for when the time comes for that quick tire change.

A landscape is there to support your roadmap by helping you see ahead for the plan you want to make.

Just to be clear, I am not advocating you throw out your roadmap, but for the landscape to be effective, you do need to be strategic, patient, and vigilant. Always on the lookout for opportunities to hone, replace, and prune the inefficiencies. Internal partnerships, research, design systems, and regular touch bases can help make sure that your trip is a successful one.

Building A Crew

Landscapes And Lugnuts

Further Reading

Related Posts