Planning, or Postponing? Stop Running Away from the Market.

Planning, or Postponing? Stop Running Away from the Market.

 m

Organisations spend a lot of time in planning activities. The motivation is often accuracy and certainty. In a world where certainty is a rare sight, are these activities postponing the road to value?

Product Managers and Developers (or the equivalent roles) invest a lot of energy and time to prepare for and participate in planning activities. The motivation is clear: people constantly chase clarity in the face of uncertainty. Think of the following activities:

  • Refinement
  • Pre-Refinement
  • Estimating
  • Triaging
  • User Story Writing
  • Roadmapping
  • (Sprint / Quarter / Yearly) Planning

Many of the teams and organisations I have worked with employ at least one of the above, and I am confident that a combination of these activities is generally implemented in organisations.

In contrast, how much similar energy is invested in validating what they are building?

By validating I mean, how often do organisations take their work outside of teams, bouncing it with stakeholders or real customers. My guess is little to none.

As a matter of fact, in Scrum, or Scrum-like environments, how often do people do Sprint Reviews with stakeholders?

My experience is, once again, very rarely.

Organisations are often happier planning or preparing rather than discussing “half-baked” artefacts. Many still aim at waiting until they can launch the perfect thing. As a result, Sprint Reviews, or similar, are more easily cancelled or postponed (or maybe never thought of) than Sprint Planning.

Accelerating Your Path to Product Value

My view of accelerating product value is based on 3 simple points:

  1. The organisation’s sense of entrepreneurship - i.e. the organisation’s approach to risk, learning, and strategy;
  2. The organisation's value creation and delivery – its approach from ideas to results.
  3. The practices employed within the organisation in enabling the above.

In what ways can an organisation accelerate its value (or fail to) based on its practices?

When we talk about practices we understand that there are always options an organisation can choose from in order to satisfy its process needs.

The need for roadmaps, for example, is to communicate future paths for the product. This is a perfect example to how choice of practices can impact the organisation’s path to value, and it’s the example I am writing about in this series.

Roadmapping is a central task of product management, and often it is a burdensome activity for product managers in many organisations.

In my eyes, there are 3 actors in this story which I will portray in this post:

  1. The Market - here referred to as the Big Bad Market. This is the ultimate validator of work.
  2. The Product Manager - who acts on behalf of the organisation and strives to communicate internally as well as influence the path of delivery.
  3. The Organisation - who at the end of the day is the one who gets the biggest impact (for better or for worse) and is the one who pays the bills.

The Big Bad Market

Whether we like it or not, the real star here is the Market, or the Big Bad Wolf: the merciless market demanding products for validation.

Here’s why I liken the Market to the Big Bad Wolf:

  1. Brutal - The Big Bad Wolf will either engage (by buying it or participating in it) with a product, or it will not.
  2. Unpredictable - The Big Bad Wolf will act unpredictably, even when it declares its preferences in user surveys. It might tell you it likes a feature and never uses it, and vice versa. It might behave one way, today, and completely differently tomorrow.
  3. Impatient - If the Big Bad Wolf knocks on one’s door needing a product, it will not wait.

The Wolf in this story, the market, does not eat up the organisations who succumb to his visits. Instead, the Wolf will simply ignore and move on to the competition. The ending is deadly nonetheless.

That is why in any organisation, the real star of the show is always the market. Whatever practices an organisation puts in place, it needs to keep in mind the urgency required to handle the Big Bad Market.

So back to the roadmapping topic, how can an organisation’s choice of roadmapping practice impact its success in validating with the market?

Long Term and Rigidity - Running Away From The Market

In many cases, organisations demand roadmaps depicting a long term picture of the product’s plan, describing months, if not years, of work - at times in detail. In this story, those roadmaps are “cast in stone” or “carved in wood”, i.e. laborious to put together, and almost impossible to adapt.

What’s the problem with this approach? Long, fixed roadmaps assume that nothing will change from what is known today. In other words, we expect the Big Bad Wolf to be kind to us and wait until we are ready, and to receive our product as we assume it will.

In practice, however, we know that this is exactly the opposite of what typically happens.

With every decision taken during the course of “cast in stone” roadmaps, organisations pile up their bets, leaving it up to the brutal, unpredictable and impatient Wolf to validate when the stakes are too high for the organisation.

Roadmaps “carved in wood” are those worked in smaller iterations while maintaining traditional approaches to roadmapping. While presumably more responsive, these are heavy to maintain. The impatient Wolf will always knock on the organisation’s door every day, providing its validation to the artefact presented which will trigger a roadmap rework.

A new dependency might require you to shift around a number of boxes in the project’s Gantt chart.

Eventually this becomes so costly to product managers that they either abandon their efforts in updating the roadmaps, or slow down the innovation rate.

The Big Bad Wolf will never give a damn, and will simply move on to the competition.

Playing the Game - Embracing the Big Bad Wolf

What we have learned from “cast in stone” and “carved in wood” is that to successfully interact with the Big Bad Wolf, organisations need to be nimble and flexible in their validation game.

Not only do organisations need be open to feedback, but they need to operate in ways that enables them to respond to it while it is still valid. Even when a validated artefact spells out failure, organisations need to be able to rebuild on that failure in time.

We can go a step further than “working in iterations”, and revise the roadmapping approach by first understanding two things:

  1. That it will deal with small changes
  2. That it will deal with a lot of them

These two points already call for a different approach at roadmapping.

Roadmapping Revised - From Plan to Flow

Any alternative to roadmapping practices needs to provide the vast variety of stakeholders with a visualisation of ongoing and future work for a product.

But what we have hopefully come to understand by now is that a product will continuously change based on the feedback received by the market.

That is why rather than talking maps, we propose options that approach the roadmapping problem from a flow perspective, i.e. ones that not only show the present and the future, but also the possibilities of emerging change.

Option 1 - Now, Next, Later

Now Next Later (NNL) is a light-weight approach at building roadmaps. All the work is grouped into these 3 categories:

  1. Now is what is being actively worked upon. We do not want to dump everything on this category, so the amount of items sitting here are typically controlled.
  2. Next is a pool of potential work items to be taken up next once the Now category has space.
  3. Later is a pool of work items that are in the organisation’s awareness but still very far away from being worked upon.

So with this approach we can tick a number of boxes required by traditional roadmapping techniques:

  1. A showcase of what the organisation is currently focusing on (the Now)
  2. The options that can be explored in the near future (Next and Later), leaving enough room for discussions to influence the product’s next steps
  3. Work items can have additional information attributed to them, s.a. dependencies and risks

Is that it?

Short answer: No.

Long answer: There is so much more we can discuss on this topic and so many other options to consider, but I would like to stop here for now so to give you enough time to try things out and let them sink in.

In the next article I will share Option 2, which builds on NNL and goes one step further in terms of simplicity.

But before we do, here’s a question for you -

In what ways would NNL simplify your current roadmapping needs? And, in what ways does it still not satisfy those needs?

I look forward to your thoughts.