Lenses for the three P's (Problems, Plans, Prioritization): Prioritization (3/3)

In case you missed last couple of weeks, this is a three-part series I am doing as I approach a kind of milestone with the first hundred posts with this blog. Here are the first part and the second part.

Now, to talk about prioritization I need to first simplify and take a big assumption out of the way. Because that alone would take a full or even a couple of posts, and that's not quite the angle I want to take here. Some of the things I want to avoid speaking about today I have in fact articulated before, but there's more that I am intending to do shortly. But not now, not here.

For the sake of this post, I am taking value for granted. Or to be more precise, assuming that we can sufficiently upfront precisely get a good sense of the value of something we can prioritize to do.

I know this is a big assumption and that turn some of the issues of prioritization obsolete. But bear with me because there's a good reason for it (and spoiler alert, I will largely anyway debunk the idea of prioritizing by upfront estimated value in the yet to come shortly couple of pieces).

For now, let's assume we are not (that) wrong when it comes to figuring out value upfront, and thus we have a bunch of good options to potentially pursue. 

Remember the first part, for as long as we haven't pulled yet something to doing, they are just 'options'. And we want to keep them that way for as a long as it makes sense, so that we can rather focus on managing risks with the 'liabilities' (currently WIP) and, even more importantly, understand whether our 'assets' (what has already made to users hands) are valuable.

The above give us a hint on ultimately what prioritization, at least from an execution angle, boils down to:

• What we could start and in what order (hopefully guided by value) – Prioritize order/sequence.

• The very next thing we can start (as capacity becomes available) – Prioritize next.

• What we should finish first after started – Prioritize WIP.

I'm guessing so far, so good, it probably makes (some) sense for you. But here's the thing, just like I pointed out in the first part with respect to managing risks, the same is largely applicable here:

We tend to invest way too much time talking about and ordering our next options (what to potentially we could pull to work later on). Then, perhaps more time than we should on precisely and upfront selecting the first in line (so the next one to be pulled to WIP), when a conversation in context that should take a couple of minutes in the moment should do the trick. And not nearly enough time talking about driving things that are already WIP to the end.

So we seem to have gotten it upside down, as illustrated below.

And that's about as useful and the only lens that I consider, from a very practical point of view, should guide prioritization: 

Focus on prioritizing WIP, make decisions of what to put next in the context of the most recent learnings (so at the moment before pulling to work on), take ordering the rest of the options at best as just a directional insight on what we think we should validate in (near) future.

To be clear: with that, I don't mean at all that all the attempt to get a sense upfront to estimate potential value is worthless. It just that it needs to be taken in probabilistic terms (which will be the focus of the previously alluded couple of pieces on the matter). Meaningful conversations is what we are after at that point anyway.

In the end, and to put it bluntly, the insight I am alluding here points out to how anyone responsible for prioritizing work (like PMs for products, for instance) should be obsessed about flow. About working in a process that has low WIP, so that what determines what goes out first is really active work prioritization (i.e., prioritze WIP), and not other factors like size of batches, for instance. 

Put in other, perhaps better words, they should obsess about validating whether the value which was estimated upfront is any close to what we truly got after something became an 'asset', and about driving the things to the end after starting (having flow; transforming 'liability' into 'asset' as fast as possible). And there's a very practical advice on how to influence it from your role of prioritizing work, but I will leave for that upcoming piece on value (hint, to not leave you fully hanging: it has to do with size).

I guess I just launched a kind of sequel series… 🙂

By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.