Wiring 4P strategy, HADI cycles, and NBM4 stages for AI-Assisted Product Delivery

Adaptive strategy is a principle. Evidence-mutated strategy is an operating model.

1. Why this matters now

AI does not make product strategy less important. It makes product strategy more exposed. When teams can research faster, prototype faster, generate specifications faster, test more options, and ship shorter releases, they also create more frequent feedback. More feedback creates more contradictions. More contradictions create more pressure to update assumptions. The team then needs to know what should change, what should stay stable, and which artifacts are now contaminated by rejected evidence.

This is where many product strategy models remain too high-level. They correctly say that strategy should adapt, but they do not fully define the mechanism by which evidence from validation and delivery changes the initial strategy artifacts.

The core question is no longer:

Should product strategy evolve?

It should. The better question is:

How does release evidence mutate strategy, roadmap, backlog, product artifacts, and business model assumptions without creating chaos?

That is the gap this article addresses. The proposal:

• NBM4 defines the product and business model lifecycle.
• 4P Strategy defines the rolling strategic state.
• HADI defines the learning loop.
• Product Delivery Platform with AI tooling manages traceability, mutation proposals, and release-aligned updates.

In other words, strategy should not merely be adaptive. It should be traceable, versioned, and evidence-mutated.

2. Building on Roman Pichler’s Strategy Stack

Roman Pichler’s Strategy Stack is useful starting point because it gives product leaders a strategy architecture. It connects business strategy, product portfolio strategy, technology strategy, product strategy, product roadmap, technology roadmap, and product backlog. Roman also explains that the backlog is included to show how strategic decisions translate into tactical ones. ^[1]

The Strategy Stack is especially valuable because it clarifies alignment and ownership. Roman argues that product strategy, product roadmap, and product backlog should be owned by the product manager or product team. Strategic decisions guide discovery and delivery and insights from development work help evolve the product strategy and roadmap. ^[1]

Roman’s Product Strategy System adds another useful angle. It frames product strategy as a system of people, processes, principles, and tools, and explicitly argues that product strategy should be adaptive and integrated with higher-level strategies, roadmaps, discovery, and delivery. ^[2]

In his AI-focused strategy article, Roman also argues that product strategy provides guardrails, keeps teams aligned, avoids “tech for tech’s sake,” and guides responsible AI use. ^[3]

I agree with this direction. The extension proposed here is an addition to adaptive strategy as a lower-level operating mechanism for it.

• The Strategy Stack answers: Where do product strategy artifacts live?
• The NBM4 extension asks: How does evidence mutate those artifacts release by release?

That distinction matters. Adaptive strategy as a principle is not enough. Product teams need adaptive strategy as a working system.

3. From adaptive strategy to evidence-mutated strategy

A product team can agree that strategy should adapt and still fail to answer operational questions:

• Which assumption or hypotheses failed?
• Which artifact depends on it?
• Which roadmap item is now stale?
• Which feature is attached to a rejected hypothesis?
• Which value proposition claim should be rewritten?
• Which pricing or channel assumption is now unsupported?
• Which principle should be kept, changed, downgraded, or retired?
• Which release should commit the mutation?

Without this machinery, “adaptive strategy” becomes a nice phrase. The roadmap keeps moving, but nobody can explain which evidence still supports it. That is how zombie features survive: the assumption dies, but the backlog item keeps walking.

Evidence-mutated strategy solves this by treating strategy as a graph of claims, hypotheses, artifacts, decisions, and mutations. The practical rule:

Every strategic artifact should know what assumption it depends on, what evidence supports or refutes it, and which release last changed it.

This is where NBM4 can extend the conversation.

4. A rolling 4P strategy model

The 4P model used here is inspired by Mintzberg’s strategy thinking, but adapted into four operational strategy objects: ^[4]

• Position is where we are now.
• Perspective is where we want to be at strategy horizon N.
• Plan is how we intend to move from Position to Perspective.
• Principles are the rules of play.

The important part is that these four objects are not a static canvas. They are release-aligned and versioned.

Diagram 1: The operating idea

The Strategy Stack defines strategic architecture. 4P defines rolling strategic state. NBM4 provides lifecycle artifacts. HADI generates evidence. AI helps maintain traceability and mutation proposals.

Each release window starts with a 4P snapshot:

Positionᵢ:    What do we currently believe to be true?
Perspectiveᵢ: What future state are we trying to reach?
Planᵢ:        What bets are we placing in this release window?
Principlesᵢ:  What rules constrain our decisions and trade-offs?

After the release, HADI feedback updates the next snapshot:

Release Rᵢ → HADI cycles → Evidence → Insight → Decision → Mutation → Strategy Snapshot Rᵢ₊₁

So the model is not

Position → Plan → Perspective

It is:

Positionᵢ → Planᵢ → Evidenceᵢ → Mutationᵢ → Positionᵢ₊₁ / Planᵢ₊₁

Perspective and Principles are also reviewed, but they mutate more selectively.

5. Where did Pattern go?

Mintzberg’s Pattern is valuable because it distinguishes intended strategy from realized strategy. In his framing, strategy can be a pattern in a stream of actions, whether or not that pattern was intended. [4]

In this NBM4 adaptation, Pattern does not need to remain a separate strategic pillar.

In a rolling-window AI-assisted product model, patterns are unstable. Each pivot or subpivot can invalidate previous behavior patterns. A repeated pattern may matter, but it should be absorbed into the system rather than kept as a fifth strategic object.

Pattern becomes evidence memory:

Pattern as current evidence → absorbed into Position.
Pattern as durable rule → promoted into a Working Principle.
Pattern invalidated by pivot → archived as historical learning.

That means Pattern is not ignored. It is operationalized.

The compact rule:

Pattern is the residue of previous HADI cycles.

This keeps the 4P model clean while preserving the learning value of realized behavior.

6. Strategy Slice Zero and Position Zero

There is one important nuance: Position cannot always mean “validated reality.”

That definition works after product and release evidence exists. It does not work for Strategy Slice Zero.

At the beginning, there may be no shipped product, no usage data, no activation metrics, no retention curves, and no validated product behavior. But the team is not starting from nothing.

Position Zero is a research-informed educated baseline

It is derived from:

• Founder experience
• Domain expertise
• Market research
• Competitor analysis
• Customer development
• Early discovery interviews
• Known technical constraints
• Known business constraints
• And known unknowns

So Position Zero is not “validated reality.” It is also not random founder belief.

It is assumed reality with traceable rationale.

Diagram 2: Strategy Slice Zero

Strategy Slice Zero is not evidence-free. It is release-feedback-free. Position Zero starts as an educated baseline and becomes evidence-mutated through release cycles.

A Position Zero claim might look like this:

PositionClaim:
  id: pos0_claim_001
  statement: "B2B product teams struggle to convert discovery evidence into actionable specs."
  claim_type: problem
  evidence_level: E3_customer_development_supported
  evidence_sources:
    - founder_experience
    - market_research
    - customer_interviews
  validation_boundary:
    segment: "B2B SaaS product teams"
    limitation: "Pain observed, but willingness to pay, retention, and repeat usage are not yet validated."
  confidence: 0.58
  linked_hypotheses:
    - problem_frequency
    - problem_urgency
    - willingness_to_pay
    - workflow_integration_need

This gives the team a starting baseline without pretending that early discovery has already proven product-market behavior.

A useful evidence maturity ladder:

Strategy Slice Zero usually starts with E1 to E3 claims. The purpose of early release and validation cycles is to move the riskiest assumptions toward E4, E5, and eventually E6.

Diagram 3: Evidence maturity ladder

Position Zero can start with E1 to E3 evidence. Release and validation loops move the riskiest assumptions toward E4, E5, and E6.

The compact rule:

Strategy Slice Zero is not evidence-free. It is release-feedback-free.

7. NBM4 as the artifact traceability graph

NBM4 is already well-suited for this because it is a method for designing and launching new business models and products, guiding organizations from initial idea to market delivery while focusing on opportunity identification, value creation, and market alignment. ^[5]

NBM4 also integrates Customer Development principles. Customer Discovery aligns with Solution Discovery, while Customer Validation integrates into Value Test and Product stages to test hypotheses and confirm product-market fit through pilot sales or repeatable models. ^[6]

That makes NBM4 a natural lifecycle graph.

NBM4 artifacts can include:

• Business idea
• Market opportunity
• Customer segment, ICP
• Persona(s)
• Jobs to Be Done (JTBD)
• Pain points
• Customer journey
• Business model hypothesis
• Business case hypothesis
• Value proposition
• Value test
• Product prototype
• MLP scope,
• Feature hypothesis
• Architecture decisions
• Pricing hypothesis
• Channel hypothesis
• GTM plan
• Product-Market Fit hypothesis/evidence
• Product-Channel Fit hypothesis/evidence,
• Channel-Model Fit hypothesis/evidence,
• Model-Market Fit hypothesis/evidence.

The 4Ps should be wired directly into this graph.

Every NBM4 artifact should know:

Which Position it came from.
Which Perspective it serves.
Which Plan bet it implements.
Which Principles constrain it.
Which hypotheses it depends on.
Which HADI cycles test those hypotheses.
Which evidence supports or refutes them.
Which release mutated it.

Diagram 4: NBM4 Artifact Traceability Graph (ATG)

Every NBM4 artifact traces to strategic intent, depends on hypotheses, is tested by HADI cycles, and mutates through evidence.

This is the operational heart of the model. Strategy is no longer a document above the product work. It becomes part of the artifact system.

8. HADI as the mutation engine

HADI stands for Hypothesis, Action, Data, and Insight. The basic idea is to formulate a hypothesis, perform an action to test it, collect data or feedback, and draw conclusions. [7]

For NBM4, HADI should not merely produce learning notes. It should produce mutation decisions.

Every HADI cycle should end with one of the following decisions:

Confirm
Refine
Reject
Pivot
Pause
Kill

And each decision should create a Mutation Event.

Example:

MutationEvent:
  id: mutation_R5_011
  source_release: R5
  source_hadi_cycle: hadi_activation_003
  target_artifact: onboarding_plan_bet_R5_02
  target_4p_layer: Plan
  mutation_type: supersede
  decision: pivot
  reason: "Evidence-linked onboarding did not improve activation above threshold across two cohorts."
  evidence:
    - activation_delta: "+1.8%"
    - qualitative_theme: "Users understood templates but not why evidence traceability mattered."
  confidence_delta: -0.28
  impact_radius:
    - onboarding_flow
    - value_proposition_copy
    - activation_metric_tree
    - roadmap_item_R6_04
  effective_from_release: R6
  requires_approval: true

This gives the product organization traceability and memory.

Six months later, when someone asks why a product direction changed, the answer is not “leadership alignment” or “market dynamics” or another phrase that has been overused into paste.

The answer is:

This hypothesis failed.
This evidence caused the mutation.
This artifact was superseded.
This release adopted the new plan.
This principle governed the decision.

That is evidence-mutated strategy.

9. Release-aligned strategy mutation

AI tooling can detect signals continuously, but official strategy state should be committed at release boundaries.

This avoids two extremes:

Static strategy:
The team ignores evidence and keeps executing old assumptions.
​
Twitchy strategy:
The team changes direction every time a metric moves.

The better model is controlled release-aligned mutation.

Diagram 5: Rolling 4P strategy window

• Position and Plan mutate frequently
• Perspective mutates selectively
• Principles mutate rarely, unless they are working principles

A practical release flow:

1. Start Release Rᵢ
   Freeze the current 4P snapshot.
​
2. Select Plan Bets
   Choose bets based on Perspective gaps, Position evidence, and active Principles.
​
3. Attach HADI Cycles
   Every major bet must test explicit hypotheses.
​
4. Execute Release
   Build, launch, observe, interview, measure.
​
5. Generate Evidence and Insights
   Classify evidence against hypotheses and artifacts.
​
6. Create Mutation Proposals
   Update, refine, split, merge, supersede, invalidate, or archive artifacts.
​
7. Run Impact Analysis
   Identify affected NBM4 artifacts, roadmap items, specs, GTM assets, metrics, and assumptions.
​
8. Commit Strategy Snapshot Rᵢ₊₁
   Re-baseline Position.
   Rewrite Plan.
   Refine or pivot Perspective if evidence requires.
   Keep, update, or version Principles.
​
9. Generate Next Release Plan
   Derive the next Plan from the new graph state.

The output of each release should be a strategy diff, not only a delivery status report.

Diagram 6: Release strategy diff

Roadmap status says what shipped. Strategy diff says what the organization learned and what changed in the next release window.

Example:

Release Ri Strategy Diff
​
Position:
- Updated activation reality from 22% to 31%.
- Added trust gap as a validated constraint.
- Marked self-serve onboarding assumption as invalidated.
​
Perspective:
- Kept target customer.
- Refined value thesis from "faster specs" to "evidence-backed spec automation."
​
Plan:
- Superseded generic onboarding bet.
- Added evidence-linked onboarding education bet.
- Paused growth campaign until activation threshold is met.
​
Principles:
- Kept "do not scale acquisition before retention validation."
- Added working principle: "All AI-generated recommendations must show evidence trace."

This is more useful than a roadmap update because it explains what changed in the strategy and why.

10. Mutation hierarchy: what changes when evidence disagrees?

Not every failed experiment should trigger a strategic pivot. Evidence should mutate the smallest sufficient strategy object.

Diagram 7: Mutation hierarchy

Evidence should mutate the smallest sufficient strategic object: Plan, Position, Perspective, Principle, or the whole business thesis.

A useful mutation table:

This gives the system discipline.

• Position mutates often.
• Plan mutates every release.
• Perspective mutates selectively.
• Principles mutate rarely, unless they are explicitly working principles.

11. Principles: durable rules vs working rules

Principles should not be slogans. They should be decision rules.

Examples:

Do not scale acquisition until activation and retention are validated.
​Do not ship AI-generated recommendations without an evidence trace.
Prefer workflow integration over standalone destination behavior.
Every roadmap item must trace to a validated or intentionally risky hypothesis.
A strategic pivot requires explicit mutation of affected artifacts, not only a new roadmap label.

It is useful to separate two principle types.

• Core Principles are durable. They represent values, risk boundaries, decision rights, and operating constraints.
• Working Principles are temporary. They are derived from current evidence and can be invalidated by future releases.

Example:

Principle:
  id: principle_014
  type: working
  statement: "Use guided onboarding before investing in fully self-serve onboarding."
  based_on_evidence:
    - evidence_078
    - insight_044
  valid_until: R8
  review_trigger: "Activation above 40% for two consecutive cohorts."
  status: active

This prevents Principles from becoming a junk drawer. A rule derived from temporary evidence should not be disguised as eternal wisdom.

12. What AI tooling should do

AI should not own strategy. Strategy requires accountability, judgment, and risk ownership.

AI should maintain the traceability machinery around strategy.

Useful AI responsibilities include:

• Extracting hypotheses from strategy and product artifacts
• Detecting unstated assumptions
• Classifying feedback by NBM4 stage and 4P layer
• Linking evidence to hypotheses
• Calculating confidence deltas
• Flagging contradictions between roadmap items and invalidated assumptions
• Identifying stale or orphaned artifacts
• Drafting mutation proposals
• Running impact propagation
• Generating release strategy diffs
• Suggesting next-release Plan bets

Humans should still own:

• Perspective changes
• Core Principle changes
• Major pivots
• Sunset decisions
• Risk acceptance
• Strategic trade-offs

AI compresses the operational burden. It should not replace strategic accountability.

13. The minimum schema

A minimum NBM4 strategy mutation schema should include these object types:

The core relationships:

StrategyWindow HAS PositionSnapshot
StrategyWindow HAS PerspectiveTarget
StrategyWindow HAS PlanBet
StrategyWindow GOVERNED_BY Principle
​
PerspectiveTarget DECOMPOSES_TO StrategicOutcome
PlanBet IMPLEMENTS StrategicOutcome
NBM4Artifact SUPPORTS PlanBet
NBM4Artifact DEPENDS_ON Hypothesis
Hypothesis TESTED_BY HADICycle
HADICycle PRODUCES Evidence
Evidence SUPPORTS or REFUTES Hypothesis
Insight LEADS_TO Decision
Decision CREATES MutationEvent
MutationEvent UPDATES / SUPERSEDES / INVALIDATES Artifact
MutationEvent IMPACTS downstream Artifacts
Release COMMITS StrategyWindow

This allows the strategy system to answer practical questions:

Which roadmap items trace to invalidated hypotheses?
​Which NBM4 artifacts lack evidence?
Which Perspective targets are no longer supported by Position?
Which Principles were violated in the last release?
Which shipped features are attached to dead assumptions?
Which Plan bets are blocked by unresolved risks?
What changed between Release R5 and R6?
What must be updated before planning Release R7?

This is the practical difference between “we learn continuously” and “our system knows what the learning changed.”

14. Final thesis

AI-assisted delivery compresses product release cycles. That creates a new burden for product strategy.

The faster teams can build, the faster they can build the wrong thing. The faster teams can analyze feedback, the faster they can produce conflicting interpretations. The faster they can ship, the more they need a disciplined way to decide what evidence changes.

That is why strategy in the AI era should be treated as a rolling, release-aligned, evidence-mutated graph.

In NBM4 terms:

Position is what we currently believe to be true, with explicit evidence maturity.
​Position Zero is the research-informed starting baseline before release feedback exists.
Perspective is the future state we want to make true at horizon N.
Plan is the next-window sequence of bets.
Principles are the rules of play and mutation governance.
HADI is the update engine.
NBM4 is the lifecycle artifact graph.
AI is the traceability assistant.

The compact version:

Every NBM4 artifact should know which Position it came from, which Perspective it serves, which Plan bet it implements, which Principles constrain it, which HADI cycle tests it, and which release mutated it.

That is strategy that learns.

References

1. Roman Pichler, The Strategy Stack: Connecting Business, Product, and Technology Strategy. romanpichler.com/blog/the-strategy-stack/
2. Roman Pichler, Product Strategy as a System. romanpichler.com/blog/product-strategy-system/
3. Roman Pichler, How to Use AI to Create a Winning Product Strategy. romanpichler.com/blog/how-to-use-ai-to-create-a-product-strategy/
4. University of Cambridge Institute for Manufacturing, Mintzberg’s 5 Ps for Strategy. ifm.eng.cam.ac.uk
5. NBM4, The NBM4: Your Guide to Innovative Business Models & Products. nbm4.com/articles/nbmf-guide-intro/
6. NBM4, What is Customer Development and Why Every Product Team Needs It. nbm4.com/articles/what-is-customer-development/
7. StartupStash, HADI cycles. blog.startupstash.com/hadi-cycles
8. mind the PRODUCT, Users engage with only 6% of product features: Product benchmark findings. https://www.mindtheproduct.com/users-engage-with-6-of-product-features-product-benchmark-findings/