Project and Venture Execution with Innovation Engineering

By Ikhlaq Sidhu | May 31, 2019

Why Execution Matters So Much – And Why It Still Gets Ignored

In our courses, boot-camps, and related Berkeley Method programs, we often explain that there are 4 parts to any successful technology project or venture. These are:

1. Story
2. Team
3. Validation
4. Execution

And, in a classroom environment, Story and Team get a lot of coverage.  Plenty of attention goes to Story, which is typically conveyed through the slides used to pitch the project. Much attention is also paid to Team formation, which is about the right balance of people on the project.

Execution is difficult to accomplish in academics, it is the hardest to do in reality, and it is the most valuable of the activities.

On occasion, some courses manage to genuinely cover Validation, i.e. talking with customers and partners to achieve product-market fit. To give credit where it’s due, Steve Blank’s work has highlighted Validation as a missing key component and has improved this weakness in project success.

However, in real-life, the biggest success factor by far is Execution, and yet it is rarely covered in the classroom. Execution is difficult to accomplish in academics, it is the hardest to do in reality, and it is the most valuable of the activities. In fact, Execution is not even well defined. Some teams seem to execute well and make great progress, while others teams with the same idea don’t make much progress at all. People might assume good execution is simply the same as working hard, but of course there is more to it. 

To fix this ambiguity, we will clarify Execution for early stage technology projects and for new ventures in enough detail to make good Execution practical to accomplish.

Where Execution Fits within Innovation Engineering

From our experience, technology projects and ventures cannot begin any process of execution until the initial conditions below have been set. Before proceeding to Execution, the team should resolve to be clear about these 3 topics:

1. Concept of the venture or project is articulated.  This is often communicated in an A x B format, e.g. A = Banking (a business), B=available only online (a new trend or technology). In this case we are making Banking possible online.
2. A target of competition is known. This means that the team is aware of firm(s) or technologies they intend to replace.
3. A match of skills and interests must exist between the team and the objective of the project.

Once these initial conditions are set, the business and technical story can be developed. The next step is Execution. Execution in this case does not mean that we make a list of steps to do and do them. That could only work if we knew the list in advance. In the case of a venture or early stage technology project, we must execute while learning and experimenting. We will call this type of Execution path a “Learning Journey.” As illustrated, this part of the process includes discovering and implementing a working business model as well agile implementing the key technology, product, or service.

What is Missing

While this may look like it spells out an Execution process, it really does not because the Learning Journey and Agile Implementation portions are as yet not defined, and therefore Execution has not yet been explained. This is exactly what we will clarify immediately below.

How can we Teach and Practice Execution?

The goal here is to make good Execution understandable and predictable.   As shown, there are two parts to the Execution phase that follow the initial story development. One is the Learning Journey where we develop the entire venture and/or organization. The other is the Agile Implementation process where we develop the product/technology. These two are interconnected with each other.

Getting Started Requires a Project CEO and Project CTO

To start the process of execution, there must be one person dedicated as the lead of the venture or project, i.e. project lead, venture CEO, etc. A second person is typically required for the agile development, or possibly just the prioritization and/or management of that development. The technical lead may be the venture CTO, a hacker, or possibly the Scrum Master in a project within a large technical organization. As a shorthand, let’s refer to these leads as Project CEO and Project CTO. These two people must be able to trust each other and work together with a high degree of communication.  There are exceptions when one person can play both roles in the beginning, but separate roles are highly preferred.

Before we go on, we must note that a log or journal must be kept during the project. Both the Project CEO and Project CTO must contribute to the log.  The log is to record the actions and considerations in the Learning Journey and Agile Implementation. This is important for the team to be able to reflect, to learn, and to take the most effective actions during the process. 

Learning Journey

When it comes to the creating/executing the business or organization, the key function is to learn and navigate while you Execute. This involves 3 components:

1. Separating knowns from unknowns
2. Strategy adjustments
3. Collecting people and other resources

These three components form a cyclical, iterative learning process.  The Learning Journey is typically run and owned by the Project CEO (i.e. product manager in a larger organization). The Project CEO continuously cycles through each of the above sub-components, and this process keeps adding new information and resources into the project. These iterations can be daily, weekly, or monthly depending on the stage and type of project/venture.

1. Separating Knowns from Unknowns:

This component is about listing what you know how to accomplish versus what you are yet unsure how to achieve. There are of course just examples, but the “Knowns vs. Unknown” list might look like something this:

Known:

1. validated the customer pain  
2. being able to demonstrate a solution
3. …

Unknown:

1. validate that the product actually solves the customer’s pain
2. knowing is the solution can be scaled for more customers
3. …

This process highlights the boundary between knowns and unknowns, which is where we can find the highest impact point for learning and execution. The action required in this process is to prioritize and select the next objectives to learn. The team then make progress by trying experiments and testing various hypotheses as part of the process.

2. Strategy Adjustment

A second component in the learning process is Strategy Adjustment.   This means that the team must regularly ask the question, “How will we win?”.  The answer may change over time as new information is gathered.   

Strategic change is about choosing a variation in the path or destination.  If we were actually using a map to plan a trip, the strategic question would be whether we should choose a different route or even try to reach a different destination, based on new information that we discover along the way — such as the changes in weather or traffic congestion.

In a project or venture context, examples of strategic re-evaluation would include:

• What does it mean to win? It is possible that even the definition of success of the mission has changed, i.e. has our intended destination changed?
• Do we now wanting to build a platform versus a product or service?
• Is the current business model still correct? Product, Service, Pricing, Channel, … etc.
• Do we need to prioritize different features? Where is our new value?
• Do we need a different mix of team skills? Do we need to recruit different types of team members, advisors, partners, customers, etc.
• Has the environment changed? Context from the news, social behaviors, or technical drivers may change the team’s approach. For example, has new technology been introduced in the market that can be used off-the-shelf instead of building it?

3. People, Resources, and Ecosystem

The final component of the Learning Journey is to prioritize and collect the collect new stakeholders.  Again, this may include team members, advisors, investors, customers, partners, etc.  Note that adding new people can be considered the same as collecting resources or funding. A new team member if chosen well may bring a working prototype with them. Another might bring channel relationships that are very much needed. The right advisor might be the key to a funding source or large customer. In each case, we should be strategic in the selection of people. Having too many people is unhelpful, having fewer people with the right assets and skills is very effective. When all the stakeholders are recruited, it results in the ecosystem that will be needed to grow the project or firm. 

Again, to be clear, the goal of this component is to use the new information that is learned to select and recruit new people to the project/venture and its ecosystem. And again, this should be considered as the approach for growing the project/firm and for collecting funding and other resources.

Learning Journey Summary

When we put these components together, it creates an iterative, inductive learning process that results in the development of the new project or venture. Each component brings new information and resources. These are used in the next step to further reflect and take actions. These actions may include experiments to prove a hypothesis, setting of a new strategy, and the recruitment of new stakeholders. Both, execution and learning happen along the way. 

Agile Implementation

Agile Implementation is the way that the product, service, and/or technology will be developed. This is a topic that has been richly covered many times. It is used broadly in Silicon Valley and in technology centers around the world. The objective here is not to re-explain Agile or its benefits, but instead to show that the Agile Development process is continually being informed by the Learning Journey described above. In this manner, it is integrated with the Learning Journey as part of the execution process. 

To begin the process, the Project CTO must drive it.  As the team grows, a Scrum Manager might take on the prioritization aspects of this role. This may also happen in coordination from the product management lead when the organization is larger. For a new venture, it is typically driven by one of the founders who take the lead technical role.

The other step to begin the process of Agile Implementation is to have a version 1.0 of the technical story.  In our work at UC Berkeley, we have used this outline below, and often refer to it as a “Low-Tech Demo.”  The Low-Tech Demo outline is one example of a technical story and is often communicated within a 5-7 page slide presentation:

1. What is the project supposed to do — and ideally why
2. User’s perspective, top 3 user expectations
3. Key technical components with risk levels
4. An architecture
5. Short-term plan and assignments towards the simplest demonstration

As mentioned, the Agile process is covered in many sources, however, the illustration below is still very helpful to understand how we launch an agile process in our programs at Berkeley within the Innovation Engineering approach.

As shown, the team forms they may be aware of a high-level business/contextual story, but the technical implementation is not yet clear.  Together the team would brainstorm possible technical solutions in an open-ended manner. Then in a norming phase, they reduce their ideas to generate the low-tech demo as outlined above. Next, the team designs the simplest possible demonstrable system. The team must be able to demonstrate a minimal viable product or demonstration within 2 weeks, no matter how simple or skeletal. After this, the Learning Journey may inform the agile process to select and re-prioritize features and technical approaches. Note that many behavioral cultural norms are used to increase innovation speed as we have written before. In a 13-week project, there is time for at least 4 agile sprints of length 2-weeks after the pre-MVP. This process may vary with organizational context within firms as well as project length and project complexity.  However, the key aspects and method of launch stays the same, as does the level of integration with the Learning Journey.

Conclusion

Presented here is clarifying explanation of how early stage technology and business projects are launched and executed.  The goal has been to demystify Execution processes for these types of innovation projects.  Our objective is to reduce the high variability in success rates with early stage innovation projects.  We have observed that these processes have turned out to be very effective in both academic and in industry settings.   Increasing the success rate and predictability can lead to a much higher success rate globally and for our industry partners.  Your comments and feedback are always welcome.