A Product Mindset is a Continual Mindset
A Product Mindset is a Continual Mindset.
Software products are fundamentally different in nature than physical products. I believe that the failure to fully and consistently recognise and internalise this fact is the root of most pain faced by software teams and organisations.
Much modern software systems are custom — they’re unique — and they’re hyper-dependent meaning that at both runtime and build time there is a relationship to other software up, down and across the (software) stack. And much of these dependencies are in turn other hyper-dependent complex systems. And both the core product and it’s dependencies (and their dependencies) change all of the time via updates so the products can be fixed, improve and pivot inline with the real world and the technical environment.
Consider reasonably complex physical systems like in-home boilers. Once installed they should work for ~15 years. They do need occasional expert support but generally they will continue to operate. Now take any modern technology product. A news / banking / dating app for example. Send all of the technical staff home, take away their laptops. How long do you think it will be before parts of the product stop functioning? A day? A week? A month?
You know when a car is ~20 years old (typically past it’s reliable lifecycle period) but with good knowledge and constant care and attention it can continue to operate really well. Network interconnected software systems are a lot closer to this state from the get go. Modern software that has the ability to continually improve is inherently more fickle and requires much more investment in to active reliability engineering to maintain quality.
I am painting with a broad brush. Much software is embedded and closed-loop. Much software e.g safety-critical software doesn’t pivot much. It’s purpose and function is well-understood and tested-to-death. But the general picture of virtual vs. physical product development and operation remains true.
I see the key difference between a project mindset and a product mindset to be embracing continual actions and processes. Active management. Being truly agile.
Our work needs to be structurally adaptive. Plans need to carefully adjust in accordance with the real world. Modern product management practices can be used to create (continual) feedback loops with real users so that we can verify as much as possible that we are solving the right problems in the right ways. Problems that users really want solving and not just doing stuff. (See final section on product management reading.)
Modern engineering uses continuous delivery and testing and incremental improvement to deliver value more frequently and enable these loops.
Learning needs to be continual. Individuals need to regularly invest time in to their personal development. Workplaces should enable this. Things change at such a pace that staying in place is going backwards. Teams need to be empowered to proactively research how to solve novel issues. Teams also need to use reflective techniques to improve. Learning via periodic retrospectives and blameless postmortems of problem events.
Product maintenance, simplification and evolution is continual.
Advocacy for your vision and alignment with internal stakeholders and concerns is continual.
Product support and operations is continual.
Product ownership / stewardship is through longer-lived teams which are continual.
Whilst migrations and dedicated improvement initiatives are a normal thing I think most transformations will always be doomed to fail unless they instil a continual cultural mindset which needs to start with organisational leadership.
Diverse product management reading that has helped me so far:
- Inspired (2008): Marty Cagan.
- The Lean Startup (2011): Eric Ries.
- Escaping The Build Trap (2018): Melissa Perri.
- Empowered (2020): Marty Cagan, Chris Jones.
- Build (2022): Tony Fadell.
Also John Cutler on LinkedIn and substack:
