This article aims to illustrate the full journey from a software product manufacturer’s Product Vision to a Release Candidate ready for deployment at customer sites. Of course, the full and detailed journey involves a range of disciplines, roles, competencies, and principles that are impossible to do justice to in a single article. I’ll only be able to scratch the surface in an attempt to tie it all together.

The article is intended to be tool-agnostic, though for illustrative purposes, example tools are mentioned. The driving principles behind it are inspired by, e.g., the following sources:

From my articles on the Product Operating Model (start here), you may recall the helicopter view of the Product Operating Model:

It captures the full journey, using Product Vision and Strategy to decide which Problems to solve, how to discover Solutions to those Problems, and how to deliver them.

In this article, I’ve had a documentarist with a camera and a notebook follow the process from the definition of a problem to the release in the customer’s hands.

Should you have followed my articles on this blog, you can hardly have missed the fact that the Cyber Resilience Act is coming like a freight train, with no mercy for deadlines for the presumption of conformity.

The example product manufacturer featured in the article is covered by the CRA, which is why the CRA will be mentioned a couple of times.

DISCLAIMER: This article is written in part with the support of AI, which can make mistakes. Do not consider the article as anything other than inspiration. It is not legal or technical advice.

Let's start the journey - recording started

With the help of the documentarist, you are invited to follow the process from the conception of a problem to solve to the release of the software product.

Just to be clear: Do not take the sequencing too literally. This is not a waterfall process, but for the sake of illustration, this approach is used.

Just like any product, we want to ensure we are effective (building the right thing) and efficient (building it the right way).

We’ll assume the Product Vision and Strategy exist and start with a Product Leadership meeting, using Vision and Strategy as context alongside the overall Business Strategy and Objectives. The task for Product Leadership is now to decide which Problems to solve next.

I know – it looks very top-down. In practice, agreeing on the OKRs is more of a dialogue with the relevant Product Teams than a top-down dictate. Also, the strategic OKRs decomposed into what fits a product team are not shown. You might want to read the article “Finding the rhythm with OKRs and Product.“

Note the integrated tooltips.

Mission-Critical Product Delivery

Documenting the Journey: From Product Strategy to Continuous Delivery

Continuous Discovery

Build the Right Thing
(Cagan, Torres, Perri)

⟷

Continuous Delivery

Build the Thing Right
(Farley)

1. Product Strategy & OKRs
Perri / Wodtke

i

Escaping the Build Trap (Melissa Perri) & OKRs (Christina Wodtke): Instead of handing teams a feature roadmap (the build trap), leadership provides a strategic business problem. This is framed as an Outcome-driven Objective and Key Results (OKR). The Product Trio is empowered to figure out the path.

REC: Vendor Product Leadership Offsite. The CPO shares market intelligence showing their enterprise wind farm clients are struggling to maximize energy capture from changing wind dynamics. "We need to focus on the outcome of increased yield, not just shipping features," she says.

Tool: Workboard / Strategy Doc

🎯 Objective: Expand market share by providing the industry's most efficient turbine yield software.

KR1: Validate a 5% increase in total energy yield during client beta pilots

KR2: Secure adoption of the new module by 2 of our top 3 enterprise clients

"Product leadership sets the destination. The product team figures out the path."

2. Opportunity Solution Tree
Teresa Torres

i

Opportunity Solution Tree (OST) by Teresa Torres: A visual framework to map the path from a desired outcome to potential solutions. The Product Trio uses this to make their implicit assumptions explicit. It forces the team to explore multiple opportunities (customer problems) and multiple solutions before committing to building anything.

REC: The Product Trio's Room. The PM is drawing on a whiteboard. They are mapping out how to increase energy yield. The Tech Lead points to a box: "What if we monitor the dynamics of the three rotor blades in real-time to optimize pitch?" They conclude applying the latest LLMs to the sensor streams is the best approach.

Tool: Miro / FigJam

Outcome: Maximize Turbine Energy Yield

Opportunity: Rotor dynamics aren't optimized for capturing real-time wind variances

Solution: LLM-based Real-Time Rotor Optimization Module

Exp 1: LLM Data Spike

Exp 2: SCADA UI Mock

3. Assumption Testing
Teresa Torres

i

Testing Assumptions, Not Solutions: Before building a full prototype, the Trio deconstructs their ideas into underlying assumptions (Value, Usability, Viability, Feasibility). They run rapid, cheap experiments to test these specific assumptions empirically.

REC: Client Research Session via Zoom. The Designer isn't showing a full product yet. They are testing a core Value Assumption with a lead operator to see if they would even trust AI-driven autonomy in principle.

Tool: Notion (Experiment Tracker)

Assumption (Value): Client operators will trust an LLM-driven autonomous pitch correction to optimize energy.

Test Design: One-question smoke test during a routine SCADA usability interview. Show a mock alert and ask: "If the system auto-corrected this, would you override it?"

Success Metric: >75% of interviewed operators say they would allow the auto-correction to proceed.

4. Risk Mitigation Check
Marty Cagan

i

The Four Core Risks (Marty Cagan): Before moving to delivery, the Product Trio must be confident they have mitigated four risks: Value (Will customers buy/use it?), Viability (Does it work for our business/compliance?), Usability (Can users figure it out?), and Feasibility (Can engineers actually build it?).

REC: Legal & Compliance Meeting. The PM is presenting the prototype to the Chief Legal Officer to ensure providing autonomous LLM software doesn't violate AI or energy industry regulations.

Tool: Dovetail (Insights)

✓

Value: Verified. Client operators kept LLM Auto-Optimize enabled in 85% of simulated test shifts.
✓

Viability: Verified. Legal cleared LLM decision boundaries; bounded outputs ensure safety limits cannot be exceeded.
✓

Usability: Verified. UI prototype required no manual training.
✓

Feasibility: Verified. Local LLM tested on client-provided historical telemetry confirms it can process blade dynamics fast enough to generate a 5% yield increase.

5. API Contracts & Arch.
Modularity

i

Separation of Concerns: A highly modular architecture relies on strict API contracts. Defining these upfront using Interface Definition Languages (like Protobuf or OpenAPI) decouples teams, allowing for parallel development and independent deployment of components.

REC: Whiteboard Session. The Tech Lead and a Systems Architect define the exact data structures the new LLM module will receive and emit, ensuring it seamlessly integrates with the client's core turbine loop.

rotor_llm_opt.proto — Tool: Protobuf

syntax = "proto3"; package turbine.optimization; // Defined BEFORE implementation to decouple teams service RotorLLM { rpc EvaluateDynamics(RotorTelemetry) returns (PitchOffset); } message PitchOffset { double micro_adjustment = 1; bool within_safety_bounds = 2; }

6. Layered BDD Executable Specs
Dave Farley

i

Acceptance Test-Driven Development (Dave Farley): BDD/ATDD bridges the gap between the business problem and engineering execution. To prevent tests from becoming brittle, Farley mandates a strict Separation of Concerns: separating the What (Business Rules) from the How (Protocol interaction).

REC: Three Amigos Meeting. The PM, QA, and a Developer sit together. They construct the acceptance tests using Farley's layered model, ensuring UI changes in the future won't break the business logic tests.

Tool: Cucumber (BDD Layers)

Layer 1: Business Spec (The "What")Gherkin

Scenario: Increase yield during turbulence Given rotor telemetry shows turbulent airflow When the LLM evaluates the dynamics Then a micro pitch offset is applied

Layer 2: Domain DSL (The "Glue")Step Defs

// Maps English to actions, NO protocol knowledge @When("the LLM evaluates the dynamics") public void llmEvaluates() { turbineSystem.evaluateRotorLLM(); }

Layer 3: Protocol Driver (The "How")API/UI Client

// Only this layer knows about HTTP/gRPC public void evaluateRotorLLM() { gRpcClient.send(RotorTelemetry.newBuilder()...); }

7. Engineering: TDD & Trunk-Based Dev
Dave Farley / CD

i

Continuous Delivery Engineering: Engineers employ Test-Driven Development (TDD) to drive code design and ensure high internal quality. They avoid long-lived feature branches, committing directly to trunk (main) multiple times a day to avoid merge hell and enable continuous integration.

REC: Engineering Bay. Two developers are pair-programming. They are strictly following the Red-Green-Refactor cycle. "We can't rely on a manual 3-week QA cycle anymore," one says. "Under CRA Article 14, if there's a zero-day in our control logic, we have to triage and push a secure patch within days. TDD and a fully automated pipeline are the only ways we survive that legally."

Pair Programming: The TDD Cycle

🔴 RED: Write a Failing Test

Before any logic is written, they write a test asserting the required micro pitch offset. They compile, and watch it fail.

EXPECT_EQ(llm.eval(turbulent_data), 1.5); // ❌ Fails

🟢 GREEN: Make it Pass

They write the absolute minimum, "hacky" code just to make the test pass and prove the wiring works.

return (is_turbulent) ? 1.5 : 0.0; // ✅ Passes

🔵 REFACTOR: Clean Up

Protected by the passing test, they implement the *actual* embedded LLM inference call.

return RunLocalLLMInference(data); // ✅ Still Passes!

Terminal — Git CLI (Trunk-Based Dev)

make test
[==========] 142 tests from 12 test suites ran. (12 ms total) [ PASSED ] 142 tests.
git commit -am "refactor: implement local LLM inference call"
git push origin main
Pushing directly to trunk (main)... Triggering Automated CD Pipeline...

8. The Deployment Pipeline Cockpit
Dave Farley

i

Automated Regulatory Auditor: The deployment pipeline is the sole mechanism for deploying software. It subjects the code to escalating stages of rigorous, 100% automated testing. It acts as an automated regulatory auditor, rejecting anything that doesn't pass strict security and business gates.

REC: Control Room Monitor. No humans are clicking "deploy." The pipeline automatically pulls the code from `main`. It passes the Commit stage, but the klaxon sounds at the Acceptance stage. A security gate has failed. The Release Candidate is blocked.

✓

Commit Stage

< 5 mins
Passed
Compile, Lint, Unit Tests

Acceptance Stage

< 30 mins
FAILED
BDD Tests & Sec Scans

⋯

Simulation Stage

< 2 hrs
Skipped
Hardware-in-the-Loop

⊘

Release Candidate

Discarded
v2.14.0-rc

BDD Acceptance Tests ✓ PASS

42/42

Executing Gherkin Specs

SAST Quality Gate

✕ FAIL

SonarQube: Critical vulnerability in parser block.

SCA Dependency Scan

✓ CLEAN

Black Duck: 0 CVEs found in OSS libs.

Deployment vs. Release

Stop The Line: Because the pipeline failed the SAST scan, the team stops what they are doing to fix the code immediately. The Release Candidate is destroyed.

Feature Flags: If successful, the pipeline publishes the artifact to the secure edge-fleet registry. It lies dormant until the Product Manager, coordinating with the client, toggles the feature flag to 'ON' for a specific beta-test wind farm. This separation allows the vendor's engineering team to continuously deliver safely while the business controls the actual feature rollout to clients.

rc_manifest.yml

# The CD Litmus Test version: "v2.14.0-rc" source_commit: "a8f93bc4" dependencies: llama_cpp_engine: "v0.3.1@sha256:8b1a..." vendor_plc_sdk: "v3.0.1" security: sbom_format: "CycloneDX v1.5" sbom_artifact: "sbom.json@sha256:9f86..." environment: os_image: "alpine:3.15@sha256:4edb..." compiler: "gcc-11.2.0-x86_64" test_context: bdd_specs: "v1.4.2" telemetry_data: "aero_turbulence_v4.csv"

Configuration Management & The Litmus Test: The vendor takes configuration management extremely seriously. The `rc_manifest.yml` above proves they pass the Continuous Delivery Litmus Test: they can perfectly recreate any historical release because everything—source code, compiler versions, 3rd party Open Source Software (OSS) dependencies, test data, and test environments—is strictly versioned. Furthermore, by generating a strictly versioned Software Bill of Materials (S-BOM) in the industry-standard CycloneDX format, the pipeline automatically enforces compliance with the strict supply-chain and vulnerability handling requirements detailed in Annex I (Parts I & II) of the Cyber Resilience Act (CRA).

Wrap-up

The ambition of this article was to illustrate the journey from Vision to Release Candidate. It goes without saying that this is a mouthful, and I’ve not even mentioned other highly relevant sources. The point is that it is complicated, spanning the entire journey from Vision to Release. This was just a scratch on the surface, but hopefully it conveyed some idea of the key principles and concepts.

Let's start the journey - recording started

Continuous Discovery

Continuous Delivery

3. Assumption Testing Teresa Torres i Testing Assumptions, Not Solutions: Before building a full prototype, the Trio deconstructs their ideas into underlying assumptions (Value, Usability, Viability, Feasibility). They run rapid, cheap experiments to test these specific assumptions empirically.

Wrap-up

3. Assumption Testing
Teresa Torres

i

Testing Assumptions, Not Solutions: Before building a full prototype, the Trio deconstructs their ideas into underlying assumptions (Value, Usability, Viability, Feasibility). They run rapid, cheap experiments to test these specific assumptions empirically.