Product centric, rather than Product all the things
As part of a recent set of articles I’ve been writing on moving from project to product, I’ve been exploring some of the challenges people…
As part of a recent set of articles I’ve been writing on moving from project to product, I’ve been exploring some of the challenges people are likely to face.
One of the more recent revelations I’ve had was from speaking to a few amazing people in my network that led me to an ‘aha’ moment.
Whilst anything can be a product
Not everything should be a product
You can take a product approach without a product
Inspiration from…
Jocko Selberg, Matt Skelton, Chris Matts, Jon Smart, Nick Tune, Nick Brown, Richard James, Tony Caink and many more…
You can read all the books, talks and podcasts you want but quite often some of the challenges only sink in when you are in the ‘belly of the beast’ and seeing things firsthand.
I am a fan of books like Better Value Sooner Safer Happier, Inspired and Empowered, Team Topologies, Escaping the Build Trap and many more.
Symptoms include people thinking that…
everything is a product, projects no longer exist
every team needs their own product
the product needs to be funded as a single entity
applications are always the equivalent of products
the Product Owner role from Scrum implies ownership of a product
Amazon’s two pizza teams means that everyone needs to be set up from day one
you need to have all the required skills to deliver a product in either a single team or a team of teams (think squads / tribes etc.)
value streams are largely long lasting and fixed structures
every single team needs to cover front end / back end / deployment / database / UX / infrastructure and product management
Update: Nick Tune, also shared an article from Sriram Narayan around a topic he called ‘Product Mode’ which is a nice way to compare and contrast products and teams. Article: Product-Mode is more than just Durable or Persistent Teams
Food for thought
When it comes to moving from project thinking to product thinking:
The approach benefits from product thinking and funding teams (capacity) to orient teams around a vision / mission.
It doesn’t require every single team to have its own product — especially in an existing complex environment.
You can apply a product thinking / mindset to anything you do (we’ll explore that in a subsequent article).
T̵h̵e̵r̵e̵ ̵d̵o̵e̵s̵n̵’̵t̵ ̵s̵e̵e̵m̵ ̵t̵o̵ ̵b̵e̵ ̵a̵ ̵s̵e̵t̵ ̵o̵f̵ ̵h̵e̵u̵r̵i̵s̵t̵i̵c̵s̵ ̵t̵o̵ ̵i̵d̵e̵n̵t̵i̵f̵y̵i̵n̵g̵ ̵p̵r̵o̵d̵u̵c̵t̵s̵ ̵i̵n̵ ̵a̵n̵ ̵e̵x̵i̵s̵t̵i̵n̵g̵ ̵l̵a̵r̵g̵e̵ ̵c̵o̵m̵p̵l̵e̵x̵ ̵o̵r̵g̵a̵n̵i̵z̵a̵t̵i̵o̵n̵.̵ (correction:, yes there is from Roman Pichler https://www.romanpichler.com/blog/what-is-a-digital-product/ — thanks Nick Tune for sharing!)
Identifying areas of opportunity to reduce Cognitive load on teams is a great way to identify unarticulated needs. These can even be thin platforms and in fact, the thinner the better! (from Team topologies Thinnest Viable Platform — TVP)
For team design there are several great resources and practices I really value Team Topologies, Strategic Domain Driven Design, Maturity Mapping, Value Stream Mapping, Event Stormingand Wardley Mapping.
The role of the ‘product owner’ has caused more harm than good when an organization is moving towards a product centric approach.
Depending on your technology stack, you will need to change your approach to enable fast flow of value e.g. an ERP or a SaaS vendor product may be the antithesis of enabling teams to work autonomously and deploy regularly.
You will need to explore patterns and practices that allow for more everything as code to create greater autonomy at a team level, however that isn’t usually the goal of software vendors so pay close attention.
Orienting to a customer / consumer means that you treat other teams as customers. X as a Service from Team Topologies is a clean way to think about this with Team APIs.
People confuse the need to collaborate with other teams in a large complex organization with dependencies in every case.
A scenario…
If team A is working on something new and team B is required to deliver value that isn’t necessarily a dependency. That is an opportunity to collaborate.
If team A always needs team B to deliver value on a regular basis, then there is an opportunity to change how team B offers its capabilities or service to others. If the interaction requires constant discussion and high coordination that is something to look out for, if it’s simply to use the team’s API for a service they offer then little communication is required.
Over time the goal should be to reduce regular dependencies in terms of team-to-team interaction. Depending on a service in general isn’t an issue if that service is reliable and non-breaking when it evolves over time. If team B has a service that requires team A to change every time team B does an update, then this is tightly coupled and something to explore.
There is a real opportunity to continue this dialogue and build on top of the work done by others in this space to give people a set of tools and processes that allow people to think about these challenges and solve the issues themselves over time.
There is no point in team A complaining about team B if team A could help team B on their capacity challenges or even some of their technical capabilities. Inner sourcing is another topic to explore, I’ll save that for another article.
Team topologies ‘enabling team’ is another great concept as it could be a roaming team that doesn’t own or deliver any products / services / components or even platforms itself, but it can help others learn how to build their own practices.
What are the heuristics you consider / use when thinking about products and the relationship a product has with teams? I’m at the stage, where I’m comfortable that teams and products can be completely orthogonal things and not all teams need to or should on products, even if teams are applying product thinking to what they build and deliver.
There appears to be a convergence of ideas which are helping tease some of these challenges out e.g. architecture, agile coaching, systems thinking / complex adaptive systems, cognitive science, domain driven design etc.
For the next article, I want to explore what taking a product approach means in plane language. It sounds great but is fluff, until the rubber hits the road. I’m loving the opportunity to interact with you and learn as I go. Please add your thoughts in the comments so that we can learn and explore together!