Why data will be so valuable in the future
‘Data is the new oil’ is an attempt to suggest how valuable data is. It’s an analogy that works when we consider data isn’t valuable in its raw form, it needs to be processed to become something more valuable. Oil is valuable because so much can be done with it, just like data. But there the analogy breaks. Oil is a limited resource, and once processed it cannot be reversed. Data is constantly and continuously being generated, and using it does not use it up. The same data can be reused repeatedly in different ways.
In many ways data is unique and non-analogous. Data is both what is processed by computers and what they use to run the processing. Nothing else in the world uses fundamentally the same thing to do the processing and be processed. Data is an abstraction of the real world, which means all data is interrelated with every other piece of data. Nothing else in the world is as connectable.
Conceptually, all data is connected. Someone buys a desk.The measurements of the desk are on a spec sheet used by the manufacturer, along with the safety standards the desk meets and what materials it’s made of. The manufacturer holds data on the employees that built the desk, including how much they were paid, when, etc. That employee’s bank also has data on how much and when they were paid, but also what they spent their money on. The retailer they spent their money with knows some of what they did with their money, including that they bought a desk. But because all these data sets are independent no one person or system sees how they connect.
As more data becomes more interconnected its usefulness increases exponentially. But in order to achieve the interconnectedness of datasets and make them useful, collection, storage and processing have to be decoupled from each other. When competitive advantage comes from the collection, storage and processing of smaller specific datasets that organisations use to draw insights only relevant to themselves, interconnection is prevented. If data collected from numerous sources is stored in a way that is equally available to everyone then competitive advantage can only come from processing. Those organisations that have the capabilities to utilise insights from the analysis of huge aggregated datasets win out, but require an intermediary to store the data and prevent monopolisation.
Data Trusts work like a bank but for data rather than money. Just as no organisation keeps the money it makes, nor would they keep the data they collect. Industry standards would standardise data collection and laws would make it illegal for organisations to store data. Data would be held by these Data Trusts and made available only to those that contribute their data. Anonymised data is accessible in real time for processing by organisations to draw insights that enable them to make decisions that take account of an unimaginably huge number of data points.
Data Trusts would specialise in particular types of data; retail, health, manufacturing, etc., creating a further layer of anonymisation and aggregation for organisations wishing to correlate datasets. Interesting new commercial models would develop around the cost of accessing data to take account of increasing returns mechanisms and the decay of relevance.
Knowledge transfer through on and offboarding
This, from Alex Danco explains how one of things that drove innovation in Silicon Valley was that when people changed jobs they were allowed to share their knowledge about their previous companies processes and practices. pic.twitter.com/M9qDpPNMbM
— Roger Swannell (@rogerswannell) June 28, 2020
Creating new collaborative organisations to operate shared services
I joined the Southwark and dxw team working on affordable housing monitoring for a two day workshop. The aim of the workshop was to spend some time documenting and discussing different approaches to developing the work beyond alpha. The alpha team had also been thinking about how cooperation between local authorities could work and the potential for reuse.
People Aren’t Sick Of Change. They’re Just Sick Of Change Programmes
We are sometimes told that people will resist our ‘change efforts’ or even need to be assessed for their ‘change readiness’. Change readiness, in case you’ve not had the pleasure, is the “ability to continuously initiate and respond to change in ways that create advantage, minimize risk, and sustain performance.”
Towards a shared understanding of product experience
I’ve been working on a way to quickly and iteratively develop and capture the understanding of people from different teams with different skills and perspectives as we define new products.
The process, and following document that structures and records our understanding, is based on five layers with progressively finer fidelity of understanding. The first layer helps to paint the big picture about ‘why’ we should be building this new product. The second layer is ‘who’ we are building it for. That breaks down into ‘what’ those users want. The even more detailed level describes ‘how’ we are going to do it. And ‘when’ introduces an element of time and knits all the parts together to create the entire product experience.
We’ve had people from different teams working together in a single shared document, using calls to discuss things quickly, chat to discuss things together, and comments in the document to raise questions that we should answer later. People join in when they are available and drop out when they have other things to do but the work flows on. It’s an interesting way of working synchronously and asynchronously, and it helps to shift the focus away from hierarchical decision-making structures towards collaborative decision-evolving.
Where there is uncertainty we have lots of activity as people work through questions, and as certainty emerges the activity reduces to the point where no more changes are being made because everyone feels settled on their understanding and how it is expressed. This is what I mean by decision-evolving, rather than someone working in isolation to create a document that is reviewed and approved by a single decision-maker.
The document uses existing methods from a variety of sources at a very superficial level, trying to put twenty percent of the effort in to get eighty percent of the benefits and move on quickly. Once that method has yielded greater understanding about the product experience it has served its usefulness. Understanding is the outcome, not the using of the methods, tools and techniques.
This way of working has a sense of narrative about it. It isn’t about producing finished artifacts to present to people who weren’t involved in the process, it’s about reaching shared understanding.
There are no wrong answers, as long as those answers help us understand together.
It’s still a work in progress, far from finished but this is what the document looks like:
Introduction
This document describes the experience for users of the _______. It follows a simple ‘why’, ‘who’, ‘what’, ‘how’, ‘when’ format where each layer increases the fidelity of information to get a shared understanding from the bigger picture of ‘why’ we are providing the product to a more detailed picture of ‘how’ and ‘when’.
Background
Is this product replacing an existing product or meeting a newly identified opportunity? What do we know about the background and origins of the idea for the product?
WHY
The ‘Why’ section helps us articulate the reasons for considering building this product. It gives us the big picture
Elevator pitch
An elevator pitch is a single paragraph summary of the product experience that encompasses the five levels of fidelity. It is used to communicate why we are offering the product and experience through what outcomes the users will achieve.
Value proposition
What makes our product different to others on the market, and what benefits will users get from our product that they don’t get from competitor products?
Goals
We can define success for the product as being one that users want because it solves a problem for them (desirable), that (viable), and that we have the resources to build it (feasible).
WHO
This section helps us to understand ‘who’ will use the product so that we can have more confidence that what we build will meet their needs.
Personas
Personas are generic descriptions of types of users with information about relevant characteristics.
Persona 1:
Persona 2:
Persona 3:
Problem statements
Problem statements describe the current situation or problem the user, how it affects them, and what a solution might look like. It is important to understand the user’s problems in order to ensure the product we build can solve them.
Alternative solutions
How are users solving problems without our product? The solutions people use can include other technology and products, but they can also be more manual solutions.
Assumptions
What assumptions do we have about our users (what they do, how they do it), and also how we think we can solve the problems / meet the user needs?
WHAT
Use cases
Describe what the users will do, and not how they will do it. Examples of use cases are ‘Upload a document’ and ‘Search for content’.
Account
Contents
Documents
Navigation
Reporting
Search
User journey map
A User Journey Map is a diagram that explains the sequential steps a user goes through to achieve the Use Cases.
Design layouts
What pages are needed and what will look like?
Style
What brand style guide and design patterns should the product follow?
HOW
This section describes the details of our expectations about ‘how’ the product will be built.
Non-functional requirements
Accessibility
What accessibility standards does the product meet?
Integration
Does the product integrate with other products and services?
- API
- Microsoft Active Directory SSO
Performance
What page load times are we expecting?
Availability
What is the average uptime of the product?
Compatibility
Does it work in all modern browsers?
Does it work on desktop, tablet & mobile devices?
Maintainability
Is the product able to be maintained, updated and patched as required?
Privacy
Identity
Are account holders identified to other users?
Security
Is password strength enforced?
Is two factor authentication available?
Data protection
Is data encrypted in transit and at rest?
Data quality
Is data validated upon entry and/or processing?
Data retention
Does the product comply with data retention policy (6 months)?
Data storage
Is user data stored in the EU?
Does the product use cookies?
Requirements
WHEN
Process map
Process maps describe functional tasks that happen within the product such as integration into other systems.
Service blueprint
The Service blueprint is the most detailed artifact, showing what the user sees and does in a sequential horizontal view along with what processes people and technology support those actions on a vertical view. It can be produced as understanding develops from the work detailed above or once earlier stages