Productising IT Services

Share this post:

It’s great to see Agile ways of working taking such a firm hold in our collective psyche. I’m a big believer, having recently found a few curious (and curiously effectively) ways to use them. Agile’s principles can be applied more broadly than most people recognise, and compliment the dominant “digital” agenda which implicitly drives much of today’s business strategy.

“Scrum” is the most talked-about approach to Agile. But once we start taking Agile beyond customer-facing products, just how does Scrum apply? In particular, how do the mandatory concepts of “Product” and “Product Owner” apply?

This seems a puzzling question at first, but answering it can make all the difference for organisations seeking to become truly agile.

The first thing to determine is how liberally we can apply the term “Product”. I’ve found it to be pretty versatile. Clearly a mortgage, or a smartphone, or a domestic energy supply can be a “product”. All these things are consumed by customers who derive value from them. The related customer experience can be mapped-out and improved. Those improvements can be managed in a prioritised backlog, and a “Product Owner” can be accountable for that backlog, the budget and the successes (or failures) derived from the investments made.

But it’s surprising where else those same criteria apply: For example, when working with a large government department, I found that they readily applied to internal end-user computing services like printing, or office automation.

More generally, I now try to pursue any longer-term strategic consulting work by styling my area of work as a “product”, so I can keep the team energised and dynamically prioritise in the face of volatility.

And I’m finding it increasingly useful to think of IT infrastructure and middleware services as products too, to better motivate faster improvement cycles. This would have been almost impossible years ago, when most sizeable IT investments were CapEx-shaped, but cloud has changed that, making it far more viable and desirable to iterate, and learn fast from what doesn’t work.

Of course using product thinking this broadly is unusual, and begs a few questions. The main ones for me have been what constitutes a good set of “products”, and where should their boundaries lie?

We’ve just worked on this problem with a client company’s IT organization. We arrived at 5 criteria which collectively make for good “productisation” of IT-centric services:
1. “an informed and empowered product owner must be available to represent user needs, and dynamically manage scope and priorities
2. “it must be possible to run a series of fast, low cost iterations which create value without repeating major investment
3. “all required contributors must be ready to work together in agile ways, ideally in a single location
4. “financial approval must be possible without firm commitments on how targets will be met
5. “there must be a clear business intent to continue investing in improvements over the medium to long-term”

The second question on the bounding of a good set of products is a tougher nut to crack. There’s an art to resolving it, but a few simple principles are helping us here:
a) product boundaries should be set to match the boundaries of coherent, end-to-end user experiences, resulting in value to those users, even where this means that human and technology resources must be shared between products
b) products should be as independent of each other as possible, so they can be managed separately most of the time
c) product scope should be large enough to permit a focussed, full-time Product Owner
d) decomposition into sub-products is fine, but each should be a meaningful subset of the content and value in the parent product

This is an emerging area of thinking, so I’d really appreciate any feedback. In the meantime … “happy productising”!