Against frameworks: a whole person approach to product management

Frameworks are such a part of product management that a google search returns 87,400,000 results. There’s even a website dedicated to product management frameworks.

Frameworks are essentially a shortcut to thinking. Want to prioritise features? There’s a framework for that. Want to create a roadmap? There’s a framework for that. Need to rank customer problems? There’s a framework for that.

Maybe product management depends too much on too many frameworks and abstract concepts and not enough on developing the thinking skills to understand what problem the product manager is trying to solve and create a corresponding and relevant solution.

A whole-person approach to product management would place greater emphasis on developing the more fundamental skills of cognitive, emotional, and social skills. It would encompass aspects of the identity of the product manager and how that affects their ability to do their job well. The whole person approach to learning has been shown to be effective in family businesses, MBA programs, and in care settings, and could be applied to product management learning and development.

Product managers product managing product management

There are a only a very few roles within an organisation where the skills of that role enable the holder to apply them to the role. People who work in HR or Finance can’t apply the thinking of their specialisms to how their role works in an organisation. Of course, it’s beneficial for all roles or teams to appreciate what problem they solve for their organisation, but very few of them get to shape how they solve that problem. The role they play is well shaped and clearly defined. Maybe we could expect Sales people to sell their role within an organisation, and maybe we could expect Designers to design how their role fits in the organisation. And maybe Product manager can product manage their role in an organisation.

They can attempt to understand the problems the organisation is trying to solve by having product managers and shape how their role solves that problem. Is essence, the role becomes a product that enables a value exchange between the product manager or product team and the organisation.

I wonder if product teams that take a product management approach to how they operate within the organisation might be more successful. Rather than adopting a fixed approach they can set hypotheses about what might work better and then run experiments to prove or disprove it. They can use prototype processes to test and validate ideas about how to work. And once they have a process that looks promising, iterate on it as the working environment changes.

Product managers should product manage product management.

What’s the difference between product manager, project manager and delivery manager?

Product manager, project manager and delivery manager each play a different role on a modern agile development team, but share a focus on achieving the outcome of the work.

Overlapping focus for product managers, project managers and delivery managers

What do product managers do?

Product managers focus on:

  • Vision – Understand the problems the product aims to solve, who has those problems, and why they are worth solving.
  • Strategy – Present how the product will solve the problem, and how solving the problems will achieve organisational objectives and meet user needs.
  • Alignment – Ensure the product vision and strategy are aligned with organisational objectives and stakeholders expectations, and that the team are aligned on the problem and the solution.
  • Prioritisation – Decide which the parts of the solution achieve the most for the organisation and the users.
  • Value – Understand the value users will get from using the product and where they might lack value they expect.
  • Cost – Balance the cost of building the product with the expected return on investment over the life time of the product.

What do project managers do?

Project managers focus on:

  • Planning – Coordinate all aspects of the project to meet the project goals.
  • Cost – Monitor and report on the cost of the project.
  • Time – Understand the schedule of work and monitor progress.
  • Governance – Ensure the project follows organisational control procedures.
  • Resourcing & dependencies – Monitor project resources and escalate dependencies.
  • Risks & issues – Monitor and resolve risks and issues that may impact the success of the project.

What do delivery managers do?

Delivery managers focus on:

  • Time – Decide how the development team best uses the time available.
  • Value – Understand what value the user should get from the product.
  • Scope – Control the scope of work that the development team work on the ensure the solution is appropriate and proportional to the problem.
  • Quality – Ensure the solution meets quality standards, e.g. accessibility and security.
  • Barriers – Remove barriers and impediments that slow down the development team.
  • Process – Implement, monitor and improve the processes the team uses to manage it’s work.

How do all three work together?

All three overlap with a focus on the outcome. All three roles succeed if the work achieves the outcome it set out to.

The Project Manager and Delivery Manager overlap their focus on time. For the Project Manager

The Product Manager and Project Manager overlap their focus on cost. This includes all investments into the project and product to ensure a positive return is going to be achieved.

The Delivery Manager and the Product Manager share a focus on the value that end user of the solution will receive. For the Delivery Manager, value is closely connected to scope of the work as defining and building the wrong product or feature risks reducing the value it provides.

Although each role has different aspects to focus on, good teams don’t work in isolation and support each other to succeed.

Using the ‘S’ word: What we mean when we talk about scaling

I hear people talk about scaling products and services and I wonder if we all understand what scaling means in the same way.

The word ‘scaling’ has a lot of baggage within the tech world, from implying an end goal of millions of users to , but used on it’s own is as meaningless as it is loaded.

‘To scale’ only makes sense if its actually phrased ‘to scale by a factor of x’. So, if x equals 2 then the exponential growth goes: 1, 2, 4, 8, 16, etc. This is a very different growth pattern from how many products and services actually grow.

If we expect a product or service to grow linearly, that it 1, 2, 3, 4, 5, etc., then there might be less ambiguity by talking more accurately about it as linear growth and avoiding any confusion from using the ‘s’ word.

Product management in charities and public health: how different is it?

The role of the product manager in high-entropy environments

Trilly Chatterjee’s post about the framing of the product manager’s role, particularly in the public health space, prompted me to try to pull together some of my thoughts about the role product managers play in charities. Trilly starts with the challenge of explaining what it is that product managers do, and how this seems to apply in all sectors and industries. He also highlights how product managers have “very different routines depending on the particular context of their product or service”.

Then specifically speaking about the public health environment, Trilly goes on to explain how there are many perspectives, tensions, trade-offs, processes, people, teams, departments, etc., often pulling in different directions, that all together create an environment of high entropy. In high-entropy environments, where things tend to fall out of alignment quickly and easily, a product manager’s role is to maintain alignment. They achieve this through conversations. Trilly’s point; conversations are the first best tool for reducing the entropy. Or to put it another way, keeping people talking to each other reinforces alignment between the problem and the solution.

I wonder if the product manager takes on this role purely because there aren’t other mechanisms for maintaining alignment and so preventing entropy in the system. If this is the case, then the working environment/system is a causal contributor to why the role of product management is so hard to define. In a very different environment, a small tech start-up for example, a product manager might not need to focus on conversations to as a means to maintain alignment. Different environment (low-entropy), different need (other mechanisms in place), different focus for the product manager.

The goal of the product manager in all environments

So… is product management in charities different to in the public health sector?

Public health and charity, at first glance, look like they could be quite similar. Both are about helping people and both deal with complex multi-faceted problems. But even the slightest scratch beneath the surface shows more fundamental differences than similarities.

Starting with the funding model, public health is centrally funded whilst charities usually receive their income from a diverse and often uncertain range of sources. This matters because how organisations are funded underpins how they organise and manage resources. Although no public health or third sector organisation is ever funded sufficiently to meet the demands placed on it, the funding ecosystem in which an organisation sits makes a huge difference to how the value-chain operates.

Secondly, branding and public perception. The National Health Service, under one banner, is made up of thousands of separate organisations. The charity sector consists of hundreds of thousands of organisations, all under their own brand. For all the benefits it brings, the NHS brand creates an expectation of joined-up-ness that just doesn’t exist in the charity sector. And perhaps it is this expectation of joined-up-ness in a disparate eco-system of organisations, processes and technologies that creates the environment where for a product manager to facilitate the value exchange between organisation and end user they first have to facilitate the conversations that create some kind of connectedness that allows the value chain to product something of use to the user.

From these examples it’s easy to see how the environment that the product manger’s operate in is very different. But, what the product manager is trying to achieve is very much the same.

At it’s most fundamental level product management is about facilitating the value exchange between the organisation and the customer/user/beneficiary. In some organisations the product manager focuses their effort on the sharp end of the value exchange, on the point of interface, the technology the customer interacts with to make the value exchange happen. In other organisations product managers have influence over the entire value chain, the strategy for taking organisational resources and packaging them in a way that is of value to the user. Neither of these positions, or anywhere in between, is more of less important a role, or of greater or lesser value to the organisation. How a product manager fits in the organisation is most often a factor of how the organisation arranges itself, as we’ve seen in the differences in the environments between public health and charities, than it is in the definition of the role itself.

The opportunity for product management in charities

But what about product management in charities? Product management in the charity sector is still fairly new and immature. It feels as equally misunderstood as product management is the public health sector, partly because of the lack, or misunderstanding, of definition, and partly I think, just because of how new it is.

A point I’m always keen to make when talking about product management and charities is that the product management function of an organisation doesn’t necessarily require someone with the job title ‘product manager’. Product management should be viewed more as a mindset and a skill set than it should as a job. Lots of people working in charities, with all kinds of job titles do product management work, it just isn’t framed as such. Perhaps this point of view makes defining what product managers do even more cloudy, but if we .

Charities, even the biggest of them, don’t have the high-entropy environments in the same way as the NHS. That doesn’t mean alignment is easy, it just means the differences between those people and things that should be aligned are less.

Traditionally, an organisation’s value-chain applied ‘engineering thinking’. Engineering thinking is based on the assumption that a problem can be understood upfront, a solution defined, developed and then delivered, resulting in no more problem. And if you’re building simple solutions to tame, well-understood problems, that approach fits. But then the world got more connected (blame to internet if you like) and the problems became more complex, and so engineering thinking ceased to be the best way to solve problems. But many charities continue to apply this thinking to the products and services they provide.

Nowadays, more organisations are applying ‘design thinking’ to how they approach solving problems. Design thinking recognises wicked problems and says that the best way to even start to solve highly complex problems is to experiment, use prototypes, get feedback, understand what effect your solution had on the problem, then try again and again, learning more each time. None of this can be done upfront and then delivered, it can only be done in real-time with real people in real life situations. Increasingly we’re seeing charities adopt design thinking approaches to problems.

What does this have to do with product management? These more complex problems require more advanced means of managing in order to reach a solution. This is where the modern product manager steps in. Their role is, as Trilly says, to facilitate alignment, or as I’ve written before, to interface, integrate and iterate. Importantly, managing alignment between the people within an organisation is done in service of managing the alignment between the problem and the solution. That is any product managers ultimate goal; to ensure the solution solves the problem.

Whereas a product manager in the vast public health system might only work across a thin slice of the value chain, product mangers have increasing scope in charities to work across the entire value chain. They can mange the interface between the charity and service users and supporters, usually using technology to provide the value exchange mechanism. They can manage the integration within the organisation, vertically between strategy and the logistics of delivery, and horizontally between different teams. They can manage the iterating of the solution to apply that design thinking approach to solving complex problems.

Charities need good product management because charities face increasingly complex problems.

Weeknotes #274

Photo of the week:

One day something else will be looking at whatever we’ve left behind

This week I did:

Architecting for uncertainty

We’re getting into the hard work now. Well, the developers are, I just try not to cause too much confusion. It’s a bit of challenge for us to figure out how to build a product that will most likely have to be able to do things in the next six to twelve months that we don’t know about yet. It means being slower and more considered now to architect the systems in more complicated ways to give us flexibility later but that’s better than taking the easy route now and having to fix it later.

My idea that product management is about interfacing, integrating and iterating came into play this week, mostly around the integrating part. I’ve been thinking about where in their different systems and processes different channels might touch and begin to test ideas for a multi-channel approach. Those touch points will be where in the journey a user can switch from one channel to another, mostly on the assumption that the current channel isn’t working for them.

Irregular

I started a newsletter about the idea as the fundamental unit of value. I only have three subscribers, and I don’t know how regularly I’ll send it . One of things I often toy with is how to decide where to write things. Should it be a blog post, go in a newsletter, be a Twitter thread, or probably better for everyone, just an idea in my notes. Giving the newsletter something specific to be about should help me decide which writing goes where.

Centering values

I’m still (slowly) working through the Humane Technology course and am on the module about values. It starts by talking about the myth of neutrality in technology, people and metrics and goes on to talk about how we might approach developing a values rather than metrics and market driven approach to product development.

Blog posts

I wrote a few blog posts this week (well, nine). Some express a single idea and some try to bring ideas together. I’m trying to be more relaxed about writing blog posts and not have to feel like every one needs to be research and have references. They should be more a way to express ideas in progress rather than present finished thinking.

And thought about:

Whole person product management

I’ve been thinking a bit about how product management is presented in blogs and books as being about models and frameworks but when you get into it, it’s all about people. User needs should express actual people’s goals, values and aspirations. The pretend objectivity of prioritising by mapping items on two by two grid when really it’s the conversations between people that actually make the decisions. The roadmap that presents a finished vision of the product when really it’s a point-in-time summary of lots of thinking. I wonder if there’s a need to admit that effective product management cannot be done solely by relying on the concepts.

Where in the value chain

I’ve been working on the idea that the reason for the variety of definitions of product managers and types of product management work is that product managers work on different parts of the value chain. Some, maybe in an early stage start-up, might work cross the entire value chain, whereas in a different type of company a product manager might work more around the interface between company and customer, and in another type of organisation the product manager works only on a specific part of the value chain to do with the technology. This might help to explain the differences but it should also mean that we think of product management as equally important wherever in the value chain it happens.

Starlings have us beat

I was thinking a bit more about stigmergy again and whether it could be used within an organisation instead of strategy. Since writing that post I’ve started to wonder if actually stigmergy does already occur in organisations through informal information networks whilst strategy continues to be applied through formal hierarchies of authority. Maybe it’s obvious that both would have a place in a modern complex organisation. Maybe it’s naive and simplistic to think that an organisation could run effectively in the way a flock of starlings or an ant’s nest does. I’ve often thought that organisations have ‘shadow strategies’ that drive the things people actually do. Maybe that’s stigmergies at work.

This week I read:

System-shifting design

I read the Design Council report exploring some of the known issues with user-centred and solution-focused design and the emerging practice of social design that is “challenging the deep structure of current systems and working at different levels of a system to drive change“. I first heard about Social Design in the service design course I did and am interested in how it can be applied to product management. I think it’s long overdue in recognising the downsides of designing for an idealised user and can hopefully help us consider more about where are the right places to interact with systems to affect how they work.

Optimising the live virtual learning experience

This framework for improving VILT (Virtual Instructor Led Training) within organisations has some suggestions on improving learning. It doesn’t have much depth as to the rationale for improving learning in organisations, other than a few mentions of things like employee retention, but it’s another angle on the evolving space of online learning. It started me thinking about whether there’s any correlation between how much an organisation invests in the learning of it’s employees and how successful the organisation is (or to be more specific, how successful it is in responding to change and innovating).

Bootstrapping

I started reading the minimalist entrepreneur by Sahil Lavingia, who built Gumroad. From what I’ve read so far, it’s interesting how it reflects many of the trends I see in the creator economy, things build an audience before you build a product.

My growth area this week was:

Keep your head up

Trying to shift focus from the specific details of solution design to how we deal with the uncertain future.

Why is defining what product managers do so difficult?

Product management suffers from a bit of an identity crisis. Actually, maybe crisis is too strong a term. Maybe it’s an identity butterflies-in-the-tummy kind of thing. It’s the feeling product managers get when asked to explain what they do. Sometimes it’s an opportunity to express a new found idea about the role, sometimes it’s a roll of the eyes as they know they’re going to sound like they don’t know how to define their own role.

There are lots of industry through-leader definitions though. Things like:

A product manager is the person who identifies the customer need and the larger business objectives that a product or feature will fulfill, articulates what success looks like for a product, and rallies a team to turn that vision into a reality.

Atlassian

Product management is a complex role that requires a balance of soft and hard skills to manage requirements and to deliver quality products that align with the business’ goals.

CIO

Not the CEO of product

HBR

But still, as Trilly Chatterjee, Senior Product Manager at the NHS, notes, product managers still have trouble explaining “what product management is and what it does —in particular how it’s distinct from other roles“.

But why? What makes product management so different from other roles in ways that make it difficult to define?

Sure, it’s a highly contextual role that depends on the sector and the organisation, but that doesn’t answer the question, it just asks it in a different way; why is product management so contextual in a way that makes it difficult to define?

And sure, it’s been/going through a change of where it fits in the organisation thanks to the agile movement shifting product management from being a purely business function to often being in the Technology department, but that’s a pretty common change across every sector so that doesn’t explain the lack of definition either.

Maybe there is something that might…

In The Team That Managed Itself, Christina Wodtke mentions the idea that for some roles in an organisation it’s the process that counts, whilst other roles are concerned with results. The people in the service teams of an organisation judge what they do by how well their processes are working, their efficiency. And the people on the business side are less interested in the processes that happen behind the scenes and more about the results. The process-orientated people in the service teams and the results-orientated people in the business teams have different mindsets, motivations, and goals. They almost speak different languages.

Could it be that what makes the product manager role so hard to define is that it is concerned with both? If they were only process people they could describe themselves by the processes they use. And if they were only results people they’d describe themselves by what they achieve. Are product managers process people and results people? Do they speak both languages and translate between the two? And does that mean that they don’t really fit fully in either camp?

What if, rather than being at the intersection of a Venn diagram, product managers are actually the union?

The impossibility of answers

A product manager’s primary purpose is to answer ‘why’. Why that market. Why this customer segment. Why those customer problems. Why this solution. Why build this thing rather than that. Why that feature should work this way. Etc., etc., etc. A thousand whys. And never enough answers.

This is the product manager’s paradox; that most of these questions can never be answered with any certainty and for every answer there are even more questions to ask. It’s not enough to simply ask ‘why’, a product manager should be focused on answering why, even knowing the impossibility of answers.

Weeknotes #261

What I did this week:

Wider learning

Our team did presentations of our work to others across the organisation. It’s an important part of communicating and embedding the changes that we’re introducing but the really interesting part was all the comments that hinted at questions we haven’t answered and questions we didn’t even know to ask. There’s so much experience and expertise for us to absorb into our work and I hope that if we get that right it will help us create a better product that doesn’t repeat old mistakes our ignore old learning. If continuous discovery is a mindset was well as a practice, then looking out for these opportunities to uncover more unknowns is exactly what we should be doing.

I’ve been thinking about the complexity of the situations that the product we’re building interacts with across the organisation. My conclusion so far is that it’s important not to down play the complexity and try to create a simplified (and probably false) view. That would risk creating simplified solutions that don’t really solve problems. Some of the questions I’ve been asking myself is, ‘where is the right point to intersect with existing systems and processes without causing disruption or unintended consequences?’ and ‘how can we help other teams improve how they do things in ways that don’t cause downstream problems for others?’.

Innovation interviews

My interviewees have started returning their answers to my research questions. I’m still hoping for more but I can begin collating the answers I have so far ready for analysis next weekend. Those that I read so far have been really interesting and make me wish I could have long chats with people about their understanding and approach to innovation in charities.

20,000 views

My website hit 20,000 views this week. That’s not many in the grand (or even not so grand) scheme of things but it still amazes me that people visit the site. I’m sure most of it is by accident or when looking for something that isn’t there, but it’s interesting how the traffic has increased over the last five years from averaging 1 view a day in 2016 to 8 in 2019, 26 a day in 2020, and so far in 2021 32 a day.


What I thought about this week:

Causal chain

I’ve been thinking about and trying to learn more about Theory of Change. The part that interests me at the moment is the how the causal logic of ‘c’ will lead to ‘b’ and ‘b’ will lead to ‘a’ is built up. If ‘a’ is the ultimate change, the larger impact on society, then ‘b’ is what needs to be true in order for that change to be realised, and ‘c’ needs to be true in order for ‘b’ to happen. So, the thing I’m struggling with in this backwards logic is how it can be anything other than a pyramid of hypotheses which could all just as likely be untrue and true. I guess that’s why it’s a theory of change rather than a plan for change, but I wonder how clearly that aspect of ToC’s are communicated. They basically say, ‘here’s lots of guesses that may or may not lead to the change we’d like to see, and those guesses are based on lots of assumptions and biases, any of which could prevent the causal chain logic from having the desired or expected effect’, but they are often presented as a more certain plan for achieving change.

Bottlenecks

Bottlenecks are designed to be just that. They are designed to reduce flow, or to put it another way, to control flow. It wouldn’t be quite so easy to pour the wine into your glass if all of the wine bottle was the same width all the way up. So why do we refer to bottlenecks in systems and processes as a negative thing? Perhaps we’re better off accepting and understanding bottlenecks as essential and necessary to any system design. Maybe constant and continuous flow at the maximum rate in the wrong places causes floods.

Product Octagon

If you believe everything you read on the internet then most products are driven by the triad of Product Manager, Engineering Manager and Design Manager. The product I work on is driven by the octagon of programme, project, product, technical, content, design, delivery and impact. I’ve only just started to think about how these eight roles interact, where each of their responsibilities lay, and how they can all be aligned to work effectively together, but as part of my ‘charities need good product management‘ thing I’m keen to explore other models of developing products and what effective product management looks like in different contexts.


And what I read this week:

Digital exclusion

Digital exclusion: a growing threat to your charitable impact, strategic objectives and funding, looks at digital transformation in the voluntary sector and what impact it might have on the digital exclusion of those the voluntary sector organisations are trying to help. The article suggests three ways that can contribute to tackling digital exclusion, which is really just social exclusion; grassroots action, funding, and campaigning. Including people in society, which is very much digital, requires a far bigger approach. So whilst tackling digital exclusion is undoubtedly a good thing, it seems to me like an impossible problem to solve. The use of digital in society is going to increase and it won’t be long until all cars are computers on wheels, money is a virtual number on our phones, and accessing any service will require digital literacy. As these changes, which are predicated on a certain level of wealth accelerate, more people will become digitally excluded than can be caught up. The argument that as digital technologies become more ubiquitous and every one alive has grown up with them is like assuming that everyone knows how to fix an internal combustion engine because they’ve been around for a while, or that everyone knows how to drive because there is an infrastructure in place to teach (some) people. I don’t know what the solution is, but it’s good that more organisations are recognising digital exclusion as an issue and looking for ways to contribute.

14 habits

I really liked this Twitter thread, 14 habits of highly effective Product Managers, from Lenny Rachitsky. My top three are ‘quality of thinking’, ‘hunting for misalignment;, and ‘sending good vibes’. Lenny says that quality of thinking shows in the quality of documentation PMs produce. I think high quality documents are essential for good asynchronous working but they depend on having the time (among other things like practicing writing well) to do the thinking. Hunting for misalignment and getting things into alignment is so important for effective working, but is so hard to achieve. There are so many contextual and points-of-view barriers that we don’t even recognise well enough as misalignments, as well as the obvious and known misalignments. Good vibes make all the difference. Anything that can be approached with a negative, defeatist attitude and can be approached with a positive attitude.

Weeknotes #260

What I did this week (and didn’t do):

What do I require?

I spent a lot of time working on (and even more time thinking about) what some people might call requirements. I regularly get my thoughts tied up in knots trying to understand what we mean by ‘requirements’, ‘goals’, ‘objectives’, etc., but using ‘This is what we want to achieve’ and ‘These are the things we’re going to try’ seems much less ambiguous, so I tried . The problem I have, especially with ambiguous jargon but in general when defining or explaining anything, is the coastline problem. That is, how the problem looks depends on your measure. A circle drawn with only four big straight lines looks a lot like a square, but a circle drawn with a thousand small lines looks pretty circular. So, a requirement or goal specified at one level looks very different from another level. And then levels of what? My bottom-up answer would be, ‘levels of abstraction from the user behaviour’, but that opens up a whole load of other questions.

Why do charities use the innovation processes that they do?

I submitted my draft literature review and research methodology. I had originally thought that my research should be able how charities are using innovation processes, but I’ve realised I’m much more interested in why they are using them the ways they are. This creates more of a challenge as it requires qualitative interviews, but I just need to get out of my comfort zone and get on with it.

Embedding a theory of change in your learning

I signed-up for NPC Labs user research session on theory of change (which I’m interested in) and learning (which I’m really interested in). I’m not sure why, but I’m really looking forward to it.

Swimming with seals

I’ve went swimming in the sea almost every day this week. The best one was around sunset and I was alone on the beach. As I lay floating in the water a seal surfaced, looked at me for a few seconds, I looked at it, and then it swam away.

Didn’t get feedback

Listening to One Knight In Product with Teresa Torres made me realise that I haven’t done any of the discovery work I set myself for July. So, if anyone reads this and wants to do me a favour: sign-up for my charity product management emails and tell me what you think about them.


What I read this week:

Mobile traffic to charity websites is rising…

…but only a third of charities pass Google’s ‘Core Web Vitals’Mobile traffic to charity websites is rising, but only a third of charities pass Google’s ‘Core Web Vitals’

Why? Because it depends how you measure. And if you’re in the business of measuring and judging websites in order to rank them in search results then maybe you want some level of influence over how websites send you signals that you can judge them by.

Why? Because it’s easier to focus on frontend/visible aspects of technology and think that if the website is responsive then it must be optimised for mobile, which isn’t the case but many website platforms don’t get that stuff right by default.

Why? Because not all ‘Jobs To Be Done’ can or should be done on mobile devices (and with mobile behaviours). Sometimes, friction, intentional or unintentional, is good for getting people to stop and think. Convenience isn’t everything.

Why not? If your user research shows that the people that need your services find you through organic search results, need a highly-performant online experience, and only have mobile phones. The points is; do what your users need you to do, not what a search engine says.

Digital adoption within the NHS

Shock treatment: can the pandemic turn the NHS digital?, asks whether the NHS can maintain the level and pace of digital transformation that came about as a result of the pandemic, and also raises the ‘fix the plumbing or fund the future’ investment question, which I think is very closely connected. These are the questions facing every sector and organisation. Charities included. I feel like the answer is obvious; yes and no. Do organisations realise how important digital transformation is for them? Yes, at least a bit more than they did. Will organisations maintain the pace of change we saw from the pandemic? No, not without the huge external pressure making digital an existential question.

Decoupling time spent from value produced

James Plunkett’s article on the four-day week was shared around Twitter this week. It talks about the Iceland experiment and how it resulted in increased productivity, and more interestingly, predicts that, based on the historical data trend of reducing working hours, the four day working week will be generally adopted in the early 2030’s. If that’s the case, we might have a few more decades to go before society is ready to make the shift to decoupling the value we produce from the time we spend doing it. Stuart said it best, “Being at work never equated to doing work“.


What I thought about:

A diamond and a tree

Speaking of how we judge value, I had an interesting conversion about why different jobs are paid different amounts and how the job market values uniqueness of skill over what the role achieves. My analogy was ‘a diamond and a tree’. A diamond is considered to have high value because of how rare it is. Trees aren’t considered all that valuable but have an important impact on the environment and life (being able to breath, mostly). Maybe we’ve got our values round the wrong way.

Accepting responsibility

There’s lots said about blame culture and how toxic it is but I hardly ever see anything about the flip side; responsibility culture (if it’s even a thing). I think taking responsibility is one of those underlying amorphous parts of a product managers job. Obviously, everyone should take responsibility for their actions, but product managers are often the ones to be most aware of the trade-offs that exist when decisions are made (even if not actually making the decision), and that knowledge comes with responsibility. Taking responsibility for knowledge, not just actions, is an interesting responsibility to take.

Do charities need innovation?

Does any organisation, in fact? An amalgamation of ideas from a conversation on Twitter, Ann Mei Chang, and some of the stuff I’ve been thinking about for my dissertation takes my thinking towards this: If the problem is unknown and the solution is unknown, then innovation is an approach, a mindset, a skillset, a method that can help to make both known. If the problem is known and/or the solution is known, then innovation isn’t needed.