Finding x — What Problem Is the Car Actually Supposed to Solve?

Before designing a car, selecting a powertrain, calculating suspension geometry, writing control software, designing a factory, or choosing suppliers, there is a more fundamental question:

What problem is the car actually supposed to solve?

In ZenOps, this is the search for x.

The ZenOps transformation begins:

x → m(x) → u(m) → p

where x represents the reality, problem, need, situation, or opportunity that must first be understood.

This sounds obvious.

In practice, it may be one of the most important and most frequently skipped parts of product development.

A Car Is Already a Solution

Suppose someone says:

We need to develop a new electric SUV.

It sounds like a perfectly reasonable starting point for an automotive project.

But from a ZenOps perspective, there is a problem.

The statement already contains several major solution decisions:

car → electric → SUV

Why must the solution be a car?

Why must it be electric?

Why must it be an SUV?

Perhaps all three decisions are correct. But if they are accepted before the underlying problem has been understood, engineering begins with assumptions rather than evidence.

ZenOps therefore moves backward.

Instead of initially asking:

What car should we build?

we ask:

What needs to become true?

Finding the Need Behind the Vehicle

Consider a family living in a region with long winters.

They may need to:

• Transport two adults and three children.
• Travel 50 kilometres each day.
• Carry groceries and luggage.
• Operate reliably at low temperatures.
• Travel safely on snow and ice.
• Occasionally tow a trailer.
• Make several long-distance journeys each year.
• Keep transportation costs within the household budget.

This is much closer to x.

Notice what has disappeared.

There is no SUV.

There is no battery.

There is no petrol engine.

There is no four-wheel-drive system.

There is no touchscreen.

There is not even necessarily a car yet.

There is simply a transportation problem existing in reality.

That distinction is fundamental.

Separate the Problem From the Solution

A common engineering mistake is to embed a preferred solution inside the problem definition.

For example:

Bad starting point:

We need a 100-kWh battery.

This describes a component.

A better question is:

Why?

Perhaps the answer is:

Because the vehicle needs sufficient energy for long-distance travel.

Then ask again:

Why?

Because:

The user must be able to travel 500 kilometres between practical opportunities to replenish energy.

Now we are getting closer to the actual need.

The battery is one possible implementation.

The required mobility is the problem.

This distinction preserves design freedom.

x Exists in Reality

ZenOps treats x as something that precedes the model.

Reality does not arrive conveniently divided into engineering disciplines.

A parent does not experience:

• drivetrain engineering,
• chassis engineering,
• thermal engineering,
• embedded software,
• aerodynamics,
• supply-chain management.

The parent experiences:

I need to get my children safely home during a snowstorm.

That is reality.

Engineering disciplines are structures we later impose on the problem so that humans can solve it.

ZenOps therefore tries to prevent the representation from replacing the thing being represented.

The model is not reality.

The requirement is not reality.

The CAD drawing is not reality.

The simulation is not reality.

The vehicle itself will eventually have to operate in reality.

Observe Before Designing

Finding x therefore requires observation.

For automotive development, this could involve studying:

People

Who will use the transportation system?

Activities

What are they actually trying to accomplish?

Environment

Where will transportation occur?

Frequency

How often must the activity occur?

Distance

How far must people and goods move?

Load

What must be transported?

Conditions

What temperatures, roads, weather and traffic conditions will be encountered?

Risk

What can go wrong?

Economics

What can the user realistically afford?

Time

How quickly must transportation occur?

The purpose is not yet to specify the vehicle.

The purpose is to understand the world in which the future vehicle must succeed.

One Vehicle May Serve Many x’s

There is another complication.

A vehicle rarely solves only one problem.

Consider a pickup truck.

Its users might need to:

Transport people

Move workers between locations.

Transport materials

Carry tools, equipment or construction materials.

Tow

Move trailers or machinery.

Provide mobility

Travel across poor roads or difficult terrain.

Provide protection

Keep occupants safe from weather and collisions.

Provide energy

Power tools or external equipment.

The product therefore exists at the intersection of multiple needs.

The task is not merely to identify x.

It is often to discover the structure of x.

x Can Be Hierarchical

A high-level automotive problem might be:

Enable reliable personal mobility.

That can decompose into subordinate problems:

Mobility

• Move people.
• Move possessions.
• Reach required destinations.
• Operate when required.

Safety

• Avoid accidents.
• Protect occupants.
• Protect other road users.
• Maintain controllability.

Economics

• Make acquisition affordable.
• Make operation affordable.
• Minimize unexpected repair costs.

Environment

• Operate in expected weather.
• Operate on expected roads.
• Meet environmental constraints.

Human experience

• Make operation understandable.
• Reduce unnecessary fatigue.
• Provide adequate comfort.
• Communicate vehicle state.

Now x begins to acquire structure.

This structure will later become input to the ZenOps Need Definition Document (NDD).

Do Not Ask the Customer to Engineer the Car

Users are excellent sources of information about their problems.

They are not necessarily the correct people to determine the engineering solution.

A customer might say:

I need four-wheel drive.

The ZenOps response is not immediately:

Requirement: four-wheel drive.

Instead, ask why.

Perhaps the real statement is:

I need to climb an icy road to my house during winter.

Now engineering has options.

Four-wheel drive might indeed be the best solution.

But improved tires, traction control, weight distribution, torque control, road treatment, or another transportation configuration might contribute to satisfying the same underlying need.

ZenOps preserves the distinction:

The user owns the need.

Engineering develops the solution.

Different Markets Have Different x

There is no universal automotive x.

A small urban vehicle in Tokyo solves a different problem from a mining vehicle in Australia.

A family vehicle in Norway solves a different problem from a delivery vehicle operating in central London.

A sports car solves a different set of needs from an ambulance.

This is why starting with an existing vehicle category can be dangerous.

Categories describe previous solutions.

x describes the problem that exists now.

The Automotive Industry Can Start Earlier

Traditional product development often begins after many assumptions have already solidified:

market segment → vehicle concept → platform → requirements → engineering

ZenOps proposes moving the intellectual starting point further upstream:

Reality → x → Need → Model → Concept → Architecture → Engineering

That additional distance at the beginning creates more freedom later.

It also gives every major engineering decision something against which it can be evaluated.

The Test for x

A useful test is to remove the proposed product from the statement.

If the problem still makes sense, you may be approaching x.

For example:

We need an electric crossover with 500 kilometres of range.

Remove the product assumptions.

We obtain something closer to:

People need reliable, affordable transportation for five occupants and luggage over journeys of up to 500 kilometres between practical energy-replenishment opportunities.

Now engineers can work.

Battery size becomes a consequence rather than an assumption.

Vehicle shape becomes a consequence.

Powertrain becomes a consequence.

Materials become consequences.

Software becomes a consequence.

Eventually, even the factory becomes a consequence.

From x to the Car

The complete transformation can therefore begin:

Reality

Something needs to change.

↓

x

The problem is identified.

↓

NDD

The need is decomposed and made explicit.

↓

ORIGIN

The relevant objects and relations are discovered.

↓

Patterns

Reusable solution structures are identified.

↓

Vehicle Architecture

Systems and components acquire structure.

↓

Engineering

The architecture becomes specifications, software, electronics and physical designs.

↓

Manufacturing

The design becomes repeatable physical production.

↓

Vehicle

A real machine emerges.

↓

Evidence

Reality determines whether the original problem was actually solved.

The Car Is an Answer

This produces a different way of thinking about automotive manufacturing.

A vehicle should not begin as an object looking for customers.

It should begin as a response to something observable in the world.

The tires, motors, batteries, seats, sensors, software, body structure and production lines come later.

Before all of them comes x.

And the most important question at the beginning of an automotive program may therefore be the simplest:

What problem are we actually trying to solve?

Only when that question has been answered should we begin deciding what the car should become.

Because in ZenOps, the car is not the problem definition.

The car is the answer.