Six Myths of Product Development

Most product development managers try to implement projects on time and within budget. They never have enough resources, and their superiors require predictable schedules and results from them. Therefore, managers force their teams to be more thrifty, write detailed plans, minimize deviations from the schedule and waste resources. But this approach, which has the right to life for implementation in manufacturing plants, can harm product development.

Although many companies treat design like industrial production, there are fundamental differences. In the world of manufacturing physical objects, tasks are repeated, actions are predictable, and manufactured products can be at one time only in one place. When developing software, many tasks are unique, the project needs to constantly change, and the resulting product is information that can be in many places at the same time.
')
Failure to see these differences leads to errors that interfere with planning, executing and evaluating program development projects. The authors of this text have spent more than 50 years studying and consulting development companies, and we have often encountered similar errors in completely different areas - including semiconductors, automobiles, consumer electronics, medical devices, software, and finance. In this article, we describe these misconceptions and ways to circumvent the problems they create.

Misconception 1: increased resource utilization will increase work efficiency

Many companies are trying to fully utilize their development resources. The average product manager keeps the resource utilization rate at around 98%. The logic is clear - projects are made longer if people are not 100% busy, so a busy organization will work faster and more efficiently than the one that does not use all human resources so well.

In practice, this does not work. We saw how the speed, efficiency and quality of projects went down when managers loaded developers to the fullest. High loads have bad side effects that are underestimated by managers for three reasons:

They do not take into account the variability of the developer’s work.

Many aspects of development are unpredictable - when projects appear, what tasks they will require, how long it will take for those who have not done such things before to complete them. But companies are most familiar with repetitive processes, such as production or transaction processing, where work does not change and few surprises appear. Such processes are scheduled and resource utilization increases. To do 5% more, and it takes 5% more time.

Non-permanent processes behave quite differently. With increasing resource utilization, delays grow sharply. Add 5% more work, and completion may require 100% more time. But few people understand this. In our experience with hundreds of development teams, we know that most of them work more than they need. To complete all projects on time and meet the budget, some of the organizations we worked with would need 50% more resources.


Dependence of waiting time for completion of work on the percentage of utilization of resources

Of course, some inconsistency arises due to the lack of discipline, and some tasks in developing projects (developing components for an airplane or clinical trials of drugs) consist of repetitive tasks. But even if part of the work is predictable, then, combined with unpredictable work, it will give problems with planning.

They do not understand how queues affect cost effectiveness

High utilization of resources inevitably creates queues from projects. When the unfinished work freezes in anticipation of the release of the desired resource, the overall duration of the project increases. Queues delay feedback, which is why developers go the unproductive way longer. It becomes harder for companies to adapt to the growing needs of the market and find weaknesses in products before it is too late. Ironically, this is exactly what managers are trying to avoid, utilizing resources 100%.

Even if managers know that they are creating queues, they rarely represent economic losses from them. Although the cost of everything can be calculated, most companies do not do this. Managers must compare the cost of queues and the cost of reclaimed resources to work out the right balance.

In the development of software that is in the process of development, usually can not be seen

Production queues create physical objects. When the warehouse doubles, it is immediately visible. In the case of developing a software product, the warehouse consists of information - design documentation, procedures and test results, instructions for building prototypes. When doubling the stock, there are no physical signs of this. And since, according to accounting standards, this information is equal to zero in value, there is also no progress in financial statements.

It is very difficult to deal with a problem that cannot be seen and measured. Consider a pharmaceutical company. A few years ago, a new drug development director faced a dilemma. He tried to turn his scientists on a more innovative way. He wanted them to experiment more with new chemicals that could eventually become drugs, and at the same time get rid of hopeless candidates as soon as possible. At the same time, animal tests were in the area of ​​responsibility of another department, which did not comply with it. This department was evaluated by how efficiently it used resources for testing, which led to the need for high utilization of resources. Naturally, scientists from the drug development department were expecting 3-4 months of test results, which took only about a week to complete. “Good management” of the testing department prevented the development department from working.

An obvious solution to such problems is to create buffer capacities for non-permanent processes. Some companies have long understood this. In 3M, for several decades, developers will use 85% of their capacity. At Google, engineers are allowed 20% of the time (day a week) to do anything, which means that additional time is always available to them in case of a project delay. But such a decision is quite difficult to organize. Few people will avoid the temptation to take employees 100%. Managers reflexively give out new tasks when they see downtime.

But there are other solutions.

Change management system

In the case of a pharmaceutical company, this may mean aligning the goals of the animal testing department with the development department. For example, you can award the testing department for quick responses to requests, rather than for resource utilization.

Selectively increase resources

By adding additional resources to areas where the recycling percentage exceeds 70%, you can dramatically reduce latency. If the pharmaceutical company did this in the animal testing department, then responses to inquiries about new chemical compounds would come faster. When testing is performed using computer simulations and simulations, an increase in resources costs relatively little, because it usually means buying additional hardware and software licenses.

Limit the number of active projects

If resources cannot be increased in the animal testing department, resource utilization can be reduced by reducing the number of active projects. Discipline with respect to the hard constraints on the product pipeline, often leads to better focus and clearer priorities.

Improve the visibility of the tasks being worked on

One of the methods is visual control boards. They may look different, but the key point is to have some physical indicators, such as notes, representing the work. The board should display all the work and status of each part of the project. It should be at the center of the management process. You can gather daily 15-minute meetings at these boards to coordinate efforts and promote work.


Typical design board

The first column is new tasks, roughly similar in complexity. The second is tasks at work. The number indicates the maximum number of simultaneously solved tasks. A check mark on a task indicates a problem. Third - parts ready for testing. Rotated leaflet means the need to intervene manager. Fourth - tested tasks. The number indicates the maximum number of simultaneously solved tasks in total in both columns. Fifth - tasks that have been tested.

Misconception 2: processing tasks in large batches improves the economics of the development process

The second reason for the appearance of queues in the development of the product - the size of the parties. Suppose a new product consists of 200 components. You can decide to design and build all 200 before you start testing them. But if you develop 20 components instead, the batch size will be 90% smaller. This will greatly reduce the waiting time, since on average the queue is proportional to the lot size.

Batch reduction is the main principle of flexible production. It allows you to reduce work, speed up feedback, improve production cycles, quality and efficiency. Small batches in product development are even more important, but few understand this.

One reason is the nature of their workflow. Since the processed information does not have a physical representation, the size of the batches does not have it either. The second is that developers have some kind of propensity for large batches. Perhaps they mistakenly believe that it saves on scale.

In a well-managed process, batch size balances transactions and storage costs. It’s like buying eggs at the grocery store - if you buy eggs for the year ahead, the cost of transportation will be low, but most eggs will spoil, which will increase the cost of storage. If you buy eggs for a day, they will not spoil, but the cost of transportation will be large.



The optimal batch size is one that has the lowest total cost (transactions and storage). Small deviations from this point do not bring big problems. For example, if you deviate from the ideal lot size by 20%, the change in the cost of production will be only 3%.

Having understood this issue, companies are starting to reduce the size of parties, which leads to surprising results. Some, instead of testing one large batch once every 90 days, go over to testing a small batch several times a day. One manufacturer of computer peripherals reduced the cycle time of software testing by 95% (from 48 months to 2.5), increased efficiency by 220% and reduced the number of defects by 33%. The savings were double what the company expected.

Misconception 3: we have great development plans, we just need to strictly adhere to them.

We have never met a project, the requirements for which have remained constant throughout the development. But many organizations continue to piously believe in their plans. Any deviations are attributed to poor management and execution, and to reduce them, they track every step. For manufacturing processes with frequent repetition of steps, this is a good approach — but for innovations in design, it is not suitable. New insights can come daily, and conditions can change constantly.

A classic study of solving technical problems reveals the changing nature of a developer’s work. It shows how the engineers who created the subsystem for aviation, developed options and chose the best of them. In the process of work, their preferences often changed, and they checked and clarified solutions. This is typical of innovative projects — testing and experimentation reveal what works and what doesn't, and preliminary estimates of value and value may change.

Defining user needs can also be a problem. And no wonder - it is difficult for customers to accurately compose requirements for non-existent solutions. Acquaintance with the existing properties of the product may prevent a person from formulating his requirements for new products. User preferences can change dramatically in the development process, as competitors present new offers, and new trends appear on the market.

Therefore, if you strictly adhere to the original plan, no matter how brilliant it may be, you can come to a complete failure. We, of course, believe in planning - product development is a set of complex actions that require coordination and attention to detail. But plans should be considered as initial hypotheses that are constantly being revised.

Misconception 4: the earlier we start, the sooner we end.

Managers hate downtime and try to use them to start new projects. Even if a new job cannot be started, because people must first finish another project, managers convince everyone that everything that can be done on a new project today will be a job that will not have to be done tomorrow. This forces companies to start more projects than they can actually execute, and leads to the erosion of resources.

If this happens, the company will stumble during the entire development process. And such slowdowns are harmful, because product development is a perishable product: technologies and the market change and go to scrap very quickly. The slower the process, the greater the likelihood that its direction will have to change. One of the military development units found that the cost and delays in the development of the project grew exponentially with an increase in the duration of its development - and to the 4th degree. If the project schedule doubled, then the cost and deviations from the schedule grew 16 times.

The importance of reducing the number of unfinished work is obvious, if you look at the formula from the classical theory of queues - the law of Little. On average, the cycle time is proportional to the queue size divided by the processing speed. If there are 20 people standing in front of you at Starbucks, and the barista serves five people per minute, then you will be served in 4 minutes. Cycle time can be reduced by increasing the speed or reducing the amount of work. Usually in practice it is possible to implement the second option.

Some developers scrupulously control the speed with which they start a new job, compare it with the speed with which the old work is done, manage the number of projects in the process, and make sure that after starting a project, there are enough resources to maintain it. They avoid the temptation to steal resources from working projects to shove them into new ones.

Misconception 5: the more features in the product, the more popular it will be.

Development teams often believe that adding features adds value to a product, and removing deletes it. This explains why the products come out so complicated. Remote controls cannot be used, computers have to be tuned for hours, cars have so many knobs and buttons that they resemble an airplane cabin, and even toasters now do with instructions and LCD displays.

Companies that do not think that more is better, produce products that are elegant in their simplicity. The Danish manufacturer of audio equipment, televisions and telephones Bang & Olufsen understands that customers do not always like to play with the equalizer, balance and other things in order to find the optimal combination of settings for listening to music. Their high-end speakers automatically adjust to the songs — all that remains for the customer is to select the volume.

Convincing companies that “less” can sometimes mean “more” is hard, because you have to make efforts in two areas of development.

Problem definition

Speaking of a problem that developers are trying to solve is the most undervalued part of the innovation process. Too many companies devote too little time to this. But this is an important phase - this is how teams understand their true goals and put forward hypotheses that can be checked and clarified. The quality of the problem statement fundamentally affects the team’s ability to focus on what really matters.

When planning for Disneyland, Walt Disney was in no hurry to add new features like other parks. He asked himself: how can one provide visitors of the park with magical impressions of his visit? IDEO and other companies devote whole phases of product development to immersion in the context in which they see a product or service. Their developers read everything about the markets, observe and interview users, study the proposals of competitors, and embody new knowledge in pictures, models and diagrams.

Determination of what can be hidden or what can be discarded

Often teams want to impress their colleagues and superiors with brilliant technical solutions. Users just need a product that works without problems. From their point of view, the best solutions are simple solutions hiding from them the work that developers are so proud of.

One company that understands this is Apple. Their greatest advantage is being able to get to the bottom of the problem. As Jobs said: “When you start to consider a problem, and it seems very simple - you do not understand its complexity, and your solutions will be too simple. Delving into the problem, you see that it is complicated. And you come to different complicated decisions - this is what most people stop at. ” But not Apple. “A truly great person will continue to move and find the key principle at the heart of the problem, and will come to a beautiful and elegant solution.”

Determining which features to omit is just as important as determining what needs to be included in the product. Unfortunately, most companies throw all possible functions into a bunch, without considering such important things as customer value and ease of use. Such companies cut out features solely because of the cost of development or behind schedule.

Managers should focus on whether the removal of one of the functions will not improve their product, and whether it will allow the team to focus on the really important things for customers. This can be verified in fast experiments for each of the functions.

Developers often think that a product is finished when there is nothing more to add. Their logic must be reversed - products approach perfection when there is nothing to throw out of them. As Leonardo da Vinci said: “Simplicity is the best complication.”

Misconception 6: we will be more successful if we succeed the first time.

Many projects fail to cope with budget, schedule and technical obligations. Of course, poor planning, inflexible processes and weak leadership play their roles. But managers often do not understand that their role is played and their demands “to do everything right the first time”. Success from the first time sends teams to the territory of less risky decisions - even if customers do not consider them to be a significant improvement over what they were before. Teams do not receive an incentive to develop innovative solutions to user problems.

To avoid mistakes, teams prefer linear processes, where each step is tracked in a survey "gate." Work on the next step will not begin until the project passes the “gate”. When a project moves along a linear path, a lot of energy is invested in it, and the cost of project changes due to new ideas increases many times over. In the later stages, successful tests are encouraged, and surprises, even very valuable ones, are considered as negative. Unfortunately, the linear process leads to project delays - because feedback slows down, teams hold on to bad ideas for longer than necessary, and do not begin to discuss problems until the moment when their solution becomes too expensive.

The best strategy will be tolerant attitude to failures in the first times - even better, people complete the iterations faster and learn faster from their mistakes.

Instructions for avoiding common errors:

1. Make queues and streams of information visible.
2. Estimate the cost of delays and consider it.
3. Do not use 100% of resources; lower utilization where it is very high.
4. Shift control systems from performance to response time.
5. Reduce transaction costs so you can work with smaller batches and a faster response.
6. Experiment with smaller batches. You can always return, as it was.
7. The development plan is a hypothesis that will evolve as new information arrives.
8. Start projects only if all resources are fully accessible to them.
9. Tune in to simplicity. Think what can be removed, not just what can be added.
10. Experiment earlier, faster and more often. Use computer models and physical prototypes.
11. Superimposed and iterative development is better than linear
12. Tune in to accelerate responses, not success the first time.

After examining 391 teams of those that made chips to order, we saw that those who used the iterative approach and did the tests as early as possible and more often were wrong more often than others. But because of the use of inexpensive prototyping, they won (in terms of time and effort) from those who tried to do everything right the first time. Teams that had too expensive prototypes spent more time and effort on specifications, development and testing. And since their iterations occurred closer to the end of the process, and their number was less - the discovery of serious problems with them occurred with a long delay.

Experiments with different ideas are an indispensable part of the innovation process. When experimenting often and quickly, of course, you have to accept the failure of many ideas. But it allows teams to quickly cast away bad decisions and concentrate on more promising ones.

A classic example of the advantages of the “make earlier and more wrong” approach is the unexpected victory of the New Zealand team in the 1995 America’s Cup in yachting. To improve the design of the keel, the team used two identical boats, one of which was changed during the development process, while the second remained the control one. Every day, the team simulated new hypotheses on a computer, applied the best of them, and then arranged a contest with a control boat and studied the result.

Their opponents, the team of Denis Conner, who also had better computers, ran large sets of simulations every few weeks and then tested the best solutions on the same boat. New Zealanders made more cycles, quickly got rid of bad ideas and won the regatta.

Experiments that fail are not necessarily unsuccessful. They give out information that could not have been foreseen. The shorter the cycle of the experiment, the more it gives feedback that you can quickly include in new stages of development.

Creating such a development environment is difficult. Mistakes confuse people, show gaps in knowledge, which as a result can undermine their self-confidence. Think about it, how often do managers increase and reward teams for early detection of problems that led to the death of the project - even if an early redistribution of the company's valuable resources was beneficial to it? It is especially difficult to work in this direction in organizations with "zero tolerance for failure."

Thomas Edison understood all this, and in his laboratories everything was set up for quick and frequent experiments in which researchers could work closely with workers. The laboratories had extensive libraries with easily accessible information, warehouses with the necessary spare parts, and a diverse workforce, from laborers to engineers and scientists. Edison wanted to be sure that immediately after the appearance of a new idea, she would be able to quickly translate into a model or prototype. He said that "success is measured by the number of experiments that can be crammed in 24 hours."

The development of IT (computer design, modeling, simulation) has already made it possible to take steps towards developing better products in less time and money. But many companies do not use the full potential of these tools, as their managerial thinking develops more slowly than technology. They still approach the development of an information product as a factory production. With the development of information technology opportunities to improve the product development process will become even more - therefore, there will be more risk for those companies that could not see the differences between software development and manufacturing.