Author: Roger

I did:

Seeing around corners

One of the less appreciated product skills that I try hard to cultivate is my ability to predict what’s going to happen based on observable signals. A few things I predicted came true this week, and a few more are looking more likely. It’s a skill I keep trying to calibrate and get better at. And did this stuff too:

• Chatted about the product strategy I’ve been working on. I did some more competitor research but still have so much work to do on it..
• Shared the bad first prototype dashboard for our North Star Metric for feedback ahead of presenting it next week.
• Handed over product management of our big bet for one of our products to another product manager. Part of me would have liked to have worked on it but I know he’ll do a much better job of taking it where it should go than I would.
• Wrote some definitions of “validation” and “time-to-value”, which I really enjoyed because it tested my logical thinking.
• Agreed recommendations for what we do next with an AI feature we’ve been testing.
• Got a volunteer to take on managing our analytics capability.
• Brought together different thinking on delivery reporting and product evaluation. Where I’d like both to go in the future is using Bayes to show the probability of delivering on time and achieving outcomes.
• Short-listed candidates for a content role in our service.
• Planned more work. Like I always say about agile planning; I can tell you what will be delivered but not when, or when but not what.

I read:

Know Your Agents

Read Tom Loosemore’s full briefing for Know Your Agent, which he very kindly sent me.

Tom says, “People are starting to send software, not themselves, to deal with your organisation. If that sounds slightly odd, it won’t for long.”

I completely agree. There was a time when organisations thought the internet wouldn’t change how customers interact with them. And then it was mobiles. Now it’s AI. The pattern repeats. Get ready.

I thought:

Loops, not lines: a modern product development process

Most product development processes follow linear steps based on manufacturing processes, often to their detriment. Far too much software gets shipped that that no one wants because once the process starts it doesn’t know how to stop.

I’ve been trying to figure out what a looping product development process that seeks progressive validation of an opportunity (rather than delivering on unvalidated assumptions) might look like.

1. Analysing existing evidence
   1. Evidence quality: Existing research data, not from users, not from interacting with a product.
   2. Techniques: Performance data, previous user research, third-party information, industry case studies.
   3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 2.
   4. Confidence-in-value level: Low.
2. Collecting new evidence
   1. Evidence quality: New research data, from test users, interacting with a test product, with an intermediary.
   2. Techniques: User interviews, prototyping, observation study, fake door tests.
   3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 3.
   4. Confidence-in-value level: Medium.
3. Generating real user proof
   1. Evidence quality: New usage data, from real users, interacting with a test product, without an intermediary.
   2. Techniques: MVP, split, concierge and wizard of oz tests.
   3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 4.
   4. Confidence-in-value level: High.
4. Collecting proof at scale
   1. Evidence quality: New usage data, from real users, interacting with a real product. without an intermediary.
   2. Techniques: Data analysis of a large user base, performance data that signals continued, repeated use or a pipeline of new users.
   3. Decision: Continue to invest in supporting the product.
   4. Confidence-in-value level: Very high.

This approach tries to fit with the stuff I go on about the job of product management tools is to filter out the ideas that won’t work. If there ever was such a tool, it might be based on this concept of progressive validation.

Disruption-proof

Are any industries not susceptible to disruption, and is higher education one of them?

We know what the pattern of disruption looks like. A new market entrant provides an offer that looks worse than the incumbent offers, attracts a new audience, builds momentum and investment to grow, provides a different or better offer to the incumbents audience and steals enough of them to make the incumbent fail, and the new entrant becomes the incumbent and sets the direction of the category.

That model works for fairly straightforward industries such as mobile phones (Nokia and Apple), watching movies (Blockbuster and Netflix), but the higher education industry is far more complex and extremely difficult for new entrants to unbundle in a way that creates a disruptive offer.

Universities bundle many things in tightly-knit ways; learning, accreditation, making friends, choosing a career, finding a partner, shaping identity, growing up, changing careers, having a sense of achievement, and so much more.

I think that bundling lots of things together in a tight-knit way where everything connects to everything else, makes universities really difficult to disrupt. Those that say things like, “YouTube is free university”, don’t get what a university is. This also means universities have no need to innovate on their business models, but then again, do they need to?

Sociotechnical systems change mechanisms

When we talk about change, what things can we actually change within an organisation? Sociotechnical systems theory gives us a broad framework of six areas so I listed all the changeable organisational elements I could think of within them.

Goals:

• Vision
• Strategy
• Prioritisation
• Target-setting
• Performance measures
• Governance

People:

• Recruitment
• Role design and responsibilities
• Reward and recognition
• Management and reporting lines
• Coaching
• Training
• Community
• Incentives
• Motivations

Process:

• Workflow design
• Policies

Technology:

• Tool utility (how well does it do the job without workarounds)

Culture:

• Leadership behaviour
• Communication
• Storytelling
• Role modelling
• Shared norms

Infrastructure:

• Workspaces
• Facilities
• Equipment

So, if you want to have a well functioning organisation, you need to get all those things right in ways that they don’t contradict each other.

Copilot notebooks

Microsoft might have actually found a way to make OneNote useful by connecting it to Copilot.

I did:

Happy new year

This week is the start of our new financial year. It’s one of those things that makes a big difference and no difference a all at the same time. Anyway, this stuff happened too.

• Interesting chat about mapping product capabilities to architecture patterns.
• Improved my opportunity analysis spreadsheet as the first step towards bringing the work of different teams into one place so all the product managers can see it.
• Wrote my quarterly objectives.
• Set up a workshop for the team to pitch ideas for future work.
• Had a good chat about whether org change work is a product manager’s responsibility. My take is that our job is changing behaviour, and sometimes that includes our colleagues behaviour.
• Started planning the business change and rollout of a new product.
• Did a first-pass walk-through of the strategy I’ve been working with another product manager. Got some useful feedback ahead of presenting to a group in a couple of weeks.

I read:

Your decision queue is your delivery problem

‘The work’ is only wasting time waiting if you think decision-making isn’t the work. But in product work, making the right decisions with the right people is the work. That carries a coordination overhead and demands due diligence, all of which takes time. So, this raises questions like, should we speed up decision-making, how might we do that, what might the risks and implications be if we did?

Agents are coming

And honestly it is one of the things that keeps me up at night. I’ve read lots of stuff this week to try to get my head around what it might mean for all our products and the scale of change is mind-blowing.

Agent experience

David Hoang talks about Mathias Biilmann’s concept of Agent Experience and bringing it together with user experience and developer experience to build systems that work for all three. As is often the case with new things, it’s important to figuring out what makes it different. The example David gives is how intuitive slide-to-unlock an iphone is for humans that have fingers and understand what touch is, but wouldn’t make sense for an agent.

Know Your Agent: Why you should act now, to avoid playing catch-up later

Tom Loosemore calls for large public sector organisations to start figuring out how to deal with AI agents interacting with them on behalf of people. He asks two important questions about who sent the agent and what authority does it carry. There are going to be so many more important questions to answer over the next few years.

Agents Week

Lots of interesting posts from Cloudflare about agents.

I thought:

What does AI mean for product operating models?

I’ve been pondering this question because of various conversations around operating models that haven’t considered the effect AI (I don’t just mean the tech, I mean social, economic, process, etc.) is going to have.

Generally speaking, the reason to move to a product operating model was to adopt a more cost-efficient ‘build once, sell the same thing to lots of customers’ approach because the economics of software on the Internet allow that. The project operating model that companies were trying to move away from didn’t have those economies of scale because software was customised for each customer. I think AI reverses that. It will allow companies to produce software that is customised and personalised for customers at the speed and economics of the build once approach.

Of course there are lots of ways to think about product operating models but as an example to see how an AI operating model plays out, lets take Itamar Gilad’s framework:

• Research – AI enables more research to be done more quickly, and analysed in ways humans can’t, to produce insight into new opportunities. Being able to connect market trends with user research reports with analytics data to identify and audience segment with specific emerging needs was really hard to do before. AI can do it, and it can do again and again to find niche after niche an organisation could serve.
• Strategic context – Then comes picking from those opportunities to ensure they take the organisation in the right direction. AI has an analysis role to play here too that changes how organisations pick the right opportunities. It’s not the ‘more, faster’ of Research, it’s
• Goals and metrics – I see this as the more challenging change for/with AI because with most of the other aspects of the operating model there is no single right answer, but with metrics there is, and that’s not AI’s strength (yet). So, maybe the way AI changes this part of the operating model is to pressure organisations to sort out their data.
• Discovery – I think AI changes discovery in the same way it changes research. Get more done faster. Discover worthwhile problems-to-solve in real-time, as they emerge, in new niche markets.
• Delivery – There’s already lots of stuff out there about whether AI coding does or doesn’t make software delivery faster, but given how much AI companies are going after this I can’t see a future for software development without AI. If this really does change the economics of software development then delivering on multiple opportunities at the same time becomes a reality.
• Go-to-market – AI can definitely accelerate the planning and asset creation for taking a product to market.
• Operations and infrastructure – AI is already playing a part in managing product infrastructure and that only looks like it’ll get better and better.
• Culture – AI makes us all generalists. That leads to a very different organisational culture than one that values specialism, expertise, seniority and experience. I’m not idealistic enough to think that makes for better culture, but it will be significantly different in ten years as incentive structures, career develop opportunities, who we work with, and who knows what, catches up with the change.

If we look back at the narrative around building products over the last few years it’s been about ‘big bets’, ‘one vision’, ‘single strategy’, all stuff that suggests a unified alignment towards one thing. AI changes this, shifting it towards multiple narrower, and possibly even temporary, focuses for organisations.

Really Simple Sharing

Why is there no platform for sharing and swapping your RSS feeds? Someone build it for me, I don’t have the time. And in the meantime, here’s mine.

I did:

No off switch

I was on leave this week but I got a bit bored (intellectual stimulation is one of the good things I get out of work) and a few things needed progressing, including:

• Laying out an approach to creating a product strategy that focuses on making choices about market opportunites. Still lots more to do on it, but I’m aiming to present it to a group of product managers in a couple of weeks.
• Having an interesting chat about data protection impact assessments and how much risk we’re willing to accept. Risk, much like prioritisation, just doesn’t work in a spreadsheet. There’s too much context to consider.
• Planning out my priorities for the next quarter. I’m working on two big products, a small one, a bunch of improvement initiatives and lots of coaching. Luckily for me, I have two years of productivity data which I used to set my goals and capacity for each piece of work.
• Having a budget meeting for one of our products. I’ve got some complicated sums to do next week.

I read:

The end of competitive advantage

Got a signed copy of Rita Gunther McGrath’s The end of competitive advantage. The premise is that too much strategy thinking is about creating a one-time sustainable competitive advantage and that organisations would be better served by being able to quickly move on temporary advantages.

Systems thinkers at Netflix

Management Tips on Setting Strategy When the Path Is Unclear

See now, this is part of the problem. The headline says “setting strategy” but the article is about organisational change, not strategy. There’s nothing about how to look outside the organisation, understand the market, and respond in a way that gives the organisation a competitive edge. And then we wonder (or at least I do) why managers can’t do strategy and mistake it for org change.

(Thanks Emily Webber for the link)

Disappointed designers

Christina Wodtke on cursed problems, conflict and contradiction, “AI lowered the floor of what anyone can produce, but it didn’t raise the ceiling of what’s good.” So, what does?

Bundling and unbundling

Interesting idea of using bundling and unbundling to explain role change within an organisation. It’s a well-known approach to building products, so I’m trying to figure out if it might actually explain and predict how roles might change by accident and on purpose. If it does, that it could make a really useful tool.

User Journey Mapping: a practical guide

Nice guide to user mapping. My problem with this approach to user journey mapping is that it’s too vague to be useful. Any of the steps could easily be replaced by a different step without making much of a difference. And that lack of making a difference is a sign that the journey map doesn’t take a strong enough stance to be a useful decision-making tool.

When I talk about user journey mapping I explain how every change of state is a step to the right along the journey. And every crossing of a system boundary is a move up or down the map. This means that the knock-on effect of any and every change can be seen throughout the map. Change a link in an email and the map shows you which web page traffic now goes to, which analytics tools track it, which dashboards get updated, what actions a user can take on the page, which database records a form submission, etc., etc. That kind of user journey map is actually useful.

I thought:

Everyone has their own system

I went to the farm shop early, just as the lady behind the till was setting up (they have the best grapes). She couldn’t find the till roll and said she wasn’t working yesterday but the person who was would have put it somewhere that made sense to them. She offered the insight, “Everyone has their own system”.

Everyone in every organisation has there own system that makes sense to them given the organisational systems around them. Even if there is a well established procedure, the people following the procedure have their own system.

When you see organisations and work through this lens you can only conclude that variability is a fundamental feature of the whole system. The idea of standardising out the variability is risky myth because it hides how things really are.

Product workflow

A while ago, after a chat with a company that was trying to build a tool for product management, I wrote up some initial thoughts on what I want from a product tool. It’s been bubbling away in the back of my mind and recently I’ve been trying to distil it into a simple explanation.

The difference between what a product management tool needs to provide, and what almost every workflow management tools provides is the difference between filtering out and everything going through.

All workflow management tools based on kanban boards come with the assumption that everything on the board has to get from left to right. Anything not in the right-hand column is considered unfinished and that’s bad. Those are fine assumptions for workflow management but they don’t work for product management.

A product management tool would be based on the assumption of having to filter out items because they don’t match the user research or strategy. In this tool, the more things left behind the better because it means we’re being focused, but it should be for rational reasons.

And this is one of the ways I see AI changing product management in the near future. It allows for faster customer and competitor research and analysis, which means far more opportunities can be considered, which means the bar for honing in on the right strategy goes way up, which means we need tools to do the filtering.

I did:

Loops

Lots of talking and thinking about feedback loops this week (and I started using Microsoft Loop a bit more, but that’s just a coincidence). “Loop” is a fundamental, first principle concept for product management and yet it’s so hard to get right. Anyway, did this stuff too…

• Saw some great leadership.
• Talked about strategy and org change as two sides of the same coin with strategy being about looking outside the organisation and org change looking in.
• Had a few good coaching sessions, particularly about the meta work we have to do so we can do good product work.
• Spent some time on data protection impact assessments which will improve how we handle compliance in the future.
• Brought our simple, consistent way of managing product work to two pieces of change work, so I’m interested to see how well it applies.
• I’ve got next week off which gives me time to step back and replan all the different things I’m working on and think about building the case for something new.

I read/watched:

Shipping Is Your Company’s Heartbeat

Charity majors writes about a letter to CTO’s “explaining why all their grand ambitions and goals with AI are blocked behind their organization’s’ ability to learn.” True, but I’d go further and say all leader’s ambition are blocked by an ability to learn, not just AI. Shipping software is only one way to learn, their are many more. The letter ends with, “If shipping is your heartbeat, then understanding is your breathing.” I want to understand more.

Theories of power

I think it’s hard to successfully navigate within an organisation with a theory of power, i.e., a mental model for who influences who, how decisions get made, which groups have aligned interests, etc. There are lots of definitions and different theories of power, but the pluralist one resonates most with me, particularly the characteristic of countervailing, where groups of similar power cancel each other out and prevent or slow progress.

How People Work, Live! … with Jukesie

Designing in the dark

Lots of great advice from Audree Fletcher on working with stakeholders and convincing them to support your work.

I thought:

Fixing things

Years ago, I had an argument with a developer about a bug in a product. He said it was “working as expected”, to which I replied that his expectations were wrong. Sometimes things can be working as expected but still be wrong, and sometimes they might not work as expected but still be right.

Four P’s of approaching situations

What kind of approach does any given situation need to give us the best chances of success?

	Pragmatic	Purest
Principles	Immediate action is required but it is unclear and so needs guidance to direct figuring it out	The way forward is ambiguous so the guiding principles need to be figured out.
Processes	The specific actions are already known and there is a high likelihood they will be successful.	The way forward is clear but doesn’t yet exist so it needs to be built.

Each has its place, one isn’t better than the other, but choosing between them is important for approaching situations in the right way.

I did:

Outcome-focused

We’re putting lots of time and energy into being more outcome-focused. It’s something I really believe in because of what it means for meeting user’s needs, for what it means for teams and trust in their expertise, and for what it means for efficiency within organisations.

• Got back into planning my week which I’ve been a bit slack on recently but think I should practice what I preach.
• Set up a wiki for a piece of work, which is another thing I preach.
• Did some more detailed capability mapping against one of our products. Next steps are to analyse the current investment into each capability.
• Prototyped a dashboard for reporting our north star metric.
• Talked about outcome-focused roadmaps that give teams the space to explore different ways of achieving goals.
• Talked a lot about analytics, metrics, measurement and, most importantly, insight.

I read:

The portal trap

Not just because everyone else is reading it, but because it’s an interesting perspective on the kind of solutionism that is the arch nemesis of user-centred design and product thinking.

The cost of ambiguity

Super insightful point from Holly Davis about how it used to be that the good practices we’ve known for a long time can reduce ambiguity could be ignored because people thought they were good at dealing with that ambiguity (they’re wrong, but that’s another point), but now AI is part of the picture, and it doesn’t deal with ambiguity very well at all, all those practices take on another level of importance.

I thought:

How to make outcome-focused roadmaps work

Outcome-focused roadmaps are a great way to balance an organisational need for predictability and financial planning with giving product teams the scope and space to understand problems and solve . But creating outcome-focused roadmaps requires a different approach than the usual approach of specifying deliverables on a roadmap.

1. User journey – Map the actual user journeys at a task level so you have a clear representation of all the actions users do as they use the product.
2. Organisation objectives filter – Look across the data behind the user journey to pull out which are the most important parts for improvement.
3. Outcomes – Write outcomes for the important parts of the user journey that should be improved. When we say “outcomes”, we mean Josh Seiden’s definition of “a change in user behaviour that gets business results”. We can phrase outcomes as “who, does what, by how much”, e.g., new visitors view three pages 15% more than they currently do, or, logged-in users convert through x journey in less than 30 seconds, or, users from the US provide marketing consent twice as much as they did last year.
4. Roadmap – Place those outcomes on your roadmap. Assuming you use a Now Next Later format, then everyone can see that the priority right now is new users, with the US market something for the future.
5. Hypothesise ways of achieving outcomes – The vital part about expressing outcomes in the way we do is that it doesn’t tell the team what to build. It tells them what to achieve and lets them figure out lots of different ways to achieve it. The team might come up with five hypotheses for reducing the time taken for logged-in users to get through a journey, but they aren’t committing to delivering all five. They can decide to deliver one and see what effect it has before they decide what to do next.
6. Deliver one/some of them – The team delivers on one of their hypotheses. They probably picked the one they thought was most likely to reduce the conversion time.
7. Measure – Then the team measures the shipped changes. If the outcome has been achieved, then you go to 4 and pick up what’s next on the roadmap. If the outcome wasn’t achieved, they go to 5 and pick another hypotheses to deliver. This way they continue to work on an outcome until it’s achieved, but are efficient in only doing the right amount of work to achieve it.