When large organizations attempt to transform themselves, they try to do it wholesale. This often leads to significant push-back, with the more risk-averse departments slowing or derailing the process entirely.
Is it any wonder? Those departments have spent their whole lives being evaluated and remunerated on one basis. It’s shaped the people they hire, the processes they have in place, and their judgment of what success looks like. It’s very difficult to change this cultural behaviour overnight, assuming it even needs changing. A good example of this is corporate IT.
For many years, the IT department ran the computers and servers on which you did your work. Later they also ran the infrastructure that your digital products and services ran on. If one of those systems went down, it could cost the company millions in lost income or productivity, not to mention the effect it would have on the CTO’s bonus. Corporate IT infrastructure has always been fairly conservative in nature.
Then along comes Lean Product Development, an approach that tries to deal with market uncertainty through rapid experimentation and learning. Trying to incubate a fail-fast culture inside one of your most risk averse departments was never going to be easy. This is one of the reasons so many large companies have struggled to introduce agile into an environment optimised to avoid failure, and have ended up with something remarkably (fr)agile as a result.
In the past few years we’ve seen the emergence of Bimodal IT, as popularised by Gartner. This model separates IT activities into two different types of work; one typified by predictability and uptime, the other based around unpredictability and experimentation.
There has been an awful lot of backlash to this approach, much of which is justified. But a lot of the criticism comes from high-performing teams in mature tech companies that don’t need to worry about digital transformation because they’re already on the other side. The arguments are often as much philosophical as they are practical. And with real digital transformation projects taking upwards of seven years, it’s a little too early to genuinely gauge the results.
Whatever happens on the technical side of things, I think it makes a lot of sense to divide your digital products and initiatives into conceptual pace layers—multi-modal product management if you will. Mature products that generate the bulk of your income need to be treated differently to fledgling products still looking to gain traction. Similarly, early stage experiments need to be treated differently to products still exploring product market fit.
Mature product teams need to be stacked with people focussed on scalability, operational efficiency, and incremental improvements. In these environments performance and uptime are critical, new product features need to be well considered, and quant will almost certainly overshadow qual. The most successful products will be making good money, and will therefore need product managers with a strong commercial focus. In the pioneers, settlers and town-planners model, mature teams need a good mix of the last two.
By comparison, early-stage teams will need to be stacked with hackers and experimenters. It doesn't really matter if code is well formed or the platform scales, as it will probably be thrown away and rebuilt. Qualitative insight will be much more useful than quantitative, and learnings are prioritised over commercial success. In this situation, the product managers are more likely to come from a UX or tech background, and have worked in early stage startups before. Think mostly pioneers with a couple of settlers or town planners steering the ship.
Fledgling products are often the least understood or properly managed. These are the products that have proved there’s a market, but are a few years away from turning a healthy profit. This class of product needs people who can help explore new feature sets, attract new customers, and grow the revenue. The team needs to be a mix of pioneers and settlers, with a few town planners thrown in to preempt their scaling needs, while the product manager needs to be entrepreneurial.
An easy way to divide up these products is the concept of now, next and future. As the name suggests, the now class of products tends to be where the organisation is placing its attention and getting the bulk of its revenue. Now products tend to have a six-week time horizon. The next class of products is where you hope to be getting your future revenue from. Some of these initiatives will succeed, while others will fail. You should get a good read on these products between six and eighteen months. Lastly the future products are the long bets. The majority of these won’t pan out, but the ones that do will eventually be elevated into the next category. These products tend to have a time horizon of three to six years, allowing you to think about your now, next and future product streams in six week, six month or six year investment cycles.
So perhaps you like the now, next and future concept. Or you might prefer to think in terms of six weeks, six months or six years. Or you may well have some other way of breaking down your product portfolio.
Whatever your way of thinking, a multi-modal approach will help you separate the inevitable pace layers that will form between your products, and ensure you have the right teams in place to support where your products are in their natural lifecycle.
What do you think of the 'now, next and future' concept? We’d love to hear from you - tweet us @andybudd and @clearleft
