I stopped collecting productivity tools and built a small operating stack instead
Most of my “productivity system” was just a pile of apps fighting each other.
Notion for notes. Another tool for tasks. Prompts in a random doc. Reviews that never happened. I wasn’t running an operating system — I was living inside the tools.
So I stripped it back to a small stack:
- Clarity (what actually matters)
- Decision (what to do next)
- Focus (how to protect the work)
Then I packaged those modules as practical digital products instead of another template graveyard.
Series 1 is the core layer — prompt systems, decision systems, focus systems, and the integration piece that ties them together. It’s designed to work as a stack, not as five more PDFs you’ll forget.
If you’re the kind of person who refuses to live in their tools, this is the direction:
https://holladigital.gumroad.com/l/practical-systems-bundle
Curious what breaks first in your current setup — tool sprawl, decision drag, or review consistency?
The only thing that has kept my own stack short while running four businesses is a non-negotiable weekly assessment where I choose what to remove rather than what to add. Without that recurrent forcing function, decision-making and clarity are meaningless; otherwise, you simply recreate the same stack of programs under different names. Tool sprawl is a symptom of missing the review stage, not the underlying issue.
Yes — without a recurring kill decision, clarity and decision just rename the same stack.
The review is what keeps the system short over time. Everything else is temporary without that forcing function.
This is exactly it - tool sprawl is a measurement problem wearing a productivity costume. You have clarity (what actually matters), decision (the output of that measurement), and focus (enforcing that the measurement stays true).
Most productivity systems collapse because they measure "am I collecting inputs in organized buckets" when they should measure "am I actually working on what I decided matters." Those are completely different metrics.
What's brilliant about your stack is that you've compressed it to the measurement layers. Clarity answers "are my priorities measurable?" Decision answers "can I choose fast?" Focus answers "can I measure whether I'm actually doing what I decided?"
The second comment here nails it - tool sprawl is symptomatic of broken input filtering. But the way to fix that isn't a better tool. It's a better measurement system for "is this input worth measuring at all?" Once you measure that correctly, tool sprawl disappears because you're only feeding the system what actually deserves a decision.
For founders building with teams: your operating stack is really your shared measurement system. Every person in the org needs the same clarity measurement, the same decision framework, the same focus metric. Tool sprawl happens when those are invisible or inconsistent.
Yes — the useful stack is a measurement system, not a filing system.
If the metric is “inputs organized,” you get tool sprawl. If the metric is “working on what we decided matters,” most tools become optional.
Same for teams: when clarity / decision / focus aren’t shared and visible, everyone invents their own stack. Consistency of measurement beats sophistication of tools.
Tool sprawl isn't the root problem, it's a symptom of skipping the review step. Running four companies, the only thing that's kept my own stack small is a non-negotiable weekly review where I decide what to kill, not what to add. Clarity and decision are useless without that recurring forcing function, otherwise you just rebuild the same pile of apps with better names.
That’s the forcing function most stacks skip.
Without a recurring “what do we kill?” review, clarity and decision just relabel the same pile. The review is what keeps the system small over time — not the initial design.
The distinction between a stack and 'five more PDFs you'll forget' is where most productivity systems collapse. Templates are static — they're designed for a version of you that already has clarity, which means they fail exactly when you need them most.
The Clarity → Decision → Focus sequence is right. What I'd add: the thing that usually breaks first isn't any of those three layers — it's the input to Clarity itself. Noisy input (too many signals, unclear priorities, context switching) means even a well-designed clarity module produces organized chaos instead of focused direction.
The version of this that worked for me wasn't a cleaner tool setup. It was reducing the number of decisions the system had to process. Less intake, less queue, more time actually in the work. The stack doesn't need to be smarter — it needs to be smaller.
Agreed. Noisy input is usually upstream of the whole stack.
Clarity only works if the intake is already constrained. Otherwise you just get a well-organized mess.
The useful version is almost always smaller: fewer signals in, fewer decisions required, more time in the work. The stack is only there to protect that — not to process everything.
The shift from “more productivity tools” to a small operating stack is compelling, but it also creates an interesting identity problem: people may agree with the philosophy without feeling they need another system. The distinction between appreciating the idea and adopting the stack seems particularly important here.
That’s the real risk. Agreeing with “stop collecting tools” is easy; adopting a stack is a different decision.
The filter I use: if someone already has a simple way to decide what matters, choose the next action, and protect focus, they don’t need another system. The stack is only useful when those three keep falling apart into more apps and notes.
So the adoption test is narrower than liking the philosophy — it’s whether the current setup is already doing that job cleanly.
That’s a useful distinction. I appreciate you explaining where you see the actual adoption threshold.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
Prefer to keep it on the thread for now so others can follow along. Happy to clarify anything useful here.