Define Vision

Most of the first 30 days are spent defining, articulating, communicating, reviewing, and validating the vision.

I suggest collaborating with senior executives from various organizational business units to crystalize the message. Using collaborative interactive approaches is the best method for creating an agreed-upon vision that is sustainable. Calling these vision meetings workshops and having the participants actively participate with the guidance of an external facilitator produces the wanted results. Postcard from the future, which I mentioned previously, is an inclusive exercise through which a two-year vision can be obtained.

More often than not, there are already many frameworks in place and you need to examine them and identify how they map into the lean startup framework in the enterprise. The postcard workshop can be used to initiate the discussion of how the lean engine drives the organization to the results depicted in the vision.

The various frameworks I discussed earlier tend to be clustered in silos. There may be agile for development, scaled agile for larger development teams, Lean UX for designers and consumer experience experts, DEVOPS for operations, 4DX for business operations, Lean Six Sigma for quality improvement initiatives; often we are missing the integrating function. To be successful, we must articulate the lean engine and its relationship to the existing frameworks.

The vision should provide an overarching compelling description of how we will be different once we adopt the lean mindset. In figuring out the direction, I suggest an outside-in view. What will be different from a consumer standpoint? What will the new consumer experience look like?

The next step is to understand how the various frameworks adopted in the past support the outside-in vision.

Consider a Boston-based software organization that recently doubled in size and was catering to new and bigger enterprises. The original vision was one of survival; however, post-IPO and as it expanded, it was figuring out how lean and business agility fit within its structure. The company was implementing agile in engineering and in operations; however, it wasn’t seeing the promised benefits. It was constantly shifting priorities; roadmaps were created every six months and then scrapped and redone. Operations were handled in a constant crisis mode where heroes were recognized by their ability to resolve crises ad hoc without providing a longer-term remedy. The sales focus was that of closing contracts rather than engagement with consumers with long-term orientation. The lean engine for growth was missing; products were not validated with the market. In other words, the company spent six to nine months developing products without validating them with consumers. The list of requirements that was handed down to development was based on best-guess scenarios developed by the leadership team. When a hurricane hit Florida or wild fires in California roared, the company was ill-equipped to support emergency operations since the product vision was disparate. Its vision was not supported by the frameworks it had in place and not validated by the various business units. The agile delivery system produced results; however, it produced the wrong results because it was missing a validating structure.

Figure 7-1 describes a compelling vision image that I developed for one of my clients. Following the concepts presented in Jim Collin’s Good to Great ¹ book, we first identified the team that drove towards the vision. In other words, we figured who was driving the bus and who was on the bus, and then we identified the behavior we expected riders to have as well as the minimal skillsets needed. The bus was headed to the vision; in this case, for this financial services company, it was a new digital consumer experience. The team on the bus utilized scaled agile to deliver results; they were also trained in human-centric design to figure out what an outside-in view was. They were supported by corporate oversight–the bird. They were supported by business architecture–the cat.² The lean engine was used to break the roadblocks that they encountered by removing traditional silos and validating assumptions on the way to attaining the vision. The lean engine focused on directing the bus towards the vision, to avoid the bus going back to the traditional way of work, which is represented by a road that curves back to the original starting point.

The client used the vision shown in Figure 7-1 when articulating the program to both internal and external stakeholders and the organization at large. The image was posted in the collaborative open space where executives met for vision and mission discussions. The vision also helped in clarifying the relationship between the various frameworks they had already adopted.

Identify Customer Personas

During the first 30 days of the corporate lean strategy and implementation program, the lean leader starts discussing the persona that they will be focusing on. Actually, in most organizations the inside-out mindset prevails and little has been done in the past, if at all, to promote an outside-in understanding. Therefore the initial activities related to this task are strategic in nature.

While startups have been trained to adopt an outside-in view and rapid validation with the consumer, bigger organizations hardly ever do. The novel approach discussed in the successful Google ventures Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days³ has started a movement towards rapid validation; however, my experience has shown it is limited in scope. The design focus of these efforts creates a local solution that is not integrated into the culture of the enterprise. I believe that the missing element is the essential orientation towards an outside-in point of view. Identifying customer persona activities in the first 30 days are spent on reflecting how the enterprise presently focuses on the consumers; usually this results in increased awareness that the current operational behaviors by-and-large are not driven by an outside-in view.

Big organizations and corporations are characterized by little interaction with customers both internal and external. Take, for example, a Boston-based company invested heavily in user experience design, employing a team of 40 experts researching user personas. They ran an innovation lab that focused on innovative product design and developed creative software solutions to fulfill persona needs. The challenge, though, was the strategic orientation of customer-centric thinking. The personas served in tactical product design but were not a driver in bigger product thinking.

While the personas were well thought and articulated, the outside-in thinking was missing. This company spent three years creating a state-of-the-art configurable online editor. They had a team of 30 engineers and product designers leading the effort. The program received priority for every product design activity during the three years.

When the new software editor was release with much fanfare, the impact was dismal. As I described elsewhere, the 30% rule was observed. Only 30% of the consumers were happy with the new editor. This begs the question, why? When we engaged in a root cause analysis we found that while the product employed state-of-the-art engineering, it was detached from the personas that were researched, analysed, and printed on large canvas boards in the engineering work space. It seemed that the persona generation, creativity, and innovation was a separate effort that wasn’t integrated into how the rest of the organization was thinking. Persona development was a one-time activity that lacked integration into the required outside-in thinking. As a result, while the consumers weren’t happy with the old editor, the new editor provided too many options and encumbered the mental decision-making process, thus many consumers opted to remain with the previous editing experience.

Summarizing: The first 30 days are not about discussing who is our customer and creating a well-designed colorful depiction of our main customer; rather, it is about engaging the organization at large in a collaborative discussion about how we presently serve our consumers. Is the approach we are currently employing sustainable for the long term health of the enterprise? For the financial services organization mentioned previously, the answer was no! Its inside-out point of view was not sustainable if it wished to remain competitive in the insurance market.

Prototype MVP and Program Training

The corporate lean strategy and implementation program and the lean leader facilitate training to jump-start the program. Prototyping an MVP (minimal viable product) is a team activity. The training program is initially geared to bring executive members of the organization to experience first-hand the mindset shift that is required to be successful with lean thinking in the enterprise.

I recommend facilitating three to five two-day workshops in this timeframe, and each workshop should train approximately 25 participants. A rough sketch of such a workshop is detailed below.

Figure 7-2 is used to explain the lean process as part of the training program. Once the enterprise integrates this mindset, the opportunities for much faster development of the right set of features is ripe.

Run Experiments with Customers to Validate Your Hypotheses

Few experiments are managed in the first 30 days. The training of the executive team occurs two weeks after the program kick off. Normally the executives identify several key areas that require attention; however, they don’t articulate them as hypotheses and therefore they aren’t ready for experimenting. You will read more about key areas that require attention and lean pilot successes in providing solutions in section three.

The first 30 days are spent providing the rational for experimenting. I noticed that the knee-jerk reaction of big organizations to the concept of experimenting is refuting the need for more experimentation. In their minds, there is enough experimenting going on already and the obstacle is actually making the decision rather than collecting more data. In that sense, they are correct. Compared with startups, big organizations do have mechanisms to collect information and they collect mounds of data without ever using it; the difference is the perspective of the scientific method and engagement with the users.

What big enterprises really mean when they say that they experiment is not what I refer to as such. Take for example a VP of Product at a financial services company in New York; when I asked him whether he validated the need for additional features for an existing investment product, his answer was yes. He followed through by handing me a 25-page summary report of a three month survey they recently completed. The report was thorough but it missed the point since there was no direct experimentation with users. When I say experimentation, I mean identifying assumptions, crafting hypothesis, and creating a test plan to validate or invalidate the hypothesis. When executives think of experimentation, they often think of sanctioning a report completed by white coat lab teams.

In the microwave example from the introduction, if we were tasked with rethinking the features of a microwave, we might assume that there are too many features. Our VP of Product would probably test this assumption by sending a well-thought survey to a list of users or even conduct a survey at several big malls. This approach would actually provide the wrong results. As mentioned, there is a difference between what people say they want and how they use it. Instead, We would follow through by creating an MVP and use it to observe the usability of the product. However, before we placed the MVP in the hands of users, we would preempt by asking what results we expect to observe. That’s the essence of the scientific methods.

The step of calling out the results is crucial. And I can’t stress this enough! Yes, organizations use various data collection tools to answers questions; however, they often miss the benchmark of evaluating their initial assumptions in light of the data. The thought process is foreign to how organizations normally think about problems. Therefore, in the first 30 days, the goal is to root out the prevailing thinking at the enterprise and replace it with true hypothesis validation.

This is easier said than done. People prefer not to call out in advance what they expect to observe since they don’t want their ideas refuted. Often, when survey results return, the leaders tend to read them in light of the results they wanted to see and explain them similarly. These psychological mechanisms are well described by Nobel Prize Laureate Daniel Kahneman.⁶ When they craft a hypothesis before starting experimentation, the team must clearly state what they expect to observe, and they must make sure that the person making the assumption also owns the hypothesis. Daniel Kahneman would say that by asking the team to state the expected result prior to the experiment, they are engaging in system two thinking, which will lead to better results.

In the first 30 days, the executives explore what has been done in the past to validate the assumptions. There are often mounds of data and the goal is to explain why the data isn’t helping in the process of creating validated learning. This is achieved by turning the assumptions into hypotheses and asking the team of executives to clearly state the behaviors they expect to discover when engaging with users.

As an example, consider the following: a major retailer was replacing one of the core payment systems it had in place for years. Normally these projects last three years and run over budget, over schedule, and deliver less than promised. The CTO was rethinking the IT project approach and wanted to deliver the project incrementally. Numerous business requirements were assessed and many seemed to be reflecting legacy system thinking that was not part of the future of this organization. During the first 30 days of the lean thinking program, the executives wanted to use the approach to validate assumptions reflected in the business requirements. They mentioned a specific requirement concerning billing options. The legacy system offered billing and payment every day of the month, but to create this functionality in the new system required a considerable development effort. The CEO was adamant that the feature had to be developed since he claimed it contributed to consumer delight. Other were not so certain. The CEO had a survey supporting his claim. I used this as an opportunity to clearly state the hypothesis in a scientific approach prior to validating with consumers. Specifically, I asked the team to call out the impact to user happiness by offering the feature of every-day-of-the-month payment. This read as: 75% of users consider the billing option as a differentiator and thus affect the NPS score by 5 points on average. The next step was to create an experiment to validate the hypothesis. Four weeks later, the actual results showed that only 15% mildly considered the option as a nice to have with little measurable impact to NPS, which refuted the CEO’s hypothesis and saved a considerable development effort.

Pivot or Persevere in a Build-Measure-Learn Cycle

The experiments are starting; little validation feedback is received in the first 30 days and thus very little is done with pivot or preserve. Often the first pivot or persevere decisions occur after 90 days.

However, we need to create readiness to pivot since organizations are reluctant to pivot and actually are afraid to pivot. The shift to a culture of embracing pivots is necessary to succeed. Since many of our product and feature decisions are wrong, as mentioned in the microwave example and the recurring pattern of waste, we must put forth an agreement to embrace pivots. All too often enterprises persevere just for the fear of stopping an ongoing operation; they rationalize the decision by saying that they invested too much already and it would be a waste to stop.

The answers to these questions support the creation of a mechanism to manage the ongoing build-measure-learn cycle, which I will discuss in detail in the next chapter.