Product Management in a Crisis

Dumb Analogy GuyLeave a comment

So I’ve been pretty scarce lately. You’d think that being trapped at home during a pandemic would lend itself to a lot of extra downtime. Instead, I find that I’m busier than I ever was when I was going into the office. Not only has the mechanics of a workday changed, but with the impact of the virus changing on a daily basis, free time seems to be at a premium these days.

To help me get a better perspective on work, I joined a local meetup to talk with other product people about how day to day product management has changed in the last couple of months. What became clear is that a lot of “facts” are now being questioned. Whether it is where you can work effectively to how you do discovery, everything is changing and people are working hard to adapt.

As I looked for ideas on how to lead my team through this change, I found a great article that talked about how software companies need to think about product management and how sudden changes in society force different behaviors.  The author used the analogy of Peacetime vs. Wartime and Driving on a highway vs. driving on a mountain road.  While I get where he was coming from, the “war” analogy can be too much for some. Perhaps there is a slightly different way to think about it.  

Here’s my spin:  Normal vs. Crisis Product Management

We’ll stick with the concept of driving on the highway, but let’s consider how you drive on days where the weather is perfect (sunny, dry, etc.).  Your focus is on your destination and you plan for getting there in the fastest time along the most convenient route.  Basically, you can set the cruise control at 75 and see traffic and road conditions for miles and you have plenty of time to react to any change.   This is Normal Product Management.  

Now what happens when you drive into a sudden thunderstorm?  You drive differently right?  You still think about your destination and you still continue to drive, but your focus changes.  You lose that great visibility and may only be able to see a few feet in front of your car.  You probably slow down a little, because you  want to, but also you assume traffic dynamics have changed as well.  You have to start making assumptions about the road, the other drivers, and possibly how long this storm might last.  You probably also start valuing other things that you may not have needed as much before – your wipers, road signs, etc.  You know you needed them before, but now they are critical to your ability to continue driving.   In this case, you are still trying to get to your destination, but for a short period of your trip, you know you’re going to have to focus a little more on the next 30 miles than you had planned.  

This is product management during a Crisis. 

We aren’t picking a new type of road or in product’s case a new strategy. We aren’t changing what we are doing or our best practices, but we do need to recognize that we need to change our horizon-focus and priorities for a period of time. 

The Debate Over Product Roadmaps

Dumb Analogy GuyLeave a comment

So if you want to start a fight among product managers, throw out the word “Roadmap” and then just step back. People seem to have incredibly strong feelings about the value and necessity of Product Roadmaps.

The Argument for Why Roadmaps are EVIL:

From what I’ve seen, those in the camp of “roadmaps are evil” come at it through the lens of past traumatic experiences. At one point, they lived in environments where the culture was held hostage by the content of the all-powerful Roadmap. In these cases, the Roadmap absolved people from making decisions and was a sacred, unchanging source of truth. If asked what was going to done by a team and when, people were pointed at the Roadmap. In turn, the dev teams and product managers were evaluated on their ability to deliver against the Roadmap.

Regardless of the market dynamics, customer reactions, or the fact that assumptions in January are different than facts in June, the Roadmap was an unwavering, unchanging artifact.

If I lived in that sort of environment, I probably would never want to use a roadmap again either. You are setup for failure because you are penalized for learning, adapting and improving.

My guess is that the Roadmap isn’t the only “evil” thing affecting the product teams. Most likely, Jira is hated as well and they have probably burned through a few “transformations” where they tried out Scrum and then Kanban, JTBD, Lean UX, and any other framework-of-the-moment. These are places that love dogma and where tools and frameworks are brought in to define behavior vs. improve outcomes. In these places, there are probably more pervasive cultural issues, like the old saying goes “a poor workman blames his tools“.

The Right Way to Treat a Roadmap – A Tool to Help Manage Change

I am convinced, when used properly, the Product Roadmap is an incredibly useful tool and one of the key foundational artifacts in a healthy product culture. Before you build a product roadmap, you need to have an articulated product vision and strategy. These are the “what we are trying to accomplish and why”. The product roadmap then provides you the “how”.

Like any tool, it doesn’t solve every problem, but when used properly, it can help everyone in the company understand:

  • What are the most important customer problems we are trying to solve (by team).
  • The sequence of problems we are going to focus on.
  • The estimated effort it will take to build these solutions.
  • Level set the company on when we will be able to solve particular customer problems.

What’s important to point out to everyone is that the Product Roadmap will CHANGE because its always a perspective based on a specific point in time.

When you build your roadmap, you have to include the set of assumptions and priorities the company had at the time of it’s creation. Simply put, the roadmap is your company saying “Based on what we know TODAY, this is what we think we will do in the FUTURE.”

With that statement, you acknowledge that the moment after you define your roadmap, it is subject to change. As you learn more through product discovery, as your sales team works with more prospects, as your competitors develop additional features, as the economy changes, those assumptions you made are also changing. By having a product roadmap, you can take each one of these changes and hold it up against your roadmap and ask the following questions:

  • Does this new piece of information change one of our assumptions? If so, what is the new assumption/fact?
  • Does this new idea help us achieve our goals faster, better, easier than what we have on our current plan?
  • If we say yes to the above, what will we stop doing to accommodate the new thing?

In this world, the Roadmap is a living, ever changing document – a record of learning and adapting vs. a list of stuff to be done.