Product Prioritization or how to be a curator

I am reading the wonderful Rework. One topic that stands out for me is their emphasis on being selective on product features. They basically argue that building a good half product is much better than having a half-ass whole product. How true!! but what causes a product to end up being the latter and not the former? No one intentionally starts with the goal of building some thing mediocre.

So what cause products to bloat?

One of the best explanation I came across is a blog post called “Product Strategy Means Saying No”. It enlists the arguments product managers and executives use to add more features to the product. I myself am guilty of making “But our competitors already have it” argument without completely being able to justify why it’s important to have all those competitors features.

If I would add one more argument to the list, it would be “Let’s hack this quickly NOW so we look cool then we’ll fix it later” and “Later” never comes. This is called “shiny object syndrome” but once the hacky feature looses its coolness and some other cool thing pops up suddenly no developer has the time and willingness to fix it. Users and customer support are forever stuck in a loop with this piece of crappy code.

How to avoid building mediocre bloated products?

If you’re building a new product, assuming that you have identified customer pain points start with the core one. What I mean is that the founder (which in my mind is really doing product management) must have a system to identify out of all identified pain points which one is most important one to address first. If the founder has experienced these pain points herself and has observed how users currently dealing with these paint points, it should not be difficult to figure out what is the most pressing issue to fix.

Much has been said about “Lean” methodology but in my mind it all comes down to figuring out the burning problem and build core functionality to address that problem only. This will be the product’s epicenter and as the product is being used by customer it will grow and evolve. But this approach create the main building blocks that ultimately create an awesome half product that solves one problem and does it very well!

What about mature products that have been around for a while? The ones that still provide value to the user but they’ve been so diluted that it’s hard to pin point its usefulness. I’ll talk about that feature audit and prioritization methods to fix these type of products in the next post

Leave a Reply

Your email address will not be published. Required fields are marked *