My background is in software.
That means I naturally like building things.
Give me a problem and my brain immediately starts thinking about the solution.
What could we automate?
What could we develop?
What could the platform do?
How should the workflow work?
What features should we add?
Building is exciting because you can see progress.
Yesterday, nothing existed.
Today, something exists.
There’s something deeply satisfying about that.
But business taught me a painful lesson that software development never could:
Just because you can build something doesn’t mean anyone wants it.
Builders Fall in Love With Solutions
When you’re technical, the product can become the centre of your universe.
You spend months thinking about it.
So naturally, you notice all the details.
The interface.
The features.
The automation.
The architecture.
The little improvements.
Then you show it to someone expecting them to immediately understand why it’s brilliant.
And sometimes they don’t care.
Not because the product is bad.
Because the problem isn’t important enough.
Or the customer doesn’t understand it.
Or they already have another way to solve it.
Or the timing is wrong.
Or the price doesn’t make sense.
Or they simply don’t trust you enough yet.
The market doesn’t reward effort.
It doesn’t know how many weekends went into the product.
It doesn’t know how complicated the code was.
It doesn’t care how proud you are of the feature.
It responds to value.
That’s it.
Sales Changed How I Build
Working in sales changed my perspective enormously.
Software teaches you how to create a solution.
Sales forces you to understand why somebody would buy it.
Those are two completely different skills.
A developer asks:
“What can this product do?”
A customer asks:
“What does this do for me?”
That distinction sounds obvious.
It isn’t.
I’ve seen how easily businesses spend months describing features when the customer is trying to understand an outcome.
AI-powered.
Automated.
Integrated.
Cloud-based.
Advanced reporting.
Smart dashboard.
Fine.
But does it make me money?
Save me time?
Reduce my costs?
Bring me customers?
Make my team more productive?
Remove a headache?
Those are the questions that matter.
Distribution Is Part of the Product
I used to think building the product was the difficult part.
I’m increasingly convinced that distribution is often harder.
You can build the best solution in a category and still lose to a weaker product with better distribution.
Because customers can’t buy something they’ve never heard about.
This changes the way I look at businesses now.
Whenever someone tells me about a product idea, I’m interested in the idea.
But I’m equally interested in the route to market.
Who is buying?
Why?
How do we reach them?
How much does it cost to acquire them?
How long is the sales cycle?
Who makes the decision?
What makes them trust us?
What happens after the first sale?
Will they renew?
Can one customer bring another?
Those questions aren’t as exciting as designing features.
But they’re often more important.
Build Less, Learn Faster
One of my biggest mindset shifts has been learning not to overbuild.
This is difficult when building comes naturally to you.
You want the full system.
The beautiful version.
Every feature.
Every edge case solved.
But the market can invalidate six months of assumptions in a fifteen-minute conversation.
So I’m becoming a bigger believer in testing the commercial assumption before perfecting the technical solution.
Can we sell the idea?
Will someone pay?
What specific problem are they paying us to solve?
Which feature actually matters?
What happens if we remove everything else?
That approach can feel uncomfortable.
The product might look incomplete.
But learning quickly is more valuable than building perfectly in the wrong direction.
Services Taught Me Something About Products
Running a service business has also influenced the way I think about software.
Services put you extremely close to customers.
They complain.
They ask questions.
They request things.
They tell you where they’re frustrated.
They reveal repetitive problems.
And repetitive problems are interesting.
Because somewhere inside those patterns, there may be a product.
Instead of sitting in a room trying to invent something people might want, sometimes you can simply pay attention to what customers are already repeatedly asking you to solve.
That has increasingly shaped how I think.
Don’t start with:
What can we build?
Start with:
What problem keeps appearing?
Then ask whether technology can solve it better.
I Still Love Building
None of this has made me less excited about technology.
Probably the opposite.
I just respect the market more now.
A product doesn’t become a business when the software works.
It becomes a business when customers repeatedly exchange money for the value it creates.
That’s a very different milestone.
So whenever I’m excited about a new product today, I try to interrupt myself with a few uncomfortable questions.
Who needs this?
How badly?
What are they doing now instead?
Why would they change?
How will they discover us?
And most importantly:
Will they pay?
Because I’ve built things that worked technically.
I’ve also built things nobody wanted.
Both experiences taught me something.
But the second category probably taught me more.