First an announcement. I have jumped on the newsletter bandwagon and am on substack 🙂 It’s an easier way to consume content – you don’t need to come back to the blog week after week, my posts will arrive straight to your inbox. Subscribe here.

And now back to our regularly scheduled programming. Today’s topic: How should product organizations change due to coronavirus?

I believe that it is now more important than ever to prioritize speed over everything else. Every customer is undergoing a rapid change in their operating circumstances and you have to change in response. Shipping features faster needs to be the default. Over the years, as consumer preferences have sharpened and matured, most product organizations have shifted from MVPs to Minimum Marketable Product (MMP’s). However, COVID-19 is changing the external situation day by day.  Product teams need to shift back to MVP mode and ship features faster than ever. Execution speed is everything in this environment.

An underrated PM superpower that makes this shift possible is the ability to clearly differentiate between non-blocking and blocking tasks. This concept is very familiar to engineers – it is one of the basic building blocks for making a set of actions run faster. At a high level, you break down your activities into independent units and run those subroutines in parallel. Thus, in a fixed unit of time, you get more activities completed and your intended end result is achieved faster. Successful execution of this strategy is only possible if there is a keen understanding of what parts of your activities don’t depend on some other activity i.e. what parts are non-blocking and what are blocking.

Now as a PM, apply that same concept to the way you orient your entire team to deliver products to your customer. Since you are trying to speed up the process, what are the activities that can run in parallel, and what are the activities that have to be run sequentially? Good PMs can do this instinctively since they have a keen grasp of the finer details and nuances of the entire process to get to the final customer deliverable.

Can you learn this? Absolutely! Here is a framework to make this more concrete:

1. Start with identifying your key stakeholders who have to output work product to get this customer feature shipped. Examples are: the product team has to deliver a requirement specification, UX has to deliver designs, engineers have to deliver production-ready code, customer service has to update the customer FAQs, etc. Write down all the high-level outputs, this is your final deliverable list.
2. Then, focus on the work activities that each of these stakeholder groups need to execute on to develop the work product. This is your task list of things to get done.
3. Next, focus on the inputs that are required for each of these tasks.
4. Now, identify the list of inputs that come from other teams – this is your dependency list. This is also your list of blocking items. Everything else is a non-blocking task for right now.
5. Get going and start making progress. Make the blocking and non-blocking distinction clear to stakeholders so they understand the parallelism you are trying to achieve.
6. Checkpoint regularly with the team, rinse, and repeat.

If it sounds too simple, yes that is the point – it is really simple. This should be the default operating model  But let’s face it, it isn’t. Ever so often, we rely on someone else’s understanding of the details or of the process, which leads to non-optimal sequencing. The superpower is to understand the end-to-end,  instinctively, and at the right level of detail. This along with the superpower of dealing with ambiguity will make you an effective doer. Doer ninjas are what we need right now – it’s time to build.