You may have heard the terms Perdue, ISA-95, IEC 62443, and MES, but you are unclear about how they relate to one another. Help is on the way.
In modern manufacturing, bridging the gap between enterprise IT and the factory floor (OT) is rarely just a technical challenge; it is a translation problem. Network engineers, software developers, and operations managers often use frameworks like the Purdue Model, ISA-95, and IEC 62443 interchangeably. This semantic confusion routinely leads to misaligned architectures, friction during Manufacturing Execution System (MES) deployments, and compromised cybersecurity perimeters.
To successfully transition complex digital manufacturing initiatives into stable, secure operations, cross-functional teams need a shared architectural language.
The Unified Industrial Architecture & MES Guide below serves as that Rosetta Stone. This interactive tool untangles the overlapping layers of industrial automation, providing a single, unified view of how these critical frameworks interact:
Architecture (The Purdue Model): Defining the physical and logical network boundaries from the enterprise down to the process level.
Functionality (ISA-95): Mapping operational timeframes and functional software roles across the automation pyramid.
Execution (MES): Detailing the critical Level 3 software layer that orchestrates data flow between business planning and local control.
Cybersecurity (IEC 62443): Securing the IT/OT boundary through strict Zones and Conduits, balancing IT’s need for data protection with OT’s mandate for absolute uptime.
Whether you are aligning a newly formed cross-functional squad, auditing existing network segments, or mapping an enterprise MES rollout, this interactive guide provides the foundational context needed to scale operations securely and efficiently. Explore the interactive levels below to see how these models map to the same physical space.
The Unified Industrial Architecture & MES Guide
Bridging the Gap: Purdue (Network), ISA-95 (Function), MES (Execution) & IEC 62443 (Security).
Wrap-up
True IT/OT integration requires a shared language. By aligning Purdue’s architecture, ISA-95’s functionality, MES execution, and IEC 62443 security, your teams can bridge the gap between enterprise IT and the factory floor.
Let’s Turn Strategy Into Delivered Value
Whether you are navigating CRA and NIS2 conformity, transitioning toward an empowered Product Operating Model, or de-risking a mission-critical technology project, let’s explore how we can work together.
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
i
Workboard / Strategy Doc: Enterprise OKR software. You'd see the VP's screen open to this dashboard, tracking real-time progress of module adoption and client-reported success metrics from beta pilots.
🎯 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
i
Miro / FigJam: Digital whiteboard. The screen is filled with messy, collaborative sticky notes, dotted lines, and voting dots as the Trio debates which solution to tackle first.
Outcome: Maximize Turbine Energy Yield
Opportunity: Rotor dynamics aren't optimized for capturing real-time wind variances
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)
i
Notion Workspace: The PM maintains a database here tracking every experiment's status, linked directly to user interview recordings and success metrics to keep the team aligned.
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)
i
Dovetail: Central insights repository. The Trio uses this to compile hard evidence for all four risks: tagging user test videos (Usability/Value), linking legal meeting transcripts (Viability), and attaching engineering spike results (Feasibility).
✓
Value: Verified. Client operators kept LLM Auto-Optimize enabled in 85% of simulated test shifts.
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
i
Protocol Buffers: Google's data format. The architects write this schema first. Once compiled, it automatically generates boilerplate code for both systems, ensuring they speak the exact same language.
syntax = "proto3";
package turbine.optimization;
// Defined BEFORE implementation to decouple teamsserviceRotorLLM {
rpc EvaluateDynamics(RotorTelemetry) returns (PitchOffset);
}
messagePitchOffset {
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)
i
Cucumber (BDD): The team writes plain-English scenarios. Cucumber reads these sentences and executes the underlying test code through layers, turning business rules into living, verifiable documentation.
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/gRPCpublic 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.
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)
i
Git CLI: Version control. Engineers push small, incremental changes directly to the 'main' branch dozens of times a day, avoiding merge conflicts and keeping the pipeline constantly flowing.
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
i
SonarQube (SAST): Static Application Security Testing. Scans the raw source code for known security vulnerabilities and code smells before compilation. Failing this gate ensures non-compliant code never reaches production.
✕ FAIL
SonarQube: Critical vulnerability in parser block.
SCA Dependency Scan
i
Black Duck (SCA): Software Composition Analysis. Analyzes Open Source dependencies to identify known CVEs and license risks, essential for CRA compliance.
✓ 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 Testversion: "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.
Based on publicly available information about PRINCE2 and PRINCE2 Agile, I’ve created an interactive guide with AI support to bring you up to speed in no time.
First, let me clearly declare a couple of my firm convictions:
Dogmatism is your worst enemy. Do not be a high priest of SAFe, Scrum, PRINCE2, Scrum@Scale, Half Double, and I could continue. See, e.g., my article on Balances and the forces of complexity.
Process is not a substitute for thinking. The frameworks above can easily lead you to believe that blindly following the prescribed recipe will ensure success. See e.g., my article on The European Process Disease.
What I’m trying to convey here is that you must have a critical approach to “frameworks“. They’ll never be your silver bullet. As an experienced project- and product manager, you’ll know that a mix of ingredients, fit for purpose, is what makes your day.
But to have this critical and balanced approach, you must know what the various frameworks are, which brings me back to the purpose of this article: Get a firm grip on PRINCE2 and PRINCE2 Agile.
DISCLAIMER: Despite my attempt to qualify the guide, AI does make mistakes. Do not perceive this guide as anything other than inspiration. It is not a substitute for the actual books behind.
Are you feeling so tired just at the thought of having to read the two phonebook-sized PRINCE2 manuals?
Help is on the way. The interactive guide has three main sections:
The Visual Overview: Conveying the main structure and relationships.
The Learning Repository: A (very) condensed essence of the two books.
The Knowledge Test: To assess whether you actually captured the essence, I’ve provided an accompanying 30-question knowledge test.
The interactive guide
The aim of this guide is to help you grasp the essence of PRINCE2, PRINCE2 Agile, and their relationship. I’m sorry to say, but if you want to appreciate it deeply, you’ll have to read both the phone books.
PRINCE2 & PRINCE2 Agile
The Definitive Master Guide & Knowledge Assessment
The Core Framework Structure
A conceptual mapping of how the PRINCE2 methodology fits together, scaling from the overarching project environment down to the core chronological execution.
Tailoring to Environment
The 7 Principles
The 7 Themes
The 7 Processes
TailoringAdapting the framework to the project's size, environment, and complexity (e.g., using the Agilometer).
The 7 PrinciplesThe non-negotiable foundation. Without adhering to all seven, it is not a genuine PRINCE2 project.
The 7 ThemesThe ongoing knowledge disciplines (like Risk, Quality, Business Case) that must be continuously applied.
The 7 ProcessesThe chronological, step-by-step project lifecycle mapping from "Starting Up" to "Closing".
The PRINCE2 Process Model
A structural mapping of who does what, and when. Processes are mapped against management levels (vertical) and project stages (horizontal).
Directing
Managing
Delivering
Pre-project
Initiation stage
Subsequent delivery stage(s)
Final delivery stage
SU
Directing a Project
SB
IP
SB
Controlling a Stage
CP
Controlling a Stage
Managing Product Delivery
Managing Product Delivery
The PRINCE2 Agile "Cake" Model
Illustrating how PRINCE2 governance cascades downwards, while Agile delivery mechanics rise upwards. They meet perfectly at the management layer.
PRINCE2 Cascades Down
Agile Mechanics Rise Up
Project Direction
Focus: Business Justification & Strategy
100% PRINCE2
Project Management
Focus: Stage Tolerances & Blockers
The Hybrid Blend
Product Delivery
Focus: Sprints, Features & Quality
100% Agile
Syllabus
The Hybrid Paradigm: PRINCE2 + Agile
Welcome to the definitive synthesis of corporate governance and iterative delivery. Traditional PRINCE2 provides unparalleled structure, accountability, and business alignment. Agile provides rapid delivery, adaptability, and continuous feedback. PRINCE2 Agile bridges the gap, allowing you to govern at the project level while delivering at the product level.
The Core Philosophy: PRINCE2 handles Project Direction and Management. Agile handles Product Delivery. They do not compete; they stack to form a complete governance ecosystem.
Key Differentiators
Tolerances (The Hexagon): In standard projects, time and cost can flex. In PRINCE2 Agile, Time and Cost are zero-tolerance (fixed). Scope and Quality are flexed to hit deadlines.
Empowerment: The Project Manager focuses on unblocking the environment and managing exceptions. The Team Manager (e.g., Scrum Master) has full autonomy over the Work Package execution.
Documentation: Heavy management products (PIDs, Issue Registers) are replaced or supplemented by "Information Radiators" (Kanban boards, Burn-down charts) and informal rich communication.
The 7 Principles
These are universal obligations. If your project does not strictly adhere to all 7, it is not a PRINCE2 project. Expand each to reveal the Agile application and common anti-patterns.
1. Continued Business Justification
Core Rule: The project must make solid business sense from start to finish. If the ROI disappears, the project stops.
Agile Application
Supported by defining a Minimum Viable Product (MVP). The Business Case is assessed continuously during Sprint Reviews and Releases, looking at actual delivered value rather than theoretical forecasts.
Anti-Pattern:Continuing to fund Agile teams purely because they have a backlog and are "building cool features," even after the primary business problem has been solved.
2. Learn from Experience
Core Rule: Project teams must actively seek, record, and act upon lessons throughout the lifecycle, not just at the end.
Agile Application
This principle is the lifeblood of Agile. It perfectly maps to the Sprint Retrospective. Lessons are not put in a massive "Lessons Log" word document; they are converted into actionable tasks in the very next Sprint Backlog.
Anti-Pattern:Treating Retrospectives as "blame games" or talking about the same process failures every Sprint without ever fixing them.
3. Defined Roles and Responsibilities
Core Rule: Everyone must know exactly what they are supposed to do, what others expect of them, and who has decision-making authority.
Agile Application
Integrates Agile roles transparently. The Senior User acts as a Super Product Owner; the Team Manager acts as or alongside the Scrum Master. Governance rules are clear, but delivery execution relies on a self-organizing team.
4. Manage by Stages
Core Rule: The project is planned, monitored, and controlled on a stage-by-stage basis to establish solid go/no-go control points.
Agile Application
Management Stages act as protective wrappers around multiple short Delivery Iterations (Sprints). You do high-level planning for the Stage, but detailed, just-in-time planning for the Sprints.
Anti-Pattern:Confusing a 2-week "Sprint" with a "Management Stage", leading to the Project Board having to authorize the project every 14 days (massive governance overload).
5. Manage by Exception
Core Rule: Delegate authority by setting tolerances (Time, Cost, Scope, Risk, Quality, Benefits). Only escalate when these tolerances are forecast to be breached.
Agile Application
The ultimate enabler of Agile. By setting strict tolerances at the Stage level, the PM empowers the delivery team to self-organize within those boundaries. The team can dynamically swap "Could Have" features to protect the timeline without asking for permission.
6. Focus on Products
Core Rule: Focus strictly on the definition and delivery of products (outcomes), not just the activities or hours worked.
Agile Application
Product Descriptions map directly to Epics and User Stories. The PRINCE2 "Quality Criteria" becomes the strict Agile "Definition of Done". If it doesn't meet the criteria, the product is not finished, regardless of how many hours were logged.
7. Tailor to Suit the Environment
Core Rule: PRINCE2 is a framework, not a straitjacket. It must be scaled and adapted to the project's size, risk, and complexity.
Agile Application
This is how PRINCE2 Agile exists in the first place! You use the Agilometer to assess the environment, and tailor your communication (using whiteboards instead of Word docs) and reporting (using burn-charts instead of weekly text updates).
The 7 Themes (Practices)
The ongoing aspects of project management that must be addressed continuously.
Business Case
Why are we doing this?
Core Rule: Establish mechanisms to judge whether the project is (and remains) desirable, viable, and achievable.
Agile Application: Validated through early value delivery via Minimum Viable Product (MVP). Evaluated frequently during Sprint Reviews.
Organization
Who is who?
Core Rule: Define and establish the project's structure of accountability and responsibilities.
Agile Application: Integrating Product Owners (Senior User rep) and Scrum Masters (Team Manager rep) into the PMT without creating conflicts.
Quality
What is expected?
Core Rule: Ensure products are fit for purpose and meet the customer's expectations.
Agile Application: Quality is FIXED in PRINCE2 Agile. Translated perfectly as the "Definition of Done" and strict Acceptance Criteria for user stories.
Plans
How, how much, when?
Core Rule: Facilitate communication and control by defining the means of delivering the products.
Agile Application: Planning is highly iterative. High-level plans at the Stage level; detailed just-in-time planning at the Sprint Backlog level.
Risk
What if...?
Core Rule: Identify, assess, and control uncertainty to improve the ability of the project to succeed.
Agile Application: Agile inherently mitigates delivery risk via short feedback loops. Technical spikes and frequent delivery validate assumptions early.
Change
What's the impact?
Core Rule: Identify, assess, and control any potential and approved changes to baselines.
Agile Application: Embraced dynamically! The Baseline is protected at the Stage level, but specific Scope details are swapped out (via MoSCoW) at the Sprint level.
Progress
Where are we now?
Core Rule: Monitor actual achievements against planned achievements and control any unacceptable deviations.
Agile Application: Measured exclusively by working, tested products, not timesheets. Utilizes Burn-down charts, Kanban boards, and Information Radiators.
The 7 Processes & Timeline
Expand each phase to see the exact data triggers, outputs, and how Agile mechanics map to the timeline. The green line represents the chronological flow of governance.
Important: Non-Linear Overlaps
In the official PRINCE2 process model, the timeline is not strictly linear—several processes overlap:
Directing a Project (DP) runs continuously across all stages from the moment it is triggered by SU.
Controlling a Stage (CS) and Managing Product Delivery (MP) operate concurrently within each delivery stage.
Managing a Stage Boundary (SB) occurs at the end of each stage, feeding vital planning data into the next.
1. Starting up a Project (SU)
Core Rule: Pre-project filter to prevent poor ideas from wasting resources.
Trigger: Project Mandate
Output: Project Brief, Initiation Stage Plan
2. Directing a Project (DP)
Core Rule: Runs start to finish. The Project Board makes Go/No-Go decisions and manages exceptions.
Agile Application: The Board manages by exception, rarely interfering in daily Sprint activities, focusing purely on Stage tolerances.
3. Initiating a Project (IP)
Core Rule: Establish solid foundations, baselines, and understand the work required.
Agile Application: CRITICAL STEP. The Agilometer is executed here to determine how Agile the delivery can safely be before committing.
4. Controlling a Stage (CS)
Core Rule: PM manages the stage day-to-day, assigns work (via Work Packages), and tracks progress.
5. Managing Product Delivery (MP)
Core Rule: This is where the Team Manager (or Scrum Master) accepts the Work Package and facilitates the actual building of the product.
Agile Application: All Scrum/Kanban execution lives entirely inside this process! Sprints, Daily Standups, Sprint Reviews, and Retrospectives happen here. The PRINCE2 "Work Package" defines the boundary constraints (Cost/Time) for the internal iterations.
6. Managing a Stage Boundary (SB)
Core Rule: Evaluates the current stage and prepares the detailed plan for the next stage.
Agile Application: Perfect alignment with major Release Retrospectives and updating the product roadmap for the next major increment.
7. Closing a Project (CP)
Core Rule: Formal handover of products, evaluate success against the baseline, free resources.
Roles & Responsibilities
Understanding how corporate governance roles interface smoothly with Agile delivery teams without creating friction or micro-management.
Project Board (Executive)
Agile Interface: Sponsor / Product Management Director
Core Duty: Ultimate ROI accountability. Funds the value stream and ensures continued business justification.
The Executive governs by exception. They empower delivery teams by setting stage-level tolerances and assessing value at Release points, rather than getting involved in day-to-day Sprint mechanics.
Anti-Pattern: Demanding to attend Daily Standups to check on team velocity instead of viewing Information Radiators.
Senior User
Agile Interface: Super Product Owner
Core Duty: Specifies needs, prioritizes the high-level backlog (via MoSCoW), and commits user resources.
Crucial for Agile success. They ensure the Agile team builds the right thing to deliver business value and accept the final product increments at the end of Sprints/Releases.
Senior Supplier
Agile Interface: Technical Lead / Architecture Owner
Core Duty: Ensures technical viability, quality standards, and resource availability.
Ensures the team builds the thing right. They guide the Definition of Done regarding technical debt, security, and architectural integrity.
Project Manager
Agile Interface: Delivery Manager
Core Duty: Manages up to the board, unblocks teams, tracks stage tolerances, monitors Risk/Issues.
Acts as an "umbrella," shielding Agile teams from corporate bureaucracy. Translates Agile outputs (Burn-down charts) into language the Project Board understands.
Anti-Pattern: Assigning daily tasks to developers instead of letting the Scrum Master facilitate self-organization.
Team Manager
Agile Interface: Scrum Master / Agile Delivery Lead
Core Duty: Facilitates sprints, accepts Work Packages from the PM, and builds the products.
Ensures Agile ceremonies are effective, clears roadblocks, and ensures products meet fixed quality tolerances before handing them back to the PM.
Management Products & Agile Artifacts
In PRINCE2 Agile, documentation focuses on value and communication ("Information Radiators") over formal word documents. Expand to see the evolution.
The Project Brief & PID
Standard Purpose: Defines the baseline, business case, scope, and governance structure before execution.
Agile Evolution
Often built collaboratively in wikis (Confluence) or visually on canvas boards (Project Canvas). They remain crucial for capturing the baseline, but shouldn't be static PDFs.
Product Descriptions
Standard Purpose: Defines exactly what must be delivered, including composition and quality criteria.
Agile Evolution
Translate directly into Epics and User Stories. The formal "Quality Criteria" becomes the strict Agile "Acceptance Criteria" or "Definition of Done".
Work Packages
Standard Purpose: The formal agreement handing over responsibility for building products to the Team Manager.
Agile Evolution
Forms the ultimate boundary for an Agile team. Defines the fixed Time and Cost constraints for Sprints. Backlog details are managed dynamically inside this boundary.
Highlight / Checkpoint Reports
Standard Purpose: Time-driven progress reports used to communicate status to management.
Agile Evolution
Replaced by "Information Radiators". Stakeholders use live dashboards, Burn-down charts, or Jira reports instead of static, text-heavy push reports.
PRINCE2 Agile Specifics
1. The Hexagon (Tolerances)
In a traditional project, scope is fixed, and if things go wrong, deadlines and budgets slip. PRINCE2 Agile flips this.
Strictly Fixed (Zero Tolerance)
TIME & COST
Deadlines are fiercely protected. You do not ask for more money. You do not extend the Sprint.
Flexed (To hit the deadline)
SCOPE & QUALITY
If time runs out, lower priority features (Could Haves) are dropped to ensure on-time delivery of the MVP. (Note: Quality *criteria* can flex, but overall quality level is protected).
2. The Agilometer
Assessed during the Initiating a Project stage, this tool evaluates 6 risk areas to determine how "Agile" the environment can safely be. (Score 1-5).
Flexibility on what is deliveredHigh (5)
Level of collaborationMed (3)
Ease of communicationLow (2)
Ability to work iterativelyHigh (4)
Advantageous environmental conditionsHigh (4)
Acceptance of AgileHigh (5)
3. The 5 Focus Areas
1. Agilometer
Assessing environmental readiness. The Agilometer is a tool to evaluate the project environment to tailor PRINCE2 correctly, checking factors like team collaboration and ease of communication.
2. Requirements
Prioritization via MoSCoW. Requirements are defined and prioritized using MoSCoW (Must, Should, Could, Won't) to ensure the most valuable features are delivered within the fixed time and cost.
3. Rich Communication
Whiteboards & face-to-face over docs. Preferring interactive, high-bandwidth communication methods (like daily stand-ups and visualizations) over formal written reports to increase speed and clarity.
4. Frequent Releases
Delivering early ROI. Designing the project to release valuable increments to the customer as early and as often as possible, rather than waiting for a single 'big bang' delivery at the end.
5. Agile Contracts
Structuring procurement to allow scope flexing rather than rigid fixed-price/fixed-scope traps. Agile contracts focus on collaborative relationships, flexible scope within fixed budgets, and outcomes over outputs.
Assess Your Expertise
This assessment evaluates your understanding of PRINCE2 processes, Agile mapping, and project governance.
Knowledge Assessment
Question 1 of 30
Detailed Performance Report
Wrap-up
Hope you enjoyed using the guide. Remember, PRINCE2 / PRINCE2 Agile is not a silver bullet. It is up to you to mix ingredients from various frameworks, practices, and tools to fit the problem at hand.
That is your Secret Sauce for success.
You must elevate yourself above the dogmatism of frameworks and processes. Only the experienced project- and product manager with an insatiable thirst for knowledge and insights can do that.
I’ve addressed the ProductInnovation topic numerous times in the BLOG, and much of the referenced literature concerns Product Innovation. Having worked with various organizations, and joined various network discussions, my aim is here to share my (subjective) understanding of where we in Europe should be in terms of Product Innovation, and what we’re struggling with, in getting there.
Some context
Even the best high-tech Product Companies have to step up their game.
Who would have imagined that the indisputable king of searches, Google, would face real competition? Enters ChatGPT and other Language Models with ground-breaking ways to search information, making the good old Google search look like some relic from the past.
Look at the automotive industry. Until very recently, the European automotive flagship was indisputably found in Germany with VW, Mercedes, Porsche, and Audi. Not so long ago, you would find these quality brands dominating the streets in China. Not anymore. The Chinese automotive industry has shown an impressing pace of innovation, leaving the Europeans on the roadside. Now the Chinese are driving in locally designed EVs. And – Chinese EVs like BYD, Polestar, Aiways, Nio, Xpeng, Maxus, and Hongqi – just to mention a few – are entering the European roads.
Look at the financial sector. The traditional brick-and-mortar banks have been in a safe haven with literally no competition. Cryptocurrency, online banking, and now solutions like Stripe and Lunar. That haven is not that safe anymore.
What is happening? With the worn-out term, disruption is what is happening. If you do not relentlessly keep innovating your products and the way you do it, you’ll get overtaken.
The goal, Product Innovation, is the same, but the means are very different
What are these thought-leaders guiding us towards, what makes these product companies so successful, and how is this similar or different from what is found in Europe?
I’ll throw in my two cents.
Before moving on, let’s be clear on the fundamental difference between a Project and a Product (not wanting to start a big dogmatic discussion)
Project
Has a start date and an end date
Serves the specific customer, asking for / sponsoring the Project
Product
Continuous Discovery, Development, and Delivery
Serves a multitude of customers / users
Though being fundamentally different, the two can and will often share some toolboxes and techniques. In the Stone Age, you would characterize a Project by the “Iron Triangle” (scope-cost-time) under the assumption that requirements/scope could be agreed upon and fixed up-front.
Realizing that often not being realistic, the notion of “Agile Projects” has entered the scene. You would still fix costs and time now having the flexibility in scope. It is still having the characteristics of a Project, not a Product.
It is fair to say, especially if you’re a start-up, that your Product typically starts with a Project in your quest for product-market fit.
In this article, the focus will be on the Product, not the Project.
Spoiler: Product Innovation is not about being excellent with some “Agile Framework”. In the best case, these are helpful means in the toolbox, but not what drives Innovation. In the worst case, this Framework fixation distracts the organization from working with the real impediments, preventing effective Innovation.
The biggest missing value statement in the Agile Manifesto is:
Successful outcomes over efficient deliveryJeff Patton
Achieving Product Innovation
The world’s top product-led companies
The key is highly empowered, loosely coupled, and highly aligned product teams
provided with a strategiccontext (Product Vision, Product Strategy, Technology Strategy)
with high-frequent customer interaction and hypothesis tests
being measured on, and held accountable for outcome for solutions to (hard) business/customer problems
Europe
We believe the key is about having the right (Innovation-) processes, and the more “process-mature” we are, the better.
When we fail to innovate, we blame the processes – not by reducing the complexity and process volume – but by adding even more rigid process prescriptions, governance bodies, controllers, checklists, and KPIs in a quest towards predictable output (Features to build).
The Strategic Context (Product Vision, Product Strategy, Technology Strategy, and high-level architecture) gives the product teams meaning, direction, and focus. In addition, it helps define a topology of loosely coupled, yet highly aligned product teams.
Product Vision: Being a subset of the full Company Vision, it provides the big WHY and common North Star for the product organization to navigate towards.
If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.
Product Strategy: The overall plan for which customer/business problems should be solved by the product teams in which sequence → Focus, as highlighted by Christina Wodtke on OKRs, is fundamentally important for success
I believe the one thing that makes the difference between excelling and flailing about in mediocrity is focus.
OKRs are a framework for creating and ensuring focus on what really matters, but they don’t work if you stuff them full of every single business-as-usual initiative you have going.
Technology Strategy and high-level architecture: This is e.g., about ensuring the company has an architecture capable of delivering the functionality, scalability, reliability, security, and performance it needs to compete and thrive. The architecture caters to a Team Topology with loosely coupled yet highly aligned product teams.
Encapsulated / loosely coupled teams are one of the prerequisites for real Business Agility. Jeff Bezos has made no secret out of that, concerning what encapsulation and decoupling mean in software:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn’t matter what technology is used. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
Firstly and fundamentally, your organization needs Technology Excellence in your field of operation. Without it, you’re irrelevant. I’m here assuming that to be the case, including the existence of a strong Technology strategy. It is like the foundation of a high-rise building. Having that assumption in place, what else do we need in our quest for high-paced Innovation?
This article suggests an answer, centered around the illustration below, assuming a multidisciplinary product.
In another article, I’m complementing the above with what I’ve coined Innovation Power:
How to strengthen your Product / Innovation Culture
A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They (ed.: the product organization) understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the results of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team.
Clearly communicate that innovation is not something reserved for specially selected people in an “innovation lab”. In a truly innovative product culture, the best ideas often come from unexpected places. Invite for and encourage to contribute to the innovation process. Crowdsource innovation in your organization.
How to strengthen your Organizational Structure
It does not make sense to hire smart people and tell them what to do. We hire smart people to tell us what to do.
Remember my attempt above to differentiate between Project and Product?
Not like this
Your (Project-) Teams are disconnected from your customers via a multi-layer proxy.
More like this
Your (Product-) Teams have been moved closer, much closer, to your customers.
In this Just Product 2023 talk, Sebastian Borggrewe provides an easy-to-grasp illustration of why you need to treat your Product as a Product; not as a Project container:
How to improve your Servant Leadership practices
Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.
Good leaders focus on culture and purpose because culture drives innivation and performance. The greatest capital of an organization is its people. To innovate, people need autonomy and meaning.Marty Cagan, EMPOWERED p. 372
First and foremost – unlearn the hierarchical “command & control” way of leading, substituting it with “leading by context“. Core elements in this context are the Product Vision, Product Strategy, and Technology Strategy. It is from this context, that the product teams are tasked with (hard) customer/business problems for which to discover the best solution.
Give room, let the team shine, control your ego, show trust, and most important of all – show through your actions that you embrace the Product Culture.
Pave the way for the teams to function at an optimal level. Sometimes a small stone for you is a major blocker for the team.
Minimum Viable Governance & VC-style funding
Innovation is only expensive if you use traditional business planning to make investment decisions. Innovation, when done right, is about making small bets, testing ideas cheaply and quickly to identify the winners in which you then invest more resources
Run an experiment. Allocate a chunk of the development budget for later allocation via an internal VC forum. Start small and learn before you scale up.
Be very critical with large investment programs / Big Bets. Their size in themselves poses a significant risk. Make sure that these monoliths are in fact what serves you best.
Tell your CFO nicely that his need for control (which in fact is not control, because it is impossible to forecast the correct budget distribution one year ahead) is secondary to our ability to do the right things in our quest to serve our customers.
Minimum Viable Process Prescription and a rich pick & use Buffet
I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign. The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.
Start by asking yourself the very basic question: “Do you trust the judgment of your employees and their professionalism enough to let them decide on solutions to problems without you policing them?”
If YES – show it!
If NO – challenge yourself. Are you hit by a process disease being a way indirectly to control your employees?
Finally, ask yourself: “Despite Amazon & Tesla being digital natives, what prevents you from turning down the volume on your process obsession and moving in the direction of Amazon and Tesla?”
Not all processes are evil. Some are highly needed and valuable. The delicate challenge is to strike the right balance between Process Prescription and a rich pick & use Buffet.
Technology excellence
Cut to the bone, technology is the product!
Solid engineering practices and deep technology expertise are of course a must during both Discovery, Development, and Delivery.
One thing that can kill your business agility is poor engineering practices resulting in, e.g., global dependencies. No matter the engineering domain, your engineers must follow the lead from software development, ensuring decoupling via encapsulation behind stable interfaces – not to forget the fundamentally important Configuration Management discipline as mentioned above.
Boiled down to its essence, we can achieve more in Europe by learning from the best:
Stronger context, less control
More empowerment, less process prescription – though a versatile toolbox facilitating knowledge sharing is highly valuable
Yes, this can seem far-fetched and scary if you’re currently caught in your (own) process web, maybe even with a burning platform. You need fundamentally to free yourself from the gravitational field of process fixation, towards a Product Operating Model.
Taking the first steps
First and foremost, you need to
Scale down on the bureaucracy/process fixation that prevents your product teams from focusing on the single most important topic: discovering solutions to your customer’s problems, balancing the core risks, being
the solution is Valuable for your customers
the solution is Useable for your customers
the solution is Feasible for us to build, maintain, and produce (in case of a physical product)
the solution is Viable for our business
Leverage the bureaucracy/process fixation with a strong context within which your product teams will thrive
A clear North Star / Product Vision for all the Product Teams to navigate
A Strong Product Strategy, giving direction as to what customer/business problems the product teams should discover solutions to, thus facilitating the fundamentally important focus
A strong and modular architecture, facilitating loosely coupled teams
If you’re currently driven by measuring Output/Features (like with Scrum burn-down charts) from teams, try this litmus test: Are you able to agree on the WHAT to be delivered by the teams (leaving the HOW-to Discovery to the teams)?
YES: At least it seems that you have something going for you, being able to cater to basic agreement management. Don’t stop here. Work on the above context, aiming for having Problems to solve in your team’s backlogs, not Features to build.
NO: You’ll probably need to work on your agreement management practices, as a minimum, getting things under control. Sorry – you have a long way to go.
If you’re currently driven by measuring Outcomes (like with OKRs) from teams, try this litmus test: Firstly, congratulations – you’re already well underway freeing Innovation talent. Do you know what now is most important for your product teams to focus on, and do you make tough choices on what is important?
YES: Great – continue sharpening the saw.
NO: With the words of Christina Wodtke “… one thing that makes the difference between excelling and flailing about in mediocrity is focus.” You need to work on your Product Strategy because it seems that it does not help you enough to understand what is important now.
Have we gotten to the point where everything – including Modern Leadership – is getting the “Agile” label? This is what this post is about.
From early on, I’ve been a strong advocate for doing software development the Agile way for one simple reason: It is pure common sense, reflecting the natural way we as humans / developers think and act in an environment with high uncertainty on what the user / customer really needs.
Great, says the consultancy industry. This Agile Wave has the potential for some serious surfing. Let’s label everything “Agile” and push the need for all sorts of “Agile Certifications”. And so they did.
Agile, essentially in the wrappings of Scrum, has undoubtedly had a transformative effect on software development in the two decades, following the Agile Manifesto in 2001. Even the most stubborn organizations have come to realize the fact, that you’re not able up front to develop and freeze a software requirements specification capturing what the user / customer really needs.
Note: The misguided and uncritical use of Agile practices from the software domain to the physical domain is a full topic for a future post – stay tuned.
Executive summary
Just like Agile (for software development) was essentially common sense 20+ years ago, what today is touted “Agile Leadership” is common sense Leadership. No need to label it “Agile” – just modern, common sense Leadership.
The New Agile Black seems to be on Leadership ... Agile Leadership
But – what is “Agile Leadership”? Is it in fact something new and unique, or did these organizations just put an Agile label on modern, common sense Leadership practices?
“An Agile Leader is a manager who has developed a core understanding of Agile principals while incorporating the Agile framework of Scrum to better improve project results. Agile Leaders must be supportive and focus on the needs of other team members. By encouraging team involvement and support, a sense of community can be developed and sustained within a team. Stronger relationships are created between team members and other stakeholders, which leads to improved business performance and customer satisfaction.”
(1) they create and nurture a culture in which experimentation and learning are embraced;
(2) they collaborate with employees (at all levels in the organization) to find common values to create a greater goal for the company and the teams; and
(3) they create an organizational structure that reinforces and rewards the other two dimensions.”
“Agile leadership is the practice of removing roadblocks to success and streamlining productivity. As agile teams are already proficient in collaboration, the focus of an agile leader is on reducing waste and empowering teams to reach their full potential.”
“Agile leadership is a growth mindset. It is a leadership approach that creates self-management skills. In an agile environment, teams collaborate, learn and get quick feedback from users. … Agile leaders do not micromanage the people nor create total freedom. They make a balance between anarchy and strict structure.”
“According to the results of the research, agile leaders are Humble, Adaptable, Visionary and Engaged. These must-have competencies inform their business-focused actions.”
“Excellent Agile Leader has four core competencies: Ability to define the vision, motivate, gain feedback, and ability to influence through themselves, others.”
“Agile leadership is the ability to be flexible, use different approaches, and adapt to the context and the people involved. Because of this dependence on context, expectations and relationships, there are no leadership behaviors that are inherently positive or negative in and of themselves. Rather, there are leadership behaviors which are more or less appropriate within the context.
Agile leadership is about the ability to make sense of the circumstances and adopt behaviors which are coherent with what the group of people you are leading in a specific context feels comfortable with. Incoherent behaviors are those that are not helpful within a specific situation and might be perceived negatively in the given cultural context. For this reason, Agile leadership is useful for any organization hoping to succeed in today’s climate, not only Agile organizations.”
“True Agile leaders have a clear vision. They don’t give order, but inspire and motivate. They create a working environment in which everyone can become self-absorbed and work autonomously. What qualities you need to become an Agile leader? We’ve listed the five most prominent features:
The ability to inspire and motivate teams and individual employees.
Good communication skills and a healthy dose of empathy.
The desire to constantly develop yourself and the organization.
A helicopter view and the ability to delegate.
Patience and perseverance. An Agile organization can’t develop overnight.”
All the above boiled-down into its essence
Taking specific Agile frameworks out of the equation, all of the above is a collection of characteristics of the modern, effective and efficient leader. “Agile” has no patent here.
If “Agile Leadership” in fact was something new and unique, different from “normal Leadership”, then a “normal Leader” would not
have a clear vision
have perseverance
have the ability to delegate
inspire and motivate
be supportive
operate effectively in a VUCA environment
be self-aware
have a growth mindset
engage others
empower teams
welcome experimentation and learning
remove roadblocks
be humble
be adaptable
… you get the picture …
That is clearly nonsense. “Agile Leadership” is not something special / exotic. It is part of – not equal to – being a modern Leader.
Before discussing what makes a process good, bad, or directly ugly, let’s start with the basics.
An often used way to describe a process in e.g., Lean Six Sigma or ISO 9001:2015, is SIPOC dating back to Total Quality Management in the 1980s:
Think of a bakery having a number of suppliers, providing ingredients to bread, the steps to process ingredients, the bread as output and the customers consuming the bread.
Generally speaking, the purpose of a given process is to create value in one of two ways
Enforcing what the organization carefully has decided to be mandatory to do
Share good practices (not having to re-invent the wheel) in a common Toolbox
What makes an organization prescribe a process always to be followed, depends on a number of factors like
Its business context. An organization within e.g., Medical Devices ISO 13485 will naturally have to have a lot of mandatory processes for it to uphold its ISO 13485 certification
Its perception of employees being mercenaries or missionaries
For all organizations, the challenge is to find the balance working best for them.
Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations.
Jeff Bezos
The Good processes
The processes deemed mandatory are in fact mandatory, providing essential glue in the organization. In the shared “Pick & Use Toolbox” we’re finding a wealth of processes and tools for different purposes – not having to re-invent the wheel and facilitate the all-important integration and sharing of learning. We trust the employee’s ability to apply this Toolbox as needed in the given situation, without strict prescription.
The Good processes help organizations in their quest for agility, customer focus and market position.
The Bad processes
Most processes are here generating value, if used in the proper context. The problem making them bad is the disproportional use of prescription, forcing the process overhead in cases not relevant.
Bad processes undermine agility and distracts organizations from focusing on the customer.
The Ugly processes
The directly ugly processes are those not generating value at all. “Each Friday you have to fill numbers xyz in your report … but nobody uses that data, so why do it? Because the process manual says so!”
Most organizations have a natural tendency to answer growth with more bureaucracy. Left untethered, this autopilot will add more governance- and control bodies and more process prescriptions.
Ugly processes kill organizations, loosing sight of the customers.
What would happen if we ask the teams, what they need to be successful?
It can hardly have missed your attention that it has become a “management thing” how teams are supposed to work. Just look e.g., at the “Agile Transformations” initiated by executive management.
Would the teams ask for the same things that the management believes are needed for successful teams?
Did management choose to impose e.g., SAFe on the organization because of its own convenience, or based on a respectful dialogue with the doers in the organization?
I’ve been doing my own non-scientific survey – with a clean whiteboard, what would the teams write on it?
NB – I’m here using the notion of “team” in a broad sense (project team, product team ..) working with unique problems.
The team perspective, what came on the whiteboard
Do not impose some framework on us, telling us how we work the best. Ask us how you can support us to work with better effect and efficiency.
Do not impose some “coach” on us. Invite us to ask for support and guidance, when we need it. Yes – sometimes e.g., an “Agile Coach” is exactly what we need … we’ll let you know should that be the case.
Do not tell us what solution to implement. Tell us what business / customer problem needs to be solved and trust our ability to discover the best solution to the problem.
Do not measure us on our efficiency to produce Output like a lean machine. Measure us on the Outcome, the effect made, from the discovered solution to the business / customer problem.
Do not ask us for high-integrity commitments in a high-uncertainty area. Support us designing and running Desirability, Feasibility and Viability tests bringing down uncertainty, and then we’re happy to bring high-integrity commitments.
Do not tell us what tools we need in our toolbox, and free us from the process-people in their Ivory Tower. Support us developing and sharing knowledge across the teams, and we’ll take full responsibility for our toolbox, just like any other professional. Often, we’ll appreciate and ask for outside inspiration and knowledge in our quest for professional excellence.
Do not strangle us in bureaucracy and policing. We acknowledge the need to follow a minimum viable set of mandatory processes, but apart from that, respect our ability to do the right thing at the right point in time. We might even have good-practice process fragments in our shared toolbox.
Do not send us on a mission without rationale or as a team not suited for the job. We expect you to show active and strategic leadership, ensuring that the business / customer problems served for us, are the right ones. We also expect you to get our team topology right and suited for the job ahead.
Do not let us hanging in the dark when we need guidance, strategic decisions or removal of impediments. Be available quickly to unfreeze us, and when done, please do not stand in our way.
A boiled-down version could be something like this:
A challenge
When did you last time give your teams full attention and really listen to their needs and concerns without any prejudices?
The fact that nothing beats a good start, is not a new insight.
Well begun is half done Aristotle (384–322 BC)
Neither is the importance of a good plan.
If you fail to plan, you are planning to fail! Benjamin Franklin (1706 – 1790)
Executive summary
You do in fact have some kind of a crystal ball.
A bad start will most likely be followed by a de-railed project (most of the project evaluation report is already written by now). The chances for a successful project on the other hand increases dramatically, when you show the tenacity and discipline, ensuring the Good Start.
This post will discuss what a Good Start is … and why it is not a one-off thing in a project.
The Good Start
The need for a Good Start is universal, being it
in a strong product environment with stable, highly empowered and cross-functional product team measured on outcome
in the classic environment with Agile / Waterfall feature-delivery teams being measured on output
doing business development, production optimization …
For the sake of simplicity, we’ll here call all the different endeavors a “project”.
In the quest for The Good Start, all projects need to understand the TO-BE situation / Vision, the AS-IS situation, its risks and opportunities, and importantly have a guiding strategy for how to reach the TO-BE situation, minimizing risks and optimizing opportunities. All this in the respect of the project’s surroundings and dependencies.
A project will always exist within some context and be subject to a number of dependencies:
For some projects (typically the classic “Waterfall project”) the Good Start includes a detailed Requirement Specification and a detailed Business Case with full financial buy-in.
Other projects with a more iterative nature are often seen driven by continuous discovery and metered funding.
No matter the type of project, we need a Good Start.
Tenacity and discipline needed
This is where you’ll find the seeds for future problems. We’re feeling a constant pressure to get moving, not maintaining the tenacity needed for a good start.
Focus on two things, and it’ll act as a locomotive for you:
Do the right things
Have a strong strategy
Do the right things
The Agile movement has been a strong proponent for Efficiency with its focus on maximized output, supported by burn-down charts, measurement of velocity etc. This Efficiency mindset is enforced by an army of Agile (delivery) “coaches”. You might want to visit the earlier post Product Discovery, elaborating on the deficiencies seen among Agile “delivery coaches”.
What is far more important than being Efficient, is being Effective, making sure that we’re doing the right things. Yes – it should be a no-brainer, but be vigilant here. Ask – “what is the validity of the input to the project?“, “how do we know that this is in fact addresses our (real) customer’s needs, pains and/or gains?”
What is the point being highly Efficient, if what we’re doing is not providing value to our customers?
Have a strong strategy
Your approach strategy binds it all together, requiring you to understand the context / dependencies, TO-BE situation, the AS-IS situation, and the risks and opportunities.
Think of your strategy as the overall plan for how to maneuver your project towards the TO-BE situation / Vision, minimizing risks and optimizing outcome.
Don't stop
Whatever type of project you’re running, don’t stop getting the Good Start. Make it a continuous habit throughout the project. Why? Because your context and dependencies are not (normally) static.
This habit comes in many wrappings, like …
The Double Diamond Model
The rationale here is to have sharp awareness of when being in problem-space and when being in solution-space.
Note the green arrows enforcing the iterative nature of focus-shifting.
Understand the problem, before trying so solve it.
Dual-track agile
Dual-track agile is a variant of the double-diamond model with a clear distinction between Product Discovery (making sure that we’re working on the right stuff) and Product Development (developing the solution in the best and most efficient way).
The same point as above: make sure to have a validated understanding of the problem, before trying to solve it.
Continuous Discovery
Teresa Torres has written the important book Continuous Discovery Habits. Note that Teresa uses the term “customer opportunity” collectively to capture customer’s needs, pains and desires.
The graphics to the right is inspired by Teresa’s Opportunity Solution Tree.
Teressa helps us understand the importance of
Starting with the end (understand the expected outcome)
Assumption Tests (do not implement a solution, unless it has been validated)
Iterating between Problem- and Solution-space
Same story: make sure to work on validated assumptions.
Starting with outcomes, rather than outputs, is what lays the foundation for product success
Teresa Torres
Wrap-up
Having the tenacity and discipline for the Good Start is not about being bureaucratic or being religious about some framework.
It is about pure common sense and business rationale.
Well – no. What you experience are often symptoms originating from some underlying problem. In our high-paced society, we’re constantly tempted to do something fast on the symptom, just to realize the symptom to reemerge. We did not have the stamina to understand and act upon the problem, causing the symptom.
Swigert: Okay, Houston. I believe we’ve had a problem here
Lovell repeated: We’ve had a problem here. We’ve had a main B bus undervolt
Apollo 13 mission
Yes – the Apollo 13 mission control was definitely under time pressure, but they knew that they needed to understand the underlying problem to an extend enabling them to craft a solution, saving the Apollo 13 crew.
The causality chain
You’ll find a variety of strategies, techniques and tools aiming at understanding the causality chain.
An example is the 5 WHYs technique having its origin from Sakichi Toyoda in the Toyota Motor Corporation. As the name indicates, the technique is very simple: continue asking WHY? five times, and you’ll have identified the underlying problem – the root cause.
Why? – The alternator is not functioning. (Second why)
Why? – The alternator belt has broken. (Third why)
Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why)
Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)
Can you continue beyond the five WHYs? Of course you can.
Are you guaranteed to identify the problem / root-cause after five WHYs? Definitely not.
Let’s continue the example above.
Why (was the vehicle not maintained according to the recommended service schedule)? – The owner did not have the money for the service.
Why (did he not have the money)? – he has lost his job
Why (did he loose his job)? – he could not cope with the stress
… and we could continue.
When to stop?
You’ll always be able to ask an additional “WHY?”, but the trick is knowing when to stop.
In the example above, the root-cause could be that the car-owner has gotten a decease making him extra sensible to stress. Even though this is the deeply founded root cause, it is far beyond the sphere of influence for the car repair shop.
Realistically the problem (though strictly speaking a symptom) is the lack of service, and the solution is to recommend keeping the service schedule.
One important indicator on when to stop, is thus knowing your sphere of influence. Yes – you’ll still be finding solutions to a symptom, but that is all you can do.
Projekt.DK's approach to problems
We take great pride in understanding the problem (actually the symptoms at the realistic level of influence) before suggesting specific solutions. This process can, and often will bring new insights, because we and our customer are forced to think to the limit and out of the box.
NB – and no, we do not call problems “a challenge”. We call it what it is – a problem.
I’m a bit puzzled why in 2022 people still contrast Management with Leadership. It makes no sense.
First of all – a Manager is a job (functional manager, product manager, project manager ..). Being a Leader is not a job function. It is a mindset and a way to act.
Everybody in an organization can act as a Leader. You do not have to have a formal “position in the hierarchy” to do so. E.g., a junior software engineer can act very strongly as a Leader, taking responsibility for the team agreeing on how best to solve a technical challenge. You’ll definitely also see the opposite, having Managers high in the hierarchy show very little Leadership skills, but that is a different story.
The memes & articles often use the stereotypes “Leaders are good people” and “Managers are bad people”. That is absolutely nonsense.
All organizations need strong Managers, and for these Managers to be successful they need (also) strong Leadership skills.
We do not need less management – we need better management.
Marty Cagan, Silicon Valley Product Group
It makes no sense trying to compare “Management” with “Leadership”. What makes sense is to discuss an individual’s Leadership skills. That individual does not have to have any formal “Management position” in the hierarchy.
Yes – e.g., the Vice President is also a Manager; though fairly high in the formal hierarchy, thus requiring Leadership skills to be applied on a strategic level. The facts remain the same: The VP is a Manager with certain Leadership skills.
The strong Manager with strong Leadership skills has the ability, dynamically to shift focus from getting everybody engaged in an ambitious vision and minutes after facilitate a Scrum meeting being very operational on specific impediments. I call this the ability to act as a helicopter pilot. It takes a lot of practical experience to become such a helicopter pilot.
Europe – especially Northern Europe – seems to be in love with process!
Process needs to serve us and not the other way around!
SAFe is just marketing (though very successful with CEOs wanting a quick way for their organization to become “Agile”)!
The desire for process is super dangerous!
Marty Cagan
Marty Cagan describes this as the “European Process Disease“. You’re most likely already familiar with the process-quotes from Jeff Bezos, Elon Musk and Steve Jobs just to name a few, but here we go:
Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations.
Jeff Bezos
People get confused, companies get confused. When they start getting bigger, they want to replicate their initial success and a lot of them think there is somehow… There is this magic in the process of how that success was created. So they start to try and institutionalize process across the company. And before very long, people start to get confused that the process is the content. That’s ultimately the downfall to IBM. IBM has the best process people in the world. They just forgot about the content.
I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign. The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.
Elon Musk
I think is is fair to say that these industry icons are not exactly fans of “process people”.
Why are (some) European organizations caught in Process Bureaucracy?
It is though worth noting that Apple, Amazon and Tesla are all digital natives with entrepreneurial CEOs.
Knowing that it is both impossible and unfair trying to find a main cause behind this “European Process Disease”, I’ll give it a try anyway finding at least some of the fragments.
The CFO effect wanting predictability and control with an upfront Business Case
For some (e.g., big CAPEX) projects it makes perfect sense to build a Business Case before starting burning money. What too often happens is that this requiring an approved Business Case has become an auto-pilot reaction. You’ll find this hardwired in many organization’s project process as a mandatory gate-criteria. The funny / sad thing is that this demanding a Business Case also holds true even when the validity of the basis for the Business Case is very questionable.
If we e.g., have decided that a given tough business problem has to be solved, it does not make much sense to demand a Business Case before allowing the product team(s) to do discovery work. How can we at this point in time provide cost estimates to the Business Case, if we’ve not yet discovered the best solution to the problem? And how can we estimate revenue effects, when we do not yet know what solution to serve the customers?
The alternative to requiring a big upfront Business Case covering the full project, is to apply a metered / VC-style funding model. And yes of course – the Product Team might at some point in time seek a major CAPEX budget for e.g., some production capacity. Here it’ll be fully understandable and expected to ask for an actual Business Case. At this point in time the team actually does have the foundation for building the Business Case.
“Are we then not doing any budgeting at all?“, you might ask. I’ve seen examples where budgets for the year are allocated, but the actual funding of the Product Teams are deferred to a metered funding. In contrast to the budget allocation on a project portfolio, this model provides the flexibility to fund what makes most value during the year. It might have been the case (many) years ago that you could plan a project portfolio a year ahead with a fair degree of confidence. That is definitely not the case anymore.
Process prescription
Having been around in many organizations, small to very big, I can confirm Marty Cagan’s observation that we in (northern) Europe have an affinity for processes, tools, templates and checklists.
The general rationale often falls into these categories:
shared and well-documented processes (and tools, templates and checklists) helps us increase efficiency and quality, and it helps us onboard new employees faster
having a strict process-compliance approach gives us control
applying pre-defined / de-facto models / frameworks (like PRINCE2, Scrum, SAFe, HalfDouble ..) frees us from "re-inventing the wheel" and it makes it easier for us hire external assistance
we've committed ourselves to some formal process certification scheme (e.g., ISO or CMMI) requiring us to enforce process compliance ... for us to keep the certification logo on our company website
The rationale is easy to follow. The approach to these categories are however very different across organizations. It seems to boil down to how employees are trusted / empowered … or not.
Low trust / mercenary culture
Here you’ll typically find a high degree of process prescription and even internal process policing, demanding formal signed waivers for you being allowed to divert from the mandatory processes. This cook-book type of culture also believes in checklists. The more and longer, the better.
In this type of culture you’ll often find a complex and very bureaucratic and multi-layered project governance.
Motto: the higher we score on the CMMI scale the better, making us a real efficient and lean feature factory, generating Output.
High trust / missionary culture
This type of culture also believes in working smart and using best practices. The core difference is the trust that the employees are able to pick & use relevant elements from the toolbox without having processes strictly prescribed … and being able continuously to develop this shared Pick & Use Toolbox.
Motto: the more we trust our teams and the less obstacles we lay in front of them, the better they serve our customers, creating great Outcome for our business.
We want and need a Product Team to be effective and efficient.
Being effective means (for a Product Team) to achieve Product / Market fit. The skilled Product Team will use a lot of methods, templates, good practices etc. in the Toolbox to achieve this. The team does not need to be told (prescribed processes) how to do its job.
Being efficient means (also for a Product Team) doing things the right way. Much of this is what I would label professional competences. It makes perfect sense to share / co-develop good professional practices and to have these structured in a shared Pick & Use Toolbox. You would e.g., not prescribe a software developer to do configuration/version management. You’ll expect that to be part of his/hers professional foundation. What on the other hand makes perfect sense is to share good practices on what works best in the given context.
Wrap-up
It makes perfect sense to develop and maintain a strong Pick & Use Toolbox, but think twice if you want to prescribe mandatory processes – and if you do, keep bureaucracy low.. Also consider a more flexible funding process.
I believe that most modern Product Leaders will agree that leading with business problems within a context is the way forward. Or rephrased – ask empowered Product Teams to find solutions to business problems – do not tell them what solution to implement.
This seemingly modern product thinking is not new at all. General Patton knew exactly the wisdom behind not telling people how to solve a problem.
Never tell people how to do things.
Tell them what to do, and they will surprise you with their ingenuity. General Patton
Product Mindset
Ask for Outcome and trust the Team to find the right solution: Cross the river!.
Project Mindset
Ask for Output and give the Team a solution to provide: Build a bridge!
The need to nurture innovation and experimentation to achieve product / market fit
That is exactly what we want and need when hiring intelligent people: create space for innovation and have these guys tell us what solutions to a problem work best.
For these innovative guys to thrive in a way best serving our customers, they need literally to innovate in front of our (real!) customers. This is done repeatedly by setting-up hypotheses and testing these hypotheses with the customers in a disciplined way. Our holy grail is to ensure – and maintain – a strong product / market fit.
You do not achieve this holy grail without a strong customer dialogue. If you fail to interact with your customers, then the only thing you’re left with are your assumptions.
What do you do then?
The puzzling thing is that most “Agile Teams” today are measured on their ability to produce Output measured by metrics like “velocity“.
Sure – it is important to have solid engineering practices and tool-chains in place enabling an efficient flow in your team’s delivery. You could label that as being efficient.
But – what is far more important is the teams ability to deliver the right thing to the market. You could label that as being effective. What good is it being efficient producing tons of features, if you fail to achieve product / market fit?
This is exactly why the modern Product Team needs (also) to have a strong Product Management competence. And no – being a Certified Scrum Product Owner (CSPO) does not make you a strong Product Manager. A Product Manager is a job description. A Product Owner is just a role in an Agile framework.
The modern Product Team needs to be effective and efficient. You might want to visit my article on Product Discovery.
You may have wondered – what is the secret sauce enabling e.g., Amazon to grow exponentially, yet keep the start-up mentality with strong customer focus and fast-paced innovation?
Some of the important ingredients in the sauce are found in what Amazon has coined the “Day 1 mentality” … put in sharp contrast to the “Day 2 mentality“:
Looking at each of the Day 1 – Day 2 pairs, you’ll probably think “makes perfect sense“. The obvious questions are “then why do we see so many big companies caught with a Day 2 mentality?” and “are they lost, or can they take a detox cure, bringing them towards a Day 1 mentality?“
Another high-tech product-led company also with a strong Day 1 mentality is Elon Musk’s Tesla. He puts innovation in a nutshell:
Pace of innovation is all that matters in the long run
Why are so many companies caught with a Day 2 mentality, and what can they do?
Let’s in all fairness start with a key background for Amazon and Tesla: they are both digital-natives. This is a huge advantage. Compare this to more traditional companies with e.g., a classic product development and production background now being challenged on the pace of innovation and a digital economy.
Many of these more traditional companies have their organization and ways of working rooted in the classic thinking. As they grow, their built-in auto pilot will generate more and more bureaucracy and internal friction.
It happens gradually and you’ll not notice it, before it has become a very visible problem impeding your ability to stay competitive – or even relevant. For some its too late to do anything about it. Others take a tough Detox cure.
But – not all companies coming from a traditional background get caught in the classic thinking. Danish LEGO is a perfect example of a company having achieved a strong product culture and fast-paced innovation. If you want to know what a product-led organization looks like – study LEGO (well, some parts of LEGO).
Clear statement on Silver Bullets and religion
Let me be very clear before moving on. I do not subscribe to the idea that some “de-facto framework / model” can or should be seen as magic way to gain success and definitely not being pursued as goals in themselves.
PRINCE2, SAFe, Scrum, Scrum@Scale, HalfDouble, AgilePM, Kanban, Agile Fluency, FAST Agile … are all potential tools in a much larger toolbox. Yes – I’ve used a lot of elements from some of these and read a lot of books. Everything ends-up in my toolbox where they belong.
None of the elements must become a narrow-sighted religion. Unfortunately I see far too many so called “Agile coaches” (or PRINCE2 high priests for that matter) doing exactly that – taking the toolbox to a level and interpretation where it does not belong. One thing is for sure: the main ingredients in the Secret Sauce are not the frameworks / models. They are more the salt and pepper.
If you are a business owner being met by e.g., a “SAFe xyz certified” person trying to convince you to implement SAFe, be vigilant! He is attempting to sell your elements in a toolbox – do not confuse that person with one being able to help you improve your business (he might, but in that case he’ll not talk SAFe until late in your dialogue).
Innovation Power
Back to the topic …
As Elon Musk says “pace of innovation is all that matters in the long run“. In other words – you need to nurture your Innovation Power:
Each area is a big topic in itself – and yes – they are highly related and some even overlap. Below we’ll recap on the essence and shortly discuss the gaps to the traditional company.
Product Culture
A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They (ed.: the product organization) understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the resuls of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team.
Clearly communicate that innovation is not something reserved for special selected people in an "innovation lab". In a truly innovative product culture the best ideas often comes from unexpected places. Invite for and encourage to contribute to the innovation process. Crowd-source innovation in your organization.
Organizational structure
In the high Innovation Power organization you’ll find organizational structures carved-out from a mindset of having highly empowered missionaries serving your real customers with as little as possible distance and friction to these customers.
The organization here is highly aware of the intrinsic auto-pilot when expanding the business: it insists having a nimble structure and keep the team sizes small. The quote Marty Cagan – they scale by leaders/managers:
Fundamentally, as organizations grow, there are two main ways today that organizations attempt to scale.
One is by scaling their leaders (the managers). The other is by scaling their process.
You may have noticed that some “Agile fundamentalists” promote the opinion of needing fewer leaders/managers when becoming “true Agile believers”. Make up your own mind, but also consider this suggestion from Marty Cagan:
We do not need less management – we need better management.
Move your guys closer to the customer ... much closer
This is how the product developers often are distanced from the real customer and impeded by bureaucracy in the Day 2 orhanization:
Aim for giving your product teams a strong strategic context within which they are empowered to discover the best solutions that your customers love, yet work for your business:
Do the above as a limited yet disciplined experiment for at least two reasons: (1) Before making changes at scale, make sure to find a model that works for you. (2) Having a success story will make your scaling much easier - nothing is more convincing that a visible success.
Servant Leadership
Books have and are being written about Servant Leadership, and its discussion easily becomes academic tending to religious. Yes – it overlaps with Product Culture and Organizational Structure.
My humble understanding, based on practical experience, includes four key areas:
Good leaders focus on culture and purpose because culture drives innivation and performance. The greatest capital of an organization is its people. To innovate, people need autonomy and meaning.Marty Cagan, EMPOWERED p. 372
Detox recommendations for the Day 2 organization
First and foremost - unlearn the hierarchical "command & control" way of leading, substituting it with "leading by context". Core elements in this context are the Product Vision, Product Strategy and Technology Strategy. It is from this context the product teams are tasked with (hard) customer / business problems for which to discover the best solution.
Give room, let the team shine, control your ego, show trust and most important of all - show through you action that you embrace the Product Culture
Pave the way for the teams to function at an optimal level. Sometimes a small stone for you is a major blocker for the team
Minimum Viable Governance & VC-style funding
Is your CFO the one calling the shots, and are you having long and painful yearly budget- and prioritization processes? Is it a common belief in your organization that you can plan a project portfolio a year ahead? Are you using big investment programs / Big Bets?
Innovation is only expensive if you use traditional business planning to make investment decisions. Innovation, when done right, is about making small bets, testing ideas cheaply and quickly to identify the winners in which you then invest more resources
Tendayi Viki, Pirates In The Navy: How Innovators Lead Transformation
If yes, than you’re impeding your own ability to maneuver. It might have been realistic in the past millennium, but no more. Three months is a long time in a digital economy that will definitely need you to adjust your priorities.
The alternative to this inflexible locking-the-budget approach is what Eric Reis back in the days with Lean Startup coined metered funding. Here we’ll use the analogy of seeking internal Venture Capital.
Instead of pre-allocating budget to next years project portfolio, only allocate the years total budget. Having your product teams seek internal venture capital will not only sharpen everybody’s awareness of where value is created, it’ll also allow you to fund unforeseen activities in the middle of the budget year.
Detox recommendations for the Day 2 organization
Run an experiment. Allocate a chunk of the development budget for later allocation via an internal VC-forum. Start small and learn before you scale-up.
Be very critical with large investment programs / Big Bets. Their size in themselves poses a significant risk. Make sure that these monoliths are in fact what serves you best.
Tell your CFO in a nice way that his need for control (which in fact is not control, because it is impossible to forecast the correct budget distribution one year ahead) is secondary to our ability to do the right things in our quest to serve our customers.
Minimum Viable Process Prescription and a rich pick & use Buffet
I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign. The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.
Elon Musk
I’ve experienced radically different approaches to the process prescription balance:
One driven by CMMI’s obsession of having everything prescribed and statistically optimized in processes (do not dare not to follow the process unless you have a formal waiver, allowing you to do so)
A trust in people, their professionalism and ability to bring the “Pick & Use Toolbox” into play as needed – not having massively to prescribe mandatory processes.
Both types of organizations can be very successful, but are clearly based on very different values. E.g.., Amazon and Tesla are clearly based on the “Minimum Viable Process” model.
Detox recommendations for the Day 2 organization
Start by asking yourself the very basic question: "Do you trust the judgement of your employees and their professionalism enough to let them decide on solutions to problems without you policing them?"
If YES - show it!
If NO - challenge yourself. Are you hit a the process decease being a way indireectly to control your employees?
Finally ask yourself: "Despite Amazon & Tesla being digital natives, what prevents you from turning-down the volume on your process obsession and move in the direction of Amazon and Tesla?"
Technology excellence
Cut to the bone, technology is the product!
Solid engineering practices and deep technology expertise is of course a must during both Discovery and Development.
One thing that can really kill your business agility is poor engineering practices resulting in e.g., global dependencies. No matter the engineering domain, your engineers must follow the lead from software development ensuring de-coupling via encapsulation behind stable interfaces – not to forget the fundamentally important Configuration Management discipline.
We want to Innovate Products the customers love, yet work for the business. Marty Cagan
If you do not deliver a Product matching your customers quality expectations, they’ll definitely not fall in love with it. Without technology / engineering excellence, you’ll become irrelevant.
Wrap-up
If you happen to have a Day 2 dominance in your organization, then let’s face it ..
.. you will get disrupted! The question is, if you'll do it yourself or have others do it to you?
.. your competitors are trying hard aiming for the Day 1 essence .. see bullet one
In the “Old Days” the rate of change was not at todays extreme level. The predominant way of thinking and organizing work had clear traces back to Max Weber, Frederic Tailor and Henry Fayol.
In our “Modern Times” we cannot afford the bureaucracy creating distance between the real customer and the teams serving these customers.
The Old Days
Characteristics:
Long distance / no contact between the product implementation project and the real customer
The implementation projects are given solutions to implement
The project teams are measured on the ability to produce Output
Bureaucratic and inflexible planning, often tied to the yearly budgeting process
The project team is populated with mercenaries, being told what solution to implement
The organization and the project team might have the self-image of being agile and customer-centric, because they use e.g., Scrum
It is the responsibility of the organizations product- and technology leadership to ensure / communicate the strategic context, and to agree with the product teams which problems to solve. These will often be formulated using the OKR (Objectives & Key Results) method.
Characteristics:
Close proximity between the real customers and the product teams
The stable and cross-functional product teams are given (hard) business / customer problems for which they are empowered discover the best solutions
The product teams are held accountable for the Outcome
Having the product teams being in constant and direct contact with the real customer, and having a flexible funding model, this organization and its product teams can strongly claim to be both highly agile and customer-centric
In the “old days”, Project Management and Product Management were two separate and often fully disconnected disciplines. Not anymore.
The trend today, at least in product-led companies, is a merge of the best from both worlds into a new (and extremely challenging) role being what really will be needed and asked for in the future. That is at least my claim, and where I’m placing my bets.
To the best of my knowledge this new role has not yet gotten a name. From hereon I’ll call the role Product Management++.
Product Management++
I’ve decided the name “Product Management++” and not “Project Management++” to emphasize what the role is about, as expressed by Marty Cagan:
We want to create products that our customers love, yet work for the business
Marty Cagan
I’ll argue that elements 1-3 are covered by Marty Cagan’s definition of a strong Product Manager. My practical experience tells me that I’m also using a lot of the tools in my Project Management Toolbox; at least the tools not having to do with the outdated “command & control” way of thinking.
Below I’ll shortly re-iterate on the four elements of Product Management++
Technological insights
In high-tech product-led organizations, technology is the product. The Product Manager++ needs to have a solid understanding of the technology trends and of how technology is integrated in the products.
Servant Leadership
The modus operandi of the Product Manager++ is not the classic “command & control” project manager. The Product Manager++ does not have any formal authority over the product team, and can best be described as acting in a Servant Leadership role:
Business & Market insights
The Product Manager++ knows that we’re here to serve the (real) customer, thus being highly alert on understanding and validating customer opportunities (pains, needs & desires). NB – too often the notion of an “internal customer” distracts the product teams from where there main focus needs to be: on the real (external) customer.
The Product Manager++ will also find great inspiration in the many important books mentioned here, covering e.g., Product Discovery.
Project Management Toolbox
Yes – you’ll find tools and strategies in the experienced project manager’s toolbox, that have lost relevance in the modern organization populated with missionaries. These will typically be tools and strategies founded on the classic “command & control” project manager role.
But – you’ll also find a lot of tools and strategies that remain highly relevant and valuable. If you as a Product Manager++ want to have success as a Servant Leader, then you need (a lot of) the tools and strategies from the Project Management Toolbox.
NB – I see all the various Agile frameworks as just some of the tools and strategies in the Toolbox. Kanban, Scrum, Scrum@Scale, SAFe … can and must never be a thing or objective in itself. The explosion of Agile Coaches and Agile courses / certifications have unfortunately done exactly that: made the Agile frameworks a thing. Carefully pick the elements relevant for your specific context, and leave the rest. It is not rocket science – it is just a contribution to the Toolbox.
You do in fact have some kind of a crystal ball.
You’ll always be able to ask an additional “WHY?”, but the trick is knowing when to stop. 
Many of these more traditional companies have their organization and ways of working 
PRINCE2, SAFe, Scrum, Scrum@Scale, HalfDouble, AgilePM, Kanban, Agile Fluency, FAST Agile … are all potential tools in a much larger toolbox. Yes – I’ve used a lot of elements from some of these and read a lot of 
The alternative to this inflexible locking-the-budget approach is what Eric Reis back in the days with 
The Product Manager++ has a very solid Experimentation Toolbox with tools from e.g.,