Four mental models for defining product

Roger on 18/12/2024

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.

Weeknotes 437

Roger on 13/12/2024

I did:

Challenges

This week has involved recognising the challenges of the past year and the challenges to come next year. It’s important to do that. Challenges have to solved together, which only happens if we can all understand them. Other stuff happened too:

  • Had a really nice team meeting with everyone sharing some of their challenges, in particular the barriers to change that we face. I still firmly believe that the only way change happens is by people talking to people. PowerPoint never changed anything.
  • Thought about different approaches for managing technology and how it depends on what you’re optimising for. It’s like the old sales thing of “Fast, good or cheap; pick two but you can’t have all three.”
  • Chatted about product discovery practices and responding to user feedback, and saw a great example. I love finding things like this. It’s so much more effective than big programmes to introduce things like user research.
  • Helped shape some work for next year.
  • Went to a visioning workshop for platform products. What I love about things like this isn’t getting to answers, it’s seeing all the different perspectives people bring.
  • Started moving my task tracking into Notion (which I’ve previously only used for notes) and trying out dashboards. I haven’t yet figured out how to show more than one chart on a page but it looks like it could replace Google Sheets.

Prioritise problems, sequence solutions

Wrote up a few thoughts on the difference between prioritising and sequencing, and whether they might fit in problem and solution spaces.

I read:

Bring skills, energy and love

Matthew Moran, with probably the greatest opening line of any blog post, “What we’re seeing right now is the prolonged demise of the post-WW2 world and its institutions.”

Clever girl

I looked through lots of Janice Fraser’s slides. They’re great. Maybe more people should make more slides. Not for presentations (we’ve all seen too many already) but as thought-provoking provocations. Because the thing about slides is, you never know exactly what point the author is making, which means you have to think a bit more and fill in some gaps with your own thoughts. I particularly like this slide about how product management is about differential diagnosis rather than process implementation. It makes me think.

Transformation is generational

Agile, lean start-up, OKRs, etc., are tools for change. I never used to think this but now I do. Christina is right, organisations do have to change for these new mindsets to be effective, but it’s also true that these things can bring about the change. The thing is, that change will take decades. The next plateau of change all these transformations across all these organisations will reach is when everyone in the workforce has only ever known this way of working. It took an entire generational replacement to make the most of electricity, it’ll take the same with the Internet. So if you’re pushing your org to be more agile or user-focused or have greater transparency, then know that you are doing good work but it takes as long as it takes, you aren’t failing because the change hasn’t happened yet.

Oh also, most organisational transformations aren’t nearly ambitious enough!

Make the state “more like a start up”

Pat McFadden’s speech about the need for government teams to use a “test and learn culture” pioneered by digital companies to tackle some of public sector’s biggest challenges created a lot of chatter. Matt Jukes said this, James Plunkett said that, Public Digital blogged about it. And lots more people said lots too.

There are lots of angles and agendas, and I’m not particularly interested in government departments, but I am interested in organisational self-image and how much it affects what’s possible. So, if the people involved think of government departments as bureaucratic, slow, risk-averse, etc., then maybe it makes sense that their perspective is that government departments can’t operate like a start-up (with the important word being ‘like’, not ‘the same as’). But if you believe it is possible for the people in an organisation to think differently about it, and that how they think about it changes how it operates, then maybe a government department operate more like a start-up (with the important word being ‘like’, not ‘the same as’). Speeches are great, funding is great, changing beliefs is greater.

I thought about:

The problem with professions

Back in the day, in functional teams, where everyone had broadly the same skill set, things like career progression, pastoral care, etc., were handled within the team. Everyone was only ever part of one team, which meant all the work happened in the same place as the line-management, and they was only one team culture. Functional teams aren’t perfect, they create inter-team and organisational problems, but for the people in them, they had a lot of coherence.

As we moved to cross-functional teams, that was lost. Cross-functional teams aren’t perfect either, but they bring a lot of benefits. The work the team does can be more effective when the team has all the skills it needs and can work independently of other teams. But the team doesn’t have a way to handle skill development or career progression or coaching and management support, which is also important. Unfortunately, hardly any organisations want to go far enough with creating properly autonomous cross-functional teams that do include these things, so instead they looked for a way to fit cross-functional teams into a hierarchical org structure.

What they came up with was ‘professions’. Professions are a way to bring together people of similar disciplines and provide some of the aspects that are important to individuals but are missing from cross-functional teams. Professions is an inadequate solution to the problem cross-functional teams creates. It makes the problem worse. A person now has three, potentially competing, team cultures to contend with. They have the culture from their original functional team, with all the historic incentives, motivations, relationship dynamics, and the culture of the cross-functional team, with new ways of working, priorities, inter-functional understanding, and the culture of their profession with pressures to mature their discipline, achieve personal objectives, support their colleagues (and this doesn’t include informal groups, communities of practice, etc., all of which also have their own cultures).

There is no overarching organisational mechanism to align and coalesce these different cultures. Individuals have to figure this out for themselves. Now, working life has far less coherence and far more confusion. I don’t know what the solution is, but it should probably consider Larman’s Law.

Variability

It used to be that the way to get efficiency at scale was to design things to be standardised, replicable and easily replaceable. Utterback and Abernathy wrote about how a dominant design emerges, that’s why most cars look basically the same. Team and org design also takes this approach. But it doesn’t have to.

One of the ideas that Internet-era and digital (whatever that means to you) thinking brought up is ‘variability’. We can create things that are unique and personalised (on-demand printing) and create things that deal with lots of difference (website that works on lots of device and browser combinations).

Applying that digital mindset to org and team design still has some way to go. The approach there is still very much about creating standard patterns. A digital-first org design might start with identifying specific ‘problems’ the org has to deal with and organise roles and teams around them. So, rather than a HR team, there would be a Hiring team, and an Onboarding team, and so on. Those teams would have roles specific to that problem. The Hiring team might have an expert in advertising or social media and developer for the application tracking system, whereas the Onboarding team has a service designer and training expert.

In this way, every team would be different. There would be no standardisation across teams, they would be all about variability to tackle the problems they are designed around.

Product management in the permacrisis

More thoughts on the future of product management, given the permacrisis we’re all living through and we can’t carry on as if nothing has changed. Moving from internal socio-technical interactions to external eco-socio-technical interventions in broken systems. Moving from revenue and endless growth to Elkington’s triple bottom line of people, planet and profit (within the org and for user success) and Raworth’s donut economics of planetary and social boundaries. One day I’ll make some sense of all this and write about it more coherently.

Prioritise problems, sequence solutions

Roger on 11/12/2024

It’s easy to get confused about prioritisation. We often use that word when we mean other things. We should mean ordering things by relative importance, but sometimes we also mean the sequencing of those things. One word, used to mean different things to different people. And that’s where it causes confusion.

I think it’s clearer to separate how important something is from when you’re going to do it. And to make that separation even cleaner, we could prioritise the problems we want to tackle, and sequence the solutions we want to create.

Prioritising problems

Like all good product managers, we want to start by understanding the problems we want to tackle or opportunities we want to go after.

We want to know which are the most important problems, and to figure that out we might look at how many people have the problem, how affected they are, how much they need a new solution, etc. All this information helps us pick which problems to tackle and which not to. And that’s the point of prioritisation; choosing what to work on, not when to work on it. It’s the logic of ‘this, not that’, whereas sequencing is ‘this, then that’.

Sequencing solutions

Once we have the problems prioritised by importance, we can then sequence the solutions.

We want to sequence the solutions separately from prioritising the problems because there are different factors to consider. Now we need to think about team capacity, technical skills, dependencies on other systems, budgets and other organisational constraints, etc. These things don’t affect what problems we’ve prioritised but they make a difference to when we’ll be able to tackle them.

By thinking about problems and solutions differently we can avoid confusing how important a problem is from when we want to solve it. It helps us make better decisions about whether to tackle more important problems sooner or when to solve easier problems.