Demote Your Product Manager, Release Better Software

When it comes to software, my second biggest pet peeve is software that doesn’t work. By that I mean software that blatantly doesn’t do things that it should fundamentally be able to do. For example, things like… I don’t know… like maybe changing the administrator password of the application to something other than “admin” without crashing the whole damned craplication until you reinstall it.

I don’t blame the developers. Sure, they write the code, but at the end of the day they’re not the ones who sign off on the release. I think it’s pretty rare that some junior developer says “We’re ready. Ship it!”, and only then will the product ship.

It’s certainly not the testers. Heck, does anyone listen to the testers or take them seriously? I do, but I think I’m in the insignificant minority there. No, it’s not them either.

It’s always the Product Manager that makes the decision to ship. Meanwhile the junior developer is jumping up and down in his cubicle screaming at the top of his lungs. “What are you idiots doing! It’s not ready yet! We still need to fix this bug over here which crashes the application 14.7% of the time, and the font size I reported as being wrong four months ago which would only take five minutes to fix STILL HASN’T BEEN FIXED!” Meanwhile, the senior developer next door has long since been hardened to such ineptitude sits back, drinks another cup of coffee, and checks the local weather for his kids soccer game that evening.

I remember being “that junior developer” and asking myself why we were shipping a product with tons of bugs that we knew about. Why couldn’t we just hold off just a little bit and fix the things that were out and out bugs? Didn’t anybody want to ship a product that actually worked the way it’s supposed to?

I’m specifically talking about bugs. I’m not referring to features that haven’t yet been implemented or are on the roadmap. I’m referring to actual bugs that cause the application to not work the way its supposed to and that we already know exist because they’re in the bug database. If some things are inconsistent or the fonts are wrong, big deal. I mean the stuff that’s kind of a big deal.

Shoddy software really gets under my skin. Over the years, I realized that the developers are actually the people who are the least responsible for these problems. Certainly, my experience is limited to the handful of companies that I’ve worked at full time. But, I’ve consulted for dozens of companies and I’ve never seen a company let the developers make the decision about when to ship a product.

This is just sad.

Unfortunately, product management generally makes the decision to ship and it’s my contention that this is probably the worst place to make such a decision. Here’s why.

Product management has the power to order a product to be released, but is not provided with the incentive to ship a good product.

There, I said what all of you were thinking and know to be true. Product managers, commence flaming.

If you look at the job description of a product manager, you’ll find that the intent is to make him the interface between developers, customers, the sales team, and management.

Developers are content to sit at their desks and bang out code day in and day out. They want to ship a good product. Their egos depend on it. Customers have demands of course, but the Product Manager  can balance them against the needs and goals of the company by putting feature requests on the roadmap and countering opposition by saying “It’s on the roadmap and our roadmap is dictated by the majority of our customers”. The customers want a good product too, but they also want new features.

Interfacing with the sales team is hard for the Product Manager. The sales team will do as much wheeling and dealing as is necessary to convince him to ship the product on a particular date and the Product Manager has virtually no incentive to do otherwise. It’s the squeaky wheel that gets the oil, and sales people squeak a lot.

The sales team has no direct power over the developers, so they leverage the Product Manager to get him to do their bidding. The sales reps are compensated on what they sell and it’s obvious that releasing a new version of any software will provide a boost in sales. Ultimately, this is good for the company and indirectly it is good for the Product Manager because more sales means the product is doing well.

With the management team, the product manager is between a rock and a hard place. He has no power to tell the management team “No, we’re not going to ship the product yet. It’s not ready.” His job is on the line and lets face it, nobody really enjoys looking for a new job or looking bad to their boss.

So products get shipped with bugs, the support team deals with the influx of calls, the product sucks,and we have the product manager to thank for it.

There’s a relatively simple solution to this problem. Make the product manager subservient to the development team. This isn’t going to sit well with Product Managers because they are currently autonomous for the most part. But if the Product Manager is forced to convince the developers that a product is ready to ship rather than the Product Manager dictating when it’s ready, then perhaps the software that gets unleashed to the rest of us will get a little better.

And isn’t better software the ultimate goal?