CHAPTER 00 | ORIENT
Introduction: IE 101 and the Project Journey

Figure 5. Every innovation project is a journey from today toward a target opportunity.

What this book is for

IE 101 is for courses where students must do innovation, not only discuss it. The course may be an entrepreneurship course, an innovation challenge, a company capstone, a technical venture studio, a research translation course, or a practically oriented science and technology project class. The book gives the instructor a sequence. It gives the student a way to act.

Where the method comes from

The concepts in this book draw on 17 years of teaching, experimentation, research, and program development at UC Berkeley. That work included the Berkeley Method of Entrepreneurship, co-created and co-authored with colleagues, as well as Innovation Engineering, Data-X, engineering leadership programs, venture and challenge labs, and many industry-facing programs developed by Ikhlaq Sidhu and collaborators at Berkeley. The common lesson was direct: students learn innovation best when they work on real projects, receive feedback, build evidence, and change their thinking as they execute.

Why students and instructors can trust it

The material has been tested with Berkeley students, engineers, founders, executives, visiting scholars, and partner organizations. Programs connected to this work have involved companies such as Google, Yahoo, Amazon, Cisco, SAP, VMware, Samsung, and other technology firms, as well as universities and institutions including UC Berkeley, IE University, Lund University, the University of Jyväskylä, BI Norwegian Business School, Prague University of Economics and Business, Qatar Foundation, SRM, and others. This matters because innovation education should not be based only on opinion. It should be based on repeated practice across people, projects, and contexts.

The journey frame

Every innovation project is a journey. A team begins with what it knows today. It moves toward a target opportunity involving new users, new markets, new technology, or a new product. Good plans and smart teams can still fail because the path is uncertain. The course therefore uses a simple discipline: learn while you execute, and execute while you learn. Each week the team should improve the story and also produce evidence from customers, stakeholders, prototypes, demos, technical tests, or traction.

What the project must produce

The final output is not only a slide deck. A strong project produces a clear narrative, NABC, customer or stakeholder evidence, product design, a demo or MVP, learning from execution, and a credible next-step plan. In some courses the project may become a venture. In others it may become a capstone result, a research prototype, or a corporate innovation proposal. In all cases, the project should become more real each week.

Selected Background

• The Berkeley Method of Entrepreneurship papers, co-authored with colleagues, describe entrepreneurship education as a holistic approach built around infrastructure, mindset, and tactics, with learning organized inductively through experience.

• The original Innovation Engineering book organized these ideas into a practical framework for project execution, story development, innovation leadership, and technical behavior.

• Data-X extended the approach into applied data science, AI, and venture-style projects, with students learning tools and concepts while building real projects.

• IE 101 adapts these lessons for instructors who need a compact course text and project guide for 10- to 14-week innovation classes.

Program Background Cases

Sutardja Center at Berkeley

The Sutardja Center for Entrepreneurship & Technology at UC Berkeley became a practical laboratory for teaching innovation to engineers, scientists, founders, and technical leaders. The Center connected courses, venture projects, industry partners, executive education, and visiting scholars. It also provided the institutional setting in which the Berkeley Method of Entrepreneurship and related innovation leadership methods were co-developed, tested, and refined.

Data-X and X-Labs

Data-X showed how a technical course could teach tools and execution at the same time. Students learned data science, AI, and applied technology concepts while building projects with venture relevance. The model later influenced focused X-Labs in areas such as data, blockchain, and alternative foods. The lesson for IE 101 is direct: teach the concept, ask the team to apply it, then use the project result to improve the next concept.

From Berkeley to IE

The same project-first logic now informs work at IE University's School of Science and Technology. IE 101 uses IE as a play on words: Innovation and Entrepreneurship 101, and also a bridge to the author's current work as Dean and Professor at IE. The book is meant to be useful in Madrid, Berkeley, Silicon Valley, company capstones, challenge courses, and any classroom where students must learn by making an innovation more real.

Case Use

Use the Sutardja Center back story and Data-X as background examples. They show how project-based learning, technical work, entrepreneurship, industry connection, and mindset development came together in practice.

CHAPTER 01 | OPPORTUNITY
Starting with Opportunity, Challenge, Change, and Team

Figure 6. The four parts of any new project or venture.

Figure 7. Valuable project ideas come from the intersection of change, team advantage, and evidence.

Every project has four parts

A new project has four parts: team, narrative or opportunity, validation, and execution. Most school projects spend too much time on the pitch and some time on team formation. That is not enough. IE 101 begins with team and story, but the course must quickly balance them with validation and execution.

Starting anything new

There is a standard model for starting new initiatives. First, develop an insight. Then build a story from change and from the team's capabilities. Then validate, adapt, and build an ecosystem of stakeholders. Only later should the project move toward operational scale. In the Berkeley Method of Entrepreneurship, this is the difference between Phase 1 and Phase 2. Phase 1 is learning and discovery of the business model at the lowest possible cost. Phase 2 is scaling with operations and measures.

The three-part solution

The path of an innovation project must be learned during its execution. The first part of the solution is a story that explains the opportunity. The second part is a disciplined process of validation and adaptation. The third part is execution that builds product, market, business model, sales process, and eventually operations. Do not rush to scale before the team has learned what should be scaled.

Choose a problem with value

A good project is not merely interesting. It has a reason to matter. Work on hard and large problems when the team can develop a monopoly of insight, skill, access, or speed. The project should be difficult enough to create learning and valuable enough that someone would care if the team succeeds.

Where opportunities come from

Opportunities often come from the intersection of change and team. Look for new technical capabilities, new regulations, new customer behaviors, new markets, new tools, or new constraints. Combine that change with what the team knows, can access, can build, or cares about deeply. The first story is the explanation of that intersection.

How to find an idea

Start with your own frustration and your own story. What do you know from direct experience? What problem keeps appearing? Where do you find yourself saying, there must be a better way? A personal frustration is useful because it gives the team energy, context, and an initial customer viewpoint. It is not enough by itself. It must still be tested with other people.

Pick a target to disrupt

Another way to find an idea is to pick a target: an incumbent, process, product, institution, or industry habit that could be made much better. Ask what the target does well, what it does badly, why customers tolerate it, and what change makes it vulnerable now. The point is not to complain about the incumbent. The point is to find a wedge where a new approach can win.

Design the ideal customer experience

Imagine the ideal customer experience without first accepting today's constraints. What should be faster, easier, safer, cheaper, more personal, more transparent, or more delightful? Then work backward. Which part can the team prototype? Which part can be tested now? Which part would create the strongest proof that customers care?

Look for automation and prediction

Many valuable ideas come from work that is repetitive, manual, slow, expensive, or judgment-heavy. Ask what could be automated, predicted, recommended, summarized, matched, routed, detected, or monitored. A useful AI or data project often begins here: find a decision or workflow where better prediction or automation creates a visible improvement.

Observe change, then ask what changes next

Look for change in technology, regulation, cost, behavior, distribution, demographics, climate, science, or culture. If the first-order opportunity is already obvious, it may be too late. Ask the second-order question: what will change next because this changed first? Then validate that implication. Do not assume the future. Test whether the next behavior, constraint, buyer, or need is actually emerging.

Use leading-edge users and connectors

Watch people who are already living in the future: expert users, extreme users, early adopters, researchers, operators, and communities at the edge of a new field. Also use the connector model. A connector, like Larry Bock in many science and technology communities, can bring top people in a new field together. One strong connector on a team can create access to customers, experts, partners, advisors, and early believers that would otherwise take months to reach.

Balance will and reality

Entrepreneurs need force of will, but force of will is dangerous when it blocks observation. Successful teams act, then look carefully at what the world tells them. Progress has two forms: technical and logical progress about the product, and social progress in the ecosystem of stakeholders. Technical experts often overbuild the first and underbuild the second.

What a good early project should show

The best early project has a simple economic logic. As Naeem Zafar and Mark Burgstone have often taught entrepreneurs, the best business looks like a mailbox that receives checks: add only what is needed to make the system work. For a class project, the equivalent is a clear path from user need to evidence, from evidence to product, and from product to a believable next step.

Case Use

Caviar can be used to show practical opportunity recognition: team background, industry interest, a failed first idea, and then a stronger opportunity discovered through customer behavior. Data-X and challenge labs can be used to show expert-framed starts, where students begin from a challenge and must learn the technical and market context quickly.

CHAPTER 02 | STORY
Developing a Better Story

Figure 9. Develop the story in layers.

Figure 10. NABC is the first complete project story.

Story development

A story is not decoration. It is the working explanation of the project. It tells the team, customers, mentors, partners, and instructors what problem is being solved, why the moment matters, what approach is proposed, and what value may be created. The first version should be simple enough to say out loud and strong enough to invite feedback.

High concept pitch

The high concept pitch explains an idea by joining a known model with a new domain, market, or capability. It is the A-intersects-B form: Uber for food delivery, Amazon for a new geography, or Jaws in space. A high concept pitch is useful because it is fast. It is not enough because it usually hides the customer, the need, the evidence, and the competition.

Elevator pitch

The elevator pitch is a short spoken version of the story, usually two minutes or less. It should create attention and explain the problem, the proposed solution, and why the project matters. It may include a high concept phrase, but it should not stop there. A good elevator pitch should make the listener want to ask a useful next question.

The NABC model

NABC stands for Need, Approach, Benefits, and Competition. It is the first complete story model students should master. Need explains who has the problem and why it matters. Approach explains what the team will do. Benefits explain the value created. Competition explains the alternatives and why this approach should be chosen.

The customer story

The customer story shows how a user or customer experiences the product or service. It may look like a short commercial, product announcement, customer case, product demonstration, or mockup. It should make the use case memorable. The team should be able to say: this is the customer, this is the problem, this is what changes, and this is the result.

The future press release

A future press release is written as if the project has succeeded. It forces the team to describe the future outcome clearly. What would the headline say? Who would care? What problem would have been solved? What proof would make the result newsworthy? This format helps teams see whether their ambition is clear or vague.

The six-page plan

Amazon's six-page narrative memo is useful because full sentences expose unclear thinking. A six-page plan begins with context, explains the question or decision, compares approaches, states what is different, and ends with what matters for the customer, the organization, and the innovation. Students do not need a full six-page plan early, but they should learn the discipline behind it: write clearly enough that the thinking can be tested.

The venture pitch and its variations

The venture pitch is the longer stakeholder presentation. It often includes problem, solution, value proposition, market, product, business model, technology advantage, competition, team, financials, timeline, and ask. The same structure can be adapted for corporate projects, public service projects, technical initiatives, and capstones. The slides are not the story. The slides support the story.

Which story type should you use?

Start with the simplest story that creates useful feedback. Early teams should usually begin with a high concept pitch, elevator pitch, or NABC. After feedback, the team can develop a customer story, future press release, six-page plan, or venture pitch. Use the story type that helps the next stakeholder understand and respond.

Revenue and non-revenue projects

Not every project generates revenue directly. A public service, internal tool, research prototype, or company capstone may be judged by mission, adoption, user satisfaction, speed, cost reduction, risk reduction, or learning. The story still matters. Replace the business model with a mission model when needed: how does this project serve the organization or the people it exists to help?

Perfecting the story

The first story will have gaps. It may have missing evidence, too much detail, unclear benefits, weak logic, or a poor solution. That is normal. The story only needs to be good enough to start. It improves when the team tells it to credible stakeholders, listens carefully, collects feedback, and realigns the project.

Judging the story

A simple early test is Excitement, Logic, and Social power. Excitement asks whether people care about the story. Logic asks whether the story makes practical sense. Social power asks whether the team can attract stakeholders, partners, customers, and supporters. A project with a strong story should create energy, withstand questions, and recruit help.

Case Use

Use Caviar as a reminder that a practical customer story can precede sophisticated technology. Use Oracle later as an example of a story that changes how an enterprise understands a process.

Story Forms at a Glance

NABC Working Draft

Judging the First Story

CHAPTER 03 | DIAGNOSE
Common Strategic Errors and Story Narrative Mistakes

Figure 11. Common story and strategy mistakes to check before the next execution cycle.

What could possibly go wrong?

As a story becomes a fuller pitch, it will be evaluated, questioned, and challenged. The story does not need to be perfect, but it should avoid mistakes that waste time, weaken credibility, or send the team toward the wrong work.

Use the idea immediately. If it does not change the next interview, build, demo, decision, or pitch revision, it has not entered the project.

All logic, no emotion

A story can be logical and still fail because nobody cares. The problem should have human pain, urgency, frustration, or aspiration. The benefit should create energy. Without emotion, the listener is left with the question: who cares?

Use the idea immediately. If it does not change the next interview, build, demo, decision, or pitch revision, it has not entered the project.

Solving the wrong problem

Many teams solve a problem that customers do not actually have, or they validate a real problem but offer the wrong solution. The team must listen carefully enough to separate the problem it wants to solve from the problem customers actually need solved.

Use the idea immediately. If it does not change the next interview, build, demo, decision, or pitch revision, it has not entered the project.

Unquantified value proposition

A value proposition should eventually be quantified. What value is created? What is the next best alternative? How much time, cost, risk, effort, revenue, or satisfaction changes? If the value is large, the project has room to learn. If the value is small, the project has little room for error.

Use the idea immediately. If it does not change the next interview, build, demo, decision, or pitch revision, it has not entered the project.

Market size nonsense

Do not use a large market number just because it sounds impressive. Use the right market. Then estimate from the bottom up: who will buy or adopt, how many, how often, at what price or value, and in what realistic first period?

Use the idea immediately. If it does not change the next interview, build, demo, decision, or pitch revision, it has not entered the project.

Financial model errors

For revenue-generating projects, the team must eventually understand customer acquisition cost and lifetime value. If the cost to acquire customers is greater than the value those customers create, the model is broken.

Use the idea immediately. If it does not change the next interview, build, demo, decision, or pitch revision, it has not entered the project.

Core competency errors

Inside an existing organization, a new project must make sense relative to the organization's core competencies, assets, and strategy. If the project does not fit, the team must explain why the organization should still do it or why another organization is the right home.

Use the idea immediately. If it does not change the next interview, build, demo, decision, or pitch revision, it has not entered the project.

A final note on starting inside organizations

A proposal must be good enough that a management team can sponsor it, fund it, and protect it. The team should communicate the story, the competency fit, the customer or mission value, and the first execution path clearly.

Use the idea immediately. If it does not change the next interview, build, demo, decision, or pitch revision, it has not entered the project.

Case Use

VMware can be used as the main case for this chapter because it shows how technical logic, business story, market direction, acquisition, scale, and trust all interact.

CHAPTER 04 | BUILD AND TEST
Execution While Learning: Building, Testing, and Getting Traction

Figure 13. Story and execution advance together.

Execution Is Not Only Building

Execution means moving the project toward proof. A team executes when it interviews a real user, runs a test, builds a demo, measures usage, secures a pilot, recruits a partner, or learns that an assumption is wrong. Building slides can support execution, but slides are not execution by themselves.

Build Only What Teaches the Next Lesson

The first build should be small enough to complete and clear enough to test. It may be a manual workflow, clickable mockup, data experiment, prototype, simulation, service trial, or working MVP. The question is not whether it is impressive. The question is whether it produces useful learning.

Figure 14. The project loop: build, test, learn, revise.

MVPs, Demos, and Traction Signals

A demo makes the project believable. An MVP creates useful learning with a real user or stakeholder. A traction signal shows pull from the world. At student scale, traction may include repeated use, sign-ups, pilot interest, a letter of intent, referrals, a technical benchmark, or a stakeholder asking for the next version.

• Customer proof: someone has the problem and wants it solved.

• Technical proof: the core function can work well enough to matter.

• Value proof: the benefit is visible, measurable, or important.

• Adoption proof: someone has a path to use, buy, sponsor, or support it.

• Traction proof: the world pulls the project forward in some observable way.

The Weekly Execution Rhythm

Each week should produce evidence. The team should decide the highest-risk assumption, choose the smallest useful action, collect evidence, and revise the story and build plan. This rhythm prevents the project from becoming either a slide exercise or an unfocused build.

Practice Exercises and Questions

• What is the highest-risk assumption in the project right now?

• What is the smallest build or test that could change the team's mind?

• What evidence would count as traction at this stage?

• What did the last build or test prove, and what did it fail to prove?

Project Guide

1. Define the Iteration 0 build target.

2. Run at least one user, customer, stakeholder, or technical test.

3. Record evidence in the project log.

4. Revise the NABC and demo plan based on what was learned.

CHAPTER 05 | EVIDENCE
Common Mistakes: Strategy, Story, Evidence, and Execution

Figure 15. Common story and strategy mistakes to check before the next execution cycle.

A Clear Story Can Still Be Wrong

Many teams believe that a clear pitch means the project is becoming true. That is a misconception. A team can speak clearly and still be solving the wrong problem. It can describe a large market and still have no adoption path. It can show a prototype and still have no evidence that anyone cares. The purpose of this chapter is to make the team harder on its own reasoning.

The Most Common Mistakes

• All logic, no emotion: the argument is rational, but no one feels urgency.

• Solving the wrong problem: the team built around an assumption instead of the user's real pain.

• Unquantified value proposition: the benefit is attractive but not measurable.

• Market-size nonsense: the team uses a large top-down number instead of a believable bottom-up path.

• Financial-model errors: the economics do not match the real selling, delivery, or operating model.

• Core-competency errors: the project requires capabilities the team or sponsor does not have.

• Evidence gaps: the team confuses activity, compliments, or slide polish with proof.

Diagnose the Evidence Gap

Before the next iteration, name the missing proof. Is the gap customer proof, technical proof, value proof, adoption proof, traction proof, or team-execution proof? A team that can name the gap can choose a better next action.

Figure 16. Use the evidence gap matrix to choose the next project action.

Example: The Friendly Interview Trap

A student team interviews ten classmates. Eight say the idea sounds useful. The team concludes that customer validation is strong. In contrast, a better test asks whether anyone has tried to solve the problem before, paid for an alternative, joined a waiting list, used a prototype twice, or introduced the team to a real buyer. Friendly interest is not yet traction. Behavior is better evidence.

Repair Before Scaling

The project should not scale until the team has resolved the most serious uncertainty. Scaling a weak assumption only makes the mistake more expensive. The practical discipline is simple: identify the largest risk, design the smallest useful test, and update the story honestly.

Practice Exercises and Questions

• Where is the story overclaiming?

• What is the weakest evidence in the current NABC?

• Which assumption would an investor, sponsor, or customer challenge first?

• What should the team stop doing because it is not producing evidence?

Project Guide

1. Mark the project evidence gaps by type: customer, technical, value, adoption, traction, or team.

2. Rewrite the weakest part of the NABC.

3. Choose one test or build that directly addresses the largest gap.

4. Prepare a revised 10- to 12-slide narrative only after the evidence plan is clear.

CHAPTER 06 | LEAD
Innovation Leadership

Figure 17. Innovation leadership connects trust, context leadership, technical leadership, and the shared story.

Leadership Begins with Trust

Many people believe leadership in a new project begins with vision. Vision matters, but this is incomplete. In an innovation project, leadership begins with trust: trust in integrity, trust in competence, and trust that team members will put the project ahead of personal ego when the evidence changes.

Context Lead and Technical Lead

A strong project usually needs both a context lead and a technical lead. The context lead keeps the team close to users, customers, stakeholders, timing, value, and adoption. The technical lead keeps the team close to feasibility, architecture, implementation, risk, and proof. One person may play both roles for a short time, but the work is different.

Example: Two Leaders in One Student Team

A health-tech team has one student who understands hospital workflow and another who can build the prototype. If the technical student dominates, the team may build a clever dashboard no nurse will use. If the context student dominates, the team may promise a product that cannot be implemented. Leadership means keeping both stories alive until they converge.

Planning, Urgency, and Agility

While many teams think agility means changing direction whenever a new idea appears, real agility is disciplined. The team sets a plan, tests it against reality, and changes only when evidence justifies the change. Urgency without learning becomes chaos. Learning without urgency becomes drift.

From Growth to Alignment

As a project grows, leadership becomes less about inspiring the first action and more about keeping people aligned. New members, advisors, partners, and stakeholders create more capability, but also more noise. The leader must keep the project story, evidence, and next build visible to everyone.

Practice Exercises and Questions

• Where does the team have strong trust, and where is trust fragile?

• Who is currently acting as context lead? Who is acting as technical lead?

• What conflict is the team avoiding because it feels uncomfortable?

• What weekly rhythm would make the team more honest and faster?

Project Guide

1. Name the context lead and technical lead for the next iteration.

2. Write the next weekly evidence question before assigning tasks.

3. Hold one direct team conversation about trust, roles, and alignment.

4. Update the demo plan so technical work and customer learning support the same story.

CHAPTER 07 | CULTURE
Culture, Mindset, and Behavior

Figure 18. Culture is mindset made visible through behavior.

Culture Is Not a Slogan

Many organizations talk about innovation culture as if it were a list of values on a wall. That is a misconception. Culture is what people repeatedly do when there is uncertainty, pressure, disagreement, and incomplete evidence. In a course project, culture is visible in how the team handles feedback, conflict, deadlines, and disappointment.

Behaviors That Support Innovation

• Storytelling: turn scattered facts into a narrative people can understand and improve.

• Trust: make it possible to say hard things early.

• Comfort-zone expansion: practice doing useful things that initially feel unfamiliar.

• Accretive negotiation: look for ways to make the total outcome better instead of simply dividing value.

• Connectors: bring people, knowledge, customers, and resources into the project.

• Diversity: increase the team's ability to see different problems, users, and solutions.

• Inductive learning: learn from real cases, behavior, experiments, and examples.

• Grit and emotional intelligence: keep moving without losing the ability to listen.

Example: The Connector Behavior

A team working on climate analytics needs access to building managers. One student does not know the technical model, but does know an alumnus in commercial real estate. That introduction produces three interviews and a pilot site. The connector behavior changes the project more than another hour of internal debate.

Mindset Differences Across Project Stages

Early-stage entrepreneurial teams need breadth, speed, and comfort with ambiguity. Later-stage technical teams need depth, discipline, architecture, and reliability. In contrast to the common belief that one innovation personality fits all situations, the better view is situational: the team must develop the behaviors required by the stage of the project.

Practice Exercises and Questions

• Which team behavior most helps the project right now?

• Which team behavior is missing or underdeveloped?

• Who served as a connector this week?

• Where does the team need more breadth, and where does it need more depth?

Project Guide

1. Choose one innovation behavior to practice deliberately this week.

2. Ask each team member to identify one comfort-zone expansion.

3. Add at least one connector action to the project plan.

4. Revise the team rhythm so feedback, evidence, and decisions are visible.

CHAPTER 08 | TECHNICAL BEHAVIOR
Technical Behaviors for Innovation

In the last section, we described a set of general behaviors and characteristics that support innovation. In this section, we will focus on the behaviors and mindsets that are the most appropriate for technical leaders and technical architects. The text explains how these behaviors intersect with entrepreneurial and innovation processes. Successful entrepreneurs/innovators have always known how to target the most valuable of problems by using storytelling, inductive learning, and agile implementation processes. In parallel, great technical architects have always understood how to solve complex problems by breaking them down to a fundamental systems-level, all while keeping the design as simple and effective as possible. We have observed that there are significant similarities between the entrepreneurial business process of creating a new venture and the technical process of creating, architecting, designing, and developing an early-stage technological innovation

System Architecture Development Entrepreneur/Innovator Start with the user’s story -> Get to Effective Implementation 1.0 Start with user’s story -> get to Business Model Break it down: first principals/relationships Use story to gather stakeholders/ resources Agile execution Inductive learning Minimal Viable System: Keep it Simple Minimal Viable Product for market fit Use broad thinking to reduce failures/flaws23 Use broad thinking to reduce business risk This table illustrates the parallels between System Development and the Entrepreneurship/Innovation Process From the table above, we can immediately see corresponding steps between the technical and contextual aspects of an innovation project. With these similarities in mind, we must also acknowledge the many aspects of the process which are specific only to the technical team. In the text below, we will focus on the best practices and behaviors that are the most relevant to the technical lead and the technical team. User-First Both the technical and business perspective should always start with the user’s perspective. Note, this is sometimes considered the customer’s perspective. The business objective is to find a working business model or mission model, while the technical objective is to 23 Could be written as increase robustness, increase reliability, reduce cost, increase performance (all are true while holding other variables constant)

get to an effective technical implementation. An important mindset for a technical leader is to begin with the user’s viewpoint first. It is only once this viewpoint is clearly established that the system architecture and the implementation can begin development. Break it down While the context lead is focused on using the story to gather stakeholders, customers, investors, team members, etc., the technical lead must evaluate potential solutions by breaking the proposed system down into simple sub-systems with minimal inter-connections. Critical thinking is always needed to understand the interactions and causal relationships between subcomponents. Of course, if a subcomponent already exists or can be easily obtained, then there is no need to build or redesign that subcomponent. For example, when Tesla created its battery, they began with the thousands of cells that were already being produced in mass scale, instead of designing a completely new battery architecture. Effectuation Great technical innovators and entrepreneurs all use “Effectuation Principals” in a natural manner. Roughly, what this means is to start by taking inventory of what you have first. By way of illustration, consider the process of making a home-cooked dinner. Would you first choose an intended dish, and then gather the ingredients (not effectuation)? Or, would you look at what you already have in the kitchen and then invent a new recipe from these ingredients (effectuation)? This principle can be applied to technical and business projects in the same manner. Look for Insight in the technical story Search for insight about the location of value, the power, or “the magic” in the system design. What will make it effective or exciting? This concept is a technical parallel to the entrepreneurial behavior

of understanding the user’s true needs, what they actually care about, or what they are willing to pay for. Minimal Viable System Architecture Get as quickly as possible to a 1.0 version. Distill the story as quickly as possible to the simplest possible implementation. From this, a more complex system can be evolved using an agile, iterative model to develop greater capability. This is parallel to the entrepreneurial approach of building a Minimum Viable Product (MVP) for testing product market fit, but in this case the focus is the system architecture for testing technical feasibility. Agile Increments and Flexible Technology Strategy: After developing a minimal demonstrable solution, use agile increments to prioritize further development:

1. Start with the simplest possible demonstration on the path to the best solution.

2. Use a technology strategy that allows for easy adaptation.

3. Be agile driven. Accept that it is impossible to predict the final product in advance. Keep it Simple The focus of the project should be on keeping the design simple, easy to explain, easy to verify, and easy to debug. Technical architects and designers are often interested in technically brilliant and complex solutions, but true elegance lies in simplicity. As quoted from a historical Apple advertisement, “Simplicity is the ultimate sophistication.” You might think of this in parallel to timeless works of art, which are characterized by having exactly what is needed to convey the message but not a single extra stroke of the brush.

Reduce the Downside Optimize to reduce the downside of risk and failure, not to maximize cost and performance. Always evaluate corner cases. This is the parallel of broad vs. narrow thinking within engineering. The broad thinking version in business would be used to avoid business risk as well as predict the expected outcome in the broadest terms. Measurable Objectives Develop measurable objectives to identify when goals are being achieved; you cannot improve what you cannot measure. For example, in a data science algorithm, how will you know that the prediction is good enough? Having both a measure and a target allows you to estimate whether the work needed to achieve a marginally higher result is even worth the expense of doing that extra work. To understand this more, learn about the concept of Value of Perfect Information. See Hubbard, “How to Measure Anything”, Wiley. Create a support ecosystem Build a support ecosystem with the highest quality partners that you can both reach and trust. Many technical leaders are tempted to reach out to the more convenient lower-quality contacts (team members, suppliers, partners, customers, etc.). These may be easiest to contact, but it will not result in the highest quality outcome. As long as trust can still be maintained, it is a best practice to push out of our comfort zones and find the most ideal people and organizations that we can.

Summary This section was written to provide a wide-ranging understanding of the behaviors and mindsets needed for technical teams and their leaders to successfully develop innovative projects. In case examples, we will see that these same behaviors come up frequently. We also note that behaviors beyond the ones listed have been identified in these cases.

CHAPTER 09 | INTEGRATE
The Solution Explained in 12 Principles

Figure 16. Every innovation project is a journey.

Every Innovation Project is a Journey As we formally defined previously, Innovation Engineering is a framework to create or transform anything aided by aligning human talent in an efficient, effective, and positive manner. This framework offers practical guidance useful in large firms, research labs, new ventures, or even innovative student projects. Also reproduced from the first chapter is the illustration below. It shows that an innovation project is a journey and it outlines the elements of any successful innovation project: i) Initial conditions ii) A compelling story/strategy iii) Execution while learning iv) Innovative leadership, behaviors, and mindsets

As in the illustration, the Innovation project is a journey or sequence of steps. Framework Preview with 12 Principles Building upon the concept of a project journey, this section provides a preview of the major concepts of Innovation Engineering. It is written in the form of 12 principles. These concepts are explained in question and answer format and they characterize how teams successfully navigate innovation projects. Warning, this next section densely packed. We even use some terms without definition. This section is written in this manner to quickly preview the concepts of the book. In subsequent chapters, we will clarify these terms and expand these concepts.

Q1. How do Successful Projects Start? Principle 1. Start with Story: Innovative projects start with a story narrative. (E.g. NABC, AxB, "low-tech demo", or inspiring product demonstration). Many projects go wrong because they start with a list of requirements. However, by starting with a story such as a venture pitch, a “low-tech demo”, or NABC narrative (which was used by SRI during the invention of Siri), it allows the everyone to better understand and agree on the objective of the project from the beginning. Refence: Berkeley Method of Entrepreneurship (BMoE), Oracle Case, Netscape Case Q2. What is the difference between Story and Strategy? Principle 2. Strategy: Remember that strategy should be set by the question of "how will the project win" in context of your mission. Example: Story = Problem + Solution: People need to eat + we offer a new restaurant Strategy = What unfair advantage will we create? What actions will you take so that others will not be able do it cheaper, better, or faster. Business strategy is a set of investments and activities that allow a firm or project to have an unfair advantage. It is not enough to be able to offer a product or service, the offering must be produced at a lower cost, or have a capability that cannot be copied, serve a niche, or be differentiated in another way that others cannot easily copy. Reference: Strategy definitions of E&Y and others

Q3. What is Technology Strategy? Principle 3. Technology Strategy: A team should set technology strategy to achieve flexibility, speed, and ease of incremental development. Besides creating a strategy for the overall project, a technology strategy creates an advantage in the way that the product or service is put together. The choices of platforms, tools, and components can make a very large difference. It can be a great advantage when these choices make the speed of development faster or when they enable quick changes. In the NVIDIA case example, the product allowed the advantage of ease of programming not for itself, but for its customers which opened a new market for GPU processors. In addition, the most successful innovators also know how to solve complex problems by breaking them down to a systems-level, all while keeping the design as simple and effective as possible. Reference: NVIDIA Case Q4. What is the first decision to make to define a new project or product category? Principle 4. Project Scope: Choose a project scope or objective which the ecosystem will support. The project plan may include partnerships, ecosystem development, or internal stakeholders from the start. For example, when Caviar, the food delivery app, was first being created, they chose the scope of business to be food delivery services because they realized that restaurants would not mind giving up that service to other companies. The delivery service function was actually considered to be a distraction to the main business of most restaurants. Reference: Caviar Case Q5. How can we know if an early stage team is making progress? Principle 5. Team Evaluation: A successful project should have:

1. an exciting story

2. high powered execution

3. social progress

Not every team member has to have all capabilities, but trust and mutual appreciation among the team members is necessary. When investors or managers think about supporting a project, they need to consider all of these factors. Available at berkeleyinnnovationindex.org, there is a BMVS survey of under 10 questions that can help managers and investors evaluate a team based on these factors. Reference BMoE Q6. How does a team learn to execute something new? Principle 6. Execution while Learning: A team should use inductive learning and reflection to execute in new areas. Learning may occur in areas such as technology, tools, validation, business model, descriptive language, sales cycle or other areas. For example, for an innovative team with primarily technology-oriented members, the team may have to develop business acumen at the same time as building the product itself. As we will see in the next chapters, this type of learning advanced by observing the environment, separating knowns from unknowns, and repetitive self-reflection. Reference: BMoE Q7. How is inductive learning embedded into project execution? Principle 7. Agile Increments: Project execution is accomplished in agile increments, generally starting from the user’s touch point. This means that while the team is following its strategy, it develops the complete project increments. After each incremental step, a reflection process is used to understand what is working, what is not working, and what is most important to correct in the next incremental step. This is in contrast to mindlessly following a plan only to find that the resulting project has missed its objective. Reference: Design Thinking, Experiential learning

Q8. What does the team need to do after making a hypothesis? Principle 8. Test or validate everything: Always be able to separate what you know will work and what you don't know. Seek truth, avoid spin. For example, when NVIDA was testing its Fermi project, the product had a problem, but the obvious or simplest explanation turned out to be wrong. The best practice is to verify every assumption while trying to figure out the issue. The same is true for business and customers. Every assumption about what a customer wants must be validated no matter how obvious it seems. Reference: culture in NVIDIA Case Q9. To be an effective innovator, a person should know ____? Principle 9. Powerful tools: Learn to use enough powerful tools. Whether we are talking about software tools we teach in Data-X, the command line interface of a router, or business applications in a given industry, it is important to be proficient with multiple tools. The same is even true for theoretic tools. Richard Feynman, the famous Nobel Prize winning physicist, said that as a punishment, he was assigned to solve integrals in many ways. It turned out later that in solving complex problems, when others gave up, he had more “tools” that he could try, while others just did not have enough options. Reference: Richard Feynman, Data-X Q10. What is the job of the innovation leader? Principle 10. Innovation Leadership: A leader’s primary job is to select, recruit, support, and align the best team. The most important element within the team is trust. An innovative leader's downfall is insecurity and ego. The innovative leader should welcome feedback and develop the strength to avoid egotistical or insecure habits. (Reference BMIL)

Q11. What are some of the behaviors and mindsets needed by the team? Principle 11: Behavior and Mindset: Innovation behaviors across the team should include wide comfort zone, EQ, grit, and a balance of broad thinkers and reliable, operational/functional experts. The original team starts with mostly broad thinkers. Positive mindsets include • "I can accomplish or learn anything" (growth), • "Resources are abundant" (to avoid over-competition) • "Adversity can be channeled to become a source of strength” (motivation). Team members should affirm positive beliefs about themselves (confidence). (BMoE, BMIL, VMware Case). A related example made famous by Nike, suggests “Just do it” which is both growth-oriented and self-affirming in mindset is a better than “We are good at making shoes” which is a factual, but fixed mindset that may even constrain the company’s growth into new areas. Reference: BMoE, Dweck, Covey Q12. How can we make any environment better for innovation? Principle 12. Innovation Environment: An environment that fosters innovation should allow intellectually diverse types of people to mix/collide together under pressure and common purpose. It has been a hallmark of innovation at Berkeley that mixing talented people with different backgrounds and ideas, and putting them together on projects with common purpose has been a key to innovation. That innovation is stronger when people are mixtures of different professional segments from on-campus and off-campus. Whether you are creating or joining an incubator, a design firm, or innovative corporate environment, the key is the mixing and trust building of intellectually diverse, capable people who can find

common purpose together. Reference: Innovation Collider at Sutardja Center Summary In this section, we previewed the concepts of Innovation Engineering in 12 Principles. In the next chapters, we will explain these concepts in the form of as a step by step guide and in the order that maximizes their value for a project’s success.