One of the main challenges of scaling up a company is growing the product and engineering teams. It always seems like tech teams are never fast enough: the product roadmap is full to the brim with features to be developed, and VPs from all around the company – sales, marketing, customer support, operations – are endlessly jockeying to push their own requests to the top of the list. This makes for a difficult challenge for the CEO, and a very tough one for the Product Manager.

At first, it looks like a productivity issue: how can we get developers to pump out features faster? Upon closer inspection, it often appears that:

1. Developers spend an inordinate amount of time dealing with incomplete or incoherent specifications, due to the fact that user needs are not fully understood.
2. Changes are frequently requested during development, increasing the cost of new evolutions and wasting precious development time.
3. Evolutions generate new problems for users within and outside the company, because important details were left out when the features were specified or because the team rushed to deliver the features introducing defects. This, in turn, creates the need for new “features” to fix the situation.
4. Despite all the effort the business results are disappointing.

In fact, the issue is not about delivery, or organizing people and tasks to get a known output more efficiently. It is a question of discovery: exploring and defining what the product should be to make a less risky bet.

What does lean teach us about discovery?

Understanding value, a matter of teamwork

From a lean perspective, discovery is first about learning how the product creates value for the customer, and second about how to design and build the product so that we don’t impose the cost of our waste to the customer.

Value and waste need to be considered throughout the value chain and not just on the core technological product. As a consequence, discovery encompasses the whole product, ranging from the customer experience to the company’s internal processes.

Let’s take a car-sharing service as an example. The core product could be the app used to book a ride, or the system that allocates rides to drivers. By contrast, the whole product encompasses the entire range of systems and services that form the user experience. In this case, a major element of performance from a customer perspective is the time one has to wait for a car. This depends on the ride allocation algorithm, but also on the number of drivers on the roads at any given time. This means that to design a service that fully delivers on its promise to users, you also have to take into account the whole driver experience and persuade thousands of them to use the platform. This, in turn, creates the need for a scalable onboarding service for drivers, as well as many people responsible for handling daily hiccups.

For the product to be a success, you have to design a complete set of products and processes. As a consequence, the product team must include representatives from all departments in a company: product, tech, marketing, sales, operations, legal, etc.

Getting all these people to work together towards a common goal is difficult: they usually have different priorities and often do not see the impact of their local decisions on the “big picture”. There is no recipe to follow to align them all. This is traditionally managed like an organizational issue, handled in terms of roles and processes, but lean frames it as a learning exercise: “Who needs to learn what in order for the product to be a success?” But how do you get such a diverse group, pursuing different agendas, to learn together and move in the same direction?

The Chief Engineer

Toyota addresses this problem by appointing a Chief Engineer responsible for all the dimensions of the product. Think of the Chief Engineer as an entrepreneur, a driven individual who is passionate about the product and the customers. A person with enough know-how to dig into technical issues and with enough leadership skills to handle the politics of the project. Steve Jobs, despite being also CEO of Apple, was the archetype of a Chief Engineer.

The Chief Engineer’s main job is to create the conditions for deep collaboration between specialists from very different domains. The CE has no hierarchical authority over them as they move from project to project, but he/she has full authority over making the product a big success. It is therefore important that her competence be recognized and respected if people are to follow her vision. The CE has to work hard to build a solid business case to “sell” her ideas and cannot just impose her point of view on people.

Chief Engineers are a rare breed, and there are no two alike. They certainly have specific personal traits, but they are also developed over the years to acquire a broad range of skills, working on many different activities across the company. They keep learning and driving the learning of the product team with a specific tool: the obeya.

The obeya

In the early 1990s, Takeshi Uchiyamada, a Toyota Chief Engineer, was given a difficult challenge: designing the car of the 21st century, with very aggressive fuel consumption targets. In less than three years, the first hybrid car, the Prius, was brought to market – 15 years ahead of the competition. To pull off such a feat, the Chief Engineer also had to invent a new product and process development approach. He designed a new kind of visual management, which has since spread across Toyota engineering offices: the obeya.

Obeya means “big room” in Japanese. It’s a large office where walls are covered with information: charts, drawings, plans, and so on.

An obeya is not another project management tool. The goal is neither to review progress nor to prioritize features. The goal is rather to think deeply, to talk, to argue about the main issues of the project. It’s a space for discovery.

Chief Engineers make information and knowledge visible in the obeya because it is a powerful way to align people. Misunderstandings are quickly surfaced so that people can talk about them and develop a shared understanding of the situation. This leads to lengthy discussions and heated arguments, but this is the process by which people get on the same page and learn together. The time spent aligning people early more than pays off in the later phases of the project.

There are no set rules for how the Chief Engineer and her team should lay out their obeya. Every obeya is unique, because it depends on the maturity of the team and the stage of the project. The layout of an obeya, however, covers a few topics that need to be explored, whatever the product. These topics take the form of four questions:

1. What is the problem that we want to solve, and for whom?

Building a successful product is less a construction issue (“let’s add this feature”) than a problem-solving exercise (“what should we do to obtain this result?”). The trouble is, we usually rush to the solution before defining the problem to be solved.

Lean practitioners use the scientific method, with the Plan-Do-Check-Act (PDCA) cycle, to solve business problems. Product development is no exception. Building a product is in itself a PDCA loop:

• Plan: define the customer problem to be solved, develop a deep understanding of the situation and identify the main characteristics of the target product.
• Do: build the product.
• Check: analyze the business results to see what works and what doesn’t.
• Act: draw lessons to improve the next product development cycle.

A good problem statement depicts an ambitious target. For instance, the Shinkansen challenge was to allow people to travel from Tokyo to Osaka in three hours in less than five years.

The next thing to learn and explore in the obeya is how customers perceive value. This kind of learning is the result of deep immersion in customers’ lives. It starts with customer complaints, trying to figure out what they were trying to do with the current solutions and in what ways these solutions failed them. It also means spending time with them to better understand how they try to solve their problems today.

The Chief Engineer and the product team need to get a sense of:

• Who are the target customers, what is their lifestyle and their taste?
• What is the concrete problem they want to solve for themselves?
• In what specific context and circumstances?
• What alternatives can they choose from to get what they want?
• Why do they choose one alternative over another?
• What do they love and what do they hate about existing solutions?
• What specific problems do they experience with existing solutions?
• What preferences should we make sure to fully satisfy so as not to disappoint them?
• What aspect(s) can/should we enhance so as to grab people’s attention?

For example, for a car-sharing service the customer wants to get from point A to point B, and to achieve this she can choose between competing services, a regular cab company, but also train or bus services. Her decision will be based on a set of preferences for each solution:

• Easy to book a ride.
• Don’t have to wait too long.
• A comfortable ride.
• A good experience with the driver.
• Not too expensive.
• Etc.

The same holds true for drivers, who have to choose between different platforms. The decisive question that will drive the vision for the product is: what is the target customers’ main preference? How can we differentiate the next generation of the product on something that aligns with what matters most to customers? This is key to focus the product development efforts on what matters most.

2. What is the company expected to gain from the project?

A few years ago, an advertising production company started developing an in-house workflow management system. The goal was to provide photographers, graphic designers, product managers and printers with an all-in-one solution to avoid wasting time in a flurry of emails and Excel files. The project was difficult, mainly because the product team didn’t have access to key representatives of various departments who were focused on other priorities. Two years later the product was up and running, but the leadership team was faced with a problem: they had invested most of the company’s profits in that tool, but they were unable to figure out what benefits it had brought to the business.

One of the first discovery questions the Chief Engineer and her team need to answer early in the project is: what are the expected gains for the company? The goal here is to craft a compelling business case that will help:

• make it a high-priority item for all needed stakeholders;
• set the right cost structure of the project;
• check that the gains are indeed reaped when the product is out.

In this example, the business case could have been to reduce customer churn by offering a more pleasant interaction with client teams. It could also have been to halve the lead-time of new advertising campaigns, or to increase the productivity of the graphic design team, measured as the number of design projects managed per person every month. It could also contribute to the company’s growth by unlocking sales that were not possible without that product.

3. What technical decisions do we need to make to create a coherent and profitable product?

The Chief Engineer and her team develop their understanding of the product by exploring how its different functions contribute or not to the value perceived by customers and how these functions interact together. They try to find out what problems need to be solved before building the product.

Take surge pricing for example. This function helps reduce the waiting time for riders by enticing more drivers to be available when demand is high. However, it also damages the rider experience with high prices at the time when they need the service the most. It also makes the pricing less clear for drivers, who may feel cheated when they get the impression that demand should be high but see no increase in their revenues. At the scale of such a service, this means hundreds or thousands of additional calls for user and driver support teams, and thus a large impact on operational costs.

In order to catch and address these kinds of issues before they are developed, the Chief Engineer starts by getting the team to map how the product functions relate to the customer preferences and look out for the trade-offs to address. The goal is to figure out how to better satisfy these preferences while remaining cost-efficient. The team also tries to understand how the product functions interact with one another in order to find frictions that can make the product more complex and difficult to build and maintain.

The team can then learn about ways to resolve the trade-offs by trying out many different combinations and analyzing their performance. They summarize and arrange their learnings in the obeya.

At this stage, one of the main risks is to change aspects of the products that should not be touched – what we call “heritage technology” – while keeping aspects that create unnecessary complexity and prevent innovation – what we call “legacy technology”. For the product team, this is a real challenge as it is not always so easy to distinguish the two.

Heritage technology is everything that defines the very essence of the product and justifies its existence. A common example is the QWERTY and AZERTY keyboards which have not changed in 150 years since typewriters were invented. These strange keyboard layouts were originally created to make up for a mechanical challenge: the most commonly used keys would get entangled. A few keyboard companies have since tried to propose higher typing speeds with more efficient layouts, but they are no longer here to tell the tale. People around the world have gotten so accustomed to them that they have strongly resisted the change. This is the essence of heritage technology.

Conversely, the system of springs that makes the keys bounce can be considered a legacy technology, as new approaches result in quieter and faster typing. Companies such as Apple constantly invest in other aspects of the technology – the shape and spacing of the keys, the vertical travel distance, etc. – to improve legacy solutions while keeping the same heritage layout.

But again, maybe even the layout could one day be considered “legacy”, especially if voice-recognition technology were to become reliable enough to replace typing altogether. This is a never-ending discussion within a product team, which is why it needs to be happening in the obeya.

4. Are we building a quality product in time to beat competition?

Discovery also applies to the product development process itself. The Chief Engineer and the product team agree on:

• how they define and track quality throughout the project;
• what milestones they need to reach in order to deliver on time;
• how to measure costs.

Quality refers to the product itself. Quality metrics provide information on whether the product functions fully meet customers’ expectations in terms of reliability, performance, and usability. In order to choose the right metrics that will guide them throughout the product life cycle, the chief engineer and the product team need to put themselves in their target customers’ shoes: what should NOT go wrong? Take a LED light bulb: a gage of quality might be that it respects the expected lifespan, brightness and color, that it does not overheat, or that it is resistant to shocks. These quality indicators are often the result of technical trade-offs the product team had to resolve ahead of time. Therefore, it makes sense to track them throughout the design and development stages, so that the team can discover all the ways in which they are not succeeding in building a quality product.

In addition to quality, the chief engineer and the product team will typically track lead-time using a large, visible project plan. This plan is used to align everyone on the main product milestones and see how each team’s own activities and decisions impact the others. The project plan allows team members to better anticipate problems and discuss ways to resolve them before they compromise the timely delivery of the product. But above all, the project plan is a way for the chief engineer and the product team to discover ways to intensify collaboration between the various teams and stakeholders inside and outside the organization.

Finally, an obeya layout typically includes metrics to monitor costs (not just product development costs, but also those costs that are necessary to support customers once the product is live). This includes infrastructure, support teams and day-to-day operations. For example, for an e-commerce firm, how long it will take to add a new product to their site, replenish a stock, or propose a new promotion. Here, the objective is to discover the impact of the team’s engineering choices on the whole process, not just development.

Over the past couple of decades, Agile has spread vastly as a countermeasure to waterfall methodologies where products saw the light only after months of specifying, designing, developing and testing. The unexpected consequence of this change of paradigm is that product development teams now have a tendency to rush through the initial phases of a project. By going from one extreme to another, we have created new sources of costs, in the form of reworks throughout development that are now considered a normal part of the iterative process.

The problem is that building the product fast to validate its utility and then continuously reworking it until we hit the right target is a very expensive way to learn. A number of startups have burned through their investment funds without ever finding a good enough market for their product. The obeya provides a breakthrough approach to reduce unknowns before starting development, which has the double effect of being cheaper and speeding up delivery, so you can drop an idea when it’s not too late yet or decide to go on with it and be the first to introduce your product on the market. In this sense, obeya is designed for discovery than for delivery.

This story was originally published by Sandrine Olivencia and Regis Medina on planet-lean.