Capability-Based Planning
Build flexible capabilities, prove them, then choose the next move
- Difficulty
- Advanced
- Time to result
- ~ongoing to results
- Steps
- 5
- Confidence
- 96%
Capability-Based Planning shifts long-range attention from a detailed product roadmap to the people, skills, systems, and technical abilities that make future products possible. A current product still gets a plan, but Petty keeps it shorter than a page and gives one person responsibility for carrying its intent through ongoing conversations. The team then tries difficult work, proves capabilities, and asks what becomes possible next. Supporting systems handle scale and coordination without prescribing every action, so discoveries can change the product in real time. The output is not compliance with an elaborate document; it is a stronger capability base and a product that reflects what the team learns while building. This approach deliberately trades predictive detail for adaptability.
Origin
Petty contrasted Blackmagic Design's short product definitions with elaborate plans he had seen fail. He said the company's longer-term planning focuses on people, skills, capabilities, and flexible supporting systems. Extracted from The Foundr Podcast.
Core principles
- 01Plan long term around people, skills, and capabilities
- 02Keep each product definition short
- 03Prove what the team can do before selecting the next move
- 04Design systems to support change rather than control people
How to run it
- 1
Compress the product intent
Describe what the team is building in less than a page. Include only the constraints and standards needed to preserve the product's purpose.
Pro tip If a decision can be carried through conversation, avoid turning it into procedural bulk.
Watch out A vague sentence is not the same as a clear short definition.
- 2
Name a human product carrier
Give one person responsibility for understanding and carrying the product's intent. That person talks with whoever is needed as the work evolves.
Watch out Do not let the document become the owner of the product.
- 3
Map required capabilities
Identify the skills, people, and systems needed to attempt the product. Treat this capability base as the durable part of the plan.
Pro tip Include the different disciplines that must cooperate, not only the dominant technical skill.
Watch out A capability list without people able to exercise it is only an aspiration.
- 4
Try and prove
Attempt work that stretches the team and use the result to learn what it can reliably do. Discuss failures and discoveries while the product is still changeable.
Pro tip Stretch far enough to create learning without making the project a reckless bet.
Watch out Do not preserve a plan after evidence shows the product needs to change.
- 5
Select the next move
Choose what to build next from the capabilities now demonstrated and the problems now visible. Update the short definition and repeat.
Watch out Avoid turning the resulting sequence into a rigid long-range roadmap.
In the wild
Petty said Blackmagic Design has a plan, but it must be less than a page and often consists largely of supported video standards. A responsible person carries the product, interacts with the necessary specialists, and keeps discussing changes rather than treating a complex document as the product itself.
→ The team retains a clear product intent while remaining free to change the implementation as it learns.
For a control panel, the team listed the controls it wanted, put them in priority order, and then determined how many would fit. This added only the structure required for a concrete physical constraint rather than expanding into an elaborate general plan.
→ The available space determined which highest-priority controls entered the product.
Common mistakes
Letting the document become the product
A complex plan can attract effort and authority that should remain focused on the product and the people building it.
Using systems to prescribe every action
Petty's systems support coordination and flexibility; using them to control creative decisions reverses their purpose.
Confusing no bureaucracy with no clarity
The approach still requires a clear product definition, a responsible person, and the capabilities to deliver it.
Is it for you?
Best for
It is best for multidisciplinary teams building products whose design will change as they learn.
Not ideal for
It is not ideal for regulated or safety-critical work where detailed documented plans are mandatory.
From the transcript
“you want to do is be capability based you want to try things and prove your capabilities”
“we have a 25 30 plan but it's literally less than a page”
“the long term planning is people skills and the capabilities we have”
From the episode
236: Bootstrapping a $300M Cinema Company, With Grant Petty of Blackmagic Design
Grant Petty