Don't develop products – develop business

The traditional companies – those developing and building something physical, not just software or web services – have looked with admiration to Silicon Valley. They have sent their executives to the Valley or Singularity University. They have engaged in collaboration with startups and run hackathons. Many have opened autonomous digital or innovation labs. Yet, nothing fundamental has changed in their core business. They still haven’t found an efficient way to deal with unpredictability, and they largely develop new solutions the way they always have done.
 
By that we mean the linear development model, often called stage-gate, NPD/PDP process or something similar. This way of developing has over the last years consistently delivered products with an average success rate of 30%, according to the 2017 Standish Group CHAOS Report. A finding that is consistent across businesses and industries. Not impressive. But if you move on to look at the employee engagement, it is even worse. A 13% engagement level has been measured across global businesses, according to Gallup’s 2018 State of the Global Workplace report. The waste (or potential) that these numbers refer to is almost impossible to grasp.
 
 

Why has nothing changed?

 
When the proof is so overwhelming that something really has to change in the core model, how can it be that we only see incremental process improvements, symptomatic treatment with new software systems, or startup experiments that end up not scaling?
 
We think that it has something to do with the value proposition offered to executives and leaders. Either it’s not attractive enough, or maybe it’s even downright scary.
 
What do we mean by this? Trawling through popular management press, Silicon Valley stories, the Agile wave, and, well, consultants, the advice often goes along these lines: projects don’t exist anymore. Instead we release change and features continuously. Therefore, project managers are not needed anymore. The key people now are product owners, Scrum masters and Agile coaches. The linear development model (stage-gate, aka waterfall) is substituted by a circular and iterative model – a model that does not require us to decide when things will be done, making it hard to define when and how to build factories, logistics, distribution systems and sales training. This model also wipes out the current organisational structure and replaces it with new dedicated Agile roles, while demanding massive big-bang training and multiple-choice certification efforts for hundreds of people in Scaled Agile techniques.
 
We strongly believe that Agile, Scaled Agile and Scrum are great mindsets and methods. Striving towards continuous release and delivery is something all professional businesses should do. Launching next-generation products only every five years can easily be too infrequent and leave companies vulnerable to faster competitors. But the success cases for evangelistic Scrum and Scaled Agile almost purely come from software and service businesses. Not even from companies developing new software or service business models. The success cases are companies operating large software-based services, seeking to continuously modify and improve these with Agile techniques. Of course, if the game is operations, maybe it’s okay to say that projects and project managers should not exist.
 
It is different if you seek to create a new business. For instance, an entirely new business concept where the assumptions to test are full of uncertainty and difficulty. It’s also different when developing complex physical solutions such as pharmaceutical products, power plants, diesel engines, pumps, compressors, or wind turbines. Saying that projects don’t exist doesn’t make a lot of sense here. Saying that we work iteratively – not sure when we will be done – doesn’t make sense either. Time is linear. For instance, if you order tooling for injection moulding, you cannot release output in circular biweekly sprints. It takes eight weeks, and there is nothing you can do about it. Investors also have a linear perspective, and they will expect a financial return after a certain time has elapsed from their initial investment.
 
 
 

The linear development model is here to stay

 
Does it make sense to have a linear development model with decision gates? In our mind, it does. Even in much-admired Silicon Valley, startups go through a linear model with gates. The gates are called seed funding, series A, series B, and series C.
 
If gates are okay, then what is the challenge of current development models? We believe the problem is that they are often called “product development” models, 90% staffed with R&D team members. Thinking seems to go along the following lines: strategy and market insight teams brief R&D on the need, product development is initiated, and R&D creates the product. When it has been developed, sales and marketing are activated to persuade customers that they have to buy it.

It doesn’t make sense to develop products. The only thing that makes sense is to develop business. To do that, you sometimes need a product, but you also need a lot of other things, like a factory, a distribution system, a business model, a thrilled and skilled salesforce, a good value proposition, and, most importantly, you need customers who will buy the product.
 
We suggest keeping the stage-gate development model but modifying it from product development towards business development. One could ask whether this change is really needed, if a company mostly does incremental innovation with little commercial uncertainty. But we would like to challenge that belief by referring to the average current product success hit rate of 30%. Even for product development where the degree of newness is supposed to be manageable, projects are often out of tune with the real customer need, and they end up significantly underperforming compared to forecasts.
 

 

Create a hybrid model

 
We need to change our way of thinking about development. But the risky big-bang change to Scaled Agile might not be right. We need a Hybrid that takes the best from the Agile world and the best from the linear world. We call our suggestion the Half Double Hybrid Development Model. Half Double because the model has demonstrated an ability to cut waste and increase focus, giving projects double the impact in roughly half the time. We call it Hybrid, because it works within a linear-gated development model and combines traditional Agile with Lean Startup and Design Thinking. Release of funding at gates is linear, while the work done between gates is Agile and iterative.
 
The gate model needs to change to better deal with uncertainty, and so does the way teams work in between gates. But our way of thinking is probably where the most change is needed. When defining the desired state and steering the change towards it, we believe that leaders should think more about the essential drivers of Agile: Impact, Flow, and Leadership.

A. Impact: Focus more on project impact than project deliverables

 
In many development models, we have experienced that gate checks focus largely on inside-out questions. We check compliance against necessary documentation, technology, and whether we can solve technical challenges or manufacture the solution. More advanced models also attempt to build readiness and engage the commercial organisation before sales ramp-up is initiated. In companies with a strong commercial focus, the business case is sometimes assessed during the development process. This might seem like a good idea but could be quite harmful if not done right, because projections of some general market sizes, price developments, or segment growth do not teach us anything about how our specific solution and process will perform. The financial system in most companies is designed with operations in mind and is not geared to assess business initiatives in a highly unpredictable world. The illusion of control can be worse than no control.
 
Instead, gates should be similar to startup funding rounds. Teams must deliver specific proof from the real world and validated learnings across vital areas. These areas could be Desirability, Feasibility, and Viability as known from Design Thinking. Teams must show new learnings about “Whether someone will buy our product” (Desirability), “Whether we can build the product” (Feasibility), and “Whether we can consistently operate the new business and value stream with a profit” (Viability).
 
One great way to focus on impact is to only do what is needed the most, or at least do that first. Here, we recommend looking for the fastest possible way to solve the customers’ or users’ most painful problems. It takes a lot of hard internal effort to battle overengineering and cut down the feature set to the essentials. Some companies have been skillful in adding only key value-driving features in the first round and then additional features in subsequent launches. Staging feature release creates faster impact, but it also creates a more acceptable negotiation with quality-concerned developers. Another way to increase impact, or reduce waste, is to find the fastest possible way through the organisational processes. This can be done by asking what documentation, reporting, and approval are really necessary. If necessary, how can we rethink the processes, so we fulfil the compliance need but avoid bottlenecks? It is our experience that waste in this area is quite significant. Today, many reports are being filled out with fake numbers, just to make them “go away”. And when the reports are completed, they are often not read or understood by the right people. Also here, an illusion of control may be the result.
 
Nothing creates impact like teams with full end-to-end responsibility for customer value creation and delivery. It is more fulfilling and much easier for teams to take the right action and make the right decisions if they are personally responsible for the end result. If teams – and managers – act as much as possible “like they own it”, results will be better, without any doubt.
 
 
 

B. Flow: Reduce handovers and make life easier for developers

 
A company can only be fast if its teams are fast. A cross-functional project team is one of the best possible ways to speed up development. It takes the drama out of functional coordination. We must strive to solve issues at the lowest possible level. Otherwise, it often becomes political and starts creating handover and approval delays. Approval delays, or vertical handovers, are the results of hierarchies, and the hierarchy is the mother of all innovation enemies.
 
The core project team needs a substantial allocation to the project, 50% or more, while peripheral members and SMEs can have a lower allocation. As people work on the project, it should be the most important thing they do. Thus, it makes great sense for the team to be co-located. It can be challenging to make it happen, especially in global organisations, but our experience shows that it really is worth the effort. There is substantial research indicating that high-performance teams are seldom more than 6-8 people, so the core team and extended team should be kept small. If the job to be done requires more effort, maybe it’s time to rethink the value and project architecture.
 
A recurring heartbeat inspired by Agile or Lean can easily function between the overall investor gates in the development model. A sprint-based model with time boxes of 2-4 weeks really helps to ensure high learning speed and focus. We recommend sprint events known from Scrum merged with an entrepreneurial and business focus from Lean Startup. In this way, a sprint will start with a look at the problem or solution that a team is focused on. Together, the team will ask themselves what needs to be true for this problem to be worth solving or for this solution to deliver results. The produced statements are assumptions. When these are clearly enough defined, the team prioritises them to find what we call “Leap of Faith Assumptions” or LOFAs. With focus on LOFAs, the team tries to find out how these can be tested to create validated learnings. Before testing, it is useful to define test pass criteria, for example, “If x out of 20 customers agree to do y”, we consider the assumption verified.
 
When testing, it is critical to obtain true answers. That is not always easy. But by building in some exchange of value, one typically gets a more truthful response. For instance, it is easy for a customer to say that they are very interested in the new product we are trying to build. But asking them whether they want to participate with resources or time reveals their true commitment. Behaviour or action is always more revealing than likes or dislikes.
 
There are many ways of testing assumptions both internally and externally, ranging from interview questions, ranking games, to simulations, prototypes and Minimum Viable Products, known as MVPs from Lean Startup. So, while the team creates what they have to create according to the gated development process, they also conduct tests specific to their prioritised assumptions.
 
At the end of the sprint, the team demonstrates test learnings, the current solution, and updates their impact tracking. The impact tracking contains leading indicators defined at the beginning of the project. Innovation accounting techniques from Lean Startup provide good inspiration for setting up indicators. They should be covering Desirability, Feasibility, and Viability, and the assumption-based testing will help update indicators once every sprint. The sprint ends with a retrospective, where the team decides what to improve for the next sprint.

C. Leadership: Install accountability and authority where the real insights are

 
Decision-making is an area with significant improvement potential. We recommend avoiding long vertical escalation processes and equally long processes for communicating decisions down to the teams. Without that, decisions will be faster and better. Many can agree that it makes sense to get decision authority as close as possible to where real insights are, but it will only work if adequate accountability, energy and skills exist in the team. To support and challenge the team, 2-3 leaders should take the role of a sponsor team, one with true interest and in very close contact with the project, maybe on a weekly basis.
 
From time to time, senior leaders and executives must make decisions, because someone needs to take the investor role. This can still be done at gate meetings. But, if the project is to build a business and not a product, the evaluation team must play it a bit like a venture capitalist would. When assessing a startup and its business idea, they pay very strong attention to two things. First, do they believe in the team, do they have strong skills and drive, and can they handle all the trouble they will meet on their way? Second, does the team demonstrate real learnings that validate the business potential? If that is not the case, they cut the money stream.
 
This funding model is also known as “metered funding”, as opposed to “entitlement funding”, where funding is often influenced by political horse-trading and typically goes on to the end of the project, because the commercial risk is significantly underestimated. Venture capitalists pay less attention to fulfilment of procedures, internal requirements, and quality standards, because all that doesn’t matter if we cannot sell the product. They don’t ask the question, “Can we build it?” Rather, they ask, “Should we build it?”
 
Generally, we believe that leaders should stop more unsuccessful projects during development to free up resources for more promising projects. Most of the leaders we know actually agree on that. Yet it still doesn’t happen sufficiently. This is a bit strange. One reason could be that leaders do not truly believe it is important, or that it is difficult to decide what to stop if individual leaders are too occupied by their personal or functional agendas. It could also be because leaders do not feel they have the right supporting information or financial metrics to make decisions under high uncertainty.
 
The waste in a typical development system is significant. Many projects have an imprecise capture and conversion of customer needs. Designing and manufacturing functionality that no customer will ever use represents waste. But worse is perhaps the waste these solutions impose on customers, such as confusion, irritation and waste of time, all leading to brand damage and less repeat business.

A better gate input, in the form of impact tracking and innovation accounting based on solution-specific assumption validation, can help make project killing easier and better. Project teams and investor teams could agree what business and solution proof they need to deliver at the next gate to get continued funding. That being said, decisions will never be truly rational, and asking for more and more details or reports may not make decisions easier. And certainly not if project teams start putting in pseudo-info and faking the numbers. Both killing and funding decisions will always contain a leap-of-faith element.
 

Ways to initiate positive change

 
Ways of moving in an entrepreneurial direction and towards lower tolerance for waste depend on experience and the unique configuration of your company. An engineering service provider can probably go further than a pharmaceutical company. But all companies can go further than where they are today, because they are all influenced by the systemic and generic challenges that appear when organising a large company.
 
When organising for change, it is powerful to have a big vision, but important to move ahead in small steps. The change (or disturbance) to current habits must be suitable. Not too big, not too small. Maybe there is no better way to succeed with a change journey than by approaching it with experiments and minimum viable solutions. We recommend asking, “What is the minimum solution to demonstrate systemic improvements?” After all, corporate history is full of grand big-bang change initiatives, top-down imposed transformations, or rollouts that delivered far less value than intended.
 
An approach to change must be iterative and curious at its core. It can be organised in different ways, but we have witnessed excellent results when the change is designed around four components: 1. True leadership dialogue, 2. Impact pilots, 3. Adapted development model, and 4. Employee inspiration and co-creation sessions.

1. True leadership dialogue: Agile thinking and principles can be incredibly powerful when developing new business and solutions. But Agile is also currently the #1 business buzzword. It is put in front of everything, often because others are also doing it. Many leaders who haven’t studied or tried it sufficiently seem to think that “Agile” is the equivalent to “Fast”. And who wouldn’t want that? Entrepreneurial processes require delegation of authority. How do we as leaders initiate that without risking too much? And how will my own role as a leader need to change? Moving from developing products to developing business will have some implications for functional collaboration. Development is not purely an R&D issue anymore, but a true cross-functional effort. It is important that all involved leaders are curious about entrepreneurial development methods and mindsets. The best way to lead change has always been to lead by example, by daring to experiment and change yourself.
    
   
2. Impact pilots: Initiating pilot projects is a great way to start learning and creating results at the same time. It is messier than drawing up a nice holistic model as a desk activity, but it works 100 times better, because it tests both business and organisational LOFAs fast. Mike Tyson isn’t known for his intellect, but he has said one really smart thing, “Everybody has a plan until they get punched in the face.” You can choose any project as a pilot, but some elements are important before starting. First, we need a sponsor team and a project team that are skilled, willing to learn and to walk the extra mile for a long time. Second, the problem we set out to solve must be significant and worth solving. It needs an ambitious target and deadline, so we do not get a long and thin effort without energy and focus. Depending on configuration, it is typically adequate to let a pilot run for 8-12 weeks with some coaching before it continues independently.
    
   
3. Adapted development model: We have helped run Agile and entrepreneurial pilot projects that were very successful in themselves. But, in others, we have also experienced that real impact was lacking because the Agile projects met traditional inside-out thinking at product development gates and other decision points. We often survey companies, asking about their most successful product development project. Seven times out of ten, it was the project that was allowed to run outside the stage-gate model. Development models need to be changed. Most people agree on that. But don’t wipe it out, just rethink it. Change the gate checks from “administrative product compliance” to “real-life business validation” with metered funding. At the outset, it is enough to do this for projects running as Agile or entrepreneurial pilots.
    
   
4. Employee inspiration and co-creation sessions: Agile and entrepreneurial thinking can do a lot for companies, and it can do a lot for developers and employees in general. But do not impose new ideas on people top down. Instead, try to create an atmosphere where employees become curious around entrepreneurial methods, start debating openly on how to approach it and initiating some meaningful experiments. If we want employees to be curious and explorative, leaders should obviously be willing to walk the same path. On an individual level, entrepreneurial approaches can create many good things: motion and energy, freedom to create, a direct line of sight to the customers we want to help, and with that often a stronger sense of purpose. And worth mentioning, it gives people killer CVs and really makes them ready for the future.

There is a sequencing to the four components. For instance, it makes sense to start leadership dialogue before adapting the development model, but much of it can happen in parallel. When the first round has been conducted across the four areas, there will be visible results. But there will also be learning for improvements, and this will be a great time to reflect before scaling to the next batch and continuing the journey.
 
The potential to create impact is massive. But the effort needed to achieve profound change is extensive. A long-term view is necessary, and even then, it could become quite challenging. The good things are that many people feel the need to change something. And that change can be initiated in suitable experimental steps. If the first experimentation, learning and results are positive, more and more people will be wanting to contribute.
 
 

Implement Consulting Group has an extensive practice around business and product development systems.

 
Over recent years, Implement has created the Half Double Hybrid Development Model that contains people-centered Agile and entrepreneurial methods for funding, portfolio management, and projects. The Half Double approach has been verified in +50 pilot projects and by independent university research. The Half Double project manager community boasts +1,000 members and has a very decent growth rate.
 
Implement has offices in Germany, Switzerland, Sweden, Norway, the U.S., and Denmark, but has driven change and business creation projects in +50 countries.