The Worst Product Meeting Ever

Photo by Icons8 Team on Unsplash
Photo by Icons8 Team on Unsplash

The title might be some hyperbole but a while ago I listened in on a product meeting that was eye opening in the sense that the bureaucracy explains why the product is in the state it is in after investing substantial amount of time in developing it. It was also a cautionary tale for every product and company I’m involved with going forward.

The meeting was a state of the union on the status of a project that had been in development for about a year but been talked about for a few. It also happened to be one that I think is the future of the business.

I pictured the product as having seven different sails all pointing in a different direction. Not making any progress anywhere but eventually one might get a big enough gust of wind that the only outcome will be capsizing.

This is a product that the high level management wants done so a lot of people are hitching their wagons to it. They hope it succeeds so they can get the feather in their cap but nobody is taking responsibility for its success. There is not a true, single project lead as everybody wants to have a say in every decision but the project is not the primary focus for anybody.

Without proper delegation nothing will get done.

The technical guys explained their choice of platform (there had been no discussion or due diligence done on this prior to development) not in terms of advantages but one which would result in the least amount of work for them when somebody wanted a report ran.

One person was not interested in what the product did only that they were able to harvest data from it for sales pitches.

It was very, very briefly acknowledged that in its current state there is no reason for anybody to use the product (one single user had logged in and used it in the lifetime of the product) but that was not deemed to be important enough for more discussion.

At no time were the actual needs of the users brought up.

As far as I can tell nobody ever asked, “What problem are we aiming to solve by building this product?”

I have no idea what the official takeaways were from the meeting. However some of my takeaways were:

  • Software is not a collection of features but a vision. Every decision that is made must contribute to and support that vision.
  • For users software is a tool used to achieve something. They do not care about any features that do not help them achieve their goal.
  • You cannot design a great product by committee. While many people may contribute, at the end of the day there needs to be a single, specific person who is the keeper of the vision and the arbitrator of all product decision.
  • When company leadership creates a product directive there are going to be many people trying to get the feather in their cap for moving it forward. Progress will drown in meetings and any that is made will be questioned and likely abandoned.
  • A meeting must have a specific, and written, agenda. When something comes up that isn’t on the agenda make a note of it and put it on the agenda for the next meeting.
  • A culture of open feedback is important. Every employee who touches the software or interacts with users is responsible for reporting bugs and passing on feature suggestions.
  • Always think of the user. If you cannot put yourself in their shoes with every decision then you’re going to lose them by creating something that does not address their needs.

There are many reasons a project can fail but if bureaucracy is unavoidable then it needs to be carefully managed otherwise an even worse fate can occur. That being a failed project that continues to consume resources as nobody will let it die.