Weeknotes 532
Weeknotes 532
I did:
All of us are smarter than any of us
One of my fundamental beliefs about modern approaches to tackling complex problems is that it needs people to work together. Sometimes that’s easier said than done, but it’s always worth it. And…
- Got product and delivery people together to talk about how we intake and triage stakeholder requests. It was a really helpful honest conversation with no agenda.
- Planned this month’s work with the team (well, actually, our fantastic delivery manager did all the hard work).
- Wrote a proposal for some product practice development.
- Designed a workshop to categorise our products.
- Researched training I might do.
- Wrote up some ideas on how to respond to AI intermediaries.
- Started thinking about product vision, ways of choosing it, and more importantly, what has to be true to achieve it.
- Chatted to our new lead content designer.
I read:
Knowing the right things to say
This article helps explain how empathy is culturally shaped and some of us just don’t get it. Knowing what is the “right” thing to say in every situation depends on being able understand how others are feeling and how what we say might affect that and make judgement calls on a culturally-specific implicit understanding.
Personal Agent Protocol
How agents and organisations might interact fascinates me, so Sierra’s blog about developing a Personal Agent Protocol is interesting reading.
The protocol is an open standard that defines how personal agents interact with businesses, including authentication, observability, etc. It’ll be interesting to see how well adopted it is.
Good neighbours
Really interesting thinking from Jeffrey Miller, product lead on Ask the NHS, about choosing where across the NHS’s digital estate a new service should be used first.
I particularly like the point about products being good neighbours and making each other better. Sometimes products have competing objectives that never really get resolved and make both products worse, so it’s great to see the thinking through of this kind of problem.
I thought:
The law of requisite complexity
After a discussion about strategy, I was thinking about The Law of Requisite Complexity which says for organisations to effectively adapt and respond to the system they are part of, they have to have at least as much internal complexity as the external environment. It explains why universities are as complex as they are, because the environment they operate is as complex.
So, strategically speaking, there are two ways universities can handle the complex environment; try to decrease the complexity in the environment so it matches internal complexity, or increase internal complexity to match the environment.
Actually, there are other strategies, an organisation can reduce internal complexity regardless of the external complexity but that will almost certainly fail so let’s stick to what might succeed.
In practice, a good strategy should try to reduce external complexity whilst increasing internal complexity to create a better chance of the two matching. Choices about which markets to operate in and what to do to affect the market, alongside building capabilities that can adapt quickly to change, affect complexity externally and internally.
The thing that’s sometimes hard to see about building flexible internal capabilities is that they can look simple, look like they are reducing internal complexity rather than increasing it, but really they enable far more variation that does increase internal complexity.
Shadow collaboration
If shadow IT is when people use their own devices and products to do their work despite organisational technology and policy, then shadow collaboration is when people find ways to work together despite organisational silos.
Dashboards are dangerous
In their efforts to make complicated metrics easy to digest, dashboards risk presenting information in ways that make it too easy to over-generalise and reach the wrong conclusion. I saw a dashboard that reported metrics for a website. The metric looked bad, but worse than that, it was meaningless. It was an average from across the website that didn’t recognise the very different use cases for the website, it just presented a number. Good dashboard design is a real skill.
To be outcome-focused you need to know what your users value
People can value many things at the same time. They can value their time spent doing something, money they made or saved, the feelings they get from doing something, the feelings they avoid, what others think of them, theirs and others safety and wellbeing. They can value things now and value things they might get the future. The promise of future value has its own value right now. And so many more things.
So, being outcome-focused (if we agree that an outcome is a change in user behaviour that gets business results) means recognising that you are dealing with complex human beings who have a lot going on when they use your product. It’s far too easy to build a product that delivers one type of value but takes away another. It might save time but reduce trust. It might increase belonging but increase cost. If you don’t know what your users value it’s really hard to achieve the right outcomes for them.
The problem with models
I accidentally found myself in Stewartby this week. Stewartby, in case you’ve never heard of it, is a model village built by the London Brick Company in 1920s and 30s.
Most villages were built organically over time because people settled there a long time ago. Model villages are designed upfront and built according to some agreed vision and principles. All modern housing developments take this approach too, they have certain standards to meet such as how much green space per number of houses is provided.
You can see where I’m going with this, right? It’s a metaphor for product development. And for thinking about what makes great products. How much does big upfront design versus iterative change affects the success of a product? Of course, often that choice is less about what might make a successful product and more about how organisations invest in products (thanks Conway) but it’s still an interesting question.
My bias (and I fully recognise it is a bias) is for small design, iterative development, fast feedback loops, frequent change. But I like to challenge that bias when I find myself in Stewartby.