The challenge of digital transformation

A colleague of someone’s, perhaps yours, woke up this morning to the alarm clock on their mobile phone. They traveled to work on the Tube or bus and their ticket was in an app. As they traveled they streamed music or a podcast and they didn’t need training or guidance in how to do it. Then they got to work, stepped over that imaginary boundary between work and life, and they stopped being digital.

The challenge of digital transformation is to integrate the organisation into the society-wide digital ecosystem so that people continue to be as ‘digital’ at work as they are in the rest of their lives, not to bring ‘digital’ into the organisation and make people do work in digital ways.

Then, they stepped back over the boundary and went back into their digital lives of watching videos, shopping online, getting a taxi, do their banking, turning up the heating.

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

The future is never finished

Started during the reign of King Louis VII in 1163, Notre Dame cathedral took 182 years to build. Four or five generations of stone masons, carpenters and labours worked on the gargantuan construction project. Today we build virtual worlds for 2.9 billion people in the time it would have taken one of those stone masons to learn his craft. What differs in the minds of those that built things centuries ago to those that build today is not only their concept of time and what the future holds but more importantly the concept of whether something is ever finished.

If we’re building something that has an end state, a point in time when that thing will no longer be changed, then perhaps we may think more deeply about getting it right. If we expect that what we build will never be finished, will always be changing, can always be undone and redone, then we might not approach it with the same depth of consideration.

Philosopher Derek Parfit said, “We live during the hinge of history”, to describe the hypothesis that given how much change society has seen over the last few centuries, we are at a point in time where present humanity has more influence over the future of humanity than it has ever had before. We could look to the obvious advances in technology like A.I. or social ideologies like Democracy as holding that influence over the future, but it seems more likely that our ways of thinking and understanding are more likely to endure for the coming millennia.

When we no longer conceive of things as having an end, even as our awareness of existential threat increases, then we implicitly build things that we expect others to take over. We expect these future others to fix our mistakes, correct our errors of judgement, or, perhaps, to just pass them on to their future others. What we build, for now and for the future, becomes always changing, never fixed, in either sense of the word.

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.