Develop Vision

The vision that you’ve well articulated in the first 30 days is still limited. As mentioned, the organization’s leaders often assume that the vision is shared merely by the fact it has been created and communicated in a town hall. That couldn’t be further from the truth. Usually the vision is still nebulous in minds of both the leadership team and the organization at large. Other forces see the vision of an overarching framework that is designed to deliver value as threatening their fiefdoms. In traditional silo organizational structures, middle managers see the overarching integration of existing frameworks as invading on their authority. This holds true even for so-called agile development organizations that push back on a holistic lean engine, claiming it to be an interruption to their ongoing delivery cycle. It is also true for UX experts and designers who under the false pretense of Lean UX prefer to focus on creating complete designs without the business orientation that is driven by the lean engine. Six Sigma professionals who often focus on the quality aspect of delivery view the integrated model as belittling their quality-driven efforts.

These adversarial stakeholders are unaccepting and in disagreement with the program objective and employ manipulative means to propagate disagreement. This group is the most difficult to influence.

That said, others in the organization support the vision and understand the need for an integrative model that is united by a lean engine driven by consumer validation.

The onerous task of building enough support for the program consumes a quarter of the program’s effort in the first 90 days. Following the stakeholder attitude analysis that was completed in the first 30 days, you direct your attention to building the support for the program.

Your challenge, though, is focusing on the supporters rather than the adversaries. That runs counter-intuitive to how we normally build support. Often we invest time and effort to build trust and agreement with opposing stakeholders. Practically, these might be wasted efforts, leading to the opposite result. The focus on this group develops into an openly hostile conflict that resonates with the other stakeholder groups and can create a landslide in the overall level of support.¹ That is not to say that you should totally ignore the adversarial group of stakeholders; rather, be cognizant to the fact that we often focus on them rather than lead the fence-sitters.

Focus the efforts on the stakeholders who support the vision and promote it with those who are still wavering, the fence sitters. Share the success stories with the entire organization, yet avoid investing time and effort by trying to convince opposing stakeholders.

Consider a Silicon Valley-based integrated circuit engineering and manufacturing company that was facing a prominent decline in market share due to changing usage patterns among consumers. The leadership embraced the lean unifying framework, articulated a vision, and participated in the executive training. While support for the program was in place among marketing, finance, and software engineering, I identified resistance with the hardware engineering, operations, and regional sales business units. The deeper analysis did confirm that the senior vice presidents of the opposing business units viewed the program suspiciously; some were more in line with the vision than others. Building on the CEO’s support for the program, I enlisted a high-profile program team to act on the ideas that emerged from the executive workshop. The cross-functional team had members of the supporting business units as well as some members of the adversarial business units. I had to work with this team in the first 90 days to identify customer personas, prototype an MVP, and run experiments with customers to validate their hypotheses.

Since at this point a few of the senior vice presidents opposing the program were taking a passive role, I saw the opportunity to find members of their organization that were supporting the effort. This required me to continue identifying support for the vision as I was learning the realities of the business. I used the learning to persuade mid-level managers in the business units of the adversarial senior vice presidents to support the program. The five cross-functional teams that emerged from the first executive training had a mix of supporters and a few fence sitters. By the completion of the 90-day program and the demonstration of successful results, I had gained momentum and sufficient buy-in to proceed to the next phase.

I often expect two or three of the five first MVPs identified in the exectuive workshop to exhibit benefits at the 90-day mark. This is in line with lean thinking; you must assume that there will be a pivot and you need to clearly communicate it throughout the 90 days. Failure by validation is welcome, and it is part of learning. However, failing to communicate that you expect some of the programs to pivot will lead prominent adversarial business leaders to call the program itself a failure. Protect the program by promoting the concept of learning by failure; share the expectation that not all ideas will yield beneficial results, and yet the lean engine enables much faster turnaround time in learning which ideas do not have merit. Figure 8-1 is a graphical representation that carries this message: We expect ideas to fail; the failure is a result of continuous validation following the scientific method.

Identify Customer Personas

More effort is required during the first 90 days in developing personas. Let’s revisit what you learned previously: in many organizations, personas are treated as a sign of being “modern.” Pictures are laminated on the wall and persona stories are included in employee booklets. However, personas should be as living and breathing as the people who they represent. Creating static types of your users and customers is counterproductive because it represents a point in time rather than allowing the persona to evolve with your thinking. Thus, consider personas as continuously evolving, much as the customer persona evolves along with a company’s understanding of the target audience and their needs.

Treat the creation of a persona as a learning process in itself. Follow up with the five cross-functional teams that completed the training and coach them to validate their assumptions about the persona they drafted during the executive training. A recurring pattern is that the organizations are often convinced that their assumptions about their consumers are true; however, once researched, many of these assumptions prove to be false.

As mentioned, big organizations and corporations are frequently characterized by little interaction with customers both internal and external. Use the first 90 days to challenge the prevailing organizational mindset that “we aren’t allowed to interact with consumers.” Ask the teams to clearly state the assumption about the draft persona and push back on their inclination to use existing internal data to validate it. Rather, request that they validate their assumptions by interacting directly with real people outside the offices, in the real world. For executive teams that hardly ever interact with a consumer, this is a quite a challenge. They usually bring up various legal and compliance excuses to push back; however, this is just a smokescreen masking their fear of actually going out of the building and validating their assumptions. When I tasked executive teams with validating their assumptions concerning the personas they created with real consumers, they often hid behind surveys and regulations.

The goal of the first 90 days is to break the fear and empower the teams to validate their assumptions concerning the draft persona they created. This is an initial step in the creation of a living persona. I will revisit the topic in the next chapter.

A persona can be summed in a simple graphic design, as shown in Figure 8-2. Avoid a pretty image of the person; sketch roughly instead.

The best example of the gap between the laminated, colorful, synthetic persona exhibited on the corporate office walls and the real, flesh-and-blood consumer occurred in the offices of a private health insurance provider in London. The laminated persona was a smiling, 60-year-old city dweller who was engaged in sports and the community, led a healthy life, and yet suffered from a certain chronic disease. There were numerous details concerning his lifestyle, dwelling, fears, and concerns. However, the persona didn’t convey the true essence of the consumer; rather it conveyed a cheerful disposition. When I conducted a user-centered design workshop with the executive team working through their persona assumptions, a different and starker persona appeared, one that allowed a much deeper appreciation of who the consumer was. It was similar to upgrading from a flat two-dimensional view to a three-dimensional view. The wall-mounted persona models could not capture the key feeling and experiences of the persona and thus contributed to a skewed perception of the possible solution.

Prototype MVP and Program Training

The training program that commenced with the executive team proceeds with training targeted to mid-level management. The goal of the first 90 days is to have approximately 3-5% of the employees trained. Considering a reasonably sized enterprise of 10,000 to 20,000 employees, this translates to roughly 500 to 1,000 mid-level managers trained. Each class holds about 25 participants grouped in five predefined cross-functional teams of five individuals each. On average, you can expect to run several dozens of these classes.

By the end of the first month, you should have identified and trained internal regional trainers to facilitate the program. Each of these trainers will then become a mentor and coach for the teams they train, supporting them weekly in getting them prepared for their separate 90-day demonstrations. I suggest that you schedule demonstrations regionally with members of the executive leadership participating in person to review the results of the MVP validations.

Each trainer-made coach supports up to six classes worth of participants, thus they need to be fully engaged and committed to the program. The weekly coaching session are scheduled for 30 minutes, hence about half their time is committed to these sessions.

The MVPs are defined by each team during the training; the goal of each team is to identify the assumption that will be validated by the MVP. That’s challenging because the team is unsure what the MVP should look like. Often the first coaching sessions are spent refining the MVP and brainstorming which assumptions must be validated.

As part of creating the MVP, the teams identify facts and assumptions. They use Post-It notes to capture facts separately, and they follow the same process to identify assumptions. They share the assumptions and remove redundancies. Often what seems like a fact is actually an assumption. Figure 8-3 captures two facts on two separate Post-It notes. On closer scrutiny, we revised our fact concerning the blue worm. We don’t know for sure whether Ross, our persona, would eat a blue worm.

The important/uncertain grid that follows is introduced in the training as a tool to identify the most important and the most uncertain assumptions that are embedded within the MVP and the persona. An example of the important/uncertain grid is presented in Figure 8-4. The team maps the assumptions into the grid individually and then discusses the discrepancies together.

Run Experiments with Customers to Validate Your Hypotheses

The sense of urgency is on; you must run experiments with your consumers to validate the assumptions that the teams identified. There is little that stands in your way to accomplish this, apart from the resistance that the teams themselves exhibit. The fear of getting out of the comfort zone and asking for direct feedback on their ideas, assumptions, and hypotheses is not something they were ever training to perform. The best method to overcome this resistance is to coach the teams, post the two-day training, to start experimenting with the customer immediately without letting the fear sink in. The learnings from the simplest of experimentation are vast. The teams I coach often discover that they crafted the wrong hypotheses or that the hypotheses were quickly refuted. Once they start, they get excited since they are receiving unfiltered feedback to their idea, something that for most is a revelation.

I already shared the following figure; I will use it again to further explain the validation process. You completed the training with each team having several assumptions (that are important or uncertain) to validate. Figure 8-5 describes the overall process. I will detail the steps starting with Hypothesize through Pivot.

Pivot or Persevere in a Build-Measure-Learn Cycle

A few pivots occur in the first 90 days, and you need to support the process of learning and failing. As mentioned, a pivot is a result of a hypothesis being invalidated, which means that the original assumption was wrong. The failing part is difficult to accept, especially if the assumption has been one that the organization believed in for a long time. Additionally, for members of the executive team, accepting that they were wrong is sometimes difficult to acknowledge.

Framing the failure as part of an ongoing build-measure-learn cycle assists in accepting the failure as part of the learning. This cycle is at the heart of lean thinking in the enterprise . The build-measure-learn cycle questions the concept of “big bang” deliveries, which dominated development and project management for a long time. Big bang approaches became prevalent in the past as organizations grew in size and distanced themselves from consumers, products increased in complexity, mass production and mass marketing ruled, and assembly lines spanned continents. We lost sight of the need to build, get feedback from customers by measuring, learning, and then iterating based on the learning. The agile software movement that officially started with the Agile Manifesto in 2001 was a catalyst towards iterative development. It was both a driver and a response to the market demand for product personalization, getting software products to market faster, and aligning the product to the actual needs of the consumer. There is some criticism about the fast iterative feedback approach in the sense that it prohibits monumental undertakings and limits the development to small improvements.³ However, the criticism doesn’t answer the problems of the remarkable waste occurring in the creation of results .

Figure 8-6 illustrates the concept of a pivot resulting from a build-measure-learn cycle. The build process has to be as small as possible, hence the concepts of MVP; the measurement has to measure the outcome. Notice that in this case, Ross the rooster didn’t ask for a progress report of twigs per square foot from the IT department or for a status report of hours invested to build the nest from Operations . He measures an outcome by interacting with the actual build; he sits in the MVP nest to validate fit-for-use. Unfortunately, the hypothesis is invalidated and the MVP assumption fails. Ross falls down. Was a safety cushion provided for him to fall into? When implementing a build-measure-learn cycle, you need to make sure you address the safety nets protecting the company in case of failures. Part of the first 90 days is learning and putting in place such safety nets .

What happens when there are no safety nets in place? Consider a financial services enterprise that adopted lean thinking to speed the integration and deployment of a back-end core system to replace an obsolete legacy system. It was a revolutionary approach because it focused on an internal core system. Traditionally, replacements of legacy systems and deployment of new IT core systems are lengthy projects , often costly, and normally under deliver on the promised results.

The team was using the build-measure-learn cycle to cut down the requirements gathering process, remove exceptions, and speed the time to deploy. They identified an MVP for a new product and created the required mechanisms to support the purchase, use, and support capabilities on the new system. They spent several months constructing the minimal core functionalities. Prior to the launch, they met with the various business owners and asked them for the possible impacts of various scenarios. The operations team and the manager of the consumer representative organization estimated that the impacts of the MVP would be minimal. No special plans were put in place in case things went wrong. Based on this, they decided to roll out the new MVP functionality across all of the lower 48 states (US).

The day after launch, vital signs showed a small increase in waiting times at the call centers. Two days later, the waiting times were doubled. By day three, the average wait time for a customer representative quadrupled. It was less than a week before urgent meetings started to appear on calendars. Executives were called in, the program was halted, and fall-back scenarios discussed. As is the case in enterprises , finger pointing started and blame was assigned. It didn’t matter that the senior vice president of operations estimated small impact prior to the go-live. Now his business unit was paying for the additional hours and days of work, and he was outraged. The program lost credibility and the term “MVP” was ridiculed. At this point, they decided to roll back the deployment and deploy the solution state by state, which is a fundamental concept of MVP deployment. On top of which no safety nets were in place.

The hypothesis can also be validated, in which case the company perseveres. It proceeds with the next most important and most uncertain assumption, validating the relevant hypothesis. Figure 8-7 illustrates the concept of persevering in a build-measure-learn cycle. The build process has to be as small as possible, hence the concept of MVP. The metrics must measure the outcome. Notice again that Ross the rooster didn’t ask for a forecast development effort from the enterprise PMO. By interacting with the actual build he measures an outcome; he sits in the MVP nest to validate fit-for-use. Ross then learns about the building process. Is the nest comfortable? Is it safe? Can it support his weight for a period of time ?

He is ready to experiment with the next step. He will validate another hypothesis; each complete loop through the cycle either adds to the MVP or redirects it. The solution will emerge through an ongoing repeat of the build-measure-learn cycle .