I Built What I Thought Customers Needed. That Was My Biggest Mistake.

A few days ago, I was sitting on my balcony with my morning tea. It was one of those quiet mornings when the mind goes somewhere without any particular reason. I started thinking about the beginning of my first entrepreneurial journey and how differently I look at product building today compared to those early days.

When we started, I was completely focused on the solution we had created. We had identified what looked like an industry problem, built a platform around it and went to the market believing that customers would see the problem the same way we did.

They didn't.

For quite some time, I remained attached to the problem we had identified. Every rejection made me think that perhaps we had not explained the product properly, perhaps the customer needed more education, or perhaps we needed more features. We kept trying to penetrate the market, but the struggle continued.

Looking back, the problem was not necessarily our ability to build the product. The problem was that I was too convinced about what the customer needed.

Around that time, a friend who had been part of a YC cohort said something very simple to me:

“Build what your customers want, not what you want.”

There was nothing technically complicated in that sentence, but it changed the way I went back to the market.

Until then, I was going into meetings trying to prove that the problem we had identified was important. After that conversation, I decided to stop proving anything for some time and start listening.

I went back with a much more open mind.

This time, instead of asking customers whether they liked our solution, I started trying to understand what actually made their work difficult. What did they spend time on every day? Where did things get stuck? Which problems irritated them enough that they would genuinely want someone to solve them?

That is when I started seeing the real problem.

We pivoted the platform and kept the initial version deliberately simple. There were very few features. The objective was not to impress the customer with everything the technology could do. It was simply to make one part of their working day easier.

There was another thought that started guiding me during that phase:

Meet your customer where they are before you make them travel your way.

When we build technology, it is very easy to think about the ideal way a process should work. We design the workflow, create screens and then expect users to change the way they have been working for years because our system is supposedly better.

Customers rarely behave that way.

Before asking someone to change their behaviour, I learnt that it was far easier to first understand their existing behaviour. If the platform could fit into the way they already worked and remove some friction, they would start trusting it. Once that trust existed, we could gradually introduce better ways of doing things.

Something interesting started happening after the pivot.

Earlier, getting meaningful conversations itself was difficult. Now we were getting a seat at the table. Customers were willing to spend time with us. Sometimes those discussions would happen over coffee in their offices. They were not listening because we had suddenly become better at presenting slides. They were listening because the product was making something in their working life easier.

In some cases, it was also helping them become better at their job.

That created another learning for me, particularly in B2B.

There is rarely just one customer.

When we say “customer” in a B2B business, who exactly are we talking about?

Is it the owner who signs the cheque?

Is it the business leader who approves the purchase?

Is it the department head responsible for implementation?

Or is it the person sitting at the lowest level of that hierarchy who will actually open the platform every morning and use it?

In the early days, I made the mistake of listening mainly to business owners.

Their view of the problem was extremely clear. When a senior leader explains an organisational problem, it can sound very convincing because they are seeing the business from the top. We built around that understanding.

But the people who eventually had to use the product were experiencing the same business very differently.

Once I understood this, I made sure I did not repeat the mistake after the pivot.

I already knew what the owner wanted. Now I wanted to understand everyone else.

The only practical way I found to do that was to keep meeting people.

That also meant being prepared to get rejected.

There were many meetings where the answer was no. There were people who stopped responding after a couple of discussions. There were conversations that seemed promising and then went nowhere.

Earlier, I would probably have looked at each rejection simply as a lost deal.

Later, I started looking at them as information.

Every meeting gave me access to another layer of the organisation. Someone in procurement would describe the problem differently from the owner. A department head would care about something else. The actual user would point out a small operational frustration that nobody in senior management had even mentioned.

Gradually, a pattern started becoming visible.

The product was the same.

The features were the same.

But the value was different for every person sitting around the table.

The owner might care about visibility and control.

A functional leader might care about efficiency.

A manager might care about reducing follow-ups.

The person actually using the system might simply want something that saves twenty minutes of repetitive work every day.

If I walked into every meeting and explained the same ten product features, I was expecting everyone to translate those features into their own value.

That was my job, not theirs.

Once I understood this, the sales conversation became much clearer. We trained the team to understand which stakeholder they were speaking to and what value mattered to that person.

There was one more complication I learnt about B2B buying.

The organisation chart does not always tell you who influences the decision.

Sometimes the biggest blocker or supporter is somebody who will neither sign the cheque nor use the product.

I remember one fairly large opportunity where there was a Strategy Officer involved. The platform itself was going to be used around purchase and contracts, so technically this person was not the obvious stakeholder for us.

But during the discussions, I sensed that he was involved in almost everything important happening in the company.

Instead of treating him as someone outside the buying process, I spent time helping him understand what we were trying to solve and why it mattered.

The deal took us a few months.

Taking him into confidence turned out to be important because he understood the organisation from multiple sides. He helped connect pieces that we could not see ourselves, from what the owner wanted to what the teams on the ground actually needed.

That experience taught me that B2B selling is rarely about finding only the decision-maker.

You have to understand the decision system.

There may be a buyer, an approver, a user, a beneficiary and an influencer. Sometimes the person with the smallest designation in the room can quietly decide whether the product gets adopted. Sometimes someone who appears unrelated to the purchase can influence whether the deal moves at all.

This does not mean creating a different product for every stakeholder.

Many times, the same product creates different value for different people.

Understanding that difference changed both the way I thought about product and the way I thought about selling it.

When I look back at those early struggles now, three learnings have stayed with me.

The first is to build what the customer wants, not what I want. A founder needs conviction, but conviction should not become an excuse for ignoring what the market is repeatedly saying.

The second is to meet customers where they are before asking them to travel your way. Adoption becomes much easier when the product first respects the customer's current reality instead of immediately trying to replace it.

And the third is to understand the need of every stakeholder and sell the value they care about, not simply the features you have built.

Perhaps the biggest change for me was learning to become a little less attached to being right.

The market rejected my first understanding of the problem. At that time, those rejections were frustrating.

Today, I see them differently.

They were probably some of the most useful customer conversations I had.