Own the Product, Not Just Your Part of It

A few days ago, one of our Cora customers called me asking for a meeting.

His business had subscribed to Cora-ERP around a year and a half ago. Yet, despite all that time, the full migration to our system had not happened.

I knew we had work to do. But I don't think I had fully understood the gravity of the situation until we sat down together.

During the meeting, he walked me through the problems in his business. Inefficient operations. Resistance to change. A lack of focus at the leadership level. People carrying too many responsibilities, leaving them unable to do any of them effectively.

He acknowledged his own mistakes, too, particularly in assigning too many roles to the same people.

But the consequences were becoming unbearable.

His business was spending around ₹5 lakh a day, losing approximately ₹7 lakh a month on top of the interest burden on a ₹48 crore loan. He was frustrated with his team, and understandably, some of that frustration extended to us.

We had failed him in an important way.

He had our product, but we had not successfully brought his business onto it. And without that transition, the business continued operating through inefficient processes, while the investment in the software was yet to deliver its intended value.

He had reached a point where he was considering shutting down the entire business wing.

I couldn't treat this as another onboarding ticket in our tracker.

This was someone's business, livelihood, and years of effort at stake.

So I offered to stay at his office for the next ten days and work through the problems with his team.

When the usual team wasn't available

When it was time to start, my core team members were either on leave or occupied with important deadlines.

I had a choice: wait until the right people became available, or find a way to make progress with the people I had.

I took three interns from our new batch and went to his office.

We started working through the problems one by one. Understanding how the business actually operated. Identifying what was preventing the migration. Getting the different business units onto the system. Working with the people who would have to use it every day.

There was no shortcut around understanding the situation. We had to get close to the actual work, see where things were breaking down, and solve the problems in front of us.

Today is our fifth day.

We have already onboarded all the business units onto Cora-ERP.

His team had estimated that this would take more than two months.

We still have work to do. Onboarding is not the same as completing the entire change-management process, and getting a system running is not the same as ensuring that everyone uses it effectively. But the progress so far has been significant.

And somewhere in the middle of this work, I realised something that went far beyond this one customer's onboarding.

I had a team ownership problem

When I had to make decisions, investigate problems, or review the work being done, I could do so with confidence because I had spent time understanding the product.

I had read the documentation. I had spoken to developers while they were building different parts of the system. I had followed the product beyond just the tasks assigned to me.

I didn't know every line of code. I didn't need to.

But I understood enough of the system to connect the pieces, ask the right questions, recognise problems, and take responsibility when the situation demanded it.

Then I thought about my leaders.

Most of them were focused on their assigned work. They were building their respective features, completing tasks, and meeting deadlines. But they weren't consistently investing the same effort in understanding the product as a whole.

And that creates a dangerous limitation.

What happens when the person who built a particular feature is unavailable? What happens when an unfamiliar bug crosses the boundaries of two systems? What happens when a customer is in trouble and the team needs someone to investigate, make decisions, and move things forward immediately?

If only one person understands a system, the organisation is dependent on that person.

If every leader understands only their own part, the organisation has a collection of individual contributors, but not a team that can reliably take ownership of the product.

We cannot build a great engineering team if our leaders understand only the parts they are assigned to work on.

And the uncomfortable part? Our product is still relatively small. If we struggle to develop this depth of understanding now, what will happen when the product becomes ten times more complex?

Ownership begins where your assigned task ends

I've been thinking about what it actually means to be a leader in a product company.

It cannot simply mean that you are responsible for a team, a module, or a set of deliverables.

You must understand how the product works as a whole. You must know why important systems exist, how they interact, what has been implemented, what remains incomplete, and where the risks are.

You must be curious enough to read documentation even when nobody has assigned it to you. You must speak to developers about systems you didn't build. You must understand the reasoning behind implementation decisions, not just the final code.

And when reviewing someone else's work, you should be capable of evaluating it in the context of the broader product.

This doesn't mean everyone needs to know everything equally deeply. It means every leader should have enough breadth to reason about the whole product, with the necessary depth in the systems they are responsible for.

Your responsibility is not limited to the code you write. It extends to the product you help build.

That is the difference between completing your work and taking ownership.

Reviews must build people, not just approve code

There is another implication.

Knowledge cannot remain trapped inside the minds of individual developers.

When someone understands a system, they should teach it to others. When reviewing a teammate's work, leaders should encourage them to explain their decisions, the assumptions behind their implementation, the failure cases they considered, and how their changes interact with the rest of the product.

A review should do more than determine whether a change can be merged.

It should help the author become a better engineer. It should help the reviewer deepen their own understanding. It should leave more people capable of maintaining and improving that part of the product.

Over time, this creates a team that can operate with greater confidence and less dependence on individual people.

That is the kind of team I want us to build at Techcora.

The kind of team I want to build

The experience at that customer's office has reinforced something I want to hold myself and our leaders accountable to for years to come.

I don't want a team that can execute only when the right individual is available.

I want a team where leaders can step into unfamiliar situations, understand the system, ask intelligent questions, and help move the business forward.

A team where people are not afraid to explore areas outside their immediate responsibilities.

A team where knowledge is shared deliberately, reviews make everyone stronger, and no critical part of the product remains a mystery to the rest of the leadership.

As our product grows, its complexity will grow. Our ability to understand, maintain, and improve it must grow faster.

That requires more than technical skill. It requires curiosity, initiative, and a sense of responsibility that goes beyond assigned tasks.

And it begins with a simple principle:

Own the product, not just your part of it.

Understand it proactively. Take responsibility beyond your tasks. Help everyone else understand it, too.

That is how we build a product that customers can depend on, a team that can deliver when it matters, and a company in which every person has the opportunity to grow alongside what they help create.