Put all your eggs in one basket

To be noticed in today’s fast world, focus is needed. Leaders and knowledge workers should ”put all their eggs in one basket”, i.e. believe more strongly in something, and act accordingly.

We should do that in four ways: Desire to change the world, change the world in an area we know something about, focus our effort on few things – that matter, and apply fast feedback and simplicity in our work.

The article explains why this is true, how it can be approached, and how to deal with the risks of putting all the eggs in one basket.

What we learned about risk management...

... at business schools, and in our management jobs, is that we must spread the risks by having a balanced development portfolio. If some projects should fail, others, with a different risk profile, might succeed. We also learned how to apply analytics in identifying the most attractive markets. And we learned how to make cost/benefit evaluations and business cases to prove effect and create support.

Whether attending business schools in the United States, Europe or Asia, the methods and knowledge acquired are very similar. It is the global lead thinking. We are taught the same best practice, and how to apply similar management tools in a similar fashion. And that makes very good sense because how else are we to create economies of scale in education, training, and management processes?

In an operationally stable environment, the future is a continuation, or an optimization, of the past. Competitive strategies imply executing the ”industry agreed” best practice a little bit better than everybody else. But when operating in dynamic environments, or when innovating, a different approach is needed. Companies need a very strong belief because they are mostly doing things that have not been done before. They need to make more experiments, take more chances, and they need to make more mistakes.

Seen from a traditional point of view, that will lead to an unacceptable level of danger and risk. Therefore, innovative organizations must have a different way of managing risks and mistakes.

If we do enough things, some of them will be successful

A manufacturer of widgets – company A – launches 37 new product models one year. Launching all these successfully requires a very thorough understanding of user needs. They acquire external research from companies that have a good track record (of doing the same thing for their competitors). They make detailed segmentation. And microsegmented analysis appears to be needed.

In our very individualistic society, consumers crave unique products and experiences. The virtues of customer focus are mass customization and needsbased segmentation. However, the effort of launching 37 widgets within a year requires an extensive coordination of technology, initiatives, project staffing, materials, supplies, logistics, sales material, and a lot of other things. It shifts focus from developing great widget user experiences towards more generalist management, coordination, and administration.

But not only that, it also dilutes that burning vision and motivation that is needed for developers to create truly great products. There is a danger that it leads to less value creation and more bureaucracy.

Another widget manufacturer – company B – develops only four new widgets a year, all of them quite expensive. The management team consists of curious practitioners and dreamers. They play with widgets, and they have a deep interest in how people actually use widgets in their daily lives. They dream of a widget that improves life for ordinary people. That is the simple, but powerful dream they communicate internally (and externally), again and again.

They do not communicate a financial dream of improving contribution rates in five key markets by 40% in three years. The reason why they don’t do that is that good developers are fueled by dreams of making great things, not by figures in a spreadsheet or quarterly bonus payments.

Company B develops only four widgets, and all the resources they save due to minimized coordination are channeled into optimization of customer experience and product quality. Of course, that is not easy, but when successful, it starts disrupting the way we usually think about segments and price points. People in the so-called low-cost segment,unaware of their own segment label, suddenly start buying expensive widgets, although they are not really supposed to.

Company B looks for similarities in needs, and not for differences. They believe that many human beings have very similar basic needs, such as ”ease of use”, ”be in charge”, ”avoid wasting time”, and ”receive recognition”. By putting all their energy into a few product experiences (dreams), they achieve something quite unusual, and make consumers seek the product, so the product does not have to seek consumers via traditional persuasive advertisingand communication.

The above story lacks a lot of details, and the companies A and B are not real companies. But if they were, where would you rather work – A or B? Many people would prefer to work in company B. But let us assume you were offered a job in company A with the task of making it more like B. What would you do?

Many people would prefer to work in company B. But let us assume you were offered a job in company A with the task of making it more like B. What would you do?

If your job was to help, what would you do?

We hope you take the challenge, and while you think about it, we would like to propose some areas to reflect upon. We list four key points, but not as a step-by-step model because the idea of just following steps might not be useful for company A or any other company for that matter. That being said, change does need to start at the top. If a company has a complex innovation portfolio sprawling with hundreds of projects, a good question would be: ”What is it, in the strategy we created and in the way we lead our organization, that makes this happen?”.

Four key points to consider if you want to change the world

All great developers want to change the world – a little bit. Developers are people creating solutions for the benefit of other people. They come in many forms: the CEO who wants to create a great company or a new business area, the line manager who wants to create great competencies and technologies, and the project managers/participants who want to create and launch great products.

1. Desire to change the world

Without that desire, we can forget about the rest. And many developers are even in a position where they have to make others desire to change the world. In fact, you might argue that all knowledge workers, at some point or another, have to sell their ideas to others.

A deep desire to change the world means that we are beyond money and position power as prime motivators. It means that we are closer to having a true vision. With a true vision, we are less anxious about looking good in front of others because we do not have to defend the position of our ego. We work for a cause larger than that. That sounds almost spiritual and a little bit silly, some would argue. Yes, working to achieve a big vision is spiritual somehow, and that is not only okay, it is necessary if we want to make a difference. Is it then okay to be ”silly”?

Throughout history, people who embarked on new explorations have always been called ”silly” and far worse things because they did things outside the norms. But creating great new things demands that we go beyond current things. How do we, and our good colleagues, get a true vision? Well, hundreds of books have been written about that. So, it is obviously impossible to make the ”plug & play answer”. But some of the elements at play are: having diverse interests and colleagues, real curiosity, lateral thinking, and the ability to ”connect the dots” across different areas. In our experience, the love for ”the thing” – the product and the user – has to be larger than the love for the administrative management game. A certain degree of ”geek factor” is not a bad thing to possess.

2. Change the world in an area you know something about

The value proposition of your organization is probably to help your customers make the world better by applying your product or services. Therefore, it is not enough to know a lot about your product. As a developer, you obviously need knowledge of the dreams, visions, and challenges faced by your users or customers.

There are different ways of acquiring this knowledge. And there are also different stages of knowing, or one might say different depths of insights. We see four stages of knowing about users:

The first stage of gaining user knowledge is to read reports made by the market research department or external agencies. That is okay, but it might not be enough. Acting on second-hand or maybe even third-hand information might leave you with an incomplete picture of what really happens. It is even possible that the people processing the information before it reaches you have an interest in presenting the data in a way that makes you require more of their services in the future. And maybe they do not fully understand the unique things you want to do to change the world, and, therefore, they are not in the right position to make useful interpretation of the data.

The second stage is to ”go and see” for yourself. It is a well-known practice by leading innovators to actually spend time in the user environment to see, feel, and smell what really happens. And even though many organizations know it makes sense, it still happens far too rarely. One reason is probably that it disturbs the ”real work”, such as desk analysis, CAD design, and the making of calculations or presentations.

Spending time with users might not be perceived as real work. But it is real work. And, like any other real work, the ability to see, feel, and smell the right things can be trained and exercised. Remembering to do so should not only be the outcome of a personal cost/benefit analysis or an act to clear your conscience. It should come naturally, driven by user empathy and curiosity. Even top managers should frequently spend time observing their users on the users’ home turf.

A third stage of knowing about user needs is ”being” your own target user. Many successful companies were started by a person who was actually trying to solve his/ her own problem, and believing that the solution could also be beneficial to other people. And for many large innovators, too, curiosity, insights, and desire come from the fact that developers are in fact developing solutions that they would love to operate or own themselves.

The fourth stage of knowing is to be the future user. A person that does not exist – yet. It is to have that rare capability of knowing which unrealized needs could be fulfilled tomorrow. Few people can do that repetitively, but we can all do it sometimes. And when we succeed in doing it, it is when we allow ourselves to dream, and are capable of visualizing future usage scenarios where solutions from different fields get connected. We succeed when we really desire to make a change, when we are interested in fields different from our own, and when we are not afraid of failure.

Individuals and knowledge organizations need to be active in all four stages of knowing. And just as it is bad to only read reports, it is also bad to only visualize distant dreams without the factuality of data and the insights from real usage.

3. Focus your effort on few things – that matter

We all know it. It has been said again and again, maybe even by ourselves: ”We need to focus on a few must-win battles, and we must execute these forcefully and fast”.

We also know the good arguments. They are several and real. With fewer really important projects, employees get a better feeling of ”doing stuff that matters”, shifting confusion is avoided, and we get more financial benefit.

If we only look at one of the arguments, financial benefit, it is obvious that situation A is less desirable than situation B. Assuming that the projects in situation A are the same as in B, the shaded area – the effort – is exactly the same, but B delivers user benefits (and, thus, revenue) faster than A. In top management teams, this fact is widely understood. But still, very few management teams have the courage to really do something about it. Why is that?

Well, probably due to many reasons.

It is healthy that ideas fight each other – as long as all of them do not win, of course. However, let us assume that the sponsors of project 1 and project 3 were to agree on which of their projects was most important. In order to respect each other and to preserve the relation, there is a risk that they would agree to run both projects in parallel. Therefore, an authority above them has to make the decision.

That authority – be it a person or a group – is facing a number of challenges, and one very big challenge. Putting all your eggs in one, or maybe two, baskets, is perceived as very risky, and, therefore, a dangerous thing to do. But what is the nature of that risk? It is, in many cases, that ”investing too much without knowing the outcome is risky business”. But is it not a paradox that spreading risk on four parallel projects actually increases that risk? The accumulated investment is the same, but we get ”real knowledge” of the portfolio performance later than if we sequenced the projects.

Entrepreneurial innovation thinking can be applied on a project portfolio, just as it can on a project. Go for fast feedback/failure and frequent evaluation. To a larger extent, risk should be managed actively (fast learning) and not passively (spreading investment). Passive risk/portfolio management may be okay when you invest on the stock exchange or in currencies where you cannot impact the outcome through your learning and effort. But in innovation where you shape the future, fast learning loops are the best risk management.

Assuming that is right, you still have to decide what to do first, second and not at all. That calls for good insights and faith. Top-down analytics and structuring of the issues are necessary. But the analysis does not have to cover a time frame of several years if the business conditions are dynamic, and they always are when you create things the world has not seen before.

Risk reducing analysis – which most analysis is – should only cover the risk until next decision (investment) point. So, in many cases, we argue that it would be better to have less ”big bang analysis” and more feedback/decision points. In the course of recent history, many innovation project managers have been asked to make solid business cases very early in their projects. And mostly, they hate it because they cannot predict it. Some even choose to insert arbitrary figures just to keep their project alive, and the management team ends up making decisions based on invalid business cases.

Doing realistic analysis and business cases will help a top manager decide which ideas to pursue. But so will a true and reflected desire to change the world in an area you know something about. In an area where you are curious and can empathize with operators, users, customers, and other people who might experience the services of your product.

4. Apply fast feedback and simplicity in your work

How each individual actually works in an organization may be the most interesting question of all. Because the joint effort is a function of many individual efforts and many individual dreams. And in innovation systems, that kind of work typically takes place in projects.

We claim that risk management should primarily be made actively in projects and to a lesser extent passively in the portfolio. And it is true that risk management is essential in projects because all the time in innovation projects we do things we have not tried before. And in the beginning of a project, we usually make a lot of important decisions on the basis of very little knowledge.

But the term risk management is also somehow a little boring. And oftentimes, we have seen risk management done half-hearted as the thing teams had to do, but did not really want to. And we all know the result of work done without motivation. Therefore, maybe we should not think of it as risk management which is typically monitoring things we do not want to happen. Could we rather monitor things we WANT to happen? If we assume that a number of people would like what we create, then how do we get feedback to verify that assumption?

Risk is always about a fear that our assumptions will not hold. The remedy to that must be concrete assumptions, and great ways of getting feedback to verify them. Therefore, a better term than risk management might be ”feedback management”.

Well, whether calling it risk or feedback management, it is about learning real and relevant things. And projects that learn fast create more success than slowlearning projects. A fast learning loop for individuals, teams, and even organizations is the best ”risk” management that exists. A fast learning loop means shifting quickly between different states, such as sensing/responding, analysis/synthesis or individual/team. At an individual level, fast learning requires knowledge workers to share ”half-finished” work with others, it requires them to make ideas and thoughts presentable although they are not thought through. And that is not easy.

Many of us are academically trained to make things ”right first time”. And when presenting output to others, we want to make a great impression, and sometimes we do not do it to get valuable feedback so we can improve, but ”secretly” to get praised for our greatness. If it happens, as it often does, that reviewers have a lot of improvement suggestions, it feels bad. It feels bad because we hoped for something else, and because we may not have time for another improvement loop. That is one very good argument for sharing ideas and assumptions earlier in a project process.

These assumptions should be identified in the very early part of a project. They could be organized in a hierarchical structure with key assumptions/needs at the top, and features addressing these needs at the bottom. With a structured approach to needs/ features, it is easier to avoid developing features that are not of value to the users. Such features are sometimes called over-engineering. The irony of over-engineering is that it also takes time: In order to develop unwanted features, we have to launch the product later than we otherwise could.

”Less is more”. ”Simplicity is the ultimate sophistication”. After a long work life, that is often what the very greatest thinkers mention as the most critical element of creating innovative solutions. An innovative solution is a simple solution to a complex problem. Knowledge workers and organizations can train their simplicity muscles by evaluating various elements of future solutions, such as functions, parts, processes, and interactions.

If they are aware of core user needs, they can ask: Which elements can be eliminated, reduced, substituted, re-used or standardized? Establishing joint design habits here creates simplicity, which will benefit customers, users or maintenance personnel. It will make solutions more precise in their value creation. And it will reduce waste, overproduction and pollution – at least a little bit.

So, if you are a developer…

… and if you want to change the world, please think about your individual ambition and approach within these four areas:

• Desire to change the world
• Change the world in an area you know something about
• Focus your effort on few things – that matter
• Apply fast feedback and simplicity in your work

Assess whether your own belief or process is strong enough. But also, please help colleagues, teams, and your organization create learning and common standards across the four areas.

Put all your eggs in one basket. Follow your vision, and do it forcefully. But doing so requires new ways of managing risks. Fast strategic and operational learning loops are needed to verify assumptions. One might call it ”Big Vision & Small Steps”.