What good product management in charities looks like

I don’t have the answer. But I’m pretty sure that it is rooted in compassion, kindness, integrity, justice and inclusiveness before it even thinks about product practices or applying them in the context of a charity. That’s the hard stuff to get right. Without that it’s easy to go astray and with that the rest of it looks easy.

Brilliant blockchain ideas

Blockchains offer a means of creating an immutable record of transactions on a peer-to-peer network of computers. Here are some brilliant ideas of things we could use blockchain for:

  • Record the usage of toilet paper in public toilets – As each square of toilet paper is dispensed a transaction is added to the blockchain so that an everlasting and never changing record of how many squares of toilet paper were used in each visit is maintained.
  • A single pixel of a famous photo – If you’re NASA and you own the rights to iconic images such as the Blue Marble from the 1972 Apollo mission, why sell the image as a whole as a single NFT when you can sell each individual pixel and create a unique and finite community of Blue Marblers.
  • Every tin of beans – In fact every piece of food produced is recorded on a blockchain, with transactions added each time it changes location, from manufacturer to wholesaler to supermarket to your kitchen. Your smart kitchen communicates via bluetooth with every piece of food within it so when you open the tin (or your robot butler does) that too is added to the blockchain so that everyone knows beyond a doubt that that tin of beans has been consumed.
  • Blockchain of blockchains – Create a blockchain that records that every transaction that happens on every other blockchain so that there is an immutable record of all the blockchains. Just in case.
  • Santa’s list of naughty and nice children – Every child in the world is added to the blockchain , and every time each of them does something naughty or nice another block is added, enabling Santa (or more probably Elves with PhD’s in data science) to maintain an unarguable list of which children are getting presents this year. Santa could sell licenses to enable apps to be built that show the data for convincing children to behave or marketing toys to them.

If you’re looking for something more helpful, this demo of how a blockchain works is great.

Dream team: twelve domains of knowledge for modern product teams

Gone are the days of the product team triad of product, design and engineering. Today’s product teams require skills and knowledge across twelve domains of knowledge.

  • Analysis – depending on the context might be business analysis or data analysis and reporting.
  • Architecture – Tech stack and architectural design and decisions.
  • Content – designing and creating content for product and marketing.
  • Customer success – supporting users to make best use of the product, collecting feedback.
  • Delivery – support development/engineering, remove barriers, schedule and facilitate software development.
  • Development/engineering – Developing and managing software packages for websites and applications.
  • Interaction design – Generate interaction concepts that enable seamless and relevant experiences for users.
  • Marketing- Identify target audience, promote products and services.
  • Product – Align product vision and strategy to organisational goals, user needs, technical capabilities.
  • Project – Manages scope, schedule, finance, risk, quality and resources.
  • Research – plan, design and carry out user and market research activities to get a deep understanding of the users.
  • Service design – Design the end-to-end journey of a service to help users complete their goal

A Leverage Points Framework for Systems-shifting product management

Systems-shifting product management builds on the work of systems-shifting design which moves away from user centred practices in order to affect change by effecting systems.

How might product management use a Leverage Points Framework

Based on the Center for Humane Technology’s Leverage Points Framework, which is based on Donella Meadows ‘12 Leverage Points to Intervene in a System‘, here is version 0.1 of the Systems-shifting product management Leverage Points Framework.

A Leverage Points Framework for Systems-shifting product management

The core concept of a leverage framework is to illustrate that there are multiple points at which leverage can be applied to achieve an outcome, that depending on where on the lever the leverage point is the more or less effect it will have on the outcome, and that multiple leverage points can be used together to increase achieving the outcome.

1 – User action. Leverage applied here is about providing the means for a user to perform an action.

2 – Feature. Leverage at this point involves change to existing or new features in an attempt to achieve the outcome.

3 – Product. Product-wide changes or new products utilise leverage at this level.

4 – Business model. Changing business models applies leverage at this point on the lever.

5 – Organisation. Changes within an organisation can have high leverage on outcomes.

6 – Culture. Changing the culture has the highest leverage in achieving an outcome.

What might that look like in practice?

Example: Let’s saying we’re looking for ways to reduce misinformation on Twitter.

The lowest leverage change that could be made would be to introduce something that relies on a user action for achieving the outcome. That could be something like displaying a message asking the user if they want to read an article before they retweet it. Low leverage changes are quick to introduce but find it extremely difficult to achieve the outcome alone.

The second point on the framework is to introduce a feature that aims to achieve the outcome. This is higher leverage than point one as it is always available for all users and doesn’t rely on a user action. For our example this could be changing the algorithm to reduce the reach of retweets with links so that fewer people then click on and read the article.

Point three is at the product level. This means either wholesale changes to an existing product or a new product. For the purposes of this example lets imagine a very different Twitter where the algorithm tries to keep users in bubbles, reduces the number tweets in users’ timeline that are counter to views they’ve shared, or anonymises content to expose users to different perspectives but prevents the originator from being attacked for expressing them.

Point four is about how changing the business model can achieve the outcome. Twitter relies on driving user engagement in order to create ad spend in order to generate revenue. If social media sites over a certain size were considered a public good and part of the essential infrastructure of countries there could be an argument for governments contributing to revenue in return for Twitter reducing the need for increasing user engagement with certain types of content.

Five is leverage at the organisational level and could include changes to the company structure, incentives that drive behaviours, success measures, the diversity of people working there, how inclusive open to different points-of-view the corporate culture is.

The sixth and highest level point of leverage is to change the culture. This means changing what society considers acceptable behaviour, legislating against certain organisations and public figures to prevent misinformation, or putting memes to work against misinformation.

Or a simpler example: increase revenue.

  1. Send a user more emails, so they click more links, and buy more stuff.
  2. Introduce a feature that users pay more for.
  3. Introduce a product that solves a different problem, and which users pay for.
  4. Change the business model. Move upstream in the value chain, e.g. from buying something from another business to producing that thing that other businesses buy from you.
  5. Restructure the organisation to downsize departments with higher costs.
  6. Change the culture, create a trend so that more people desire what you produce.

Why do product managers struggle to achieve outcomes?

Because they almost always work at the lower levels of the lever. Why do product managers work at the lower levels? Because organisations often really don’t want to change in order to achieve outcomes, especially if they feel they are succeeding with their current features, products, business models, organisational structures and cultural view of the world.

Not only is is hard to do, it’s also difficult to be sure you’ll achieve the desired outcome. Any action in a complex system will have unintended consequences, but higher leverage changes are more likely to have vastly disconnected consequences which are impossible to tie back to the change.

The great web portal naming debate

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

Actually, naming things isn’t only hard in computer science. It’s hard wherever new things are viewed in old ways or whenever there’s a question about what the new thing does.

Those that build websites and work on digital products and services tend to react against naming websites in ways that tells the user what the website is or does. Maybe there’s a familiarity bias there.

Giving a website a name such as ‘portal’ or ‘hub’ makes sense if you have to tell people what this thing is and what they can do with it. The Bodleian Library has the word library in it’s name so that you know that it’s a library. But Starbucks doesn’t need to include ‘coffee shop’ in it’s name because it has sufficient brand awareness among people who want to visit coffee shops. The OpenSea website explains that it is a marketplace, because it and NFT’s are quite new, whereas the Ebay website doesn’t have to explain that it’s a marketplace because it’s already well-known.

So, from a user experience perspective, if a website is new or it’s purpose uncertain, its helpful for the website to communicate whether it is a portal, marketplace, whatever. Sometimes, and sometimes by default, this means using the same language that is used internally by the organisation becomes the language that is used on the website to explain to users. It might be, through some strange coincidence, that the internal language is the same as users use and makes sense to them, but it’s best to test with real users to get the messaging right.

Deciding whether the website is a website, a microsite or a portal can be done by understanding whether the functionality and audience is specific, e.g. registered members and whether access is public or private. But that understanding doesn’t have to be surfaced on the website. That understanding serves a need within the organisation, but the users of the website have a different need. They need to know what the site does, especially if they are new to it.

So, in summary, it’s ok to use terms like ‘portal’ internally if it helps to clarify the purpose of the website within the organisation. And its good to ensure that, especially for new site and services, the website communicates what its for and what a user can do with it. Sometimes those two overlap, and sometimes they shouldn’t.

Mission and measurement don’t mix

On one hand, we hear organisations talk about mission and vision, goals and direction. Abstract things. Intangible and immeasurable. Lofty ideas and ideal outcomes.

On the other hand, those same organisations want to know the schedule, measure the progress, manage the resources. Concrete, tangible things. Outputs. Inventory.

Philosophically, this distinction is thousands of years old. Heraclitus thought that everything changes all the time, that the world is in constant flux. For him, intangible things that are constantly in a state of becoming, much like the sometimes unachievable missions of organisations, can never be, they can never materialise. Parmenides viewed reality as static. In his world you can measure things, they are predictable. It is his thinking on which we built most of our scientific knowledge and our ability to measure the world and our activities in it.

The problem isn’t us having these two views on the world or wanting to have a vision of what could be achieved and a schedule for achieving it, the problem is expecting to be able translate between them. Our organisations can have a mission, and they can measure and manage their efforts, but we can never connect the two. The schedule doesn’t tell us if we’re heading in the right direction. Mission and management don’t mix.

Non Functional Knowledge

Non Functional Requirements are used in software systems design to describe how, and sometimes how well, a system does what it’s supposed to do. They might include things like reliability, security, usability, or anything else that sets the constraints and restrictions for what the system does. They are different from functional requirements which describe what the system should do.

Maybe social systems like teams and organisations require Non Functional Knowledge in how and how well their systems behave. Maybe the depth of Non Functional Knowledge of those acting on and being acted on within the system has a bearing on how successful the system operates.

We need to know more than just what the work is, we need to know how to do it, how to do it well, and how to do it as part of an interconnected system that involves lots of other people.

Copy and paste

Copy and paste is probably the most impactful productivity tool in the modern workplace.

Imagine not having it. Think about having the rewrite everything that you want to move within a document or from one document to another every time.

Now imagine what more we could copy and paste. Think about what copy and paste actually enables and what it means for how we conceive of work.

Copy and paste, of text and images, of templates, but more importantly of ideas, means not having to start from scratch every time. It means always being able to build on what went before because what went before can be easily taken into a new context. Copy and paste is a ratchet mechanism that enables progress to occur, work to become more efficient, ideas to build and grow.

Every time you creating something new, ask yourself how you can do so in a way that makes it easy to copy and paste next time you need it.

Replacing isolated work with networked work

There are two ways to do undertake a role. In an isolated way or in a networked way.

Working in isolation sees the job as having a defined remit of only doing the work that your job title implies or your job description defines. It regards individuals as separate from each other and producing discrete outputs that are then used by others acting in isolated ways.

Working in a networked way sees the role as part of an interconnected system. It means working to improve how the organisation works as a whole ahead of what works for the individual. Connected working contributes to the overall activities and performance of the system, it recognises that global optimisation is a better goal than local efficiency.

How do we work in more networked ways? Smaller and less self-conscious contributions might be way. Collaboratively producing a document might be a small example. Recognising that there is organisational gain to be achieved by sharing knowledge could be another. Informal coaching and feedback between lots more people.

Once it’s on the internet you can’t get it back

I had a slightly surreal phone call. It was from someone inquiring about something I’d been involved a few years ago. After the call I wondered about how they found my number. A quick Google search and I found lots of websites had my phone number. In promoting the thing I’d been working on I had added my phone to a website. Lots of other websites scraped that website and so it’s data became their data.

A product manager, or someone assuming the responsibilities of a product manager, made choices about how those websites were going to work. They considered ‘their user’ as the person visiting their website and wanted to provide a wide range of information. They assumed that data on the public web is free for all to use. And they probably didn’t spend a great deal of time thinking about the original owner of the data, how they should have some control over how that data is used, and what problematic or harmful things could result from it being used in ways they didn’t intend.

Today, product managers working with public data sets or building products that allow users to share information about themselves publicly have no excuse for not considering the wider impacts of their choices. It’s irresponsible to assume that because data is open for all to see that this means it’s free for all to use. It’s irresponsible to push the responsibility for making those choices onto users and not inform them of the risks or give them the tools to manage the data they share.

Luckily for me, the thing I was working on was very niche so I don’t expect much interest and I’m pretty good at ignoring phone calls, but it made me think about how once we’ve added something to the internet we lose control over where it goes and how it’s used.