I get asked the same question at least three times a week: "What tools are you using?" And I always answer. But the answer has never once been the thing that actually mattered.
The Question Behind the Question
When someone asks what tools you use, what they are really asking is: "How do I get the results you are getting?" That is a fair question. But the tools are the final expression of a strategy, not the strategy itself. Every tool I use exists because I identified a specific bottleneck in my workflow, defined what the output needed to look like, and then found or built something that could produce that output reliably.
Most founders do it backwards. They hear about a new tool, sign up, spend a weekend configuring it, and then try to find a place for it in their workflow. Two weeks later, the tool is gathering dust and they are back on the conference circuit asking what tools other people are using. The cycle repeats.
I have been guilty of this myself. In 2023, I signed up for eleven different project management tools in four months. I configured dashboards, built templates, invited collaborators. None of them stuck because none of them were solving a problem I had actually diagnosed. I was treating the symptom, which was a feeling of disorganization, instead of the cause, which was that I did not have a clear content production process.
Strategy First, Then Systems
A strategy is a set of choices about what you will and will not do. It answers three questions: Who are you serving? What value are you providing that others are not? And what activities will you consistently execute to deliver that value? Tools enter the picture only after you have clear answers to all three.
At Intelligent Operations, our strategy is to produce brand films for mid-market companies that would otherwise hire agencies charging three to five times our rate. We deliver comparable quality by running leaner crews, owning our equipment, and using AI tools to handle pre-production tasks that traditionally require dedicated headcount. Every tool in our stack exists to serve one of those three operational advantages. If a tool does not directly enable crew efficiency, equipment utilization, or AI-augmented pre-production, it does not enter the stack.
That filter has saved me more time than any individual tool ever has. Saying no to tools that do not serve the strategy is a competitive advantage, because it means the tools we do use get our full attention and actually get implemented properly.
The Three-Layer Framework
I think about operational design in three layers, and I have found this framework useful for every founder I have shared it with. The first layer is strategy: the choices about who, what, and how. The second layer is systems: the repeatable processes that execute those choices. The third layer is tools: the software and hardware that make those processes faster or more reliable.
Most people start at the tool layer and work backwards. That almost never produces durable results. The ones who build lasting operational advantages start at the strategy layer, build systems that express that strategy, and then select tools that accelerate those systems. When you do it in this order, tool selection becomes almost obvious. You are not browsing Product Hunt looking for inspiration. You are searching for something specific because you know exactly what you need it to do.
What This Looks Like in Practice
Here is a concrete example. One of my systems is "intake to brief in ten minutes." The strategy behind it is that Intelligent Operations wins work by moving faster than agencies that take two weeks to produce a proposal. The system is: record the intake call, transcribe it, extract the key decisions, and generate a creative brief. The tools that execute this system are Otter for transcription and Claude for brief generation. But if better tools emerge tomorrow, I can swap them in without disrupting the system because the system is defined independently of the tools.
That independence is the point. Your strategy should outlast any individual tool. Your systems should be describable without reference to specific software. And your tools should be replaceable without rethinking your entire operation. If removing one app from your stack would cause your business to collapse, you do not have a strategy problem. You have a dependency problem.