Build Capabilities, Not Systems
The instinct is to build a system. The better question is what capability would make the work better now.
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.
Large systems are expensive. They take months to spec, build, and deploy. They encode assumptions that become outdated. They require maintenance, training, migration, and buy-in. By the time they ship, the problem has often changed.
Capabilities are different.
A capability is a small thing that makes someone better at their job. It does not replace what they do. It amplifies it. It does not require a complete workflow redesign. It slots into how the work already happens.
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 long project with uncertain ROI. The capability is bounded, testable, and immediately useful if it works.
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.
Small improvements compound into transformation. Unlike a big system bet, each improvement is low risk. If one does not work, you learned cheaply.
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 may eventually earn the right to build a system. But by then you will know what the system should do because the capabilities have already taught you.
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.