Surface solutions and problems

When someone describes a problem, what they reach for is usually a category they recognise or a solution they already use. The to-do list is one of these. What gets named is not the problem itself but the shape of a solution. The shape can be simple while the problem behind it is anything but, and the surface won't tell you which is which.

Asked what they wanted, people said faster horses. They were not lying, just naming the closest thing their vocabulary could hold. What was actually wanted was a way to get places without spending the day on it. A horse was as far as their words went.

Why the shape comes first

Naming a problem requires a vocabulary, and the vocabulary you have is built out of the world you already live in. When something bothers you about your day, the words available are the names of products and routines that exist around you, so you reach for them. A to-do list is what the language hands you when the actual feeling is closer to wanting to feel okay about the work you didn't get to today.

This isn't carelessness or laziness of thought. It's how language works.

What gets addressed

Make what was asked for and you make a better to-do list. What made the user want one in the first place is mostly untouched.

Make something for the problem instead - whatever made the named solution feel necessary - and the result looks different. It may not look like a to-do list at all. The thing that originally bothered the user is what gets addressed, even though they were not calling it the problem.

An honest articulation takes longer to find than a familiar one.

Recognising it

The named solution is easy to spot. It comes pre-formatted, in a sentence, with a name attached. The problem takes longer to find because there isn't a word for it sitting around waiting to be picked up. There is no canonical phrase for the feeling of carrying a head full of undecided commitments through a day that is already in motion. The closest available word is "to-do list," which is why people reach for it. But the closest available word is not the same thing.

The work of finding the problem is the work of staying with the discomfort long enough for a more honest articulation to appear. Not a longer one. A clearer one.

What earns the work

The named solution is easier to defend. It has a name. The problem usually does not, and committing to it means making something nobody asked for in those words - because the words to ask for it did not exist yet.

All of which means I should probably stop telling people I am building a to-do list app. The to-do list is the door. What I am working on is for the problem on the other side of it - and finding the words for that problem is part of the work.

The old logic

Startups became the unit of disruption because they could move. Enterprises had the moats and the distribution, but they also had the overhead. Every change had to pass through approvals and roadmaps before anything shipped. The startup's advantage was the absence of that apparatus. No governance meetings, because there was no governance. No release train, because there was no release train. No negotiating with legal, because there was no legal yet.

Investors, writers, and talent markets organised themselves around the premise that startups disrupt and enterprises defend.

The shift

The same logic applies one level down. What used to be a startup's edge over an enterprise is now an individual's edge over a startup.

If shipping something requires a spec, a scoping meeting, and a release process before anything lands, you are running the startup's version of enterprise overhead. An indie developer can do the whole thing in a single sitting, because deciding and building happen in the same moment when there is only one person.

Startups are still faster than most enterprises. That comparison hasn't gone away. But when the competitive unit is an individual with good taste and a laptop, "faster than an enterprise" is measuring against the wrong thing.

Speed and no baggage used to be the startup's edge over the enterprise. It's now the individual's edge over the startup.

Where the old playbook still holds

Some frontiers still need groups. Hardware runs into physical constraints that don't fold under a single person's attention. Regulation requires institutional relationships and compliance infrastructure. Supply chains span geographies nobody assembles solo.

Most software has no such anchors. Naval's take: pure software is rapidly becoming un-investable. No moats, no durable returns, no reason for capital to pool around a single team. The value moves to the operator - the builder who doesn't need the money, only the taste and the execution.

What this means for how you work

This is not advice to work alone. Some work needs a team, and that won't change. What has changed is what coordination costs you.

For a long time, coordination was cheap relative to building. You wrote the spec, you had the meeting, you agreed the plan, and then the real work began. The meeting was an investment in getting the build right. Now the build is the cheap part. Coordination burns whatever momentum you have.

The cheapest advantage right now is no longer building faster. It is deciding faster. Not isolation - feedback loops still matter, and taste sharpens by other people. But when a decision has to pass through two calendars and three opinions, its real cost is the velocity you burn to get everyone aligned.

The biggest advantage left is not a technology, a market, or a playbook. It's the ability to close the gap between deciding and doing.

What else got cheaper

An idea you had this morning can be a working demo by lunch. For testing whether something has legs, that's as good as it gets. Ideas that would have stayed in notebooks can now be held, turned over, tried. The barrier between thinking and testing has mostly disappeared.

But the same speed that makes testing cheap also makes avoidance cheap. When the project you're working on hits the boring middle - past the prototype, not yet near the finish - a new idea is one conversation away from becoming a working prototype of its own. Building to test an idea is different from building to avoid the project you were already on. They look the same from the outside but lead to very different places.

Displacement

There's a specific moment in every project where the work stops being exciting. The architecture is decided, the prototype works, the interesting problems are solved. What remains is the long middle: refinement, edge cases, the tedious work of making something good enough that other people can use it and care to use it. This is where most of the value gets created and where most of the fun disappears.

When a new idea arrives in that moment - and it will, because ideas are cheap and plentiful - you have a choice. You can stay with the thing that's no longer new but almost real, or you can spend an evening making a new thing that's exciting and definitely not real. Before AI, the second option cost you enough time that it registered as a detour. Now it costs you an evening and produces something that looks like progress.

The difference between exploration and displacement is what happens next. Exploration means you test what you built, learn something, decide whether to continue or discard. Displacement means you move on to another new thing next week. One is a method. The other is a pattern.

The hard middle

The work that actually matters - the part that turns a prototype into something worth using - happens in the stretch where there's nothing new to discover. You already know what the thing should do. You already know roughly how to build it. What remains is doing it well, which is slow and repetitive and completely absent from the highlight reel.

AI can help with this work. It's good at the mechanical parts, the boilerplate, the things that are tedious but well-defined. What it can't do is make you show up for it.

The decision to open the same project on a Tuesday morning, when your head is full of ideas you could start instead, is still entirely yours.

The question that matters each morning is not what you can get done. It's what you're staying with.

Attention is all you have

The transformer paper taught machines to attend - to focus on what matters in a sea of input and ignore the rest. The tools that followed gave us the ability to create at speeds that would have seemed absurd a decade or even a year ago. What they didn't give us is the ability to stay with what we've created past the point where it's novel.

That part is still on us. It always was. It's just that the alternatives got cheaper.

What the gap costs

A plan is a commitment to yourself, even when you don't think of it that way. Each task planned and not done is that commitment, not kept. Small enough to dismiss, but they accumulate.

The cost isn't the unfinished tasks. It's that planning realistically and finishing what's planned is rare. Not because it's hard. Because the plan was never sized for it.

Instead, planning carries a faint sense of fiction. The plan exists, things get done, but the link between them is loose. What happens in a day has less to do with what was planned and more to do with what came up or what was easy to start.

The cost isn't the unfinished tasks. It's never knowing what it feels like to keep your word to yourself.

Why the plan stays long

A long plan is comfortable. Everything on it, nothing chosen, nothing cut. Each item added makes it feel fuller, more considered. Cutting means confronting how little a day holds, and accepting that most of what needs doing won't fit.

Removing something looks like giving up on it, even temporarily. Adding carries no cost. Removing does.

There's a fear underneath: if something isn't on the plan, it might slip. Might lose its urgency, drift out of view. The overloaded plan is a hedge against forgetting. That instinct might be earned. But overloading doesn't solve it - it redistributes the failure from forgetting to not finishing.

Why prioritising misses the point

Rank things. Put the important ones first. Eat the frog. But rearranging the plan doesn't shrink it. The order changed, not the volume.

The act that changes something is leaving things out. Ranking asks which matters most. Leaving out asks which can wait. One is analysis. The other is a confrontation with the plain fact that the day is smaller than the list.

What honesty feels like

A short plan feels exposed. A handful of things, and that's it. No extras filling the margins, no reassuring sense of being busy. The day has room in it, and that room is uncomfortable at first.

There's nowhere to hide. No buffer of half-planned tasks to absorb surprises, no long tail to roll to tomorrow. By the end of the day the answer is plain. That clarity - knowing where things stand, with nothing to hide behind - is what the long plan lets you avoid.

What you get back

Finish what's planned, once, then again, and something compounds. The plan stops being a wish. It becomes a commitment worth taking seriously, because the evidence says it holds.

This builds over weeks. Planning gets more careful because the plan carries weight. Deferring gets easier because the trust is there to come back. Fewer promises, kept - and that turns out to be worth more than the long plan ever was.

The hard part of planning isn't deciding what to do. It's the honesty to stop.

That choice sounds simple. On good days, it is. On hard days, you sit with it. You weigh things no system has access to: how rested you are, which project needs momentum, what conversation you've been avoiding. Half of it isn't information at all. It's feel. A sense of what matters that you can't explain to a database and shouldn't have to.

This is judgment. Most productivity tools are built to take it off your hands.

The pitch

Smart scheduling. Auto-prioritisation. AI that analyses your habits and tells you what to work on next. The assumption underneath is that choosing what to do is overhead, a bottleneck between you and your real work.

That assumption makes sense for scheduling a meeting room or routing a package. These are tasks where human judgment adds nothing and automation adds plenty. But planning your day is not an optimisation problem. The act of choosing what matters is itself the most important thing you do.

Where the line is

A tool that shows you everything clearly - your commitments, your deferred tasks, your deadlines - supports your judgment. It gives you the raw material for that decision without editorialising.

A tool that sorts your tasks by "urgency" has already made a judgment call. It decided what urgency means. It weighted the factors. It presented a ranked list, and now you're not choosing, you're approving. The difference feels like help, which is why it's hard to resist.

Each step further down this path trades a little more of your judgment for the tool's. Auto-scheduling moves tasks into your day without asking. Smart suggestions highlight what you "should" work on. Priority scores replace your sense of what matters with a number. Each one turns your priorities into a calculation and hands you the result.

What you stop noticing

The cost is hard to see because nothing breaks. You still finish tasks. Your day still has structure. But the structure is the tool's, not yours. The difference shows on the days where what the system thinks is urgent and what you know matters are not the same thing. Those are the days where judgment earns its keep. If you haven't been exercising it, you won't trust it when it counts.

Judgment doesn't improve by being outsourced. It improves by being exercised.

What a tool owes you

A tool that respects your judgment shows you what's there and steps aside. It keeps deferred tasks visible so they don't vanish. It surfaces deadlines when they become real, not before. It gives you an honest picture without ranking, scoring, or nudging.

The hard part of building a tool like this is resisting the urge to help more. Suggesting is easy to justify. Nudging demos well. But each suggestion is a moment where the tool's logic quietly replaces your judgment.

The choice is yours. A good tool trusts you to make it.

This isn't a failure of discipline. It's a structural problem: two fundamentally different acts, treated as one.

Two acts, one gesture

Collecting is catching a thought before it disappears. It should be cheap - no friction, no judgment, no weighing whether something deserves to be written down. The whole point is to get it out of your head so your mind can stop holding it. Committing is the opposite act: this is what I'm doing today. Not marking it important. Not noting it's due. Deciding it's happening. A promise to yourself, and it carries the weight of one.

Most task tools collapse these into a single gesture. You type something into a list. Now it exists alongside everything else - the thing you need to do this afternoon, the idea you had in the shower, the project you might start next quarter. They're all just rows. You're organised but not decided. You have a system but not a plan.

The illusion of deciding

Priority flags exist in nearly every task tool, and almost nobody uses them. This isn't laziness - it's instinct. Marking something P1 feels like a decision, but it's the wrong kind. You've decided the task matters, which is a different, much cheaper act than deciding to do it. Twelve things can be P1 before lunch. Twelve things cannot happen today. The flag gives you the feeling of commitment without its cost.

Task management itself becomes the reassurance. Everything captured, everything tagged - you can't be lost if it's all in the system. But organised and decided are not the same state. One is maintenance. The other is commitment.

Organised and decided are not the same state. One is maintenance. The other is commitment.

What actually changes

When collecting and committing live in different acts - not different labels, but different modes of thinking - everything shifts.

Capturing without consequence. When writing something down doesn't commit you to anything, you stop editing at the gate. Every thought goes in - the urgent, the speculative, the half-formed. Your inbox becomes what it's supposed to be: a complete picture of what's on your mind, not a pre-filtered version of what you think you can handle. The background noise of uncaptured thoughts goes quiet.

And committing gains weight. When there's a distinct act that means today - not a flag, not a due date, not a sort order, but a deliberate move - choosing carries cost. Five things you've actively chosen are not the same as fifty things you've ranked. The short list is what's happening. Everything else is what might.

The daily decision

The separation holds because of a ritual: the daily act of looking at everything you've captured and choosing what's actually happening. Not sorting, not reorganising - choosing. Once that choice is made, the list is set. The day has a shape.

No algorithm can do this. Software can sort by urgency, surface what's overdue, estimate what matters. But committing - looking at everything and choosing, knowing you're leaving the rest behind - is the one act that has to be yours. No one and nothing makes that decision on your behalf.

Seeing the line

None of this is about software. It's a structural observation about how we think about work. The thought that you'll get to something eventually and the decision to do it today are not the same, and they deserve different treatment.

Once you see this, you start noticing. Not whether lists are good or bad - lists are fine. Whether, somewhere in a given system, there's an actual commitment to what's happening today. When that's missing - when everything sits in one undifferentiated pile, waiting to be sorted into relevance - very little moves.

Collect freely. Commit deliberately. Everything else is sorting.

At the other end are people who've given up on tools entirely - a sticky note on the monitor, a mental list half-forgotten by lunch. They look like the opposite of the system-builder, but they're responding to the same overwhelm. One over-structures. The other opts out. Neither questions whether the complexity was necessary.

Nothing slips through

Most task tools sell the same promise: capture everything, structure it correctly, and nothing falls through. So you build the structure - goals, milestones, tasks, sub-tasks, each nested inside the last.

Then the doubt creeps in. Are your milestones at the right level - weeks or deliverables? Does the Gantt chart reflect reality or last Monday's optimism? Should that be a Task or a Sub-task? The system offers so many ways to be wrong that you stop trusting your own sense of what matters.

You're not doing your work any more. You're describing it to a machine, hoping the description is accurate enough. In some organisations, the overhead becomes its own department - entire roles dedicated to maintaining the system rather than doing the work it tracks.

Each feature that promises to organise adds another layer your work has to fit into. The questions never resolve.

Why simplicity feels suspicious

When a tool has suspiciously few moving parts, the first reaction is distrust. A flat list feels like a toy.

That instinct comes from somewhere real. Code genuinely needs layers of abstraction - thousands of interacting parts, state that compounds, failures you can't predict. But your task list isn't a codebase. The things you need to do on a given day don't warrant that structural apparatus. They got one anyway.

A tool that makes good decisions about how work should be structured doesn't need to ask you how to structure it. The absence of options isn't a limitation - it's a sign that the thinking happened before you arrived.

Complexity compounds

Features don't add up. They multiply. A priority system interacts with sorting. Sorting interacts with filtering. Filtering interacts with views. Each new capability doesn't add one decision - it multiplies the decisions already there. The overhead grows faster than the capability.

This is why complex tools feel heavy even when each feature is well-designed. The weight isn't in the parts. It's in the interactions between them. You can understand every feature in isolation and still feel lost in the combination.

Complexity accumulates one reasonable feature at a time, until the tool itself becomes the work.

What simplicity costs

Simple products aren't easy to build. Cutting a feature is harder than adding one, because you have to be right about what the tool should do instead of handing the user a choice. Every feature you remove is a bet that your judgment is better than an option. That takes research, taste, and a willingness to be wrong.

Most tools take the other path. Adding a feature is easy to justify - it satisfies the request and sidesteps the question of whether the feature should exist at all. Features accumulate. Each makes sense on its own - someone wanted it, a competitor shipped it. But the cumulative cost isn't borne by the maker. It's borne by everyone who opens the tool and has to find their way through what it became.

Someone else's thinking

The lightest tools aren't the ones with the fewest features on a spec sheet. They're the ones that absorbed the most decisions, so you never had to make them.

You open them and start working. No structure to learn, no taxonomy to maintain, no layers between you and the thing you sat down to do.

Simplicity isn't the absence of thought. It's the presence of someone else's.

AI removed them almost overnight. You can build a working prototype in an afternoon. You can ship something functional in a week without writing a line of code yourself. The barrier that kept most people from building is gone.

And yet most people who can now build anything are building nothing. Or - more accurately - finishing nothing. Which raises an uncomfortable question: if the barrier was never really technical, what was it?

The alibi

The interesting thing about removing a constraint is that it shows you which constraints were real and which were alibis. "I can't build it" was, for a lot of people, a comfortable reason not to confront a harder question: do I care enough about this to see it through?

It's easy to have ideas when you can't act on them. The impossibility is what makes them safe. You get to imagine the product, the users, the outcome - without ever testing whether you'd actually do the tedious, unglamorous work of making it real. AI called that bluff. It solved the how. And it revealed that the how was never really the problem.

The replacement fantasy

The most common first instinct when people realise what AI can build is: I'll replace the tool I'm paying for. My own CRM. My own task manager. My own invoicing system.

But nobody obsesses about invoicing. These are solutions to mild annoyances, not responses to problems that keep you awake. You'll get a prototype running in an evening, feel clever about it for a day, and never touch it again. Not because you failed - because the problem wasn't important enough to sustain your attention past the novelty of building it.

The prototype works. You just don't care enough to make it good.

The thing that didn't change

The people who will build things that matter are the same kind of people who always did - the ones who feel so strongly about a problem that they can't leave it alone. The kind of person who uses every existing solution, finds all of them inadequate, and can't stop thinking about what the right one would look like. That hasn't changed. Obsession isn't a skill you acquire. It's something that finds you.

What changed is who those people can be. You no longer need capital, a technical co-founder, or a computer science degree. The barriers to entrepreneurship collapsed. But the barrier to persistence - genuine, slightly irrational care about a specific problem - is exactly where it always was. The filter didn't disappear. It moved.

The filter didn't disappear. It moved.

The double-edged sword

The obvious downside is that this cuts both ways. When starting is nearly free, you start everything. The graveyard of abandoned projects isn't a personal failing - it's the predictable result of a world where every new idea is one prompt away from feeling real.

But the same dynamic that creates the graveyard might also shorten the search. You probably can't tell upfront whether a problem is yours to obsess about. The historical advice has always been to try things quickly and see what sticks. If AI makes trying nearly free - if you can go from idea to working prototype in an afternoon - maybe people cycle through the false starts faster and arrive at their real obsession sooner.

The doom is more abandoned projects. The boon is a shorter path to the one that won't let go of you. And you'll know the difference, because the project you care about is the one where the prototype isn't enough. It's the one where you look at what you built and think: this needs to be better. And then you actually make it better. And then you do it again the next day.

The real unlock

The story being told right now is that AI democratised building. Everyone can create software. Everyone is a founder. That's technically true and practically misleading. Everyone can start. That was already mostly true before, and starting was never the hard part.

The real unlock is quieter. Somewhere, right now, someone who has been bothered by a specific problem for years - who always knew what the solution should look like but couldn't build it - can finally act. Not because AI gave them an idea. Because it removed the last obstacle between them and the thing they were already obsessed with.

That's who AI is really for. Not the person looking for something to build. The person who already knows.