Good products die when people become resources

Throughout my career the one thing I've watched kill good products is a single word: resource.

Once a company calls its people resources, it starts treating them like resources. It adds them, rotates them, splits them across locations. The product is the first thing to suffer.

Yes, you want a team. The dynamic of that team decides far more than the org chart admits.

Chemistry you cannot buy

People talk about forming, storming, norming and performing, and then forget what it means. A team is not a list of job titles. It is a living system, and when the team changes the system changes with it. One common reading of Tuckman's model is that a new member can push a team back into storming.

The chemistry between people either works or it does not, and you cannot buy it after the fact. It reminds me of arranged marriages. Back in the eighties, when I was growing up, they were commonplace, and I assumed one was the path for me too. People would grow to love each other, we were told. But I saw enough unhappiness to know chemistry mattered. In my own family and the world around me, that has changed a lot. People are far more likely to choose their own partners now, and families have had to change their culture and thinking to accept it.

Good product teams work the same way. There is a line from Simon Sinek I like: "A team is not a group of people who work together. A team is a group of people who trust each other." You can assemble one backend engineer, one frontend engineer, one tester and one product person on a spreadsheet and call it a team. You have capacity on paper. Trust is a separate thing, and it takes time.

The person I would choose again

I have worked with someone I would choose again tomorrow. At one company they were seen as too quiet. At another they did not work out. For me they were one of the best people I have worked with.

Not for agreeing with me. For how they challenged me. The way they set out an argument worked. The way they shared what they knew worked. The way they pushed back made the product better, without ego getting in the way. We put the business first, and we put the product first, and the work clicked. You need conflict, but it has to be the right conflict.

Marty Cagan makes the case for durable, empowered product teams, and SVPG has long argued against outsourcing core competencies when they are central to the business. His phrase for the teams that work is missionaries, not mercenaries. His measure is outcomes over output. You lose both when you move people around like pieces on a board.

The cost lands on a person

I have been on teams where the people making the staffing calls sat nowhere near the day-to-day work, and their bad choices did not stop at the team. They landed on a person.

A brilliant backend engineer was told to become full-stack. He did not want to be. It was not what he enjoyed, not the books he was reading, not what he spent his own time on. He could not bring himself to care about the front end. But he loved the product, so he accepted it.

It drove him into a downward spiral. He lost motivation, and we all do our best work on the things we love, so the work showed it. He felt trapped. Every task was uphill, work he had never chosen and had no pull towards. He had written React before, and he still got no dopamine from solving a problem in that part of the stack.

He had been added as a resource to fill a full-stack gap, and no one asked what he actually wanted to do. The team suffered. People started to read the mismatch as a performance problem, when it was a role-design problem. He had been placed into a slot, not chosen for the work he was best at. So how was he ever going to do good work on something he did not want to do?

There is a place for disagree and commit. This was not it. Adding him that way, and bending the team around a role no one needed to fill like that, was bad for the product and worse for him. It was bad for the company too. He walked away not long after.

Product thinking or resource thinking

That story is the difference between product thinking and resource thinking. The two ask different questions. Product thinking asks whether a change improves the outcome, protects context, and helps the team understand the customer. Resource thinking asks whether you can add a body, rotate a body, or fill a gap. Those are not the same question, and I now sort companies by which one they reach for first. The best product culture I have been part of came from people, not process, which I wrote about in creating a product culture at Cambridge University Press.

A lot of the confusion comes from ideas companies have read but never lived. The Spotify model is the obvious one, a way of working that even Spotify does not use, which I wrote about in before you change the process, understand the problem. These hyped ways of organising teams can look right on paper. Before you adopt one, ask who actually benefits from it.

AI raises the stakes. It is already part of everyday development, and the more raw production work it absorbs, the more the human work shifts towards judgement, taste, context and attention to detail. Dotting the i's and crossing the t's stops being the small part of the job and becomes the job. So the question sharpens: what is the resource for, and what outcome do you expect from it?

How the decline starts

I have worked at companies I would call fantastic product companies, and I have watched some of them decline. The decline starts quietly.

Leadership decides to bring in offshore teams, or rotate people, or split the work across locations, without thinking about the dynamic. The problem is not geography. The problem is breaking context and chemistry while pretending nothing has changed. In a planning deck it reads as efficient. In the room, the product suffers. I once saw the dynamic of a team die inside a day.

Before that, testers, engineers, product people and stakeholders solved problems together. Testers had a real voice, treated as first-class members of the team rather than a service on the side. I had spent a long time breaking down the silos the Jira lanes enforced, which is the work I wrote about in the team I built before I fixed anything. Then the resource thinking arrived. People got added without care. The work fell back into silos. Context leaked away. The people who cared started to care less. The harmony broke. People who had respected each other found it hard to work together.

That is the part leaders miss. When you treat the team casually, the team sees it, and that carelessness spreads into the decisions and into the product. Fred Brooks named the mechanism decades ago in The Mythical Man-Month: "Adding manpower to a late software project makes it later." Nine women cannot produce a baby in one month. Some work does not get faster because more people have been assigned to it. Coordination, onboarding and communication all take time, and they can make a late project later. We still believe people are interchangeable units of delivery, and they are not.

Consulting runs on the same incentive

This is not only a product-company problem. Consulting has its own version of the same trap.

I have spent years as a consultant across many consultancies, and the model there is plain. The more consultants on a project, the more the consultancy earns. That does not automatically make it right for the company paying the bill. They care about the product, not the staffing model.

The line often attributed to Charlie Munger applies here: "Show me the incentive and I will show you the outcome." The consultancy's incentive and the client's incentive are not the same, and everyone involved should be honest about that.

Knowledge without churn

The same holds for the bus factor. You do not want all the knowledge trapped in one head, so pairing and documentation matter. Knowledge sharing works when it comes from a stable team, not from constant churn. Spreading knowledge and disturbing the team are two different acts.

AI can help with the bus factor, but only if the team uses it deliberately. It can keep documentation fresh, capture decisions, explain workflows, and remove some of the mundane work. Done well, it helps knowledge stay in the system. But it does not replace the judgement, taste and context of the people building the product.

If the value sits in judgement, shared context and knowing why past decisions were made, you cannot rotate it in every three months. I hold six months as the minimum contract for serious product work. You need that time to understand the product, its history, the decisions taken, and the decisions the team chose against. Some companies understand this instinctively. Your opinion in week one is worth a dollar. Three weeks in it is worth three. Two months in, five. The context that makes it worth anything never shows up on a resourcing plan.

Autonomy and fit

Not everyone fits everywhere, and that is fine. Two people click, another two are chalk and cheese. Neither is a bad person. The chemistry is wrong for that context, and the product carries the cost when every conversation turns into work and every decision turns into conflict. I have watched that curdle into office politics and a bitterness that spreads.

The product shows it. Instead of something clear and coherent, you get a run of compromises made by people who are tired, frustrated, and ready to give up so they can move on. People stop pushing. The product turns into a mishmash of clashing patterns and styles and half-finished initiatives, a platform that hardens into its own kind of minefield over time.

The alternative is worth the discomfort. Resource thinking optimises for the average, and average is where products go to die. I would take a team with real chemistry, even if it does not last forever, over a safe, interchangeable one that never risks anything. Better to have built something you were proud of and watched it end than to have never built it at all.

Amy Edmondson defined team psychological safety as "a shared belief that the team is safe for interpersonal risk taking." That is not about being nice. It is about people speaking honestly, challenging well, and disagreeing without it turning personal, so the loudest voice does not run the room.

The product has to come first, and for it to come first the team has to work. Communication has to flow, the way I described in teams should communicate like a team fielding in cricket. Get the chemistry right and the safety sits there, invisible, so everyone keeps their eyes on the product instead of on the friction.

If you hold any power over how teams are formed, be careful with the word resource, and with the arbitrary rotation that tends to follow it. You would not choose a partner from a spec sheet. Do not choose a team from one either. Chemistry is not the soft part of the job. It is often what decides whether a good product survives.