Your projects are running into problems late in the development process. They are fully staffed and some of them even look to be moving on pace through the use of daily stand-up meetings, visual management and obeya rooms and then – BAM! – a problem arises which requires significant back-tracking in the design, a resetting of market expectations or perhaps even a re-evaluation of project viability. You wonder, “How can this happen at this late stage of development?” The project hit its initial milestones and the team indicated they were making progress towards your aggressive timeline. Now, you just hope the delay and cost won’t be too great and are starting to get concerned about having to shut down the project. You begin to reprioritize the other projects that were counting on the resources that should have been coming off of this one. You start factoring these delays into your revenue projections for the next two years.
Because innovation requires achieving something new it always involves learning. Identifying what you think you need to learn is perhaps the key to efficient planning and execution of the early phases of product development and essential to set up success throughout subsequent execution. Fortunately, with a little thought early on, your teams can know what most of the big issues facing them are or at least where they likely reside. These issues should form the focus of the early phases of development and commercialization planning where many of them are resolved, new issues are discovered and plans are put in place to mitigate any outstanding issues that may not be resolved prior to generating a plan and fully funding the development effort.
Learning is most critical in this phase of a project and actually failing should occur at this time if ever in the course of the project.
Learning fast requires that you fail fast in productive ways. Maximizing productivity in this case is optimizing the ratio of the relevance of the learning achieved to the amount of resources (time and cost) spent learning it. This definition weights the “relevance” of a potential show-stopper unknown (one in which if you get the wrong answer then you should stop) on the high end of a spectrum with one that simply optimizes the value to you or the customer (i.e. if you get the wrong answer you can provide a slightly less valuable but still viable solution) on the low end of that spectrum. In between are unknowns which when known will determine design architecture decisions, design interface decisions or commercialization options that could require more or less design rework if not learned early.
Prioritize Efforts on the Value of the Knowledge without Fearing the Consequences of Knowing
Unfortunately, it is often the case that the team will tick off unknowns (chalk up milestone successes) by selecting those they know they can overcome first to make progress or those for which they have resources rather than those they know are most critical to determining success or failure of the project. John Wooden, the legendary coach, whose wise advice to his players often included life lessons beyond the court said, “Never mistake activity for achievement”. Quite often we get caught up in demonstrating progress by prioritizing activity over meaningful effort. Our natural tendency is to tackle easy things rather than hard things so that the count of milestone “successes” rises faster. We will keep moving on the little things while we wait for engagement from those required for the outstanding big things in an effort to keep progressing and maintain an aggressive timeline with faith or delusion that the big stuff eventually will take care of itself. It is also the case that a team tasked with delivering a product will subconsciously shy away from tackling the big questions that could endanger their project. All of these tendencies lead to effort with little real advancement – activity without achievement.
Determining where time is best spent requires a team to take the time to discover what is knowable, starting with why the organization is choosing to pursue the effort (their internal value proposition) and what the customer value proposition appears to be. This then enables focus to discover the critical elements needed to achieve these value propositions, including how these objectives match with the capabilities of the organization. Business and systems thinking then goes into prioritizing the unknowns for their importance to the project and successive decisions within it. Guided by this assessment the team can optimize its efforts to rapidly progress towards a successful final solution or even determine that the project is not viable because of inability or organizational unwillingness to realize critical elements of the value propositions. They cannot fear failure at this point because failure is a success in that it will either allow the company to move resources on to more productive efforts or allow them to “pivot” the project as they adapt to the new knowledge gained.
Determine Unknowns Critical to Success
Once the team has its bearings about what is critical to know, they should move rapidly towards getting those answers. Fortunately, in most cases, they don’t have to build the final product to learn the unknowns most critical to success. For example, unknowns are often technical issues that can be explored as modular elements of the final system and do not require the whole system to discover. The prototypical critical unknown is the understanding of how the customer will accept and use the product. This is the typical learning problem that is addressed by the concepts of failing fast and use of minimum viable product (MVP) to test. The concept of the MVP is that even this knowledge can usually be acquired or approximated with something far short of the complete package and consequently at relatively low cost.
This fast (early) learning is not just necessary to understand customer needs and gain confidence about how to overcome the technical design barriers but is also necessary to overcome the anticipated commercialization barriers. For example, manufacturing may need to fully engage early to understand and explain the requirements enabling them to customize product on the assembly line, regulatory may need to explore the requirements for a new market or product category to ensure that the design will capture these, business development may need to establish a partner to OEM the product as the only viable way to introduce it into the market. If these unknowns are not resolved early they can lead to costly redesign when finally understood and may even determine the non-viability of the project at a costly later stage.
Management should encourage their development teams to identify these critical unknowns and then remain focused on figuring them out. This requires support for appropriate engagement from the non-R&D functions prior to significant design work and before project planning for the design and commercial implementation. The milestones of interest during reviews should be those that contribute to solidifying the probability of a project’s success rather than those that can be easily hurdled on the way to piling up meaningless statistics. Management should stay focused on the big issues and hold their teams accountable for reporting on this without getting lost in the minutia required to bring a product to life.
Help your teams not to fear failure early in the project. They should fail with a purpose – to learn early. Make your teams take the time early to know what is knowable and this will guide them to understand what they don’t yet but critically need to know. This is the first step toward focusing on activity which will most quickly lead to achievement. Encourage teams to fail early so they can learn fast.
