Live data from Hacker News

Why products built by large teams fail so often

blog.mojotech.com

1–10 of 43 posts

Re: Why products built by large teams fail so often

#3
The absence of a clear product definition and strategy is hardly unique to large teams, and in fact will manifest itself more fatally in small teams in my experience.

I may be suffering from a bout of biased sampling but it certainly seems that the problem of actually defining a product is getting substantially worse these last few years and in the absence of real product strategies there is instead a proliferation of cargo cult product thinking.

Re: Why products built by large teams fail so often

#5
Or, a possibly much simpler answer:

Projects that require large teams are larger, and thus more complicated and difficult. More difficult projects fail more often.

Artificially shrinking the size of the team without reducing the scope and complexity of the project will rarely improve its chances (unless the team size was only an effect of beaurocracy, and you manage to only kick off the people who aren't contributing).

Re: Why products built by large teams fail so often

#6
What products are we taking about? Why does the author simply assume the fact that a large team exists is the reason why the project fails?

He doesn't seem to touch on the fact that many times large teams exist because a project is large and complex, which makes it easier for projects to fail.

Re: Why products built by large teams fail so often

#8
Generally products built by large teams are large products. There are extra challenges associated with coordinating large groups of people, and there are extra challenges associated with developing big, complicated software products with lots of different subsystems that have to work together.

Hopefully no one is using a large team to build a small product. If so, yeah, don't do that. But you're going to get into different problems building large products with small teams.

Ultimately there's no silver bullet, the best you can do is maintain awareness of the tradeoffs, identify and deal with problems as they arise, and otherwise do the best you can to maximize the likelihood of success and minimize failure.

Sometimes people feel like they've found a silver bullet just by identifying the problems, in which the silver bullet is "well just don't do that then". In contrast, I feel like everything that's nontrivial in life consists of choosing from a set of compromises and tradeoffs. There's a natural tendency to feel the pain of the compromises and assume that if only we weren't making those compromises, everything would be great, without taking into account the tradeoffs and compromises that alternate approaches would create.

Re: Why products built by large teams fail so often

#9
I agree with and have experienced this situation. I've also experienced it more often with small teams (3 seems to be critical mass).

Having a product manager is key, even for internal products. You don't even have to call them a product manager. That person can be a senior engineer who knows what the system has to do to be useful in the company's ecosystem. Someone has to have the final say when there are decisions to be made about the direction/execution of development and feature choices.

Also, there must be a manager above the "product manager" who has the guts to kill the project or remove a poorly performing product manager. This seems to be a big factor in most of the projects I've seen go south.

Re: Why products built by large teams fail so often

#10
I agree with the article mostly, but one issue I've always had with product owners is the lack of willingness to lay the proper foundations for technical products to succeed. That can be anything from training and allowing developers to do a proof of concept before they decide on the technology. The importance of automated testing,code reviews, refactoring, etc.
Post reply on HN