Weeknotes 465
I did:
Expected future value
I realised this week that most of my product management work is underpinned by an unswerving belief that we can create a better future. Solve problems for users because it will make their future easier. Set-up tools and process because it will make the team more effective in the future. Coach people because they’ll do better work in the future. Everything we do is the promise of a better future. Here’s some stuff that is now in the past:
- Grouped up a few problems of the same type so we can try to solve them together in a consistent way, rather than individually and differently. It was a good lesson in looking for the patterns and knowing when to change approach.
- Chatted about finding the right problems to solve and how they are usually non-obvious. Also, when it comes to strategies for solving problems, expected future value sooner and later matters.
- Joined a demo for Monday Dev. Made me think about how solutions are easy and organisational momentum pushes us to prematurely pick solutions.
- Had a surprisingly good session about setting up ADO, which is not usually the most interesting topic, but branched off into discussions about agile, ways of working, and organisational change.
- Wrote a short story about an imaginary team creating their product strategy and setting OKRs. I haven’t really used it yet but I’m interested to find out if something like this helps people understand differently to instructional content.
- Won a small victory for plain English.
- Went to EduCamp in Sheffield. It was awesome. Spoke to lots of wonderful people and learned so much.
I read/watched:
Are we more creative when under pressure?
No, according to this HBR article on creativity and deadlines. The pressure of deadlines doesn’t help people be more creative, which is worth considering when tackling complex problems that need creative thinking.
Platform as a Product: Building Trust, Not Just Tools
More goodness from Ragan McGill. Treat your internal platform like a product – with a clearly defined value proposition, customer personas (your engineering community), feedback loops, and success metrics.
The feature factory strikes back
“A Feature Factory is a team that exists to ship features. Not to solve problems. Not to deliver outcomes.” But I’d like to offer an alternative perspective; optimising on known solutions. If you manage products for a large organisation with a well-established product suite and no new problems to solve, then the feature factory is probably the most efficient and effective configuration for your product org, because the goal isn’t to have leading edge product practices, it’s to have business and user impact.
OKRs and impact-first product teams
Feel like this is going to be my go-to video over the next few weeks.
I thought:
Lots of thoughts this week. Don’t know why, maybe it’s the weather. Some of these should probably be blog posts in their own right but we all know I’ll never get around to that.
Tendencies
Rather than processes, principles or practices, I think I’d prefer tendencies. Tendencies say, all things being equal, we tend to do this rather than that, but if things change we’re not locked in.
When to use GenAI
I don’t get why people are still getting worked up about GenAI making stuff up and getting stuff wrong. That’s exactly the point of it. That’s what the “generative’ part of Gen AI means. Maybe we should be better at using tech for the right things.
| Known solution/answer | Unknown solution/answer | |
|---|---|---|
| No verifiably correct answer | Use GenAI. E.g., what should be included in a business case. | Use academic discourse. E.g., what’s the best approach to education. |
| Verifiably correct answer | Use established knowledge. E.g., how to calculate the circumference of a circle. | Let the experts figure it out, come back later. E.g., what’s going on inside black holes. |
Standardise
External-facing product management is all about experimentation. Experimenting your way to market-fit via viability, feasibility and usability. If you’re not experimenting to learn what users actually need and will use, you’re just guessing (I don’t mean you personally, I mean the organisation you work for). So, what’s the equivalent for internal products? Standardisation, maybe? Internal-facing product management is focused on standardising the interface, functionality and usage of a product to meet the needs of the organisation.
And as they start at opposite ends of the experiment-optimise-standardise spectrum, we could say that experimentation is about changing the product to meet user needs, and standardisation is about changing the user need to meet the product (so everyone does things the same way).
Defining a product
I’ve been thinking about how organisations define products so they can talk about them coherently and not get confused between what’s a product, what’s a piece of technology, what’s a channel, etc.
I start from the stance that a product is the sum of other things. And, so far, my incomplete list of those things has six categories that make up a product, and for something to be defined as a product, it requires all six to be involved.
| Thing | Examples | Reason |
|---|---|---|
| User need | To purchase a car, to record information, to listen to music. | Solves a worthwhile problem. |
| Value exchange | Payment, data, attention, action. | Users, customers and organisation get something they desire from each other. |
| Channel | Website, app, email, phone, API, etc. | Interfaces between the user and organisation. |
| Technology system | CRM, CMS, ESP. | Enables structured transactions at scale and speed. |
| Organisational capability | Data analysis, order management, payments. | Brings together and uses multiple organisational capabilities. |
| Business logic | Market & customer choice, pricing. | Surfaces business decisions in codified, repeatable ways. |
Some implications of this definition:
- Multiple products can use the same channels or technology systems, or organisational capability.
- Different products within the same organisation should have different business logic and user needs, those are the things that make one product different from another.
- How organisations organise their products across channels, capabilities, etc., helps them understand commonalities.
- Parts can be changed and replaced, but the product continues to exist.
- This definition make the goal of product management to bring those things together in coherent way. Product manager roles have different responsibility coverage in different organisations. Some have more focus on particular aspects such as being a specialist for a technology system. I think this might be because organisations like to feel that people have something tangible to say they manage, but they are doing all the other stuff too, it’s just not so visibly.
Things to think about:
- Should Data be the seventh thing?
- What would a mapping of the different parts look like to show how things overlap?
- What other characteristics might sit alongside the parts to help people define products, e.g., long-standing, focused on outcomes, etc.?
- How could this be tested to find out how useful it is?
Digital transformation = Organisational codification
Heard an interesting definition of digital transformation: converting organisational structures and business logic into a machine-readable format. Not because any machine will ever need to read it but because the discipline of standardising and codifying things forces organisations to change away from analogue variations.
More or less agile
Requirements, feedback, requirements, feedback, requirements, feedback, design, feedback, design, feedback, design, feedback, build, feedback, build, feedback, build, feedback, test, feedback, test, feedback, test, feedback, launch, feedback…
…is more agile than…
…discovery, design, build, test, launch, discovery, design, build, test, launch, discovery, design, build, test, launch.
Or to put it another way doing all of the same types of work together (waterfall) but with feedback is more agile than iterative delivery without feedback.
No new ideas in the building
Was thinking about organisations creating porous boundaries again.
It relates to the return-to-office debate and claim that watercooler moments don’t happen if people aren’t in the same physical space (ignore that fact that if an organisation relies on chance encounters to drive innovation they’ve got bigger problems). What often gets missed is the question of where did those people get the ideas they talked about whilst sipping their cool filtered water.
If an organisation has the expectation that work only happens at a desk, in the building, between 9 and 5, how can people ever get new ideas? Go to one conference a year and then go back to the office to get on with “the real work”?
But if we set the expectation that work can happen anywhere anytime – that going to a conference, talking to customers, having impromptu conversations with people at a co-working space, listening to a podcast while going for a walk, all of that is “work”, then people have lots of sources of inspiration and new ideas.
The thing is, the anywhere anytime work expectation that is necessary for getting all those new ideas is incompatible with the expectation of everyone being in the same place at the same time to discuss the ideas. There are no new ideas in the building, but there are lots of ways to discuss them anywhere anytime.
Hiring process
There’s a weird hypocrisy in hiring processes where organisations expect one type of person to put lots of time and effort into applying for a role, but expect another type of person (who is being paid) to spend as little time as possible reviewing applications. The use of AI in the hiring process, writing job applications and/or assessing them, has surfaced the discussion more, but the problem goes to hiring processes not being designed in a human-centred way.