Four mental models for defining product
I’ve been thinking about how mental models relate to definitions (like ‘product’) which relate to artefacts (like roadmaps). It’s confusing and dissonance-creating to define a product one way and then create a roadmap in a different way. So, if an organisation defines it’s products as pieces of tech, then an outcomes-based roadmap is going to make no sense. Lining up artefacts, to definitions, to mental models might help create more coherence and understanding. So, I thought I’d start with mental model based definitions of products.
By tech
This is the usual thinking in lots of organisations: a piece of tech equals a product. ¯\(ツ)/¯
Pros – Intuitive mental model because it’s fairly easy to see the boundaries of the tech and what that means for user experience, etc. Aligns the capability of the tech with the expertise of those working on it. Features roadmap makes sense because it expresses changes to the tech.
Cons – It makes it almost impossible for a product team to be outcome-focused as a user hardly achieves their outcomes by interacting with a single piece of tech. It falls into Conway’s law, which means users across multiple products often don’t get the consistent experience they’d expect when going from one tech to another.
By outcome
A product is all the things necessary for a user to achieve an outcome, including tech, team capabilities, policies, processes, etc.
Pros – Most user focused way to think about a product. Offers greater flexibility in how to achieve an outcome as a change could be in policy, user interface, etc.
Cons – Limits how to structure teams to work on a product as there aren’t going to be that many outcomes. Measuring outcomes is hard, so teams have to rely on proxy measures.
By activity
I’m not sure activity is the right word but it fits well enough. I mean product managers being responsible for things users do like Payment, Notifications, Search or Onboarding.
Pros – Allows for a great deal of flexibility in how the activities are defined which makes it easier to add, merge and disband teams aligned with activities.
Cons – It can be a bit feature-led, which means teams need to communicate and coordinate to create a coherent product experience.
By goal
The goals would usually be metrics based, e.g., Increasing Daily Active Users or improving retention.
Pros – Product teams can experiment and implement across any tech or user experience to achieve their goal.
Cons – Requires coordination across teams to prevent one team from negatively impacting another team’s goal.