Under each option and route there are assumptions that need testing, just as I test my planned route and change it when working my way around Los Angeles. That’s the essence of a true product roadmap; by setting the right goal you can then begin to ask the right questions to discover the many different options available to enabling that goal.
There’s a reason I call kids mini-philosophers, and to a parent they can sometimes be as easy to contend with as Socrates was on a bad day at the marketplace. I’ll spare you the rest of the discussion, needless to say at some point I utter the parent’s final recourse of, “Just because”, which I’ve heard sometimes delays the discussion until they hit their early teens.
In my case study, the right questions had never been asked because the goal was always software.
What Charlie and Mali are doing, which I’ll call the “MACH” approach, is very similar to many thinking tools that we do a pretty good job in software development of ignoring. The most well known of these is the FiveWhy’s approach, as originally codified by Kiichiro Toyoda's father Sakichi. In this approach there are not really 5 why’s involved, that’s not the important point; the important point is to really figure out why you’re doing something in order to build a proper roadmap towards a solution and explore the options on how to get there. The aim is to get to the root of a problem in order to embrace the right options for a solution.
ASKING THE RIGHT QUESTIONS; THE MACH APPROACH They say that kids can teach us a lot, and my kids are no exception to this rule. Charlie is 5, Mali is 4 and they spend most of their time with me asking me the same question over and over and over again, occasionally varying the context and often tagteaming the interrogation. Here’s an example: Mali: “Where do you go Daddy during the week?” Me: “Work.” Charlie: “Why?” Me: “Because it makes us money to buy things and I love creating software.” Mali: “Why?” Me: “Because people need software.” Charlie: “Why do they need software?” Me: “Well, funny you should mention that because sometimes they don’t and … well … isn’t it getting late and time for bed?” Mali: “Why do we need to go to bed…?”
In our case study, the real goal had been defined too narrowly. The real goal had nothing to do with software, and had everything to do with simplifying the process such that people could spend their time doing more valuable things. If we’d asked different questions we could have built a roadmap to enable the right impact to meet the right goal:
• Why the change is important; why this goal? • Who the change will affect, and who will enable the change? • How the behavior change that’s necessary to achieving the Why could be enabled? • What needs to be built or enabled for the behaviors to result? These 5 questions are the cornerstones of one simple approach to building a real product roadmap, Impact Mapping[2]. An Impact Map helps you sensibly explore the options and elicit underlying assumptions to enable you to pick the simplest journey that will enable the most valuable result. AVOIDING OVERSIMPLIFICATION Merely asking why is not enough however. Even the why itself needs to be carefully examined. Let’s take a look at the two goals stated from our case study and from the retrospective journey of software development over the last 10 years: Goal 1: Case Study - “Software that enables process to be completed in seconds” Goal 2: Software Delivery for the last 10 years - “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” There is a fundamental flaw, brought on by a non-explicit assumption, in both cases. In both cases the goal has been oversimplified. Oversimplification is where you reduce a concept down so far that it no longer delivers on the purpose and values it originally served. Or, as Edward de Bono more succinctly puts it[3] “Oversimplification means carrying simplification to the point where other values are ignored”. In Goal 1 the goal is over-simplistic as it prioritizes one solution approach, one ‘What’ if you will, over another because the underlying values of the delivery team are taking priority over the business stakeholders. The goal
59