If you’ve spent more than five minutes in the startup world, you’ve probably heard this advice:
“Don’t build a vitamin. Build a painkiller.”
It’s become gospel. The idea is simple: people don’t need vitamins—they’re nice to have, aspirational, future-facing. Painkillers, though? People need those now. When you have a migraine, you’ll pay whatever it takes to make it stop.
In the world of business software, this translates into solving urgent problems—manual processes, confusing workflows, data chaos, lost revenue, compliance headaches. That’s the pitch. Solve a painful problem.
But let me tell you something that doesn’t get said enough: solving pain once isn’t enough. Not if you want to build a sustainable, profitable product.
You don’t just need a painkiller. You need a habit-forming solution to a repeated problem. Bonus points if your solution itself becomes the habit.
Let’s unpack that.
One-Time Pain Doesn’t Build Recurring Revenue
Here’s a trap I see a lot of smart developers fall into—especially those of us with a problem-solving mindset.
We find a problem. We build a solution. It works. The client’s happy. Maybe we even get a few sales.
Then… crickets.
Why? Because the pain only flared up once. Or the person experiencing it had no real urgency to solve it again. The solution was “good enough,” or worse, it was “done.”
That’s the software equivalent of selling a fire extinguisher to someone who just had a kitchen fire. They’re glad they bought it. They may even recommend it to friends. But how often do they come back and buy another one?
That’s not a business. That’s a transaction.
If you want a product that scales, that people use and renew and build into their workflows, you need to look beyond painkillers.
You need addiction-level utility.
Look for Pain + Frequency + Friction
I like to think of product-market fit as a three-part equation:
- Pain – is it urgent, frustrating, costing time, money, or sanity?
- Frequency – does it happen often enough to be annoying or costly?
- Friction – is the current workaround clunky, manual, expensive, or error-prone?
When all three are high, you’ve got gold.
Let’s take a real-world example.
Imagine an HR manager who needs to generate onboarding paperwork for new hires. The process is painful (manual), frequent (weekly or monthly), and full of friction (errors, compliance risk, wasted time).
If you build a product that automates that with a few clicks? You’re not just solving pain—you’re creating a habit. Every time they hire someone, they use your tool. You become part of their process.
That’s recurring usage. That’s sticky.
Now compare that to a tool that helps HR managers create one-time employment agreements. Helpful? Sure. But it’s a painkiller for a single moment in time. Once it’s done, it’s done.
The Real Goal: Build a Product That Becomes a Behaviour
The best software products don’t just solve problems. They reshape behaviour.
Take Calendly. It didn’t just solve the pain of scheduling. It changed how we book meetings. It’s embedded now. People don’t say, “What’s your availability?” They say, “Send me your Calendly.”
That’s when you know you’ve won.
You want to build something people return to, rely on, and can’t imagine living without. Something they instinctively open when they sit down at their desk.
It could be their CRM. Their reporting dashboard. Their task manager. Their analytics tool.
Whatever it is, it’s not just “useful.” It’s part of their flow.
That’s the leap you want to make: from utility to ritual.
Find the Trigger Moments
Every habit starts with a trigger.
Great software identifies and integrates with that trigger—so the user knows when to come back and why.
- New sale? Update the pipeline.
- New hire? Start the onboarding.
- Month end? Run the reports.
- Event finished? Send follow-ups.
Your job is to make sure your product is there at the exact moment your user feels that familiar friction again. And ideally, you make the process so smooth that next time they say:
“Why would I ever go back to doing this manually?”
That’s the moment you’ve replaced their behaviour. That’s when you stop being optional and start being essential.
Don’t Confuse Novelty with Necessity
One of the biggest temptations in the tech world is to chase novelty. The shiny new thing. The clever hack. The AI-powered, blockchain-infused, quantum-certified widget that sounds cool in a pitch deck.
But novelty doesn’t create habits. Repetition does.
Just because your solution is smart doesn’t mean it’s needed—or wanted—every day.
And if you’re targeting businesses? Remember this: enterprises don’t buy novelty. They buy reliability. They buy ROI.
So stop trying to impress. Start trying to embed.
What You’re Really Building Is Workflow Real Estate
Think of your user’s day like a property grid. Every tool they use owns a little square of real estate in their mental and operational workflow.
Slack owns communication.
Google owns search and docs.
Trello or Asana owns task flow.
Salesforce owns CRM (love it or hate it).
If you want to succeed, you have to claim your own square. Better yet, you have to earn it—by being the obvious tool to open when that job needs doing.
And once you’re there, you need to defend that territory with relentless utility and ease.
That’s why solving a repeated problem isn’t optional—it’s foundational.
So, What Should You Build?
Here’s my no-BS framework for figuring it out:
- Start with frequency. What do people do every day or every week that drives them nuts?
- Layer on friction. What part of that task is still slow, manual, annoying, error-prone, or risky?
- Look for consequences. What happens if they don’t fix it? What’s the cost in time, money, morale, or reputation?
- Design to slot in. Make your tool feel like a missing puzzle piece in their process, not a whole new system to learn.
- Test stickiness early. Ask: would they come back tomorrow without a reminder?
If the answer to that last one is yes, you’re onto something.
Final Thought: Build for Dependence, Not Just Delight
Look, I love delightful software. Clean UX. Smooth onboarding. Clever little animations.
But if I had to choose between a delightful product and a necessary one? I’d choose necessary every time.
Delight fades. Dependence sticks.
So yes, go solve pain. But make sure it’s pain that hurts again tomorrow.
Then wrap your solution around that moment so tightly that using your product isn’t just a choice—it’s the only sane option.
That’s not just product-market fit.
That’s product behaviour fit.
And that’s what makes the difference between a tool that gets tried… and one that gets kept.
#StayFrosty!
Q&A Summary:
Q: What is the difference between a 'vitamin' and a 'painkiller' in a startup context?
A: In a startup context, a 'vitamin' is something nice to have, aspirational, and future-facing. A 'painkiller', on the other hand, solves urgent problems like manual processes, confusing workflows, data chaos, lost revenue, and compliance headaches.
Q: Why is it not enough for a software product to just solve a problem once?
A: Solving a problem once is not enough for a software product because it does not promote recurring usage. For a product to be sustainable and profitable, it should solve a repeated problem and ideally become a habit-forming solution.
Q: What is the three-part equation for product-market fit?
A: The three-part equation for product-market fit is: Pain (is it urgent, frustrating, costing time, money, or sanity?), Frequency (does it happen often enough to be annoying or costly?), and Friction (is the current workaround clunky, manual, expensive, or error-prone?).
Q: What is the real goal of building a software product?
A: The real goal of building a software product is not just to solve problems, but to reshape behaviour. The best software products become a regular part of users' workflows and are something they return to, rely on, and can't imagine living without.
Q: What is the 'no-BS framework' for deciding what software product to build?
A: The 'no-BS framework' for deciding what software product to build involves starting with frequency (what do people do every day or week that drives them nuts?), layering on friction (what part of that task is still slow, manual, annoying, error-prone, or risky?), looking for consequences (what happens if they don’t fix it? What’s the cost in time, money, morale, or reputation?), designing to slot in (make your tool feel like a missing puzzle piece in their process, not a whole new system to learn), and testing stickiness early (would they come back tomorrow without a reminder?).
