The Balance Between Quality & Speed in Product Development

Posted by | January 16, 2017 | Enterprise Software, Startups, Technology | No Comments

I’m going to make some controversial statements in this post regarding product management. If you’re currently a product manager, I’m sure you’ve been peppered with the “do this! don’t do this! you’re a bad PM if you do this! 10x PM’s do this!” rhetoric. Honesty, it’s exhausting. Earlier in my career, I read a ton of books on how to be an effective product manager. What stuck out to me is that these books often pushed opposite agendas – sometimes even within the same book.

Having gone through some of my product management career thus far, I’ve realized that there is no silver bullet to doing a good job. In fact, it largely depends on where you’re at in the lifecycle of your company, the industry, the team you’re working on, etc. These books often write about a set of criteria PM’s must meet. They pain the picture of a panacea outcome if you do these 10 things. That’s never the case.

What I learned early on (and quickly) is that there is a very hard balance between delivering high quality products and delivering them in a very rapid format. These aren’t mutually exclusive but they are very hard to balance. Sometimes they shouldn’t be.

For example, let’s say you’re losing a ton of business by lacking a major feature set. The company has put it off for too long and it’s now a top priority in order to help sales to stop losing in competitive deals. To create a feature parity product would take you a minimum of 9 months. Looking backwards, you know that you’ve lost $900k in the last 9 months to competitors because you lack this feature, so it’s safe to assume that over the course of this entire development of 18 months, you’ll lose $1.8M.

Do you build as fast as possible and ship something “good enough”? Do you go for a high quality product and release later?

Personally, I’d opt to release something that is barely good enough. Something that is almost embarrassing but paints the vision, dream, and demonstrates that we can accomplish the basics of what our competitor can do, refocusing the sale back onto features that you crush competitors on.

On the other hand, let’s say that you’re trying to leap frog the competition. Time is on your side and the feature you’re developing is very complex with a high barrier to entry from a user experience perspective. You know that if you ship early, its going to have little to no adoption which will make iterative testing and development challenging since you could be stuck building in the dark.

Do you build as fast as possible and ship something “good enough”? Do you go for a high quality product and release later?

In this scenario, I’d say build a high quality product with lots of UX/UI iterative testing, prototypes, etc. before you commit to engineering on it. This is going to take a lot longer but you know that by doing this, it’s going to make the adoption a bit easier. Plus, you’re confident you have time on your side since you’re blazing a new path through a different aspect of the market.

My opinion is this: product management is a case by case job description. There is no silver bullet method to building great products because every company is in a different place. A super fast, agile, and “release often” approach may not be appropriate for monolithic, highly audited and complex industries. A PM must understand the vertical and adjust their style to match the most effective form of delivering product in that organization.

This isn’t to say that the paradigm can’t change over time. Often times, it’s the product department helping create ways to be more efficient and deliver products in different ways. However, these things don’t happen over night and require a flexible product management style.

As the title of this post suggests, it’s a constant battle between delivering very high quality products and delivering products very fast to the market. They’re not mutually exclusive by any means, but rarely (in the real world) is the environment setup to enable both to happen.

Leave a Reply

Your email address will not be published.