What should we be working on?

My favorite things to do on Winter weeknights are to watch NBA basketball, (thank you NBA League Pass), and plow though the seemingly thousands of unread items that accumulate each day in my Feedly feed reader. So in case you really care, and I am pretty sure you don't, this piece is being drafted (who am I kidding, on the blog there are no 'drafts', it is ship or don't bother writing around here), while watching LeBron and company take on Lance Haun's Portland Trail Blazers.

But I digress.This is not Lance Haun

While grinding through my Feedly looking for some inspiration for the blog, I came across this excellent compendium of product development prioritization techniques and approaches called 20 Product Prioritization Techniques: A Map and Guided Tour. The piece is a fantastic collection of strategies and methods that are employed by product managers and developers when faced with the fundamental and critical questions of 'What product features should we build?' and 'In what priority order should we build these features?'

Both questions seem kind of easy on the surface, but for product managers and leaders they are not only very often quite complex, but how successful product leaders are at answering these questions plays a significant role in how successful (or not), their product will be. Build the 'wrong' features and current customers may defect and acquiring new ones may prove impossible. Build the 'right' features but in the 'wrong' order and risk making customers wait too long for features they need and end up losing 'bake-offs' for new customers when needed product features are not yet available.

Like I said, simple sounding questions that are often really hard to answer. And really, really important to get right. 

That's where the list of the 20 product prioritization techniques makes for a really useful starting point not just for 'product' people, but anyone that needs to assess and prioritize work efforts from a range of options, or what always seems to be an impossibly long 'to-do' list. Let's pull one example from the piece and see how it can be relevant and useful for both product and non-product, (I suppose that is just 'service') leaders. This is one I liked a lot and I think also can be pretty easily applied to say any internal HR or talent function.

Technique: Feature Buckets

The Feature Buckets technique by Adam Nash is also very popular on Quora.

Adam believes that feature prioritization varies a lot across different product types and industries and that’s why he emphasizes that this technique was thought specifically for consumer internet products.

Feature concepts should be placed in one of four buckets:

• Metrics Movers — Features that will move the target business and product metrics significantly. There should be specific goals and strategies behind the decision to invest in a product or feature (things like AARRR metrics come in handy here);
• Customer Requests —  These are features that have been requested directly by customers. They are usually incremental enhancements, but it’s important to consider them or else risk alienating users or miss important feedback coming from their usage of the product;
• Delight —  Innovative features that are internally generated based on insights in design or technology. Working on surprising and exciting features is important to delight customers and create a differentiated position in the market (c.f. Kano Model for more on this);
• Strategic – Features that are included for strategic reasons related to learning or future goals (e.g. experimentation and data gathering.)

A well balanced product release should typically include features from all of these buckets. The framework is not explicit as to the appropriate distributions among these buckets and to how to prioritize internally within each. These implementation details are left up to the Product Manager to define.

Breaking down the four components or buckets helps us see how if you could consistently deliver across all four that you would have an increased likelihood of customer (both internal and external customer) satisfaction.

In this technique you address your fundamental, internal goals, (the Metrics Movers), as well as direct customer feedback, (Customer Requests). But you also showcase your innovation, and give your team opportunity to work on exciting stuff that your customers will be surprised by, (Delight). Finally, you continue to strengthen your position as market, product, and service leaders by building towards the future, (Strategic). 

And I think you could just as easily apply the Four Buckets approach to any HR or Talent or Recruiting organization's quarterly plan as you can to a product development organization's list of potential features for the next product release. 

If you are in product management, or just have the important, (and tough), job of figuring out what the organization should be working on today, tomorrow, next week, next month, etc., take a look at some of the prioritization techniques in the above-linked piece.

No one can do everything we are asked to do. The most successful organizations know this, and they get really good at deciding what to do and what not to do.

Ok, I am out. 

Back to basketball.

Have a great day!

The problem with deadlines

Is that, all too often, they are completely one-sided.

When I need something done, answered, actioned, or otherwise handled is almost certainly not perfectly aligned with how you would like to accommodate my request, (or to spend the time to take a decision to actively not accommodate the request).

My, 'I need it by the end of next week' has to be translated into the language of your workflow, capability, availability, and most importantly, that mental list of the things that are ranked in order to their importance to you, (and that I almost definitely am not aware of).

I can ask you if it is reasonable if I can have that thing by 'End of next week', and you will likely tell me 'Sure, not a problem' because when looked at on a Monday or a Tuesday 'The end of next week' seems like forever away from now and the commitment to deliver seems so far afield from the promise that I would think you kind of incompetent if you simply said 'No'.

I think a better question than 'Can I have this by the end of next week?' or its close equivalent, 'About how long will it take before you can turn this around?' would be, "Where is this item on your priority list?' or 'Assuming you had everything you needed to work on this, when would you actually, you know, start working on it?'

I think it is much more important for the requestor to know how the person being asked to do something actually has the item prioritized and importance-ranked in their own mind than the often irrelevant 'How long will it take to complete?' angle.

It almost never matters how long something will take to complete.

What matters is how motivated you are to start.

Have a great week everyone!