Problem Backward, Not Role Backward

On April 29 we were in an org discussion about how work gets picked at Cars24. The conversation kept returning to roles. My role covers this. That part sits with another team. I will take it up if it reaches me.

At some point I said the thing I had been circling for months. We are working role backward. I want us to work problem backward.

Role backward starts with the job description and asks what work fits inside it. Problem backward starts with the world we are trying to create, finds the customer whose experience proves that world is not true yet, and works back to whatever has to be done. The gap defines the work, not the function that happens to contain it. A role records how the company divided yesterday's work. The customer does not care how we divided it.

I want to be fair to everyone in that room. Nobody there invented role-backward thinking. We taught it to them. I approved the org charts. I signed off on job descriptions that told smart people exactly which problems were theirs and, by silence, which were not. If Cars24 thinks in roles, that is on me before it is on anyone else.

At Cars24, Flatland means everyone is a Builder. Work forms around problems, in pods, and a Builder can own a problem for as long as it needs owning without becoming anyone's permanent boss. A job description no longer chooses the work for you. So what do you actually work on?

The comfort we took away

Earlier this month, in another Flatland discussion, we admitted something to each other. Removing role instructions has made choosing work harder.

Let me say that plainly. A job description was a service. It chose for you. You could come in on Monday and the hardest question of the week was already answered. When we removed it, we did not just hand people freedom. We also handed them the most difficult part of the job, the part the org structure used to do on their behalf, sometimes badly.

A few weeks after that April discussion, one line stayed with me. Solving problems is not our scarce skill. Selecting problems is. We have plenty of Builders who can solve a hard problem once it has been named. Naming the right one is rarer.

My own adjustment has been to step back from assigning. I used to hand people problems, and part of me still itches to. But there are many ways to reach the top of the mountain, and if I dictate the route every time, I have just become the org chart again. The test I care about now is simple to say and hard to live. Can a Builder select the right problem, and take it on the chin when the selection turns out wrong?

What a real problem looks like

A vision does not choose your problem for you either. A vision is a direction, not an instruction. It turns into a problem only when you can see it failing one specific customer.

Here is one. A buyer was close to finalising a Creta with us. Before the transaction went through, our challan check surfaced pending dues on that car from another state. The money had not moved yet. He heard it from us before he paid.

I am not telling this as a trophy story, and I will not pretend the capability came out of some clean problem-backward ritual. I use it because of its shape. Look at what that one customer's situation touched. The listing he saw. The inspection of the car. The loan being arranged. The ownership documents. Government records sitting in another state. Support, if it had gone wrong later.

Whose role is that? If catalog, inspection and finance each examine only their slice, every local dashboard can look fine while the customer is still exposed. Problem backward, there is one question and it belongs to no function. Can a person hand over their savings for this car without inheriting someone else's mess?

Real customer problems usually look like this. They cut across the company sideways while the org chart runs up and down.

A good list can become a wall

Some time back, one of our Builders walked me through the five important areas he was focused on. All five were real. That was exactly the trap.

Catalog photos were showing up as a big delta in what customers actually experience, and they were not one of the five. So I pushed him. "But also apply your judgement. If catalog photo is such a delta, is it worth to dive in?"

His list was not wrong. A list of priorities, even a good one, can quietly harden back into a role. You can be diligent about your list and still miss the biggest thing your customer is living through because you have stopped looking outside it.

I ended that exchange with the sentence I now repeat everywhere. "You don't need permissions. Just we all practicing to work problem statement backward and not role backward. And this is true for everyone."

Everyone includes me. Mostly me.

When real problems compete

The fair pushback is this. Fine, no lanes. Then five Builders find five real problems, all consequential. Who decides? Does Flatland pretend trade-offs disappear?

No. Flatland removes assigned lanes. It does not remove priorities and it does not make judgment optional. It moves judgment closer to whoever can see the customer and asks for the choice to be made in the open.

When several problems are all real, the tie should not go to whoever argues loudest. Start from the company's stated direction and the consequence for the customer. Then ask the unglamorous questions. Does this recur, or was it one bad week? How many people does it touch? If we get it wrong, can the damage be undone? What does waiting another quarter cost? The same questions protect you from the opposite failure, a fascinating gap that touches almost nobody.

Then write the problem down with the evidence. Others should be able to ask why this problem, why now and why ahead of everything else. That is how we keep self-selected work honest.

If two problems still look equal after that, stop debating and run the smallest real experiment that can teach the pod something. Some problems get owned now. Some get parked, with the honesty to call them parked. Some belong with a different group entirely and should be handed over loudly, not hoarded. The Builders closest to the problem make the call, in the open, and own it either way.

After all of it, the choice can still be wrong. No method removes that. That is what taking it on the chin means.

What AI changes, and what it cannot

People assume AI is what makes this workable. Let me be precise about what it actually does, with the same Creta buyer.

Assembling that customer's full picture used to mean collecting fragments from several functions before anyone could agree on what had happened. An agent can now help one Builder gather the listing, inspection report, loan file, documents and support trail. A small pod can use that context to build a first answer and test it against real cases. One Builder can now see and begin moving a problem that previously disappeared between departments.

AI can help one Builder move much more of the work. It still does not answer the hardest question: is this the problem worth choosing over the five others? As action gets easier, that choice matters more.

This is why removing role instructions made work feel harder, and why it was still right. The difficulty was always there. Roles hid it inside a few people's calendars.

We are still learning this. I will not claim every pod at Cars24 finds its problem cleanly today. But when it works, it looks like a Builder starting from the world we are trying to make true, finding the customer it is failing for, naming the gap where everyone can see it, moving it with the smallest pod, and taking the outcome on the chin either way.

That line is one I have to eat first. Problem statement backward, not role backward. True for everyone, starting with the person who used to write the roles.