Weeknotes 482
I did:
Continuous change
- Had more chats with people from the team I’m joining. Still more to meet but everyone is so generous with their time and knowledge. It’s helping me to understand a really complex product.
- Learned about how one of our policies is reviewed and changed to meet changing user needs.
- Was asked how much of my time is allocated to a piece of work. It started me thinking about how things like that might be decided. I’m lucky to be able to make my own decisions about how I spend my time.
- Chatted about spotting potential problems and getting ahead of them before they become real problems. It’s not easy, especially if others don’t see the potential.
- One of the product managers showed me a vibe-coded product that had a really clever feedback loop built-in. I so impressed with the thinking behind it. I work with some really clever people.
- Read about how our new organisational strategy is shaping up. It’s really good to see how much it focuses on our societal impact.
I read:
Competitive by design
Public Digital’s collection of writings about user-centred design, modern technology practices and a test-and-learn approach.
Iterate, if you can
James Plunkett wrote, “Although design and user research have led the way in making public services work better for users, these disciplines sometimes add to this sense of work being linear. Work often starts with a long upfront design/research phase, without any ‘build’ or real world testing.” That’s definitely a problem.
Here’s another. Often, the skills needed to get a service/product live are not the skills needed to iterate towards success. So, here are some of the things teams need to be able to iterate:
- An understanding of how to run experiments. It’s a specialist skill set.
- Experimentation tools to set up and run experiments quickly and easily.
- Product instrumentation and data analysis capabilities and skills to understand the results.
- A team resourcing model that supports the uncertainty around experiments taking unknown lengths of time to get results, and unclear changes that might need to be made.
Winning at new products
Bought Robert Cooper’s 2011 book on product development. I can’t believe I’ve never read it as Cooper’s Stage Gate model was one of the product development processes I analysed for my masters dissertation. I’m interested to find out what it says about teams using stage gates to make decisions to stop work.
I thought:
Alliance and adaption
I’ve been thinking about pluralism… a lot. It explains so much about how our work happens and what it takes to succeed.
I’m a member of two product groups, two teams, a profession and a department. I work with various stakeholder groups and lots of other teams. Each of those groups can “claim to possess, and attempt to exercise, a measure of legitimate authority over their members.” (Muñiz-Fraticelli, 2014). Or to put it another way, they all think they are right, and none of them can tell any other that they are wrong.
This has it’s advantages of course. “Constructing a pluralistic intellectual environment and nurturing a culture of critical dialogue and skeptical inquiry will help draw out a more robust exchange of ideas.” (Whittington, 2019). But on the downside, it means things go more slowly.
Unitarist product management tries to align these group’s goals. When it can’t, it regards this as conflict and expects that conflict to get resolved. But a pluralistic culture doesn’t want to resolve conflict. It sees conflict as a natural and necessary part of more important things such as critical dialogue and discussion.
A pluralistic product manager accepts that every individual, every team and every informal gathering has their own goals. Progress towards one’s own goals is made through constant reflexive negotiation with all those other groups.
I’m not sure autonomy and alignment works in pluralistic cultures. Maybe alliances and adaptions is a better fit. It describes how teams seek success by affecting other’s goals and adapting their goals for others.
| High alliance | Lots of changing other team’s goals but not so much changing own goals in response to others. Win/lose. | Adjust own goals to meet other’s needs, build alliances with others and influence them to adjust their goals. High-performing teams who understand their pluralistic cultures operate here. They create win/win situations. |
| Low alliance | Fixed goals, not much adjusting with other teams. Unitarist teams operate here and so struggle in pluralistic cultures. It’s lose/lose. | Lots of adjusting own goals to meet other’s needs, not much influencing others to adjust their goals. Lose/win. |
| Low adaption | High adaption |
Coherence over coordination
Yes, I know I’ve previously gone on about ‘with not over’, but this is the exception that proves the rule. Product managers should be more focused on creating coherence (of purpose, of context, of business model) than on coordinating work. All things being equal, if you only have an hour, spend it on coherence.