Definition
What Is Knowledge-Based Development?
Knowledge-based development is a development philosophy and practice in which the primary output of development work is not deliverables, prototypes, or milestone reports — it is validated knowledge that enables better decisions. Every experiment, prototype, simulation, and review is designed to answer a specific question. The answer is captured in a form that can be reused. And decisions are made when knowledge is sufficient, not when a calendar date arrives.
The philosophy connects directly to lean principles: front-loading means creating knowledge early, when it is cheap to learn and cheap to change. Delaying decisions means not committing to a design direction before you have the knowledge to commit with confidence. Reusing learning means that knowledge earned in one project is not lost — it is captured, organized, and accessible to the team that starts the next project.
Knowledge-based development is not anti-execution or anti-delivery. It is pro-learning before execution. The goal is not to slow down development. It is to front-load the right learning so that execution is fast, predictable, and free of the expensive surprises that come from acting on assumptions.
“In activity-based development, the plan defines what will be done. In knowledge-based development, the questions define what needs to be learned. Documents are containers for learning, not proof of progress.”
The problem
The Problem It Solves
The most common symptom of activity-based development is what practitioners call “busy but blind”: teams are working hard, meetings are full, prototypes are being built, reports are being written — but nobody can say with confidence what the team now knows that it didn’t know three months ago. Development produces activity and documentation, but not reliably validated learning.
- Decisions made on assumptions and seniority rather than evidence — the most senior person in the room wins
- Repeated mistakes across projects because learning is captured in project archives nobody reads, not in reusable knowledge artifacts
- Late risk discovery: key uncertainties are not identified until they become problems, typically at validation or launch
- Milestones that measure deliverable completion rather than knowledge sufficiency — teams pass gates on schedule but not on understanding
- Prototypes built to demonstrate rather than to learn — confirming what the team already believes rather than testing what it needs to know
- “Learning events” that are actually review meetings: findings are presented, acknowledged, and then forgotten
Knowledge-based development addresses each of these by making questions — not tasks — the unit of planning. When you plan in questions, you know when you have answered them. When you plan in tasks, you know only when you have finished them. Those are not the same thing.
The contrast
How It Differs from Activity-Based Development
The difference is not about tools or formats — it is about what drives the work. In activity-based development, the plan drives the work: what needs to be done by when. In knowledge-based development, questions drive the work: what needs to be known before which decision.
Activity-Based Development
- Plans, milestones, and deliverables define progress
- Prototypes demonstrate the design
- Reviews check whether deliverables are complete
- Documents prove that work was done
- Decisions happen at milestones, on schedule
- Learning is implicit — captured if someone remembers
- Knowledge lives in project archives
- Next project starts from the same baseline
Knowledge-Based Development
- Questions, experiments, and decisions define progress
- Prototypes test specific hypotheses
- Reviews ask “what did we learn?” and “what do we now know?”
- Documents are containers for learning — K-Briefs, A3s, trade-off curves
- Decisions happen when knowledge is sufficient, not when calendar arrives
- Learning is explicit — captured in reusable form as part of the work
- Knowledge lives in a shared, searchable knowledge base
- Next project starts from a higher knowledge baseline
The shift does not require a new process or a new tool. It requires a different question to start every project, every phase, and every review: “What do we need to learn — and what does that learning look like?”
The practices
Core Practices in Knowledge-Based Development
PRACTICE 1
Lean Learning Cycles
Short, time-boxed loops (1–2 weeks) with explicit learning questions, minimum experiments, and captured outcomes. Each cycle starts from a decision gap and ends with a validated insight. The 7-block structure gives cycles rigor without bureaucracy. See the full Learning Cycles guide.
PRACTICE 2
Knowledge Artifacts — K-Briefs
A K-Brief is a one-page knowledge artifact: the question asked, the answer found, the conditions under which it holds, and the implications for design decisions. Searchable, shareable, and reusable across projects and teams. K-Briefs transform individual experiments into organizational knowledge.
PRACTICE 3
Trade-Off and Limit Curves
Visual representations of the design space: what is possible, what is not, and what the key trade-offs are between competing requirements. Limit curves define the boundaries; trade-off curves show the shape of the space within them. Both make expert knowledge explicit and transferable.
PRACTICE 4
Knowledge-Based Milestones
Milestones defined by knowledge criteria, not deliverable checklists. Instead of “CAD model complete,” a knowledge-based milestone asks: “Do we know enough about the fatigue performance of this interface to commit to the current architecture?” A team can answer yes or no — and the answer tells them whether they are ready to proceed.
PRACTICE 5
Obeya & Visual Knowledge Walls
The obeya (literally: big room) is the shared visual space where the team’s knowledge is made visible and current. A well-designed obeya makes the current state of knowledge, open questions, and key decisions visible to everyone — so that reviews are conversations about what we know and what we need to know, not reports about what was done.
PRACTICE 6
Set-Based Design
Exploring multiple design alternatives in parallel and converging as knowledge increases. Set-based design delays commitment until confidence is sufficient — but it does not delay learning. Running multiple alternatives creates more knowledge faster, because different paths surface different constraints and trade-offs.
In the Playbook
Knowledge-Based Development in the Playbook
Knowledge-based development runs as a thread through the full LeanPeak Playbook. The primary references are Chapters 6–7 (Validate & Learn, Validation & Decisions) and Chapters 20 and 23 in the Lean Learning Cycles section (7 Building Blocks and K-Briefs). Together these chapters show the full system: how to create learning intentionally, how to make decisions when knowledge is ready, and how to capture and reuse what the team learned.
Chapter 6 — Experimentation & Learning
Experimentation & Learning
Experiment A3s, learning cycle design, and the practices that make uncertainty a resource rather than a risk to be avoided.
Chapter 7 — Validation & Decisions
Validation, Learning & Decisions
Knowledge-based milestones, review formats that create pull rather than just report progress, and the behaviours that make decisions trustworthy.
Chapter 19 — 7 Building Blocks
The Seven Building Blocks of a Learning Cycle
The structural elements that make a learning cycle disciplined: learning question, priority matrix, key decisions, increment and iteration plans, execution, and K-Brief.
Chapter 22 — K-Briefs
K-Briefs & Visual Knowledge
How to write a K-Brief, what makes knowledge reusable, and how to build a visual knowledge system that compounds across projects and generations of products.
E-Learning
E-Learning Modules
The modules below from Chapters 6 and 7 cover the full knowledge-based development system: experiment design, learning cycles, knowledge-based reviews, and practical upgrades to your current milestone and decision cadence. They are designed for product development teams and leaders — both to understand the concepts and to apply them to a current project. Modules require a subscription.
Ch 6 · Module 1
Experiment A3 and Learning Design
Ch 6 · Module 2
Running Experiments in Development
Ch 6 · Module 3
Learning After Launch
Ch 7 · Module 1
From Output Reviews to Knowledge Reviews
Ch 7 · Module 2
Experiments at Portfolio & Review Level
Ch 7 · Module 5
Practical Start: Upgrade Your Next Review
Access the full library
Chapters 6 and 7 together have 11 modules on experimentation, learning, and knowledge-based decisions. Sign in to access your full library.
Sign in to access modules →Getting started
How to Get Started
The fastest entry point to knowledge-based development is a single upcoming decision. Not a programme, not a new process. One decision, expressed as a learning question, with a minimum experiment to answer it. That is a knowledge-based development practice.
Read Chapter 6 (Experimentation & Learning) for the full practice of experiment design and learning cycle structure. Read Chapter 7 (Validation, Learning & Decisions) for knowledge-based milestones and review formats. Read Chapter 22 (K-Briefs & Visual Knowledge) for the full K-Brief system and how to build a team knowledge base.