How to f*ck up a great product in 2022

Spoiler: the same way as in 2020, 2015, 2010, 2005, …

It’s 2022 and I attended yet another awesome product that was not yet scrapped and will hopefully shine in the future. But until now it followed the same recipe of how to run a simple but awesome product concept into the ground.

And it’s always a people thing.

This time we have a well-founded PropTech Startup with a (for this overly conservative business) great idea.

After an initially already long period they released a version of their product. Afaik it worked, producing income.

Then they decided to replace the product and the system behind it. Not migrate, no parallelization: replace. All of it. tech stack, concept, and in the end, the team.

I often do this when I get bored with a video game, lately the new Total War: Warhammer. Just restart the whole thing. But that’s a game, not real life.

Also when restarting a video game you usually do it while learning something from the previous playthroughs: which mistake to go around, or which problems to take care of then and when.

Not this time.

This seemed to be a greenfield product based on an already available product and its ideas and concept while ignoring it.

And an actual dysfunctional team because of a small missing part: there is no actual lead for this type of development.

Yes we had:

• A tech “lead” with a great conceptional vision, but without any noteworthy hands-on coding skills (which is not necessarily required), people skills, team-management skills, or a view for short-term goals to reach the bigger vision. Not being able to communicate with the whole team on a level that is necessary for this. But instead follows back door diplomacy with his favorites.
  He is maybe a good Solution Architect, but no dev lead in my book.
• A motivated team of developers, but without an actual lead to looking up to. Or actual deeper knowledge about the overall system concept. And with this, small motivation to go the extra mile and just do what they are told to do.
• A bunch of external developers where you can’t expect any deeper binding to the product (by nature) and so actually only doing what they’re told to do without questioning.
• Dysfunctional project management with either too many tasks or too less. Too much (self-proclaimed) responsibility or not enough (thanks to low self-confidence). Which ends up that they couldn’t do the simplest concept preparations. This is required so that the developers actually know what to do.
• A lot of time and money so that this was a big playground without real repercussions

Until the actual “Big boss” (the cash cow) said they wanted to see the actual product the team was working on. Remember? The product was scrapped and started a new one not long ago.

And so the whole house of cards started to collapse and ended at the moment like any similar run downed product:

I’ve seen this representation of product development in the above image 15 years ago for the first time (i think). And I believe it was already an old joke at the time. Old, but true. And still true.

As Tom DeMarco described it in “Peopleware”: the biggest problem in product development most of the time is not the tech or the product. But the people who are working on it.