Systems thinking as a product superpower

Every product I’ve built has taught me the same lesson in different ways: features solve one problem, systems solve categories of problems.

At Coopsight, we could have built a simple directory of startups. Instead we built a matching system. The directory solves “find a company.” The matching system solves “find the right company for this specific company at this specific stage with these specific needs.” One is a feature. The other is a system that generates value every time new data enters it.

At Tildenn, I could have built a chatbot that suggests places. Instead I built a hybrid system where each layer does what it’s best at: the LLM parses intent, the clustering algorithm groups by geography, the rule engine ensures variety, the validation layer confirms reality. The chatbot is a feature. The system compounds because each layer improves independently.

The pattern: when you’re tempted to build a feature, ask “what’s the system that makes this feature trivial?” If you can answer that question, build the system instead.

This applies beyond code. At Blue Origin, the “feature” was monthly financial reports. The “system” was automated ETL pipelines that make any report trivial to generate. The system reduced 30+ hours of manual work to zero, and now every new reporting need is a configuration change, not a project.

Systems thinking isn’t just an engineering pattern. It’s a product strategy. Build the machine that builds the thing, not just the thing.