How to Change a Tire on a Moving Car

Scott Himmer at UXDX Community: USA East. Video: https://youtu.be/N00f4B5I9bM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Is your product showing these symptoms?

[00:00:00] Hello everyone from around the world, I want to thank you for joining me today. I'd like to begin this talk with a problem that I've experienced too many times, and I think that you might be able to relate to it, and I'm going to start with a few questions. So first off, is your product, that is the car that makes your company go, is it experiencing these symptoms? Is it slow or sluggish, not performance wise, but in delivering value to customers, where improving the quality seems like you're moving mountains? Have the seams or the parts on the panels become worn out, and gaps are becoming more apparent? Does it feel like your product is becoming dated and you continue to lose ground in modernizing it? Particularly for larger legacy platforms, it might actually feel like this.

[00:00:55] But what about the people, the ones who are working feverishly to improve your product? How are they feeling? Maybe they feel like they're never getting ahead, they're always playing catch up, because they're always being asked for more. Do they feel disconnected from the big picture? They're being told one thing, ship more features as efficiently as possible, yet at the same time that same motive becomes less and less efficient. Are they feeling worn out or helpless? It's inevitable when productivity declines and the business desires more and more. Now this can put a tremendous amount of pressure on people, especially those very people who only want your product to succeed.

What we overlook and what we avoid

[00:01:42] Now, I recognize there are various factors that can contribute to this. From my perspective, in my years of experience in this pain, it comes down to two fundamental things. Number one are the things that we keep overlooking, and number two are the things that we never wanted to deal with. And this can take different forms. So maybe you've been forgetting your maintenance cycles. There are parts that have been giving you trouble but you haven't really made time to address them. Maybe you have not been dealing with your technical or design debt and pruning parts of the product where it's needed. These are typically things where we say, no one's complaining about it, so let's not deal with it.

[00:02:26] Maybe it's how we actually view roadmaps. When roadmaps are treated as milestones, we can often overlook the need for maintenance to reaching our destination. Now the truth is, you can't bolt on to your products forever. Sooner or later that leak in your wheel is going to lead to a blowout, or something worse, an accident. But let's look at it this way, which is a common way for all of us to see it: we have this roadmap and there's blocks of work that are assigned approximate periods of time, which align towards greater business goals, and then we have agile and scrum cycles.

[00:03:02] Now, besides the cognitive bias of the planning fallacy and other optimistic planning biases with roadmaps, this is where back bloat comes in. And that back bloat, which are all the things that we've been glazing over, is eventually building up and building up. And the more insidious problem with this back bloat in large organizations is that it becomes scattered across various backlogs and documentation. And that, my friends, is what I wanted to talk about today.

[00:03:35] So I'm Scott Himmer, lead UX designer at Renaissance Learning. Renaissance is an educational software company in the US, and we're working to accelerate learning for all children and adults of all ability levels and ethnic and social backgrounds worldwide. I've been doing enterprise platform design for many years, and I'm going to talk about how to address this process problem with product roadmaps to start chipping away at issues towards incremental improvement. I believe that this can be done with your existing company and teams, using the power of people. And key takeaways from my journey are thinking critically and questioning the status quo, collaborating with others and partnering with them, and being flexible and willing to adjust, pivot, and most of all be patient.

Roadmaps assume fair weather

[00:04:28] So roadmaps can often assume sort of this carefree fair weather journey. We'll stop here, we'll get a bite to eat[?], then we'll drive down the scenic valley, and so forth and so on. But what if events change, or for your product your understanding of the problem changes? What if after doing research you find out that you're solving the wrong problem, and the real problem is much, much bigger? Will you have enough gas for your journey? Will you have your spare tire ready? Will you have the tools needed for repairs? Now, don't get me wrong, roadmaps are useful for sequencing blocks of work and planning, but they're not the be-all end-all, and unfortunately they can sometimes pin us into corners and lock us into sort of this narrow view of the ecosystem.

[00:05:20] So let's look at a roadmap. For some companies your roadmap might assume smooth sailing, which is rare, and it's a straight line to your destination, point A to point B. There's no incremental improvements planned, or that we think are needed, and this is not agile. It carries a ton of risk and we're not delivering any incremental value at all. You don't get any value until you get to the end, you reach the destination. So let's assume that we have planned in some incremental improvements along the way. This is a little more agile. And if we think of a roadmap simply as a path with landmarks and milestones along the way, we can sometimes assume that we won't learn anything along the way, or even have room to learn, because if we learn something new we won't have any time to pivot, because we've never planned it in. It's point A to point B.

From a roadmap to a landscape

[00:06:14] And so that's a roadmap, and the key word here is road, it's a path. And so then we have this concept of a landscape. So how does that differ? Well, landscapes are the surface features, they're the big rocks, the valleys, the hills, the swamps. And at Renaissance, on the platform side, when we took a step back from our roadmap to see the landscape, this different view began to emerge, this different picture. So we plotted our landscape out on what we called our platform radar, which eventually became a special project in Jira, and this helped us to track these larger strategic areas for improvement of the ecosystem that we knew we eventually needed to address, but they're not on the roadmap yet.

[00:07:01] And this helped us get ahead and prepare for the work that is to come. It's not a question of if, it's a question of when we have to address it. So it's important to remember and keep in mind that things on the landscape, or on your radar, they're not things that you need to necessarily tackle right now, but you know that strategically you must address them. In many cases it may be low-hanging fruit, and the next time you touch this area of your platform you can simply check it off your list.

[00:07:31] And now, I'm a believer in giving credit where credit is due, and so I want to give credit to an article written by Kevin Caple[?]. It's titled "Ditching Your Roadmap for a Product Landscape". I recommend it, it was really insightful for me, and it connected this concept that I had been thinking about for a while with something that he had been thinking about. Again, the power of people.

Cross-cutting and chipping away

[00:07:53] So how do roadmaps and landscapes relate to one another? Well, let's say from a roadmap perspective we've plotted this course, that's our path, and there's a series of epics to meet those goals, and some of those epics might touch some of our strategic areas of improvement. But maybe there's no room in the epic to touch that area. Well, that really depends on how we touch it. So maybe we can't bite off everything, but why wouldn't we want to chip away at what we can? What we're doing here is we're cross-cutting, we're looking at related work, and we're trying to get the most bang for the buck.

[00:08:32] I've used this landscape strategy in a number of ways. So for a couple of examples: in one instance we were updating a header component on a legacy portal to bring it up to standard. We'd been having issues with the UI component, keeping it updated across multiple single page applications and keeping them all in sync, and this one epic made it easy for us just to change it, because the points were extremely low. It was a small value proposition that contributed to the bigger picture. In another instance we reduced the scope of a north star to pull in a very thin slice of value for an area that was getting revamped. Now, we didn't complete the whole north star or the big picture, but we laid the foundation, and because we had been planning for this all along, the work was ready to be picked up as soon as the epic came along, and we were able to slice it just right to fit it into scope.

[00:09:26] Now, what I can say about the smaller stuff is that when an engineer is up to their armpits in code, that is the best time and the least expensive time to get these, particularly the little things, fixed. These little chips may seem insignificant, but they are part of the bigger picture toward improving the customer experience. Customers will, and they do, if you've ever talked to your support team, they will see through the veneer and eventually the gaps, and ask your sales team as well.

[00:09:56] So we need to really think critically about this, the bigger picture and the potential routes. If we don't, we generally just throw up our arms and say, well, we don't have the resources to fit any of this in scope, and the bloat continues to build. And when you think about it, this is generally work that needs to be done anyway, but no one wants to justify it over new features, and so the cycle continues, and your product continues to hobble down the road and further denigrate.

The process for strategic areas of improvement

[00:10:26] So the process might look something like this. We have these strategic areas of improvement. They're simply loosely defined problems or opportunities that we could address. Product managers are invaluable at this stage, as well as researchers. And then we have analysis, which is pretty self-explanatory: we dig in, we explore the problem space, we flesh it out. We have internal reviews, and this is where we leverage internal stakeholders and subject matter experts to look at the problems faced from different perspectives, for us to hone our focus on the core value.

[00:11:01] And then we segment that value. We roughly size the work and we look at it from different angles, or value slices, if we do need to break it up, because we need to determine, is this one big thing, is this a bunch of little things, is this a couple of medium things, that we can figure out how we can take this off in pieces towards that larger vision. And then we build these cases. So we prepare all the analysis, all the feedback, all the input, all the estimates, into a block of work that's ready for execution. Now it's important to note, these cases are just different ways, they're different routes to reach our destination. It's not the road, these are multiple ways we could lay the road.

[00:11:45] So some examples of strategic improvement areas might be, maybe there's reporting enhancements, those can be rather big, complex, depending on your enterprise. There's enterprise search, which can be an extremely large effort. Maybe there are scheduling features in your product. But then there's these low-lying value[?], these incremental small improvements. They might be navigational flows that have been plaguing customers, there could be inconsistencies that have been leading to user confusion. There's a ton of value in cleaning these up because it overall improves the user experience. Now, this might look like a normal design process, or even a design sprint, sort of. However, this is not happening during a sprint, it's happening when we realize there's a need for us to address something before the road is ever paved. So essentially we don't know where the road is going to go yet, but we do need to figure it out.

Tips for addressing roadmaps

[00:12:45] So, how we might view and approach a roadmap, this is where we have the most impact for real change. So a few tips for addressing roadmaps. We should always, always be looking ahead. We're scanning the landscape, we're evaluating what's next, because agile is all about learning and it's all about achieving goals. We want to give people room to dream, define a north star. There is nothing more frustrating than ideating these great ideas and brainstorming only to say, oh well, we can't build that by X date. Maybe we can't in the short term, but we need to start that journey towards that ideal state. We can define an ideal state and work backwards to chipping away at the pieces. There's incremental ways to achieving that goal, instead of just surrendering and saying we can't.

[00:13:37] We need to lean on team members. We can't have all the answers, we need to lean on others and their skills to have meaningful impacts, and others often have a piece to the puzzle that we simply don't see. And we have to listen to people, their ideas, their concerns. We need to give people space to be heard, because it's in this space that we build real trust and camaraderie with others, and that's when great things can happen.

Your pit crew

[00:14:05] So cars, like products, as you can imagine, require maintenance. And in racing, pit crews, they're the quick mechanics. Each have a very specialized skill to keep that car in the race to win. Individually we can't do everything, we need a wide range of specialized people to support us. Now I'm not a racing fan, I don't watch racing, but if you've ever seen a NASCAR tire changer do their job on a track, it's pretty impressive.

[00:14:36] And so in different organizations we have different people to lean on. So product managers, they can help direct the vision and align it towards the market needs and the strategic goals of the company. Architects and engineers provide insights into the mechanics: how does this thing work? They provide us input and insight into that. UX researchers, they provide data about the problem space to give us a laser sharp focus on the target. UX designers can provide user-centric design direction. Support team members can give us information about frustrations customers have, solutions and workarounds they've been applying. You might have sales, you might have customer enablement, and these are all people who can help you.

[00:15:20] So for example, if there's a certain team that's working on a particular feature, or owns a particular feature in your platform, you might want to reach out to the front end engineer and just talk to them for 15 minutes. Give me the gist of this area from your perspective, of what you're facing. It's the mechanics, they can open the hood and tell you that your belts are loose, or tell you that you need to change your air filter. You can learn a lot in 10 to 15 minutes from a person. And I might talk to a support rep for 15 minutes to see what sort of customer complaints we might have in that particular area. This might lead me to another piece of the puzzle, but it's all coming from a group of people.

[00:16:02] I often find that these specialists love being part of the big picture. People love being part of the solutions, and we all have a common goal that we can get behind. And when you think about it, these specialists have been the ones in the trenches dealing with these issues, and now they actually get a chance to do something about it. They've recognized for a long time there's wonky navigation, or there's these oddities in the user flow, and now they have an opportunity to do something about it, by contributing to it, or even actually doing the work, depending on how the work pans out. And it has often been a rallying cry for people to get behind. I found that people have risen to the occasion every time we've engaged in these interactions. Now personally, I've built really great relationships with this process, and it's helped others work towards practical outcomes, just simply by teaming up with others.

Building a crew, and influence

[00:16:56] What I want you to remember though about your crew is that it's not static. It's always evolving and it's expanding based on your needs. Ultimately what you're doing is you're building a network of trusted specialists, and they're ready to jump in when you need that help. So a pit crew provides powerful insights into strategic areas of improvement, because they highlight gaps in our understanding.

[00:17:22] So a few tips for building a crew. Know your roles. Partner with that ambitious PM, find that rockstar front end engineer, learn from the architect on how certain technologies work, get to know your support specialist. Aligning goals: as UX designers, of course we want to improve the customer experience, but so do the engineers. But they also want to code as efficiently as possible, reduce debt where they can. So we want to align our goals and work together towards a solution that works for all of us. And then we need to learn from each other. It's okay, and we need to give ourselves permission, to step outside of our lanes. In return we should be sharing our customer experiences and the user research that we've been building up.

[00:18:11] I've often found, me personally, way too much friction between different roles, because each side thinks that they have it figured out, like, we have our side figured out, now you need to figure out your side. Collectively we all win or we all lose, so collectively we need to work together to find the right answer, and we can't ever stop learning. Cross-pollinating, I found, can be very powerful for teams.

[00:18:34] So, influence. The thing I want to say about influence that should be understood is that I recognize not everyone has the same level of influence. So for a PM or an architect, you may carry a lot of sway when it comes to decision making, and I recognize there may be many designers and engineers that don't feel like they have any sway at all, they don't even have a voice. So decision makers aside, I feel like this sort of comes down to two perspectives. So there's this high impact influence, I would say, and that's working very closely with teams. You're embedded, you're working in close proximity with them, you're asking questions, you're iterating, you're clarifying, you're bringing that voice of the customer in. It's very organic, back and forth within the team.

[00:19:21] And in those cases I believe that decision makers need to allow people to speak up, give them room to speak up, and also listen to them, because you may be hearing a perspective that you haven't heard before, because these might be the quiet people in the room. And then there's this lower impact influence, and that could be simply listening, sympathizing with others, and just supporting them. We may not be embedded, we may be in a lot less proximity with them, but we are cross-pollinating and we are building trust in a very small way. I believe that anyone can have influence, but we just need to start somewhere.

Putting it into practice

[00:20:01] So, of all these things we've talked about, we've been on our journey, we're journeying across the landscape down this roadmap to success, and we've been replacing a windshield wiper here, and fueling up there, and loosening up a lug nut here and there, and all of this is incremental improvement that never would have gotten the time of day for an epic. No one's going to write an epic that says replace the windshield wiper. Usually it's related to the front window, and then it may have a story related to the windshield wiper. So I'd like to share a few concrete ways that I've put this into practice.

[00:20:37] So at Renaissance we had been rethinking our entry portal, and we sliced the value a couple of different ways based on the process I was sharing, and we just sort of put it on the shelf. We recognized there's no room on the roadmap at this time. And then it just so happened, and we didn't see it, it came out of left field, it just so happened the team was getting ready to make updates to that portal, and we were able to take this thin value slice, tighten it up and get it inserted into the scope of that epic, because they were able to have scope, and we just had to figure out what's the scope that we could fit in that actually delivered value. So we had been doing all the prep work, and had we not, we would have totally missed the opportunity to get that value in place, because now we would have this learning curve to get our heads around something that we've already been planning for.

[00:21:28] At Delta Air Lines we were completely re-architecting a platform, a new platform, and we were aware of some of the core capabilities that were needed, but it wasn't on a roadmap yet. But it was on the landscape, because these were strategic areas we knew that we needed to address. Now, it did have a core team dedicated to the platform, and so we knew that we needed to put the infrastructure in place, and over time, as we found gaps in our work, we were able to start putting the pieces in place to fulfill those needs.

[00:22:04] And one day a project manager had come to me and he was berating me, because someone else had been chewing him out related to a light and a dark feature that pilots needed. It was a really important feature for pilots, particularly where they're flying at night, and a number of other features. And after he was done needlessly chewing me out, I simply asked him to go to the app, and I showed him that those things were actually functional. And now I think he felt a little embarrassed for berating me needlessly for something that he failed to prioritize for the roadmap.

[00:22:45] But the landscape told us it was needed all along, and because we were self-organizing and we saw the landscape, we knew it had to be addressed, and we worked together organically. We knew what we needed to get done, and we were able as a team to determine how we needed to slice the value to get that infrastructure in place for that feature to actually manifest itself. And so we had been planning and tuning for this all along, and we were always looking ahead towards that north star of what was needed before the roadmap ever told us. We found alternate routes to reach our destination that the roadmap never told us.

Notifications: slicing toward the north star

[00:23:26] Another example was this need for notifications in our platform. So customers continued to request it, but it was sort of a large effort, as we had determined at the time, and it just wasn't a priority. And so after some internal reviews with the crew, we determined that the long pole of it was getting a service or an engine in place to drive those notifications and those messages. So we looked at multiple ways that we could approach the value slices, and that would reduce rework, again, that's an engineering or architecture goal, and to define sort of these incremental pieces that'll lead us to the north star, that desired destination. And what is the absolute minimum viable product here, and then what are the incremental steps, and how would we scale this feature?

[00:24:15] And we were able to actually build a small value slice, which was just simply a UI component with very simple logic, and the idea was that when the engine was ready, then we could simply plug the engine into the component. So rather than building the engine and then building the component, we built the component, defined the structure for it, and then we would plan for the engine later on that we could plug into it, and that could be supplemented with additional logic until we had the engine. So we still were figuring out how we would scale that, but that was sort of our plan of sequence.

[00:24:54] The point is that planning and persistence does pay off. We need to try to not let roadmaps narrow our perspective of the big picture, of these areas that do need to improve. We need to keep our gaze fixed on that north star and not be distracted by all these little stops along the way, because it can cause us to lose focus.

In conclusion

[00:25:17] So in conclusion, you don't need to ditch your roadmaps, just examine how you're using them in terms of a landscape or a platform radar. Roadmaps are useful for sequencing and prioritizing work, just don't let them limit your potential. Partner with people and rally a team to fall in love with the problem space, and think creatively about how you're going to solve those problems and those challenges. And be vigilant and look for opportunities to prune and to improve the big picture.

[00:25:48] So I hope this presentation was beneficial to you all, and if you found it useful and you want to begin to put it into practice, I'd recommend starting small, be lean, and learn as you go. Build a network and build partnerships with people. You can find my article, which goes a little bit more in depth on this topic, at smashingmagazine.com. You can hit me up on LinkedIn or email for further conversation or discussion, and I thank you for your time today.