Day 2: Construct the NDD

Day 1 asked:

What problem are we actually trying to solve?

Day 2 asks:

Can we structure that problem well enough that the rest of the vehicle program can grow from it?

This is the purpose of the Need Definition Document.

The NDD is not a requirement specification.

It is not an architecture.

It is not a feature list.

It is not a project plan.

It is the structured model of the need space.

The Day 2 transformation is:

x → Need Tree → Context → Unknowns → Evidence → NDD

The objective is to take yesterday’s broad understanding and turn it into something explicit enough to navigate.

Begin With Yesterday’s x

Suppose Day 1 ended with:

x:
Provide safe, reliable, affordable and practical
family mobility under Nordic operating conditions.

That becomes the root of the NDD.

Everything below it should help explain what that statement actually means.

The NDD Is a Decomposition Tree

Start:

AURORA NDD
│
├── Mobility
├── Safety
├── Reliability
├── Energy
├── Winter Operation
├── Passenger Experience
├── Cargo
├── Affordability
├── Manufacturing
├── Serviceability
└── Lifecycle

This is the first structured map of x.

It is still not detailed enough.

Day 2 is about decomposition.

Ask “What Does This Need Require?”

Take:

Mobility

and ask:

What must be true for this need to be satisfied?

Perhaps:

Mobility
│
├── Reach Intended Destination
├── Travel Required Distance
├── Carry Required Occupants
├── Carry Required Cargo
├── Operate in Expected Conditions
└── Remain Available When Needed

Now the branch has meaning.

Continue Until the Need Becomes Understandable

For example:

Travel Required Distance
│
├── Daily Travel
├── Regional Travel
└── Occasional Long-Distance Travel

Then:

Occasional Long-Distance Travel
│
├── Sufficient Energy Availability
├── Acceptable Recharging Time
└── Predictable Charging Access

The tree gradually exposes the real problem.

Do Not Jump Into Architecture

At this point, avoid:

Battery Pack
Charge Controller
Heat Pump

These are solution objects.

The NDD should still say:

Store Sufficient Energy
Restore Energy in Acceptable Time
Maintain Energy Capability in Winter

The architecture comes later.

Keep Need Language Explicit

A useful test is:

Could this statement still be true if we selected a different technical solution?

For example:

Provide cabin comfort in winter.

Yes.

But:

Install a heat pump.

No.

The first belongs in the NDD.

The second belongs downstream.

Construct the Safety Branch

For example:

Safety
│
├── Avoid Collision
├── Maintain Directional Control
├── Stop Predictably
├── Protect Occupants
├── Protect Other Road Users
└── Enter Safe State After Failure

Each of these can later generate requirements and StoryQ.

But today, they are needs.

Construct Reliability

Reliability
│
├── Start When Required
├── Complete Normal Journeys
├── Resist Environmental Exposure
├── Maintain Critical Functions
└── Recover From Non-Critical Faults

This begins to define what “reliable” actually means.

Construct Winter Operation

For a Nordic vehicle:

Winter Operation
│
├── Start at Low Temperature
├── Maintain Battery Capability
├── Maintain Visibility
├── Maintain Cabin Comfort
├── Maintain Traction
├── Maintain Braking Capability
└── Support Charging

This branch will later cut across many technical systems.

That is expected.

Construct Passenger Experience

For example:

Passenger Experience
│
├── Enter Vehicle Easily
├── Sit Comfortably
├── Understand Controls
├── Maintain Comfortable Environment
├── Enter and Exit Safely
└── Access Required Information

This keeps the NDD focused on outcomes rather than screens, switches, and hardware.

Construct Affordability

Affordability
│
├── Acceptable Purchase Cost
├── Acceptable Energy Cost
├── Acceptable Maintenance Cost
├── Acceptable Insurance Burden
└── Acceptable Lifecycle Cost

This is important because purchase cost alone does not define affordability.

Construct Manufacturing Needs

Manufacturing belongs in the NDD because the product must be physically producible.

For example:

Manufacturing
│
├── Build Required Volume
├── Maintain Required Quality
├── Control Vehicle Configuration
├── Maintain Traceability
├── Support Variant Mix
└── Maintain Safe Production

These are manufacturing needs, not factory solutions.

Construct Serviceability

Serviceability
│
├── Detect Faults
├── Identify Root Cause
├── Access Failed Components
├── Replace Components
├── Restore Configuration
├── Verify Repair
└── Preserve Vehicle History

This helps prevent service from becoming an afterthought.

Construct Lifecycle Needs

Lifecycle
│
├── Support Software Updates
├── Support Maintenance
├── Support Spare Parts
├── Support Recall Actions
├── Preserve Technical History
└── Support End-of-Life Treatment

The vehicle’s life does not end at factory release.

The NDD should reflect that from the beginning.

Add Stakeholder Context

Each important node can identify:

Stakeholder:
Driver
Passenger
Owner
Service Technician
Manufacturer

For example:

Need:
Easy Diagnosis
Stakeholder:
Service Technician / Owner
Reason:
Reduce repair time and vehicle downtime

This adds meaning.

Add Operating Context

A need may only make sense under certain conditions.

For example:

Need:
Maintain mobility
Context:
Ambient temperature -30°C
Snow-covered roads
Vehicle parked outdoors

Context later becomes crucial for requirements and evidence.

Add Priority or Criticality Carefully

Some needs matter more than others.

For example:

Need:
Safe Braking
Criticality:
CRITICAL

while:

Need:
Ambient Lighting Personalization
Criticality:
LOW

The NDD can expose this difference.

But do not let priority replace structural thinking.

Add Evidence Already Available

Suppose previous fleet data shows:

Typical Daily Travel:
52 km

Link that evidence to:

Daily Mobility Need

Suppose customer research shows:

Winter charging frustration:
High

Link that to:

Winter Charging Need

The NDD becomes evidence-aware from the start.

Mark Assumptions Explicitly

For example:

Assumption:
Five seats satisfy the primary customer segment.

Do not disguise assumptions as facts.

This is essential.

Separate Assumption From Evidence

For example:

Assumption:
Towing is low priority.

versus:

Evidence:
Only 4% of target customers currently tow trailers.

The distinction matters.

Mark UNKNOWNs

Day 2 should deliberately expose uncertainty.

For example:

Required Long-Distance Range:
UNKNOWN

Target Fast-Charge Duration:
UNKNOWN

Required Towing Capacity:
UNKNOWN

Maximum Acceptable Purchase Price:
PARTIAL

The NDD should make these visible.

UNKNOWNs Are Not Weakness

They are honest knowledge states.

A program that hides uncertainty will generate false precision downstream.

A program that exposes it can generate useful work.

Turn Important UNKNOWNs Into Questions

For example:

UNKNOWN:
Required fast-charge duration

becomes:

Question:
What charging duration is acceptable
for the target use case?

The question later becomes a FLEXI task.

The NDD Begins to Pull Work

The chain becomes:

NDD Node
↓
UNKNOWN
↓
Question
↓
Work

This is one of the most important ZenOps transitions.

The project plan begins to emerge from the need model.

Do Not Create the Full WBS Yet

Day 2 should not turn into project scheduling.

Only capture obvious knowledge-building tasks.

For example:

Research customer towing need

Analyze long-distance travel pattern

The detailed WBS comes later.

Avoid Duplicate Need Nodes

Suppose:

Winter Reliability

and:

Cold-Weather Reliability

mean the same thing.

Merge them.

The NDD should become clearer as it grows, not more repetitive.

Prefer One Need, Many Relations Later

If:

Operate safely in winter

affects brakes, battery, software, and tires, keep one coherent need.

Later ORIGIN will connect it to many objects.

Do not duplicate the need under every subsystem.

Keep the NDD Hierarchical

The NDD is primarily a tree.

For example:

Safety
↓
Stop Vehicle
↓
Maintain Stopping Capability Under Failure

Cross-links belong more naturally in the OR model later.

This keeps the need model readable.

Tree for Why, Graph for What

A useful rule is:

NDD = Why

OR Model = What

Day 2 stays mainly in the “why” layer.

Ask Whether Each Child Actually Explains the Parent

For example:

Parent:
Affordability

Child:

Panoramic Roof

No.

That is a feature.

But:

Acceptable Maintenance Cost

does explain affordability.

This is a useful quality check.

Ask Whether the Branch Is Complete Enough

Completeness does not mean exhaustive.

It means:

Have we captured the major dimensions of the need that matter for the next decision?

The NDD can continue evolving.

Do Not Seek Perfect Decomposition

There is no single mathematically perfect tree.

The objective is a useful structure.

If two structures both preserve the important meaning, either may be acceptable.

Add Need IDs

For traceability, nodes can receive stable identities.

For example:

NDD-MOB-001
Travel Required Distance

NDD-WIN-004
Maintain Charging Capability in Winter

Later requirements can reference them.

Persistent Need Identity Matters

The wording may evolve.

The identity should remain stable where the concept remains the same.

This makes change history easier to preserve.

Record Why a Node Changes

Suppose:

NDD-CARGO-003
Carry 650 L Cargo

was based on an early assumption.

Later research changes the need.

Preserve:

Original:
650 L
Evidence:
Customer study
Revised:
500 L

Do not simply overwrite the reasoning.

Add a Basic Knowledge State

A practical status set might be:

DRAFT
SUPPORTED
VALIDATED
CHALLENGED
UNKNOWN

For Day 2, many nodes will still be DRAFT or UNKNOWN.

That is normal.

Example

Winter Charging:
SUPPORTED

because previous customer evidence exists.

Towing:
UNKNOWN

because research is missing.

This gives the tree a knowledge dimension.

NDD Parent State Should Not Be a Simple Average

Suppose:

Safety
├── Braking: SUPPORTED
├── Steering: SUPPORTED
└── Crash Protection: UNKNOWN

Do not say:

Safety = 67% complete.

The UNKNOWN branch may be critical.

Semantic state matters more than arithmetic.

Connect Constraints Separately

Suppose there is:

Constraint:
Vehicle width <= X

or:

Constraint:
Initial factory investment <= Y

Record these.

But distinguish them from needs.

The model should know whether something is:

Need

or:

Constraint

Regulations Can Enter as Constraints or External Needs

For example:

Constraint:
Applicable crash regulation R

Later this will generate requirements.

The source should remain visible.

Business Needs Can Be Included

For example:

Business Viability
│
├── Achieve Target Margin
├── Reach Required Volume
└── Fit Target Market Position

A vehicle program is both technical and commercial.

But keep commercial needs distinct from customer needs.

Avoid Mixing Means and Ends

For example:

Need:
Reduce manufacturing cost.

Fine.

But:

Use fewer robots.

is a proposed means.

The distinction should remain consistent.

A Practical OPUS Delivery NDD Record

A node might contain:

ID:
NDD-WIN-004
Name:
Maintain Charging Capability in Winter
Parent:
Winter Operation
Stakeholder:
Driver / Owner
Context:
Low ambient temperature
Knowledge State:
SUPPORTED
Evidence:
Customer Study CS-12
Unknowns:
Exact acceptable charging delay

This is already a useful engineering object.

The NDD Becomes Navigable

A user can start at:

Winter Operation

and drill down until they find:

Charging Delay Requirement:
UNKNOWN

Now the next learning task is obvious.

The NDD Also Makes Scope Visible

Suppose someone proposes:

Add autonomous valet parking.

Ask:

Which NDD node does it satisfy?

If none exists, either:

1. the need is missing, or
2. the feature is outside current scope.

This helps control feature creep.

Scope Becomes Need-Based

Instead of saying:

This feature is not in the project plan.

say:

This feature does not currently map to an accepted need.

That is a stronger scope argument.

Day 2 Should Reveal Conflicts

Suppose:

Need:
Maximum range

conflicts with:

Need:
Low purchase cost

That tension should be visible.

Do not resolve it prematurely.

The architecture stage will handle trade-offs.

Conflicting Needs Are Normal

Engineering is often optimization under competing needs.

For example:

Performance
vs
Efficiency

Resilience
vs
Cost

The NDD should expose these tensions.

Priorities May Help Resolve Later Trade-Offs

For example:

Safety:
Non-negotiable

Performance:
Target

This provides decision context.

Add a First Definition of Success

For important branches, write:

Success Means:

For example:

Need:
Reliable Daily Mobility
Success Means:
The target customer can complete normal daily travel
with low unexpected vehicle unavailability.

This keeps the meaning concrete.

Do Not Over-Quantify Yet

It is acceptable if Day 2 contains:

low unexpected unavailability

rather than a final numeric reliability requirement.

Precise requirements come after enough need understanding exists.

The NDD Is the Source of Future Requirements

Later:

NDD-WIN-004

may generate:

REQ-CHARGE-041

The requirement will be measurable.

The NDD preserves why it exists.

The NDD Is Also the Source of Future OR Objects

For example:

Need:
Store sufficient propulsion energy

will eventually lead to solution objects such as:

Battery Pack

But only after design begins.

The NDD Can Pull Candidate Patterns Later

For example:

Need:
Maintain thermal conditions

may later connect to:

Liquid Cooling Pattern

Day 2 does not need to choose it.

The need should remain independent.

Day 2 Is a Structural Thinking Day

Day 1 identified the problem.

Day 2 organizes the problem.

The team should spend most of its energy asking:

Is this really a need?

Is it under the right parent?

Is anything important missing?

What do we actually know?

What remains UNKNOWN?

A Useful Team Exercise

For every node, ask five questions:

Why does this matter?
Who needs it?
Under what conditions?
What evidence supports it?
What remains unknown?

If the team cannot answer any of these, the node probably needs refinement.

A Day 2 Example NDD

By the end of the day:

AURORA
│
├── Mobility
│   ├── Daily Travel
│   ├── Regional Travel
│   └── Long-Distance Travel
│
├── Safety
│   ├── Avoid Collision
│   ├── Stop Predictably
│   └── Protect Occupants
│
├── Winter Operation
│   ├── Start Reliably
│   ├── Maintain Visibility
│   ├── Maintain Traction
│   └── Support Charging
│
├── Affordability
│   ├── Purchase Cost
│   ├── Energy Cost
│   └── Lifecycle Cost
│
├── Serviceability
│   ├── Diagnose
│   ├── Repair
│   └── Verify Repair
│
└── Lifecycle
    ├── Maintain
    ├── Update Software
    └── Preserve History

This is a far better starting point than a feature spreadsheet.

The NDD Can Be Incomplete and Still Useful

Suppose:

Long-Distance Travel:
PARTIAL

That is acceptable.

The model already tells us where to work next.

Day 2 Initial NDD QT

A useful threshold might be:

DAY 2 NDD QT
[ ] Root x preserved
[ ] Major need branches created
[ ] Important sub-needs decomposed
[ ] Solution language minimized
[ ] Stakeholders/context added where useful
[ ] Major assumptions explicit
[ ] Critical UNKNOWNs visible
[ ] Constraints separated from needs
[ ] Major evidence linked where available

If these are satisfied:

DAY 2 NDD QT:
PASS

The NDD is mature enough to drive the next stage.

PASS Still Does Not Mean Finished

The NDD will continue evolving.

Tomorrow’s research may change it.

Prototype evidence may challenge it.

Field evidence may challenge it years later.

The NDD is not a contract with yesterday’s assumptions.

It is a living model of current understanding.

What Not to Do on Day 2

Do not:

• choose major hardware
• build a detailed BOM
• lock suppliers
• design factory stations
• write thousands of requirements

Not yet.

Those activities should be downstream of need definition.

What Day 2 Should Produce

At minimum:

Root x
+
Structured NDD Tree
+
Known Context
+
Assumptions
+
Unknowns
+
Initial Evidence

That is enough.

The Complete Day 2 Flow

The practical sequence becomes:

DAY 1 x
↓
CREATE NDD ROOT
↓
IDENTIFY MAJOR NEED DOMAINS
↓
DECOMPOSE NEEDS
↓
ADD STAKEHOLDER + CONTEXT
↓
SEPARATE NEEDS / CONSTRAINTS / SOLUTIONS
↓
ATTACH EXISTING EVIDENCE
↓
MARK ASSUMPTIONS
↓
MARK UNKNOWNs
↓
GENERATE QUESTIONS
↓
DAY 2 NDD QT

The product is still mostly undefined.

That is intentional.

Why the NDD Is So Important

Everything downstream will depend on this structure.

Requirements will inherit from it.

The OR model will respond to it.

Pattern selection will try to satisfy it.

The WBS will resolve its unknowns.

StoryQ will verify behaviors derived from it.

Evidence will eventually tell us whether its needs were satisfied.

The factory will instantiate the selected solution.

The customer will judge the result.

A Weak NDD Creates Downstream Chaos

If the need model is vague, teams compensate by inventing assumptions independently.

Engineering creates one interpretation.

Manufacturing another.

Marketing another.

Service another.

The project fragments.

A Strong NDD Creates Shared Context

Everyone can point back to the same structure.

Why does this requirement exist?

Why is this feature in scope?

Why are we spending engineering effort here?

The NDD can provide the answer.

Day 2: Construct the NDD

That is the second practical step in the ZenOps Car Factory.

Take the broad x defined on Day 1 and turn it into a structured hierarchy of needs. Decompose until the problem becomes understandable, keep solutions out of the need tree, add stakeholders and operating context, distinguish assumptions and constraints, attach evidence where it already exists, and mark every important UNKNOWN explicitly.

Do not try to design the car yet.

The objective is more fundamental:

build a reliable map of the problem before building the solution.

Day 1 gave the vehicle program a reason to exist.

Day 2 gives that reason structure.

And once the NDD is strong enough, Day 3 can begin transforming needs into an explicit automotive domain of objects and relations.