The What-Else-Can-You–Expect Management Bottleneck
There are moments when my calendar looks impressive but the work feels strangely empty and exhausting. The bigger the project, the larger my struggle in trying to be in control; while tracking dependencies, updating dashboards, sitting in endless meetings about meetings.
On paper, the team demonstrates and convinces everyone that everything is “under control.”
In reality, we all are spending more time feeding tools than making decisions. Every system promises visibility but with more and more devilish demands of updating the data. And somehow, the more sophisticated the tooling appears, the harder it is to answer simple questions like: What actually matters right now? and What decision are we avoiding?
At the end of the day, we could be staring at a project board and realizing that the stakeholders aren’t confused because the work is complex. Everyone is confused because the system offers no real insight. The proverbial “the emperor-is–naked” scenario. The best project management tools (yes, the very best) show us everything and help us decide nothing.
Sadly, these potentially epiphany-laden moments are mostly shrugged off as “what else can you expect” mindset.
Welcome to Linear Tool and Mindset
As a project manager / leader / founder, what is your favorite task / project management tool? Asana, ClickUp, Jira, Monday.com, Trello (one of my favorites)? Whatever it is, let us admit that our beloved humanity has yet to invent the perfect PM tool. Let us look at a relatively new disruptive entrant.
Around 2019, Linear (began as an issue tracking tool) was conceptualized out of a very specific kind of frustration. Its founders (Karri Saarinen, Jori Lallo, and Tuomas Artman) had worked inside fast-growing companies like Airbnb, Coinbase, and Uber. They had lived with tools that were powerful, configurable, and painfully slow. Tools like Jira that could do almost anything, except respect your attention.
Instead of adding features, Linear’s founders made a quieter decision. They chose constraints. Linear is fast because it refuses to be everything. It has opinions about how work should flow.
Defaults guide behavior. For example, the opening screen introduces the simplest “Ctrl-K” command for essential PM behavior:
The interface stays out of the way. You don’t configure your way to clarity. The system nudges you there. That’s beautiful architecture.
Don’t Build For Everyone “and” Every Scenario
Steve Jobs once said that design is not just what something looks like, but how it works. What often gets missed is the second half of that idea.
How any system or tool works is a highly-opinionated belief system. Every product encodes assumptions about users, their behavior, etc. About what deserves attention and what should fade into the background.
Linear’s opinion is clear: speed matters, focus matters, and cognitive load is expensive. So the product enforces those values quietly, without speeches or documentation.
This is where many product managers and system builders trip (into an endless feature-adding list). They think neutrality is kindness. Maybe, they think flexibility is power. They generously assume more options help more people.
In practice, the opposite is often true. When a system refuses to take a stance, it pushes decision-making onto the user. Over time, that becomes fatigue (think, which tool tires you most?).
Why should Linear users have all the fun?
What strikes me about Linear isn’t just how well it seems to be working for engineers. It is the uncomfortable question it is raising for everyone else.
If engineers deserve tools that are fast, opinionated, and calm…why do product managers, program managers, operators, and founders still live inside bloated systems that mistake activity for progress?
Most non-engineering PM tools are built around tracking tasks and producing artifacts. Roadmaps that look confident. Status updates that sound reassuring. Layers of abstraction that create the illusion of control.
But the real work of managers / leaders isn’t task tracking. It’s decision-making under uncertainty. It’s alignment. It’s trade-offs. It’s saying no with incomplete information.
Very few tools are architected around that reality.
In an AI-heavy world, what’s scarce is taste
As a founder / builder, once you’ve run small experiments and found something real, the next leverage point isn’t speed. It’s structure. The question becomes: What kind of system am I actually building? And just as importantly: What behaviors does it reward by default?
In an AI-heavy world, this matters even more. Execution is cheap. Code is abundant. What’s scarce is taste. Judgment. The ability to decide what should be easy and what should be impossible.
Jobs understood this deeply. He wasn’t obsessed with features. He was obsessed with coherence. With end-to-end responsibility. With removing choices so users didn’t have to think about things that didn’t matter.
That’s not minimalism for aesthetics. That’s respect.
Imagine, for a moment, a Linear-like tool for non-engineering PMs
Not “Linear but with tasks renamed.” Something more radical and more restrained:
- A system where the primary object isn’t a task, but a decision.
- Where every item asks: what choice is pending, who needs to weigh in, and by when clarity must emerge.
- Where work doesn’t linger indefinitely in “in progress,” but either resolves or escalates.
- Where the interface assumes ambiguity and helps you navigate it, instead of pretending it doesn’t exist.
Such a tool wouldn’t try to do everything. It would take responsibility for one thing: helping humans decide together without drowning in process.
That’s an architectural choice. And it starts with a hard (harsh?) opinion about the world.
Most product managers underestimate how early these opinions get locked in. Defaults become habits. Habits become culture. Culture becomes the product.
By the time something scales, it’s too late to retrofit taste
That’s why the early brainstorming phase matters. The moment between experiments and structure. The moment where you decide what kind of product you want to create. The moment where you choose constraints deliberately instead of inheriting them accidentally.
If you’re at that point right now, feeling the pull to build something more thoughtful, calmer, and more honest than the tools you’ve been tolerating, you’re not alone.
And you don’t have to figure it out in isolation.
If you want to talk through architecture-first ideas, constraint-driven MVPs, or tools that encode better defaults based on lived frustration, write to help@founderhelpdesk.in. Share what slows you down, what exhausts you, and what you wish your tools understood about your work.
You don’t need a finished vision. Just an opinion that’s starting to take shape.
That’s how systems worth using begin.
– Fat Tony, FounderHelpDesk
Originally published at
https://www.linkedin.com/pulse/issue-13-every-product-opinion-world-founderhelpdesk-vbscc
