Weeknotes 340

This week I did:

Value, direct and indirect

The majority of our work at the moment is internal-facing. This is an interesting conundrum for me about how we deliver value to our users. There’s an obvious argument to be made for “fixing the plumbing” now in order to provide more value later, and I’m a believer when it comes to creating the right environment for products to be successful. Perhaps a problem occurs when user value and internal work becomes mismatched, and user value becomes tomorrow’s promise. I wonder if there are any signals to show that mismatch, and how you’d get the two aligned.

One of those internal things I’ve been working on is an incident management system. I’m keen to try out the CASTLE framework (Thanks, Jonathan) to help make it as easy to adopt as possible. One of the things that make this system interesting to work on is that it’s really low volume and yet needs to be really really reliable and robust. It’s almost the opposite from a user-facing product where the number of people using it is a fundamental measure of success. But the outcome goal for this system is to drive process and policy improvements that mean the system never has to be used.

Irregularity

I haven’t written an Irregular Ideas newsletter for a few weeks. Life stuff was more important, and the pause has helped me think about why I’ve been doing it and what to do next. I wanted two things from it, one was to be a place to explore ideas around how humanity and technology affect each other. That’s such a broad topic that I would never run out of things to talk about, even though I sometimes struggle to find an idea that interests me enough to spend a day learning and writing about it. And the second thing was to develop a writing style and improve how I express these ideas. I feel like writing the newsletter has helped with both of these, so my question for myself is whether those goals are still motivating enough to carry on with the newsletter.

I read this week:

Delivery Management

I’ve been (slowly) reading Jonny Williams’ Delivery Management. I have this idea that Delivery is about behaviour change within an organisation and Product is about behaviour change outside an organisation. Although they use very different approaches and techniques, the interesting question for me is how connected those two behaviour changes are or can be. Does excellent Delivery Management lead to high-performing teams, which leads to better products, which leads to changing user behaviour? Or is there no causal connection and team performance has very little impact on the success of a product (because other, usually external, factors have over-sized influence). Jonny’s book is helping me figure that out.

Product enablement principles

Another great post by John Cutler. Timely for me as I shape up my thinking about creating the right environment for successful products. John said, “You have to make it easy to do the right thing. At first, people will manually do stuff (you have the early adopters). But later on, you need to nurture the systems and tools that will enable everyone.” We’re at the stage where we need bring more consistency and predictability into how people use systems as part enhancing our capabilities.

Faster, sooner, righter, wronger

I listened to the Troubleshooting Agile podcast about going faster by starting sooner. I like the point they make about learning faster through moving faster. And Kimber Lockhart wrote about not creating a sense of urgency and fostering a sense of purpose. These aren’t competing points of view, just vaguely connected around the theme of speed. We’ve know purpose is important since Dan Pink’s 2009 book Drive introduced the concept of Autonomy, Mastery, Purpose in motivating us to do good work. And McGregor’s work in the 1960’s developing theory x and y of management has helped us understand some of the management thinking behind creating a false sense of urgency. And then there’s the critique of the “twice the work in half the time” notion that agile is synonymous with working faster, which is or isn’t true depending on how you look at it. Basically, speed is a complicated concept. I think teams need to know how to go fast before they can make choices about setting the right speed in different situations.

And I thought about:

Ernest Dichter is the father of user research

You know how I like to get to the source of things (boundary objects are the source for user stories, this paper is the source for the big product risks)? Well, I wonder if the field of user research and product discovery has it’s roots in the focus groups and consumer behaviour analysis that Dichter created in the 1950’s. Dichter took observational research methods from psychology, applied to businesses, and used them to understand the beliefs and attitudes that explain why people behave the way they do. This new understanding was used to create the advertising industry, which Dichter has been heavily criticised for, but it’s also what gave rise user research and product discovery. It’s interesting that techniques developed to manipulate people seventy years ago are still being used today under the guide of being “user-centred”. I wonder how much has changed.

Looking around

I’m tending towards accepting the success for teams, products, services and probably entire organisations is mostly down to how they notice and respond to what is going on around them rather than within them. When we look around outside and bring what we see back into the organisation, we create a porous membrane. The hard bit is knowing what to do with that information, figuring out what is relevant, deciding how to respond to it. That’s the challenge to success.