I did:
Happy holidays
Two and a half day week with lots of people on leave, so time to finish off things.
- Took part in some product manager interviews.
- Finished another retro analysis.
- Talked about what I think a great onboarding experience looks like and how it’s mostly meeting expectations and expanding mental models.
- Finished development plans for two of our junior product managers.
- Talked about a development plan for another member of the team.
- Put together a dashboard for a business review meeting in January.
- Started thinking about how to build a recommendations engine.
Getting agile governance right
Wrote up some thoughts o…
I did:
Happy holidays
Two and a half day week with lots of people on leave, so time to finish off things.
- Took part in some product manager interviews.
- Finished another retro analysis.
- Talked about what I think a great onboarding experience looks like and how it’s mostly meeting expectations and expanding mental models.
- Finished development plans for two of our junior product managers.
- Talked about a development plan for another member of the team.
- Put together a dashboard for a business review meeting in January.
- Started thinking about how to build a recommendations engine.
Getting agile governance right
Wrote up some thoughts on what sometimes gets missed about why teams do show and tells and what else is needed to make agile governance work.
I read:
The Product Operating Model at Google
I read Itamar Gilad’s response to Marty Cagan and Elias Lieberich’s article about the product operating model at Google, so I thought I’d critique their concepts of a product operating model using neo-sociotechincal systems theory. Neo-STS evolved from traditional social-technical system theory, which was the basis for lots of ideas about modern work such as empowered teams, but it recognises that digital technologies have changed how organisations operate and so adds four components: multi-encapsulation, complex interrelation of socio-technical elements, multidirectional inheritance and continual negotiation.
SVPG’s and Gilad’s product operating model are limited by the same outdated thinking about how organisations are organised. For example, they show strategy as being done . Multi-encapsulation tells us that is ‘containerising’ of work is problematic and that strategy work is better done when it’s part of and affected multiple different socio-technical systems. Cagan splits discovery form delivery in the SVPG model, but the complex interrelation elements shows us how these kinds of activities are interrelated, redundant, competing, or conflicting at the same time. Gliad’s model shows goal and metrics in isolation to other parts of the model, but continual negotiation reflects how goals are simultaneously reinforcing work structures required to achieve goals and being changed by ongoing negotiation.
Their models suggest specific parts of the organisation are responsible for specific functions, they don’t show the relationship between the parts or how information flows, and have no sense of change over time. It’s a shame so many product people look at popularist thought leaders like this when there is far more robust thinking available.
Why Agile Teams Succeed – or Don’t
The agile mentors podcast about what makes teams succeed and some interesting stuff about the difference between task conflict and relationship conflict, and how adaptable people are when it comes to fitting into teams and work cultures.
Task conflict is good because people care enough to disagree and discuss how something should be done, but when conflict becomes about proving who’s right and who’s wrong, then it’s relationship conflict and that’s dysfunctional within teams.
The research shows, they say, that the blending of different personality traits and preferences isn’t really much a problem because human’s are social creature and are really good at adapting to fit into groups, and it’s how the group works as a whole that affects its performance, not the personalities of individuals.
I thought:
Product thinking skills
If product management is all about finding worthwhile problems, then two product thinking techniques for understanding problems are decomposition and abstraction. Decomposition, breaking big complex problems into smaller more easily manageable chunks, and abstraction, filtering out the factors in order to understand which affect the problem in what ways, are essential skills that are hard to learn but will make far more difference to a product manager’s practice than any prioritisation framework.
Understandable
Making things understandable is a super power. You can have the best metric in world but if no one understands it then it’ll be ignored. You can have the most impactful actions but if they aren’t themed together in a way that makes sense no one will get behind them.
Management feedback loops
You know how I feel about feedback loops, I go on about them all the time. I’m trying to build them into my practice as a line manager. As we’re product managers, it’s not about the activity but the results we get. So I don’t want to ask questions like, “Am I challenging you enough”, I want to ask, “Are you being challenged enough”. I need to figure out my system for collecting and responding to the answers, but I think the product managers I work with will do better if I get fast feedback loops in place.