Get to the hard problems fast.

Every project has two kinds of work. Most people spend almost all their time on the wrong one.

The hard work is what decides whether anything you build matters. What problem are you solving? Who is it for? How will they find it? What does the experience need to feel like? These questions don't have obvious answers. They require taste, judgment, and honest conversations with people who might tell you things you don't want to hear.

The easy work is everything else. Writing code. Setting up infrastructure. Designing screens. Wiring payments. Assembling the pitch deck. This work can be complex and technically demanding, but it's knowable. The patterns exist. The documentation exists. Given a clear enough spec, a competent person can execute it.

Figuring out whether anyone will pay for what you're building? There's no tutorial for that. Just you, your judgment, and reality.

Why We Default to Building

Easy work feels productive because it is productive. You can see it, ship it, demo it. At the end of the day you have something tangible. Hard work doesn't give you that. You can talk to users all afternoon and walk away with more questions than you started with.

So most people open the editor and start building.

I've done this more times than I want to admit. New idea, and within two hours I'm setting up the repo, picking a framework, configuring the build system. By Sunday I have a working app with auth, a database, and a landing page. I feel great. Then I realize I still don't know if anyone wants it.

This doesn't just happen to solo developers. I've watched companies spend six months building perfect CI/CD pipelines and microservice architectures before they had a single paying customer. Standups were full of completed tickets. Sprint demos showed polished features. The burn rate was justified because everyone was busy and everything was shipping. But none of it answered the questions that mattered. The team perfected how to build before they understood what to build.

Easy work is genuinely productive. But its value is in carrying you to the next hard question. A prototype surfaces what users actually need. A landing page tests whether your positioning holds. A payment flow proves people will pay. When easy work serves that purpose, it's essential. When it becomes the whole job, it's just expensive motion.

AI Changes the Math

AI is very good at easy work. Not just passable. Actually good. It can write functional code, build reasonable UIs, draft coherent copy, and scaffold entire applications in hours instead of weeks.

This matters because it removes the old excuse. Easy work used to be expensive enough to justify spending most of your time on it. Setting up auth took a week. Building a landing page took days. Those were real costs.

Now you can get a working prototype with decent UX in days, not months. You don't have to settle for the minimum viable version of everything anymore. AI lets you build something genuinely good, quickly, and get it in front of real people to start learning.

But the hard work hasn't changed. AI can't tell you what to build. It can't feel the friction in a user's workflow. It can't weigh the tradeoffs specific to your situation. The gap between easy and hard just got wider, and the teams that see this have an enormous advantage.

The Loop

Name the hard questions before you start building. Be specific. Not "will people like it?" but "will an engineering manager at a 200-person company switch from their current tool to ours, and why?"

Then do only the easy work that helps you test those questions. Get it done fast, get it done well. You want something real enough that people react to it honestly.

Put it in front of someone. Watch what they do. Then go back to the hard questions. Did your assumptions hold? What changed?

Hard thinking, quick building, real feedback, hard thinking again. The faster you cycle, the sooner you find out if you're building something that matters.

The Work That's Yours

Easy work will keep getting easier. But the hard work will still be hard. Deciding what matters. Understanding people. Making bets with incomplete information. These require context, taste, and courage that no tool can replace.

Treat easy work as a bridge, not a destination. It's productive when it's pointed at the next hard problem. But if you're building without a hard question on the other side, you're just moving fast in a circle.

Get to the hard problems fast. That's where the real work lives.