A toolbox for digital transformation, part 2: Navigating with incomplete information and moving targets

Does the world change faster now than it used to? Looking at the advances of society and technology during the last 100 years, the answer seems to be no. The rate of change has been on a high level for a long time, and is likely to stay that way. In this context it is surprising to see companies still operating as if the environment was known and unchanging. Of course, every organization needs to be able to plan its work. But practices such as detailed project plans, yearly budget cycles, and multi-year strategies are not well adapted to uncertainty and change. So what alternatives are there?

In this post I am going to explore a few highlights from modern product management (for lack of a better term), an approach made popular by entrepreneurs and writers Marty Cagan and Eric Ries, and adopted by many tech companies. It is not a framework ready to use or a certification you can get, it’s more like a label stamped on a set of concepts. The area has an active community of practitioners and is still evolving rapidly. I'll only scratch the surface here, but there is a reading list at the end of the post if you'd like to know more.

How is this related to digital transformation? First, digital always involves software. And software, due to its nature, is exceptionally difficult to succeed with using traditional project management tools. “Plan the work, work the plan” does not have a good track record here. Second, if the motivation for doing a digital transformation is to be digital savvy and fast moving like a tech company, then you’ve got to adopt the mindset of the tech companies, not just copy what they do. So let's start with the mindset of thinking in bets.

Thinking in bets

No business initiative is risk free. Things can always go wrong. And the further you go into new and innovative terrain, the higher the risk. That is why it is helpful to think of business initiatives as bets: everybody knows that a bet may or may not work out, and that the outcome isn't entirely in your control.

How much are you willing to invest in an initiative? How much do you have to gain from it? How likely is it to succeed or fail? How long until you will know? – these questions come naturally when thinking in terms of bets. That is a good thing, because you want to know what you are up for.

You can work with bets and shape them before you take them on. If a bet is too risky, you might want to do some research to de-risk it, or ensure that you have fallback solutions if new innovations don't work out. Building prototypes or even product are valid options, too, just be aware that these are the most expensive ways to gain information and usually shouldn’t be your first choice. A bet which is uncomfortably big in terms of effort can often benefit from down-scoping or at least slicing into a sequence of smaller bets. On the other hand: if all your bets are small and low risk, maybe it’s time to raise the bar and look for bets with higher returns? If you can't make the bet appealing enough, it's probably best to drop it and move on to the next. In my experience, there are usually more ideas and opportunities than there is capacity to execute on them.

Thinking in terms of bets might make you uneasy. Professionals don’t gamble, do they? Consider this: every time an R&D project, an IT project, or a marketing campaign is launched, what is this if not a bet? No matter how well prepared, in the end it will still be a leap of faith. There is even scientific backing for the thinking-in-bets mindset. Kurtz and Snowden studied leadership and decision making approaches in different contexts for their Cynefin framework. They found that a complex domain, which is often what you find in business, does not lend itself to fail-safe business plans with defined outcomes. It requires a more experimental mode of management.

Obsessing about customer value

Many companies, for example Amazon, take every opportunity to say how much they care, or even obsess, about customer value. Interestingly, this is not only a matter of philanthropy, it is also a strategy to ensure that product development stays on track and a way to mitigate risk. Let's see how.

A product, be it a physical item or a service, is nothing but a vehicle to deliver value to customers. Getting the product right is of course important, but too much emphasis on the product can be a dangerous trap; you might end up with a solution looking for a problem. And that is certainly a hard sell. Clayton M. Christensen’s Jobs-to-be-done model can help get the product right: the idea is that the customer “hires” your product to get a job done, and will be more or less satisfied depending on how well the job is done. It is a powerful concept, because it covers not only to the product offering, but also to the positioning – what the customer thought she was buying – and pricing – the customer’s perceived value for money.

If a great product is only part of the equation, what else is there? Product manager Nils Davies has a deceptively simple model of a product business consisting of three boxes: the customer need, the solution (product offering), and the go-to-market. The customer need box is, well, just what it says: the customer has a want or need important enough to spend money on solving. The solution box contains everything it takes to design, build, operate and manufacture the product. The go-to-market box contains everything it takes to get the product into the hands of the customer: marketing and sales, distribution, positioning, pricing, and so on. When you first manage to check all three boxes at the same time – not only in a business plan, but working in the real world – you will have reached product-market fit, and should start to see some substantial growth. Then, as your product grows and matures, you will need to keep all three boxes checked throughout the growth journey.

It is insightful to look at the three-box model from a risk perspective. The product offering is mostly in your control. The laws of physics still apply, and your budget might not be infinite, but in the end it's up to you to design and build the thing. The go-to-market isn't exactly in your control, especially if you work with channel partners, but at least you have options. But you have absolutely no control over the customer need, and that makes it the riskiest part. A good reason to obsess about customer value!

The good news is that there are good, proven methods available to work with customer needs and value. I can recommend the methods described by Osterwalder and Bland, because I find them easy to get started with and at the same time they have depth. Some of their key components are:

• Visualization. The value proposition canvas and business model canvas formats help to structure information so you can see how it fits together, identify gaps, and so on.
• Making assumptions and facts explicit. This applies to anything that is important for the business model or value proposition. What evidence is there to back it?
• Treating lack of evidence as a business risk. Work to reduce the risk until you reach a level you are comfortable with; the authors offer a toolbox of methods in their book.

Moving forward step by step, with tactical course adjustments as needed

“Driving is not about getting the car pointed in the right direction. Driving is about constant adjustment. A little this way, a little that way, forever. You always pay attention. You are always prepared to change things.” -- Kent Beck

Kent Beck’s driving analogy might not hold up against self-driving cars, but at the time of writing this post it was still as relevant as ever. It was originally written for the Extreme Programming framework, and is just as true in the context of product development: while the high level vision/strategy (the place you want to go) stays mostly fixed, there are small tactical decisions to be made all the time.

We know that our initial plan will likely be based on flawed assumptions. The environment we’re operating in is likely to change. That is just how it is. So we need a process which can cope with change, that is, a process with tactical course adjustment built in. Sounds complicated, but it can be really simple: instead of doing detailed planning far into the future, work with a coarse plan for the long term and a detailed plan only for the near future. Run a planning session every now and then to revise the outline plan and come up with new detailed plans. This is known as “rolling wave planning” in traditional project management, and you can see the same pattern in e.g. Scrum. How often do you need to replan? It depends on the level of detail and how fast the environment is changing. How far into the future is it meaningful to plan on a detailed level? In Scrum, where the work items are on the feature/story/task level, the planning horizon is usually between two and four weeks. A product roadmap, on the other hand, might use quarterly updates.

Given that we can make course adjustments, how do we know if we should, and in which direction? We need sensory inputs to guide us. Again, sounds complicated, but it doesn’t have to be. Digital products offer some convenient, fast, and inexpensive ways to collect input, but many of the techniques can also adapted for traditional products. For example:

• User testing. Give users tasks to perform with your product and observe them as they work. This can be done at any stage from design sketch, to prototype, to final product. It addresses questions like: Can the users figure out how to use it? Does it do the job for them?
• Event tracking/telemetry. Collect and analyze (anonymous) tracking data from the usage of the product. How much are the features used? Are they used the way you thought they would be?
• A/B testing. Instead of rolling out a new feature to all users at once, start with a random selection of 10% or so. Compare the tracking data from this group with the rest. Did you get the results you expected to see?

Usually there will also be input from the development team to consider. It is quite normal to run into technical challenges, even for an experienced team. And sometimes the code base will need some maintenance work to get it in shape for further development. There are two important factors to let this input surface. First, to finish work all the way to shippable product and not leave it at “80% done”. Because getting it to "done done" sometimes turns out to be surprisingly difficult. Second, to foster a work environment where the team can be transparent and honest about progress and difficulties without fear of repercussions.

The process described here is basically what is known as a feedback loop in control theory. It is a proven way of working in an uncertain and changing environment. It may feel like you’re less in control when there is no big project plan to check off work packages from. But in reality this way of working gives you more control, because you can see where you are going and you have more options. In the end it’s the outcome that matters, not the output – delivering value to customers here and now, not delivering according to a plan set sometime in the past.

As a side effect, it turns out that working in small increments has a strong, positive effect on efficiency. This, and automation, will be the topics for the next post in the series. Stay tuned!

First article in the series – Previous article in the series

Note: Opinions expressed in this article are my own, not necessarily those of my employer. 

References:

• David J. Bland and Alex Osterwalder (2020). Testing business ideas: a field guide for rapid experimentation
• Marty Cagan (2008). Inspired: How to create products customers love
• Clayton M. Christensen et al (2016). Competing against luck: the story of innovation and customer choice
• Nils Davies (2017). The secret product manager handbook
• Cynthia Kurtz and Dave Snowden (2003). The new dynamics of strategy: Sense-making in a complex and complicated world. IBM Systems Journal 42(3):462-483
• Alex Osterwalder and Yves Pigneur (2010). Business model generation
• Eric Ries (2011). The lean startup