Category: priortization

  • A neat technique to manage product requirements

    I came across this awesome video from Ryan Singer via Mind the Product blog and I just couldn’t pass up the opportunity to share it. It’s a neat method to categories a million items that comes up during product development. It talks about identifying and decoupling ‘orthogonal’ tasks. This means you find tasks that are independent of each other (doing or not doing task  A doesn’t have a prevent you for doing task B) put them in separate bucket/category. If use find another task (say task C) needs to be done after task A then A and C belong to one bucket. By the end of  this exercise you have a couple of different buckets (look at the image below) that are all independent of each other. Within each bucket though there are a sequence of tasks that are related together. The great think about this technique is that it helps you, as a Product Manager to be able to focus on the most important bucket on at a time and delegate another bucket to another group.

    I loved how simple, short but super powerful this can be! Enjoy:

     

     

     

  • 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