But the question that separates a weekend project from a real company is the same one it’s always been: Who are you automating this for?

One of the most dangerous things a builder can do is fall in love with something they’ve made and then go looking for someone who needs it. It almost never works. The museum of failed products is full of beautiful solutions that never found a real problem. The old rule still holds - maybe more than ever in the age of AI: fall in love with the problem, not the solution.

If you want to build a product that succeeds, you must go where the pain is high. But how do you identify real pain versus a passing complaint? Let me try and put some structure to it.

Satisficing

People love to complain about a lot of things in their life but will only take actions to solve a select few of them. When you’re interviewing users, it’s tempting to hear a complaint and treat it as a market. But what looks like pain from the outside often feels like a mild inconvenience from the inside. Not every frustration is a problem people will pay to solve. Most of them, in fact, aren’t.

There’s a useful word for this — satisficing. It’s a blend of “satisfy” and “suffice,” and it describes something deeply cognitive: we solve most problems in our lives just enough to stop thinking about them. You don’t install a cable management system — you shove the wires behind the desk. You don’t spend two hours unsubscribing from newsletters — you clean up the first couple of pages and move on. Good enough is good enough.

Here’s where it gets tricky for AI builders. A huge number of the things we’re now automating with agents lived comfortably in the satisficing zone before AI showed up. People weren’t losing sleep over them. They had workarounds. They’d made peace with the mess. Which means that just because AI can solve something doesn’t mean anyone will pay for the solution. Solving a problem no one was truly bothered by doesn’t earn you a business - it earns you a demo.

People often practice “satisficing”, term that combines ‘satisfy’ and ‘suffice’ to indicate that we solve a lot of problems in our life only to an acceptable threshold. For example, you’d rather choose to hide messy wires by pushing them behind your table rather than implementing a cable organiser. You’d choose to clean the unread emails of the first two pages of the inbox rather than spending hours to filter mails and unsubscribe each of them.

As a builder your job is to distinguish between “I will pay for that solution” vs “I can deal with it” kinda solution.

The Workaround

So how do you know the pain is real? You don’t ask people to predict what they’ll do. You look at what they’ve already done.

People are surprisingly honest about their problems but remarkably unreliable when it comes to their future behavior. Someone will tell you with absolute conviction that they’d pay for a solution - and then never open the app. The best signal isn’t what they say. It’s what they’ve tried.

To find out if a pain point is severe, ask: “What else have you tried?”. If a user claims a problem is terrible but hasn’t actually spent any time or money trying to fix it, it is not a high-pain problem. I think of it as the “top of mind” test. Is this problem occupying active space on their mental to-do list - the one they actually look at — or is it buried somewhere they’ll never scroll to? If they haven’t already gone looking for a fix, they’re not going to find yours either.

The workaround doesn’t have to be impressive. It just has to exist. It can be active - someone trying to get fit who has started walking every day, or swapped one meal for a salad, or takes the stairs instead of the lift. Or it can be passive - they follow three fitness creators, can name their channels, and have a specific workout method they’ve been meaning to try. Either counts. But if they’ve done nothing - not even a YouTube rabbit hole - then this problem isn’t alive for them. It’s just a thought they had once.

The customers with the highest pain aren’t the ones who demand a polished product. They’re the ones who’ll tolerate your duct-tape MVP, use it anyway, and give you brutally specific feedback - because the problem bothers them that much. These are your early evangelists.

One last thing. When someone gives you a feature request or voices a complaint, don’t take it at face value. Go one level deeper. Ask: “Why do you bother doing it this way?” The answer to that question is where the real product lives.

Dollar value of the pain

Real pain has a price tag. Your job is to find it.

When someone tells you about a problem, don’t stop at the symptom. Ask the next question: “What happens if you don’t solve this?” That’s where the truth lives. Understand the opportunity costs.

Maybe it’s hours lost every week. Maybe it’s revenue leaking through a broken workflow. Maybe it’s three people doing a job that should take one. The implications of not solving a problem tell you more about its severity than any description of the problem itself. Pain that doesn’t cost anything isn’t pain - it’s just a preference.

And once you understand the cost, try to put a number on it. Not your number — theirs. What’s the mental price tag this problem carries in the user’s mind? Is this a $100 frustration or a $100,000 bottleneck? That distinction changes everything - what you build, how you price it, where you spend your time, how many resources you throw at it.

By understanding the dollar value to the pain, the calculation of Return of Investment to your solution becomes easier.

Desperate Users

When testing your problem statement, pay close attention to the emotional signals your users give off. There is a massive difference between a user saying, “Yeah, that’s a problem,” vs “Shut up and take my money”. Everyone wants the latter.

In customer discovery phase you are looking for prospective who who truly feel the pain and are near desperate for a solution. Knowing the size of a prospect’s demand helps you understand the magnitude of their business pain; the higher the pain, the more motivated they will be to pay for your solution.

Which brings me to something most first-time builders avoid and most experienced ones swear by: have the money conversation. You must have the “willingness to pay” talk early. If the pain isn’t high enough for them to open their wallets during the concept stage, it won’t be high enough when you actually build the product

Here’s the thing about building in the age of AI: the technology has never been more capable, and the temptation to build has never been higher.

AI has given us an extraordinary new set of hammers. The skill that matters now - the one that’s always mattered - is knowing which things are actually nails.

For over a decade, the tech industry ran on a single power imbalance: people with opinions needed people with code. That gap created entire career categories - product managers, designers, tech co-founders who got 50% equity just because they could open a terminal and not be intimidated. It turned ‘technical co-founder’ into the most sought-after phrase in every WhatsApp group of aspiring founders. That era ended quietly sometime in the last four months, and most people haven’t processed it yet.

I started building a product a few weeks ago. What began as ‘let me just make one small web page’ turned into the most addictive experience of my professional life. One page became two, two became a full prototype, and somewhere around day three I stopped sleeping properly. Not because of stress - because of dopamine. For the first time, the thing in my head was becoming the thing on my screen without another human mistranslating it. I’d say something, and it would happen. There is magic right in front of my eyes without back to back meetings or PRDs or sprint plannings. In a decade of managing teams, I was finally working with something smarter than most people I’ve hired - and it had no ego.

Say hello to (my) Claude Code!

The internet is full of people feeling this exact high right now. ‘5 AM and I can’t stop building.’ ‘Shipped more this week than my last quarter at work.’ ‘Why does this feel like falling in love?’ They’re calling it a simulationship - a romantic relationship with your tools. I call them Claudaholics. I’ve also been around long enough to know what comes after the honeymoon. The question isn’t whether you can build.The question is whether what you built matters to anyone other than you. And that’s a much older, much harder problem that no AI model can solve.

We’ve seen this movie before - literally. There was a time when making a film itself was the achievement. Then phones got great cameras, editing software became free, and YouTube removed the gatekeepers. Did we get a golden age of cinema? We got a million reels. Making a film stopped being the moat. Storytelling became the moat. Taste became the moat. Knowing what to cut became more valuable than knowing how to shoot. Software is about to go through the exact same compression. Right now, building a product still feels like an achievement. Give it eighteen months. When every PM in Bangalore can ship a prototype, the flex of ‘I built this’ will carry the same weight as ‘I made a reel.’ Zero.

Here’s what I think is coming, and I don’t think most builders are ready for it. Everything you and I have built in the last three months will become irrelevant - not because it’s bad, but because a million other people are building the exact same thing. The dopamine of ‘I shipped something’ has a half-life. When everyone can build, building stops being the differentiator. We’re about to enter a phase where the tech industry looks a lot like the film industry: making the thing is table stakes. The question becomes - do you have taste? Do you know which problem is actually worth solving? Can you tell the difference between a feature that feels clever and a product that someone will pay for? Because LLMs can build anything. They cannot tell you what’s worth building.

So what survives? I keep coming back to the same answer: the people who understood humans before they understood machines. What survives the compression is what has always survived every technological democratization: judgment. Not taste in the aesthetic sense - taste in the strategic sense. The ability to look at a hundred things you could build and pick the one that solves a problem someone will pay to have solved. This has always been the hardest skill in tech. It was just invisible because building was so hard that most people never got far enough to realize their idea was bad.

My wife maintains a garden. When new seeds arrive, she mixes them all together and scatters them across the soil. She doesn’t know which ones will grow. She just increases her odds and waters everything. Every morning she walks out to the balcony with her coffee and gets surprised by what bloomed. That’s where we are right now - a million seeds in the ground, everyone watering furiously. But here’s what my wife knows that most builders don’t: a garden isn’t beautiful because everything grew. It’s beautiful because someone knew what to keep and what to pull out.

The tools have never been cheaper. Taste has never been more expensive.