Yo ho, yo ho, an R&D roadmap for me
How thinking like a pirate might help fill the gap between too little planning and too much planning.
Hey you guys! Many who have worked in my teams over the years have heard me use the analogy of a pirate map to talk about how many software development plans develop. This would usually involve me drawing terrible maps of treasure, obstacles, opportunities, and ultimately reaching the treasure (aka goals). I will try to move this beyond the whiteboard sessions into a more coherent document. Bear with me, the seas may be complicated and complex (not to mention the puns that may crop up). Let me know if this analogy makes sense, resonates with you, or if you think I’m a scallywag who doesn’t know what he’s talking about.
Loose in the stays
For many years software development was controlled by detailed Gantt charts meticulously mapping where we are, where we need to be, and exactly how we will get there. We called this waterfall development, partly to indicate the sequential order of work, but also to give a pleasant name to what was a daunting and error-fraught approach. This process required heavy investments to prepare but suffered from low predictability of delivery and needless sequencing of things. In response, many have adopted lean agile practices that focus on learning and adapting plans to incorporate that new information. This has largely been effective but there is a danger of over-focusing on the near-term goals at the expense of long-term goals.
A few years ago the leadership team I was part of struggled as we discussed roadmaps and how far we should be looking. One of my peers called out, “Why would we plan past 6 months when we know that everything will be different then”. This, of course, is a valid observation. However, I pointed out that if we are only looking at the next few months how do we know our teams are going in the right direction to achieve our long-term goals? Each of us focused on what our individual disciplines needed. Product and design teams focused on plans we could execute now and a long-term strategy, spending time in the middle thinking about products that may never get built was seen as a wasted effort. Engineering teams were focused on trying to see around the next corner to build architectures that could empower not only the current work but the work that comes next and were not concerned with the far future state as it was too undefined to consider. This created an uncomfortable but important tension to try and figure out near-term, mid-term, and long-term thinking. Without digging into it we might end up sailing in circles or missing critical opportunities.
Weigh Anchor and Hoist the Mizzen!
An analogy I use to resolve this tension is to think of roadmaps as a pirate treasure map. Treasure maps don’t include all of the information, details, or specific directions on how to get to that treasure. Rather, they paint the story of potential gold and riches, including vague directions on how to reach it, a rough idea of its location, and a few warnings about dangers that exist. It’s value is not in having all of the answers, but enough to guide the crew to their goal. There is just enough information to inform us intrepid explorers to set sail, persevere, and find the treasure. After all, Goonies never die! So just like a treasure map used to find pirate gold, we can use product roadmaps to reach our goals: those riches.
We start with some loose ideas of goals we want to achieve and some rough ideas of how we might achieve them. Like our treasure map, this is never a straightforward path to that goal. After all, if it were, others before us would have achieved them by just executing on a well-defined plan. Instead, we must find our own path, learn, adjust our thinking, and explore. This is why we have teams of highly talented folks pursuing these goals. Continuing our analogy we have:
X marks the spot: The X on the map is our goal state. This should be audacious enough to move the company forward but not so out there that it is unattainable. It needs to inspire the team to keep pushing even when obstacles appear. It also needs to be specific enough to start we should not wait until we have all the answers and miss the opportunity.
Landmarks: This is the data about the terrain and things that we can look for along the journey. We need to define metrics and collect the data to understand if we are getting closer to our goals but also to refine and update the goals on new understandings. This includes user research, user metrics, business analytics, and milestones of success as we approach our goals.
Booby traps: These will be pitfalls or obstacles that we will need to overcome. This could be technical limitations, red herrings, incidents, or other distractions that will appear. We need to account for them and try to understand when and where they will arise, but we cannot plan for all inevitabilities, so we must adapt to the situations that arise. It is important to document what risks exist both to help mitigate them but also organize our work to better understand and react to them early.
The dotted line: This is the rough outline of how we might proceed given our current location and current understanding. It is never a straight line but we keep an eye on the X to ensure we are moving towards that by looking out for the landmarks. In the early formation of our map we may have little confidence in it, but it is important to have a sense of how we will proceed, taking the above into account.
Wind: The wind is not always predictable just as new product ideas or considerations can come out of nowhere. We need to understand how to harness those ideas and ensure that they help push towards our long-term goals. And if they push us off course we may need to push back on them or articulate the impact on our goals. Our map needs to take into account the unexpected but importantly we cannot plan for every contingency.
As we start out, it is important to understand that it will be defined by the goals, the learnings, and the journey itself. We need a map to help guide us but it is important to understand that it does not promise or define our future. It is a tool to help guide and communicate only. We need to be able to find comfort in the unknowns and not be afraid to make progress, lest we stall and never make progress. We can use existing data to understand our landscape and landmarks and focus on places where we may need more information and start to explore those areas first. Building out a roadmap, nay a treasure map, to help guide us will allow the team to focus on the long-term goals, understand progress against those goals, and evaluate new opportunities beyond just their near-term work.
By embracing the tension between moving quickly and planning, and not fearing it, we can build a plan that we know will change but offers important guidance to focus on the long-term goals.
Make Fast!
This of course is not an easy thing to build, and not all teams are prepared for it. We need to balance effort with value. Too detailed of a product roadmap and you may miss other important work and move too slowly. Too little work and the team has no direction and may be underachieving on their goals. But teams must develop this muscle, lest they run aground. One technique I have used is to set up timelines as a forcing function, whether they are actual external deadlines or internal goals. While deadlines are scary to many and at face value seem to be counter to agile practices, they can be a good forcing function for creating a flexible map and idea of when goals may be achieved. For the team, this can offer a rallying cry and create focus. For the business, it creates a mechanism to check in on progress, support the team, and understand the impact. A key here is the realization that not all is known, plans will need to be updated, and milestones can be moved as we learn more.
The right level and type of planning for any given team may differ as it depends on team maturity, the strategy, and the culture of the team. But as leaders, we need to support and foster practices that build trust and focus for a team. By empowering teams to develop roadmaps and developing trust in the organization we can create more productive teams. One of the teams I led was faced with a project that included a deadline, which ran counter to their “release when ready” ways of working. In their heads they feared waterfall planning that would require weeks of effort and hours of documentations. To help overcome this I gather the team in a room and on the white board had lines for “NOW” and the date of the launch. We spent an hour adding things we knew we needed to reach the goal, discussing what they meant, and sequencing them where needed. After this exercise it was clear we were at risk, but this allowed the developers and product manager to dig in and discuss if there were areas to descope and derisk. After about 2 hours of work we had what we needed, a rough outline of the work we needed, places where we knew it would be important to start, and places where we knew we could do work later.
Truly cross-functional teams are critical to this approach as we need many different disciplines to navigate, just as a ship's crew. This creates opportunities to maximize learning, reduce communication overhead, and adapt quickly to new situations with the least amount of effort. The treasure map is there to ensure that the progress is in service of long-term success. My role going forward was to ensure we used it as a guide and ensure we updated it as we got a better understanding, using the agile process to refine the plan. I also used it to communicate to the business, not as a promise of specific delivery but to increase confidence in understanding our goals that could lead to strategic decisions. In the example above, this led to us delivering on our initial milestones and having a much better understanding of where we were going long-term.
Product development is quite like hunting for treasure. We’re driven by the promise of treasure but also the sense of adventure. That dual motivation is what drives us into the unknown, to plot a course, take risks, and eventually find that gold. Having a treasure map is a critical component, but ultimately we need to gather our developers, hoist the main sail, and learn as we go. We’re not going to find the gold if we never set sail.
