Why I Like Products
I’ve mostly been writing her about agile and processes – I think because that’s freshest in my mind from my latest work. And I was realizing that I haven’t spoken much about products, or why I attach so much importance to product thinking (and why I enjoy it so much).
For decent chunks of my career I’ve thought up products and ideas (I’m largely a ‘plant’ in the Belbin model), and then gone on to build them.
It’s my experience that ideas are easy – I’ve been a first mover in two billion-dollar industries – and execution is hard – in both cases I lost out (once due to inexperience, and once because I sold out to someone too powerful to resist). So I’ve worked to strengthen my personal execution muscles to go with the ‘thinking stuff up’ ones.
And I’ve come to realize that thinking about things we do as products – as a ‘thing’ which goes out into the world and has a live of its own – is actually a great way to improve both our thinking about them and our execution of them.
I’m not going to go deeply into product management mechanics (although I’ll write about my take on them soon, and start mixing that in with the process stuff) – what I want to talk about is what the core idea of product means to me.
Here are some thoughts based on an old presentation I wrote:
We typically deliver work in ‘projects’ which are containers for work.
A ‘product’ (or service) is a container of value – it defines the basis for a transaction with a customer (what they get).
Work is ephemeral – bounded by the boundaries of the cost cycle; value is persistent.
By shifting from work that is intermittently associated with value (projects are planned once a year, in the strategic planning process) to work as incremental improvement in a product we make value a constant factor.
What does the customer buy? If you were a vendor to your company today, what deliverable would you be getting paid for?
You may not actually sell anything to an end customer, but you still have customers who use what you do or make and value it – or you should.
Don’t think about the managing work you do, think about maximizing what customers use & want, and using your capacity to effectively deliver it.
The presentation was to an internal IT team at a major corporation, and out of it, we spun up an actual product idea: “system updates as a service.” As a corporate user, you’ve shared the pain of random software updates dropping on you at awkward times. We asked the question ‘what would we do to make that experience for the end device user better?’ – and spun up a bunch of ideas which were taken away and I hope put into practice.
Right now, we manage projects (containers of work) which are only loosely connected to value and to the customer. If we shift to managing the lifecycle of products (containers of value) we can bring clarity as to the ‘why’ as well as awareness of the lifecycle of the thing we’re building.
In addition, we build in a structure idealized for learning – because we can start thinking of our product as a collection of components – some of which are stable, some ephemeral, some dynamic – and we can manage the heartbeat of innovation and growth against the components that will deliver new value through change (as opposed to the 10mm locknuts that deliver value through consistency, low cost, and quality).