Category: Weeknotes

I did:

Meta-work

This week felt pretty fast. Lots going on that needs to happen sequentially at pace to prevent other things from becoming blocked. And Christmas is getting closer.

• Chatted about our OKRs, how we set them and how they prioritise the team’s work, even if the team isn’t always aware of it. What gets internalised (and accepted as a given) and what gets externalised (and stated explicitly) is really interesting and connects to cognitive load, I think.
• Had a great coaching session. I was really impressed with their degree of connected thinking across different domains and appreciation of the implications from a change in one domain. It got me thinking about how tools like roadmaps are representations of product manager’s critical thinking.
• Was reminded that complex systems that work always evolve from simple systems that worked. It’s one of underlying principles of modern product teams that gives us prototyping, iteration and the like. Upfront design of the perfect end state is risky and costly.
• Talked a lot about simplifying things to reduce cognitive load, and tried to practice it by writing things clearly for people.
• Went to n levels of inception to do some glue work for those doing the glue work for those doing the work.

Championing user needs

Wrote about how product managers can approach championing user needs. Not my best work but at least it gets the ideas out of my head.

I read:

Design Thinking for Change

Samantha talks about Design Thinking as having a focus on discovery and definition and needing to work with other methodologies such as Agile and Lean which focus on delivery. I’m really interested in how we get different methods to work together coherently. I think that offers more value to teams than creating new methods and frameworks. We need to learn from what we know about the downsides of handovers between teams (information loss) and apply it to methodologies.

Centre of expertise

I read a paper about how organisations should be designed for optimising the expertise of knowledge workers. It’s a tough challenge but one I think creates a competitive advantage for organisations. For sure, there’s more to the answer than just writing more stuff done as we know most knowledge is tacit so can’t be written down and even when it is there’s a large percentage of information loss. It’s interesting to think about designing an organisation around knowledge management rather than thinking the solution is a tech system.

Middle-Out: Turning Strategy into Action with the Decision Stack

Jonny Schneider says, “The power of the Decision Stack isn’t in being comprehensive—it’s in being clear. While the top half (vision, strategy, objectives) typically remains stable over months or years, the bottom half (objectives, metrics, initiatives) evolves rapidly through learning and execution. This isn’t oversimplification. It’s about distilling complexity into actionable clarity. Teams still go deep in ways that suit them best, but the Decision Stack becomes the one artefact that consistently motivates aligned action.”

Not being sure

I like Debbie Blanchard’s definition of product management as being about taking on the uncertainty, listening to the experts, and placing the bets.

Mess mapping

I thought about:

Organisational self-image explains organisational culture

I have a theory about organisational culture counter to dominant idea that culture is made up of the collective behaviours of individuals. I think “organisational self-image” explains culture better. Self-image is a mental picture that is generally quite resistant to change.

If the organisation makes takeaway pizzas, the culture probably prizes speed and low-cost efficiency. If you work in a bank and regard banks as careful, reliable, and steady, that’s the kind of culture you’ll have. If you work in a university and assume universities last for a long time and that academic consensus arises dialectically, then you’ll have a culture with no urgency and lots of discussion. How everyone “sees” the organisation is how the organisational culture manifests.

So, if you want to change the culture, change the mental image people have of where they work.

Brooks’ Law

Brooks’ law is an observation about software project management that “Adding manpower to a late software project makes it later.” The reason is that more people requires more coordination which means each person spends an increasing percentage of their time not working. It’s often expressed with a diagram showing an increasing number of points and how the number of connecting lines between the dots increases exponentially, but gets misunderstood as communication, rather than coordination. Coordination doesn’t require the same amount of time for everyone, that’s why coordinating roles like project manager and organisational structures like hierarchies exist, to reduce the coordination effort for some people.

Now, I’m not saying Brooks was wrong, I’m pretty certain he was and still is correct. But I am saying that confusing communication and coordination also slows down teams. Both are necessary, but not always to the same degree for everyone at the same time. Being intentional about coordination, communication, collaboration, etc., makes a big difference to how people spend their time.

Talking is competitive advantage

The more people talk to each other, the more knowledge is shared. And in modern knowledge work, sharing knowledge is a competitive advantage.

Uncertain outcomes

When thinking about the outcomes and impact of product work, there are two boxes you can put the work: ‘Most likely won’t succeed, and ‘Might succeed’. There is no box called, ‘Will definitely succeed’.

I did:

You are not the user

But you do your best to represent them and do what you think is right for them. Sometimes (including this week) that can seem quite abstract and doesn’t always work out how you’d like. There was other stuff too:

• Reviewed the financial data for a new business case. Because it’s new and unvalidated it goes in the low confidence pile, so the next question is how to approach validating it to increase confidence in it’s value.
• Chatted to more product people from other teams. It’s so interesting finding out about what people do, what they think about things, how they got where they are. Everyone should do it.
• Argued with Information Security about phishing your colleagues being ineffective for improving security awareness and that induction training would be better.
• Attended our Digital Service’s all-staff meeting. Emma, our CDIO, talked about our priorities for the near future and how we’ll need to change policy, people, process, technology, etc., you know, product management stuff.
• Got some of the people and process stuff in place for a large piece of work we’re starting. My reflection is that I/we could have done better at coordinating what to do and by who to reduce the uncertainty.
• Wrote requirements. It was fun, like being a junior product manager again.

I read:

Everyone wins when product managers work in the open

Really nice post from Isabelle Andrews about working in the open as a product manager. I really like the point, “Putting information out there and being understood are quite different things.” And focusing on why we’re working in the open and not on the performance of it.

Is product management a profession or trade?

This interesting question was posed by John about futures, but it applies to product management too. John describes the difference between a profession and trade in terms of pacing layers and speed of change. “Professions are traditionally in the slower layers; governance, culture, etc., whereas ‘trades’ react to fashion and commerce signals and trends to constantly evolve.” I think this firmly places product management in the trades layer and maybe shows some of the confusion from trying to treat it as a profession.

Hi

Every so often, this nonsense about how people should use chat messages comes up on social media. Usually the justification is to not interrupt others, but this is the first time I’ve seen anxiety used as an excuse for telling people they should communicate in ways that meet your needs not theirs. I think people should feel comfortable to communicate however works for them. If it doesn’t work for you, talk to them about it.

How Complex Systems Fail

I’ve read Dr. Richard Cook’s work before but this is cool website presents his short treatise on the nature of failure. There’s lots to learn there, especially about how all complex systems are inherently hazardous but run a degraded mode. I’m interested in how/whether an organisation tips over from being a complicated system to being complex and how it affects the orgs ability to function effectively.

I thought about:

Small simple steps

Following on from last week and reading about how to lead in a VUCA world (do more planning more frequently to get better at responding to change), I’ve been experimenting with writing short, simple, step-by-step plans after meetings which:

• Say who is doing what by when.
• Have the next three to five steps.
• Are easy to let go of when something changes.

I guess the thing here is that although the work is novel for this group of people in this situation, which means it can’t be planned upfront, that doesn’t mean that planning is useless.

And so far, I’ve seen a few little glimmers of more clarity and alignment, so I’m going to carry on doing it.

Principles

More thinking about the decision stack (I should probably bring all these thoughts together into a single blog post). This week, how having principles in the stack places it in a deontological moral philosophy space. Whereas an outcome focus feels more utilitarian, that the ends justify the means, a principles focus is more about having guiding boundaries that you don’t cross.

The decision stack places principles at the bottom, almost like a foundation that everything above sits on, and it includes the ‘No’ zones either side of the other layers, both of which make it feel like it comes from a deontological standpoint. How product manager’s deal with the interplay of those utilitarian and deontological positions is part of the fun.

The future of product management

I’ve seen a few posts about the future of product management recently, and they all seem to be about whether product manager’s use AI or not. That is not the future of product management. The future of product management will have to be about redefining success beyond the assumptions of infinite growth. The current state of the global economy and global climate change are hard stops we can’t ignore. Our vision for the future of product management has to take these harsh realities into account. We can’t carry on basing our profession on the assumptions of Schumpeter and Friedman. It’s time to move on and create something better.

I did:

Hearts and minds

Only worked three days this week but lots going on. This week was mostly about people and relationships (you know, the good stuff).

• Had a coaching session with a product manager about effectiveness over efficiency, and how it comes from having good relationships with people.
• Presented this quarter’s OKRs.
• Talked about using one-pagers to get alignment and agree the boundaries of a piece of work before diving into the actual work.
• Had a wonderful high-energy chat with a product development manager, and we agreed that product work is people work.
• Interesting discussion about understanding product value, and how that’s product people’s responsibility, and product delivery, which is delivery people’s responsibility.
• Started working on a presentation about improving our data capabilities.
• Did the third team session of what product managers should and shouldn’t do. We talked about defining product success. We’ve got actions too.

Standardisation in product management

Wrote about standardisation in product management and why it’s a bad idea for a discipline that is going through so much change.

I read:

Decisions

Read an excellent (94 page) paper about decision-making by the brilliant Ruth Malan. Ruth explores a lot about decision-making, but there’s a lot to explore, including how information, leadership, community, regrets and autonomy affect decisions. However much you know, and whatever techniques you use, making hard decisions is still hard.

How to Be a Better Leader Amid Volatility, Uncertainty, Complexity, and Ambiguity

Two things to help leading better in a VUCA world:

• Look for signals that provide unexpected information, and actively go looking for exceptional information, to help make decisions when information is incomplete and imperfect.
• Understand problems deeply and do more planning more frequently to get better at responding to changing situations.

First, become trusted

Marty Cagan wrote about how product teams and product leaders can build trust because it’s

a successful transformation is a race to win the hearts and minds of the executive team and stakeholders before they lose confidence or otherwise decide this isn’t going to work. This includes:

• product leaders taking responsibility for ensuring strong and capable product teams
• product teams having product managers that understand business, data and customers
• product teams that can solve problems in ways customers love yet work for business
• product teams that can consistently deliver on high-integrity commitments
• product teams that can deliver real business outcomes
• product teams that can respond quickly and effectively to customer issues, and
• product teams that understand their obligation to keep the lights on.

Which is cool ‘n’ all, but no mention of creating the enabling environment so that teams can do those things. The whole rhetoric around team success and failure being purely down to the team bothers me.

The future is collaborative

“The higher education and research sectors in the UK are currently facing several challenges that threaten the sustainability of many institutions, with as many as 40% facing budget deficits. To address these issues, a shift towards deeper and more systematic approaches to collaboration is essential.”

I’m particularly interested in opportunity 5; “Co-building sector-specific technology”. I think we should lead the way in this kind of thing, building products that universities need for distance learning and make it available for other universities developing an online offer. We’ve got the history and scale to learn quickly, and respond to shifting trends to keep the products meeting user needs.

Thanks to Dave’s daily notes for the link.

And I thought about:

Skills Framework for Information Age

Continuing with my thinking about the best way for product managers to develop the right knowledge and skills, I looked at the Skills Framework for Information Age. There’s nothing groundbreaking about it. It’s good to see measurement mentioned, but not so good that it doesn’t mention Internet-era things like feedback loops. My quest continues.

Delegation

Following a chat about holding product manager’s responsible for achieving value that they weren’t involved in agreeing is achievable, I thought about how delegation happens and what gets delegated. I wonder if delegation is the side of RACI we don’t talk so much about. There’s always a power dynamic, so maybe accountability is taken and responsibility is given. And as I’ve mentioned before, if you’re in a position of power to say someone is responsible for something you also have to say how you’re going to use your power to give them what they need to succeed.

I did:

Consequences

Did you ever play that game where everyone writes words on a piece of paper, folds it and passes it to the next person to write their words, and when everyone is done the story is read out. That could be a pretty accurate description of how work happens, but there’s more to it than that. How good the story is depends on the people writing it, on how well they know each other, what signals they follow to stay aligned whilst doing their bit. The more complicated the story, the more alignment is needed, but it’s worth it for story we get in the end. This week I…

• Added to our Theory of change so it aligns with three pieces of work that all add up to the change we’re trying to create.
• Did some scenario planning to look at how different options pan out and make sure we get to all aspects of the end state we’re trying to reach.
• Talked about a product toolkit of things like a roadmap, OKRs, etc., that product managers are well-versed in using, know how to introduce to a team, and use effectively. The challenge, of course, is that the team exists within an ecosystem of other people and teams that may or may not be willing to accept the product manager bringing in these things.
• Started planning some solution design work to tackle some some evolving problems. Then stopped myself when I realised we don’t understand the problems well enough yet (or what problems we’ll have in the future). Rookie error. So, next week I’ll bringing together what we currently know about the problems.
• Wrote up some thoughts on what others should know about what product managers do and how to work well with them.
• Saw some wonderful examples of people reaching out for help and tackling problems together.

OKRs are really simple but…

Got around to writing up the intro to OKRs presentation I did back in October.

How does service design and product management fit together

Went to the good product leaders group session about how service design and product management fit together.

An interesting theme came out about how we think about the size of things, how the bigger the thing the more important it is, and how roles that work on bigger things are seen as more important than those that work on smaller more detailed things. This old hierarchical thinking doesn’t fit with roles like product and service design which don’t work at a single size level and have to be able to zoom in and out, and connect the big vision-y stuff with the small change stuff.

I’ve written before about how I think product managers and service designers can work together, but in a world where a service and a product are mostly the same thing, it doesn’t make sense for these roles to have mutually exclusive responsibilities, but instead to have complimentary perspectives. So, if I had to somehow try to explain a difference, I might say both roles create alignment for the team and coherence for the product/service, but product managers do it by zooming in and and out vertically, to connect strategy, goals, etc., and service designers do it by zooming in and out horizontally, to connect experience, process, etc.

I read/listened to:

10 things nobody tells you about OKRs

This looks like an interesting series:

• 10 things nobody tells you about OKRs part 1
• 10 things nobody tells you about OKRs part 2

What’s particularly useful about what Neil says is how it serves as a diagnostic for an organisation’s ability to work effectively. He says, “OKRs should be quick to write”. If you’re spending ages writing them it highlights a lack of alignment on organisational strategy and priorities. Fix that and OKRs will be quick to write. And OKRs demand data to be able report on key results, so not being able to report highlights the need for better data analytics. Fix that and OKRs will show if the objective is being achieved. I think this is where OKRs can be a tool for change, but only if there are used in this way by people with that intention. If they are implemented as just another goal-tracking method, then they are just more admin overhead, they won’t change anything.

My Product Management Toolkit

Read some of Marc Abraham’s My Product Management Toolkit book. It’s a quick and easy read with some interesting points.

Interventions

This study talks about how policymakers tend to treat enduring, systemically generated problems with limited interventions that are insufficient or inappropriate for the intended improvement. Of course, it’s only one study about something very specific so we should be wary of generalising the conclusion, but when have I ever been wary? It’s a pattern that shows up within organisations and in products as a result of most problems being wicked, novel and vague, and solutions usually being small, specific and constrained by time, knowledge and budget. We just don’t have the tools and techniques for making effective system-level changes.

My go-to example is the effect Uber had on drink-driving in the U.S. Researchers found ride-sharing reduces alcohol-related traffic fatalities by 6.1% and total traffic fatalities by 4%. Uber didn’t set out to achieve that. No product manager came up with an OKR to achieve that. But it still happened. That’s a product having a system-level intervention, and it was unintended. So, I think that’s the only way to work. Build products that have the potential for unintended consequences, and let those consequences emerge as people use them in real life.

Randomness

I listened to this podcast with Matt Ballantine, which completely ticked my boxes for thinking about working in non-deterministic ways.

I thought about:

What are your Whypotheses?

A simple hypothesis is like, ‘if this, then that’. It expresses a cause and effect that says if ‘this’ thing happens, then we can expect ‘that’ other things to happen. And the ‘this’ thing is usually something in our control. But hypothesis don’t explain why we chose the ‘this’.

So, a whypothesis asks, “Why this, if this, then that?” It tries to express intent beyond the simple effect we’re trying to have, to check that the ‘this’ isn’t seen as purely a means to an end, because of the unintended consequences isolated thinking can lead to.

Where do logic models fit

Where does the logic model for a product fit in the decision stack? I think it probably goes either between vision and strategy, if we want to order things by longevity, or maybe it’s better between opportunities and principles, if we think it’s more important to show that it’s foundational and supporting of how all the things above will work.

Whether you show the logic model using north star metrics or impact mapping (a favourite of mine) or theory of change (been exploring this more recently), the point is to help understand which aspects of the product that are within our ability to change, will lead to what outcomes (change in user behaviour) and impact.

Is it a product?

A product is a product if an organisation chooses to treat it as a product, and the best way to decide is to look at the problems it’s tackling. If the problems are well-defined, stable, and have predictable solutions, you don’t need product thinking or the skills a product team brings in tackle uncertain problems, and so don’t treat it as a product. If the problems are new, unknown and the potential solutions are uncertain, then a product team with the skills to apply product thinking are a good way to tackle those problems, and so the organisation should treat those problems as a product.

I did:

• Data analysis, financial benefit modelling and theory of change. I love this kind of abstract intellectual challenge. Sometimes it’s a nice break from all the people.
• Chatted about the idea of long-lived teams versus agile investment. They seem mutually exclusive. If products receive investment based on a feedback loop of the value they return, they can’t have a long-lived team as that accounts of a lot of the cost. And if a team has funding committed so they can be long-lived, and assuming they can’t be easily moved to a different product, then the investment can’t change based on feedback. I wonder which is most valuable in the short or long term?
• Watched a piece of work get and lose alignment, and wondered why. I think it was because different people were involved in different conversations, and no update was sent to those who weren’t to keep them on track. So, I asked myself what behaviour can I change, and realised I don’t write things down so much any more, so I started changing that.
• Chatted to some more product people in another part of the university. I’m fascinated by everyone’s background and the lives they led that brought them to where they are. Everyone has so much knowledge and experience.
• Tried to help someone with building momentum for a piece of work. It isn’t easy to get there but there definitely comes a point where path dependency takes over and it’s easier to carry on than stop.
• Tried to explain what I do. Can’t say I nailed it.

I read/watched/listened:

Shaping Product Culture

No offense, but if these are the people we’re listening to about product culture then we get what we deserve.

Treating people

I watched this video about unreasonable hospitality. The bit that resonated with me was about not treating people like a commodity, treating them like a unique individual so they feel seen. We believe that not treating people as a commodity is good for them and good for the organisation, but why do we believe that? I was watched another video of Russell Ackoff explaining how systems understanding has changed management. We have come to expect that the parts of a system place demands on the system to better meet their purpose. As people, we are parts of an organisation and we expect that organisation to help us achieve our purpose, part of which is being treated as a unique individual and not a cog in the machine. As managers are the interface between the organisation and individuals, they get the job of figuring out how to make the parts and wholes work together.

Work as a product

An obvious but nonetheless interesting idea about how organisational management can consider employees like customers who choose to work for the org and that they should design jobs in the same way they design products. It fits the trend Ackoff explained above about recognising organisations and people as part of a system that all have demands on each other.

Nice

Been listening to Snarky Puppy and Gogo Penguin, because good product teams play jazz.

And I thought about:

Product management capability frameworks

I’ve been looking into and thinking about product management capability frameworks, but most of them and many definitions of product management seem so overly simplified as to be useless to a product manager working in any context other than the silicon-valley-esque ‘company is the product’. So, in true product style, I’m trying to figure out, if a capability framework is the solution, what’s the problem we’re trying to solve? I’ve seen quite a few organisation turn to the idea of standardisation, where every product manager has the same skills, as a proposed solution to that problem. But I think that creates lots of round pegs, which is fine if all your holes are round, but what happens when a square hole shows up. Rather than trying to make everyone the same, let’s make everyone different. Lets have people who have unique specialisms. Lets have people who can learn quickly and adapt. Lets have S-shaped people.

The road junction

I’ve been pondering Simon Wilson’s road junction problem since I first saw it months ago. Here’s my solution: cycling infrastructure, school governors and friends of groups, community action, self-driving cars, smart roads and materials sensor technology, local highways departments learning from and designing with data, better public transport, working from home, relocating local facilities. Create the enabling environment and let the solution emerge.

Flow

Ducts are conduits that enable flow. If you were trying to make the flow better, you’d be a duct manager. If you were really good at it, you’d be a pro duct manager.

This week I did:

All talk

Lots going on this week to get ready for the next couple of months work. And also…

• Second workshop with the product managers to analyse the activities we do and decide whether we should be doing them. Next time we’ll pick a few and come up with things we can do to improve our knowledge in certain areas and then go do more of the things we should be doing. Follow-through is the key here. It would be easy to run a few sessions and then never make the change happen. Keep on keeping on.
• Had a chat about how we improve communication in the team. My simple answer is talk to each other more. And following my own advice I’ve started setting up chats with all the other product people across the university.
• Reviewed this quarters OKRs and set next quarters. We had some nice successes last quarter but are still getting into the rhythm of when to measure to have confidence we’re achieving the objective. It’s like, if we measure in ten years from now we’ll be really sure.
• Chatted about how to manage some upcoming work that’ll have some challenges. My instinct is to go with light-touch coordination, a bit individuals and interactions over processes and tools.
• Talked a bit about dealing with knowledge worker imposter syndrome, because thinking and talking doesn’t feel like work as it doesn’t produce something tangible.

I read/watched:

User needs checklist

Can’t remember where I found this slideshow but I get the feeling it makes much more sense as a talk. This slide has some nice heuristics for good user needs. It got me thinking about how user needs and user stories relate. And I mean user stories as boundary objects, not formulaic descriptions of what we think a user is trying to do. Clearly user stories should be based on user needs, but beyond that, should there be a one-to-one relationship, should a user story try to meet as many needs as possible, can a user story partially meet a need?

Research methods

Lennart Nacke wrote a great post about picking the right research method. He’s right. It’s so easy to just go with what you know rather than understand what you’re trying to learn and pick the method accordingly. I was I had time to spend analysing a whole load of data. I’d really like to validate my idea that product metrics should be constructivist rather than positivist.

Applying Product Thinking To Your Product Transformation

As is John Cutler’s style, it’s less of a talk about applying product thinking to product transformation and more of a stream-of-consciousness through lots of concepts and frameworks with all kinds of insights. I really like his hill climb analogy and how it takes a long time and has lots of false starts to reach the next local maxima.

I thought about:

Why teams should have regular contact with users

One of the assumptions that makes Internet-era product teams different from industrial-era is that teams work in an open system that is constantly changing and they have to respond to those changes. Industrial-era teams assume a closed system, they aren’t affected by things changing out there in the world. One of the best ways for Internet-era product teams to know about changes is to have regular contact people who’s behaviour shows the change. Things like insight reports on customer behaviour, whilst useful, distance the team from the changes users are going through. They make an open system behave like a closed system.

Operationalising working in the open

Stef Webb, posted on Bluesky, ““Working in the open” are there checklists, frameworks, spectrums I can learn from? Often it seems a theory without practice…”

I think, that like health, working in the open is a phenomenon that can’t be understood by itself. We don’t have a way of saying someone is healthy so we look to indicators like BMI, alcohol intake, etc. We also don’t have a way of saying a team is working in the open so we have to look to indicators like blog posts, show and tells, weeknotes, etc.

Obviously you have to be clear about why you’re working in the open, what you’re trying to achieve, because without that its easy to just mindlessly do stuff, but assuming it’s because you want to change the governance model around the work the team is doing, then other indicators might be how many senior leaders attend show and tells (because it tells you they are being taken seriously), how many questions are asked in non working in the open governance ceremonies like steering groups (because the team is answering them ahead of time), does decision-making speed increase in line with the accumulated working in the open artefacts (because more people have the same knowledge when they need it).

Sociotechnical influencers

What if the delivery manager role was modelled on a social media influencer? They would create a personal brand, get well known for being well known, have followers, learn how to influence people, individually and in groups. If delivery managers were like that, then they’d be in a stronger position to bring about change in whatever organisational situation they find themselves.

User journey happylytics

Been trying to visualise a way of reporting the success of each step of a user journey by defining cohorts by behaviour, where one set of actions are the most desirable but there are other sets that for other cohorts that tell us where we need to do work to shift the percentages.

This week, I did:

Horizons

I’m starting to see the future of our product fitting nicely into some well defined horizons which helps with the real roadmap (not the one with features). Also…

• Quarterly direction-setting. And thinking about OKRs.
• Saw a really interesting presentation from our director of marketing about the competitive environment we’re working in.
• Set my personal objectives for the year. You know how I feel about this sort of thing, but sometimes I have to do as I’m told.
• Did some prep for a big presentation in a couple of weeks.
• Started (unpopular) conversations about how we decide if work is worth doing before falling into path dependency of doing it because we’ve started doing it. It’s tempering ambition with the challenges of complexity.
• Chatted about how the product manager’s role involves getting close to the reality, which includes understanding market shifts, organisational politics, priorities and processes, teams capability and capacity, tech debt, data, etc., etc., to help other’s who don’t get to see all those different parts of the picture to be more aligned, make better decisions, etc.
• Added our design principles to my product assessment (along with user outcomes, service standard, delivery progress and eventually financial performance such as ROI).
• Passed my probation, or to put it another way, I’ve been in my role for six months.
• Lots of retros.

And I read:

Building software like hiring a team

David Knott writes some interesting stuff, including thinking of investing in software like investing in hiring a team. It makes a lot of sense and the analogy goes a long way. There’s a hint of posthumanism in there too.

Roads are set, routes are discovered

I completely agree about using roadmaps to tell the story of a product as you write the story, to show the uncertainty and . That message about how product development goes is as important as what is being developed. But the thing about roadmaps is that time is inherent to them, whatever you call them and however you format them. For example, the Next on a Now Next Later roadmap is always taken as ‘what we’ll do next’, not ‘where we’ll go next’.

Common direction, boring magic

Canvases

Lots of canvases here and here. I like canvases for visualising the work and providing limiting constraints. There are a lot of bad canvases that are just boxes on a page, but there are some really good ones that actually get people to put their thinking together in one place.

The SCARF Model for Psychological Safety in Groups

The SCARF Model identifies five key areas that affect how our brain works in social situations:

• Status
• Certainty
• Autonomy
• Relatedness
• Fairness

These 5 areas represent the social needs our brain considers essential for safety and survival. When any of these 5 needs unattended to, or not met, it sets off a threat response in our brain. When the needs are well-attended to, our brain experiences a reward response. I like this response better than the other one.

Who does what by how much

No solution is specified, and customer behaviour is the measure of success, so the team has to discover the best solution for achieving the behaviour change. If they learn that what they shipped didn’t change behaviour, then they try something else.

I thought about:

Enabling environment

An incomplete and not-entirely-thought-through model of things you might have to change to make a new framework work.

Characteristics of teams from different paradigms

	Industrial-era	Internet-era
Governance	Hierarchy	Responsible autonomy
Team structure	Functional	Cross-functional
Purpose	Meet stakeholder needs	Meet user needs
Organised around	Technology	Problem
Focus	Efficiency through standardisation	Effectiveness through adaptability
Scope	Clear division of labour	Whole task
Assumptions	Closed system isolated from its environment	Open system influenced by environmental factors
Theory	Scientific management. Taylor (1910s)	Socio-technical. Trist and Bamforth (1951)

Deproductisation

Not everything has to be a product. In a non-zero interest rate age, organisations have to make very careful decisions about what they treat as a product and where they use more tried-and-tested methods for running teams and systems effectively. A product is a sociotechnical construct. That means it only exists in our minds. Something is a product if we choose to treat it like a product, and it isn’t if we don’t. So, things that just have to happen for an organisation to operate shouldn’t be treated as products. If the problems are well known and there are already established patterns for solving them, there is nothing to be gained from involving product management in trying to discover worthwhile problems. Better to point product managers at areas of uncertainty where there could be competitive advantage.

This week I did:

Drawing boxes

A lot of stuff this week seemed to be about drawing mental boxes to put things in or out of. Kind of a conceptual tidy up, which among other things included…

• Wrote an audit report for how we’ve been using OKRs. That was fun.
• Our product director presented a shorter version of his talk about decision stacks. It’s an interesting concept for helping product managers frame their remit, but like so many frameworks it says nothing about the environment necessary to make it a success.
• Ran a workshop with some of the product managers to discuss what we do but shouldn’t and what we don’t do but should. My aim is that together we figure out what we’ll need to change about the environment we’re operating in and start same safe-to-fail experiments that help others understand what product managers do and why it’s important.
• Chatted about the vision for campaigns on our communications automation platform. It helped me think more deeply about that aspect of the product and how it might affect user outcomes. One of the challenges we’re trying to figure out is how users have a coherent experience of communications when every user journey is unique, and I think the vision for campaigns helps with this.
• Started conversations about how we achieve data maturity as our product scales. Without the data we can’t do anything and I’m not comfortable waiting to see what goes wrong, I’d rather we start improving things now.
• Mapped out two version of the same ‘thing’, one as a product (long-lived, cross-functional team, empowered to meet user needs and responsible for outcomes) and other as (hierarchical, functional team, centred around technology, briefed to meet stakeholder needs and responsible for outputs). It helped me think more about how to define what a product is.

North Star Workshop

I joined John Cutler’s North Star Workshop, which was full of thought-provoking advice as you’d expect. He talked about thinking of north star metrics as a constellation of connected metrics where “Great thing… is a function of… what the different teams input” and how the north star metric is a leading indicator of sustainable success (because revenue is always a lagging indicator). North star metrics very much fits the positivist ontology, which I’m still not entirely sure I agree with. I think the ‘product’ bit of ‘product metrics’ is fundamentally constructivist as it’s about user’s, their behaviour and how they construct their reality around the product. One day I hope to have the time to properly explore this.

Continuous learning

Signed up for all of Teresa Torres’ email courses. Now I just need to find time to read them and see what I might want to apply.

And I read/watched:

Beyond Team Topologies towards Continuous Stewardship

Sketches of future digital services in government

This is very cool. This is what blogging was made for. And Steve mentions our own Kate Ivey-Williams, which is nice too.

The Service Organisation

Started reading Kate Tarling’s The Service Organisation. I haven’t got very far yet but it sparked a thought about the units of analysis that are available for this kind of organisation transformation work (individuals, teams, organisations, products, services).

And I thought about:

pics or it didn’t happen

Documentation is great, but it’s only useful if people keep going back to it. And we know that most knowledge is tacit and can’t be documented explicitly anyway. Talking about the same things again and again keeps them alive.

Risk analysis

Thought about a different way to analyse risk. Rather than the traditional seriousness and likelihood, I wondered if we could use ‘time-to-fix’ as the risk measure. So, for a financial risk, how long will it take us to replace the money we spent if it turns out to be a waste? And for reputational risk, how long will it take to gain user’s trust if we get something wrong? Knowing how likely a risk is might be useful, but it doesn’t really help us decide if the risk is worth taking. Making the consequences of risks tangible might help us make better decisions about which risks we accept.

Homonyms, huh?

I remember being in a show and tell once where the question, “what is service design?” was asked. As the conversation progressed, an IT colleague said that IT had been using the concept of service for a long time. The conversation ground to a halt because it was clear that although they were using the same word, they were using very different meanings. This is the problem with words like service, product, etc.; they have multiple meanings, none of which are wrong, but which no one can agree on. That doesn’t mean we should stop discussing them, but we have to accept and make clear to everyone that to have useful conversations, we have to accept that there isn’t a single definition to be reached. And as always, we should start with understanding what we’re trying to achieve anyway. If a definition of ‘product’ is the solution, what’s the problem…?

I did:

Later

Most of my work this week has been over there in the Later space, a bit for what’s Next, and only checking in on the Now work as the team don’t need me there, which is great. Among others things, that meant I…

• Started trying to understand the Service Standard and map our work to it. Getting advice from the product leaders chat group was really helpful for thinking through how it works in practice.
• Did an ‘Intro to OKRs’ presentation for the marketing team. I really enjoyed it. Sometimes I hate presenting and sometimes I love it and get a lot of energy from it. Perhaps I need to think about what makes situations different and change the energy sucking ones.
• Had a chat about responsibility, accountability and other vague terms. My thoughts are you can’t say someone is responsible for something unless you also say, “what do we need to provide for that person to be successful in being responsible”.
• Designed a workshop for product managers to analyse their day-to-day activities and understand whether they should be doing them and whether there are things they should be doing but aren’t. I’ll be delivery it next week so we’ll see how far we get towards our goal of narrowing the gap between how things are and how the team want them to be.
• Had some thinking time on what success looks like for an organisation-wide capability product that is never finished. My first thoughts are a balancing of user outcomes & OKRs to show we’re working on the right things, delivery status to show how much is done, service standard assessment to show the quality, and financials to show ROI.
• Had one of those last-thing-on-a-Friday-afternoon meetings where lots of things click into place and become clearer. It’s going to be on my mind for a while.

User-centred prioritisation

Went to Product Leader’s discussion on prioritisation where the main theme was around helping people have good conversations because prioritisation is really just negotiation. It’s interesting how we use things like prioritisation frameworks to distance ourselves from those conversations, to make things seem objective and ‘fair’.

I read:

Scoping and Shaping For Success

John Cutler’s mini-book is a collection of thought experiments, mental models, reflection questions, and actionable activities. And it doesn’t contain the word “briefing” once.

Succeeding with OKRs

Read a bit of Allan Kelly’s, Succeeding with OKRs after I’d done my presentation to try to validate how I think OKRs might be best used.

Agile Time Machine

I love stuff like this Overview of the pivotal moments and momentous ideas worth spreading again, and a general feeling of the original essence [of agile].

Better decision making

Top insight for product managers is when Annie is talking about parenting. “Nevertheless…” is a better response than “No”.

I thought:

Some problems aren’t worth solving

In an ideal world we’d be able to make everything perfect, but over here in the real world we have to accept that is never the case. This is where, I think, we sometimes get confused when we talk about prioritisation. There’s a big difference between choosing which problems are worth solving and which order we’ll work on the solutions. If we mapped problems on an Impact/Effort grid rather than solutions, I think we’d see that lots of problems fall into the low impact/high effort (which, in my experience, no solution ever does because people are already invested in it).

Messy maps

Carrying on the theme of imperfection, I like the idea of imperfect, incomplete, messy roadmaps that are closer to the reality of our understanding, rather than the perfectly polished, everything-fits-neatly-into-quarters roadmap. Not sure anyone else would agree.

Better questions

That thing about leadership being about asking questions rather than telling people what to do was on my mind this week. But asking good questions is a real skill. Questions can do so many things; lead people to reach their own conclusions, draw out information, make sense of things. And bad questions do a lot too, they can create confusion if they are vague, out of context or badly timed. Asking better questions is number two on my list of leadership behaviours (after having more conversations with people below their pay grade).

This week I did:

Alignment

Had a day off this week and noticed how quickly some things became misaligned and misunderstood because the necessary discussions didn’t happen on the day I was off. Maybe all the rain interfered with crystal ball because I didn’t see it coming. Other stuff happened too.

• Now that I’ve handed-over a proposed new piece of work to the product manager who’ll be owning it I can work on the next two. These are about user experience and data maturity. Lots of conversations ahead to get support from people and shape the work, which I’m looking forward to.
• A month ago I reflected on not doing enough to support some team members. This week I tried to fix some of that.
• Went into the office twice this week. To be honest, on site meetings have a high bar to make up for the lost productivity of being remote.
• Went to a talk about how we’re using machine learning and generative AI. They are table stakes for large modern organisations. Is AI going to revolutionise everything, no. But it’ll probably change things like content generation and data analysis on a similar scale to how email changed communication.
• Had a chat about a piece of work that had lost alignment with the service it was trying solve for. Made me realise I need to do more to communicate how different things fit together so others don’t feel misalignment in my work. Maybe I need to make my roadmap more public.
• Refined the outcomes (remembering Josh Seiden’s definition of a change in user behaviour that drives business results) we’re working on. Firstly, thinking about how to communicate them and then how to measure them.
• Did a retro for the last four weeks of work. One of the things we talked about was documentation. We discussed what should be documented, where we should store it, etc., etc., but my thoughts are that you don’t need to tackle those kinds of problems until you’ve got into the habit of documenting. Otherwise you can put a lot of time into organising only to find out you’ve got nothing to organise. As with so many product problems, user adoption is one of the most important to solve.

Four principles for great teamwork: communicate, collaborate, contribute, coordinate

Or in plan language: talk to each other, work together, be helpful, check things are going ok.

Updated my roadmap

I reorganised and redesigned my roadmap to help me focus on what might help achieve my goals over the next few months.

Radical Product Thinking

I’ve set myself a goal of doing lots of small online courses, and I started with Pendo’s Radical Product Thinking. It’ll be interesting to think about the difference between the pure practices shown in training and the pragmatic principles that actually work in my experience.

I read/listened:

Risk Schmisk

Beware of the Team Doughnut

Brilliant insight into using the Team Onion to improve how teams work from Sport England.

10 principles for the design and delivery of greener services

A set of principles that aim to guide project teams to design and deliver UK government and public services with lower environmental impacts.

Networks for the win

I’ve previously blogged about how authority flows through hierarchies and information flows through networks, but this article from Corporate Rebels does a much better job of explaining why networks trump hierarchies.

I thought about:

Signals

I thought a lot about signals in teams. And how language, incentives, behaviours, rituals and artefacts signal what work (and often who) is important. What doesn’t get taken as a signal gets taken as noise, and considered unimportant. So that means there is a signal-to-noise ratio to understand within teams.

A crash course in modern work

Wondered about what you’d want to teach someone for them to learn about modern ways of working. I’d definitely include psychological safety, dynamic reteaming, agile, lean. Might make an interesting blog post.