Build Capabilities, Not Systems
The instinct is to build a system. The better question: what capabilities would make your people faster and better at what they’re already doing?
When someone has a problem, the default response is to design a solution that solves it completely. An RFP system. A proposal system. A customer management system. A “platform.”
This is usually wrong.
Systems are expensive. They take months to spec, build, and deploy. They’re brittle — they encode assumptions that become outdated. They require maintenance, training, buy-in. By the time they ship, the problem has evolved.
Capabilities are different.
A capability is a small thing that makes someone better at their job. It doesn’t replace what they do — it amplifies it. It doesn’t require a complete workflow redesign — it slots into how they already work.
The Difference
System thinking: “We need a tool that manages the entire RFP response process from intake to submission.”
Capability thinking: “What if scanning a 100-page document for insurance requirements took 2 minutes instead of 2 hours?”
The system is a 6-month project with uncertain ROI. The capability is a week of work that pays for itself immediately.
Capabilities Compound
Here’s the thing about capabilities: they stack.
One capability saves 30 minutes. Another saves 20. Another catches errors that would have cost hours to fix later. Another surfaces context that leads to better decisions.
None of them “solve” the problem. All of them make the problem smaller.
A hundred 1% improvements compound into transformation. And unlike a big system bet, each small improvement is low-risk. If one doesn’t work, you’ve lost a week, not a year.
What This Looks Like
Instead of: “Build an automated proposal generator” Try: “What context do people wish they had when writing proposals?”
Instead of: “Build a customer intelligence platform” Try: “What questions do people ask repeatedly that could have instant answers?”
Instead of: “Build a workflow management system” Try: “Where do things get stuck? What friction could we remove?”
The answers to these questions are capabilities. Small, useful, deployable now.
Implication
When someone describes a problem, resist the urge to design a system. Ask instead: what’s the smallest thing that would make this noticeably better?
Build that. See if it helps. Build the next one.
You’ll end up with something more useful than any system — a collection of capabilities that actually match how people work, built iteratively based on what they actually need.
Contrarian To
“We need to solve this problem properly.”
Properly often means comprehensively, which means expensively, which means slowly. Useful beats proper. Capabilities beat systems. Compounding 1% improvements beat big bets.