Weeknotes 512

I did:

Move fast and brake things

This week was a lot about quickly figuring out what to stop. Or why that work started and whether it’s right to carry on. That involves lots of talking to people, getting different perspectives, looking at data, considering end-to-end, and making decisions about whether to speed up or slow down. Did this stuff too:

  • Presented new opportunities to stakeholders, all of which they approved thanks to the solid thinking our product managers did.
  • Talked about doing cohort-based reporting so we can see the difference between users who are successfully completing their enrolment and those that aren’t.
  • Worked on a marginal gains strategy. There’s lots of thinking to do that will help us focus on the right things in the right way as returns diminish.
  • Avoided a sabotage moment.
  • Started planning the next six months of roll-out for one of our products.
  • Used Microsoft Planner to organise some work. It’s changed a lot so I might have to update my guide.
  • Did some interviews for a senior product manager role.

I read:

Rhizomes FTW

I love rhizomes. It’s my go-to mental model for organising without a centre, so it was great to read two things this week about rhizomes. Rachel Wood exploring rhizomatic service design, thinking about services as non-linear, interconnected, adaptive ecosystems that are constantly evolving. And Steve Messer shared some links to interesting thinking about rhizomes.

Continuous Discovery Habits That Actually Work

Listened to Melissa Perri’s round out of continuous discovery habits. Made me realise how much I miss the pace continuous-x work, but also how it’s only appropriate in certain circumstances.

Product strategy

Watched Ant Murphy’s talk about product strategy, which was cool and all, but like so many talks/posts/articles about product strategy, talk about what it is rather than how to do it. I don’t think I’ve ever seen anyone explain how they created a product strategy. It’s both strange and understandable at the same time. Strange because of how much a product manager’s job is about product strategy, and understandable because strategy is an ongoing emergent thing that is difficult to explain.

I thought:

Moving the goal posts

The problem with the metaphor is that in sports the goalposts don’t move, and so moving them is considered unfair. In business, the goalposts move all time and that’s a good thing.

The difference between wrong and getting righter

Ignore the grammar, it was never my strong suit, but I was thinking quite a bit this week about the difference between unitarist, binary, right/wrong thinking and the idea there is an end state to be reached; and pluralistic, more or less right thinking that recognises constant change as the norm. These co-exist but they feel mutually exclusive. You can’t have both and not have them conflict each other because they see the world in completely different ways. And there doesn’t seem to be any way to reconcile that conflict without changing people’s entire paradigm. It’s an interesting meta-problem.

MOPEDD teams 🛵

We’re experimenting with hexagonal teams (which is obviously twice as good as a trio). These teams that have six roles; marketing, ops, product, engineering, design and delivery. Putting people together is easy. Helping them reach a shared understanding is going to be the hard bit, so I’ve been pondering the different concepts and perspectives each role brings and how they might fit together. Maybe marketers think about audiences and campaigns, whereas maybe designers think about users and journeys. Where is the overlap in these concepts that helps create common ground and shared understanding?

Weeknotes 511

I did:

HSLD

Universities have an annual cycle of students enrolling, starting studying, completing their first assignment, etc. It’s a cadence that drives everything else that happens. It gives us product people focus but means if we don’t ship in time, our work isn’t going to have impact for a whole other year. This week has mostly been about:

  • Discussed service-level KPI’s, including switching our thinking from funnels to cohorts. I’d like to mock-up a dashboard to help me get my head around it but I doubt I’ll get time. Luckily, we’ve got fantastic data analysts who do a much better job than I would.
  • Reviewed a whole bunch of new features as part of a fixed scope piece of work. Sometimes I think we’ve been convinced that agile is the only way to do things right, but it’s just not true. Right tool for the job.
  • Pushed a couple of ideas forward through technical feasibility analysis that have been suffering from a flow efficiency problem (small pieces of work with lots of time in between them).
  • Kicked off some new work with a new way of working for product managers. It’s going to be a challenge to do quickly but it’s an interesting part of repositioning product managers as responsible for outcomes (changing user behaviours in ways that get business results).
  • Enjoyed a coaching session talking about outcomes.

I read:

Webinars

Watched Jeff and Josh’s webinar on prompting AI for outcomes using their ‘who does what by how much’ template to generate ideas for achieving that outcome. And I watched four four’s webinar on using AI to organise and analyse customer feedback.

You can’t fake belonging

“The best organizations don’t just give you a paycheck. They give you a shared language, a sense of purpose, a reason to show up that transcends the specific task in front of you. That is not a recruitment tagline. That is, increasingly, a documented competitive advantage, and it is built, or destroyed, one interaction at a time.” Interesting points about the effect a sense of belonging has personal and organisational performance.

Shipped Isn’t Solved

“…speed is an amplifier, not a strategy. It amplifies whatever you point it at. If you point it at a deeply understood customer problem with thoughtful design, you get to a better product faster. If you point it at a half-understood problem with no design thinking, you get to the wrong answer faster.” Arguing that adoption is the biggest constraint, which I agree with, and that’s why product managers care about time-to-value, not time-to-delivery.

No rules rules

Trying to get back into using my Kindle for reading so I bought Reed Hastings and Erin Meyer‘s No Rules Rules. It’s about how “Hastings rejected the conventional wisdom under which other companies operate and defied tradition to instead build a culture focused on freedom and responsibility, one that has allowed Netflix to adapt and innovate as the needs of its members and the world have simultaneously transformed.” The implication is that organisational culture positively correlates with business success, which is impossibly hard to prove.

I thought:

Shots on goal

One of the problems with product managers working on the same product for a long time is that it often means they don’t get to build up the experience of dealing with different problems. I think, the more shots you take, the more you goals you hit, and the better judgment you develop from the experience of winning and losing. Maybe the measure of product managers is how many how shots on goal they have.

Decisions in the garbage can

It’s an unfortunate metaphor because it suggests everything in it is rubbish and that’s just not the case, but the garbage can model is a really useful for thinking about how decision-making works in organisations like universities.

In the garbage can, decisions take a long time to be made, involve lots of people with lots of different perspectives, they change as they are being made, and they don’t always stay made.

At first glance, that seems like an ineffective way to make decisions, and the obvious way to improve it seems like it would be to add structure, process, documentation. But garbage cans resist that. The only way to make decision-making work in the garbage can is through relationships, discussion, influence, negotiation.

Jonah Berger, in his book Contagious, says ideas move through people and culture in predictable patterns. They spread like social viruses through networks, relying on human psychology, social dynamics, and the environment. Decisions are the same. Decision-making in the garbage can relies on having a mental model for how things work in the garbage can that closely matches reality.

What if bottlenecks are release valves?

Not quite sure what I mean but I was wondering what would happen to a system of work that had no bottlenecks, one where everything flowed at maximum capacity all the time. Sounds to me like it might have some knock-on effects, so maybe the bottlenecks serve a purpose.

Weeknotes 510

I did:

Focus

Focus is such a hard thing. We all know we need more of it but can’t really say how we’d know if we had it. Is it fewer things? The right things? Short-term or long-term things?

  • Went to a session on this quarter’s focus.
  • Worked on two features without following any kind of phased product development process because I want to understand what difference process makes.
  • More encouraging product managers to hustle and pitch and explore opportunities.
  • Planned out operationalising a new product including process design for the team that will be using it.
  • 16% of my time this week was spent in one-to-one conversations with product people because I continue to believe it’s the best way to create change.
  • Had our half-yearly business review with senior stakeholders.
  • Talked about how product managers are positioned with an organisation, especially as part of org change initiatives.

I read:

Conversational design

Scrum as governance, not delivery

Fantastic write-up from Simon Wilson on Dave West’s (CEO of Scrum.org) talk at Agile Yorkshire about on What happens to Scrum in an AI world. Does it become a governance framework rather than delivery?

I thought:

Coherence

Grace Kwon shared her service design 101 course curriculum which centres the idea of mapping. It made me think about what central theme I’d choose for a course on product management and I chose ‘Coherence’. That’s what I think product managers try to achieve, and what makes what we do different to project management, which is about coordination. Coherence is the “logical connection, consistency, and fitting together of parts to form a united whole, whether in ideas, text, or physical systems”. It’s the closest I’ve come so far to a unified theory of everything for product management that helps us understand the a product is made up of architecture, budget, data, process, etc., etc. All different kinds of things that have to work together in complementary (or at least non-conflicting) ways.

AI-enabled PDF’s

Yeah, that’s a thing Adobe released. Why, you may ask. Obviously there’s the ‘sprinkle AI everywhere’ answer, but I think it shows us something else about products that are designed to be used in lots of different ways; they are more open to misuse. The only reason you might need AI to summarise the contents of a pdf is if the pdf has too much poorly structured information in the first place. If you create products without any guardrails then users can use them in all kinds of ways that end up ultimately not achieving their goals (which in the case of a pdf might be to present information). It’s an argument for product managers having a strong stance about their products.