Communication is a team sport. Teams should work together to communicate a consistent message about their work.
Prioritisation is a team sport. Teams should work together to set goals and decide what is the most important work to achieve those goals.
Coordination is a team sport. Teams should work together to plan the work and decide how that work should be delegated.
Accountability is a team sport. Teams should work together to share responsibility for the work.
Disagreeing is a team sport. Teams should work together to positively challenge their assumptions and understandings.
Everything is a team sport.
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:
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’.
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?
The ‘Why’ section helps us articulate the reasons for considering building this product. It gives us the big picture
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.
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?
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).
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 are generic descriptions of types of users with information about relevant characteristics.
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.
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.
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?
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’.
User journey map
A User Journey Map is a diagram that explains the sequential steps a user goes through to achieve the Use Cases.
What pages are needed and what will look like?
What brand style guide and design patterns should the product follow?
This section describes the details of our expectations about ‘how’ the product will be built.
What accessibility standards does the product meet?
Does the product integrate with other products and services?
- Microsoft Active Directory SSO
What page load times are we expecting?
What is the average uptime of the product?
Does it work in all modern browsers?
Does it work on desktop, tablet & mobile devices?
Is the product able to be maintained, updated and patched as required?
Are account holders identified to other users?
Is password strength enforced?
Is two factor authentication available?
Is data encrypted in transit and at rest?
Is data validated upon entry and/or processing?
Does the product comply with data retention policy (6 months)?
Is user data stored in the EU?
Process maps describe functional tasks that happen within the product such as integration into other systems.
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
My name is Roger… and I have a hero complex.
But what else would you expect of me? I grew up in the eighties watching Airwolf, MacGyver and The A Team.
For me, TV was all about Airwolf and it’s main character Stringfellow Hawk, the brooding loner Vietnam vet who stole the super-copter from the CIA so they couldn’t use for morally-questionable missions, MacGyver, the a pacifist creative problem who went on secret missions to rescue people who had gotten themselves in trouble, and, best of all, the A Team, four ex-Green Berets who were accused of a crime they didn’t commit and promptly escaped from a maximum security stockade to the Los Angeles underground where they survived as soldiers of fortune. If you had a problem, if no one else could help, and if you could find them, maybe you can hire the A Team.
The A team were the best. Every Saturday afternoon they would go up against some drug-smuggling Central American dictator or nasty land-owner who was forcing the people of a nearby town to leave their homes, and every Saturday that team of four friends and comrades-at-arms would win. They never lost.
Now, the cynics among you might stay that they always won because the show was about them, but my hero worship won’t allow for cynicism. I choose to believe that the A Team always won because they had a few special qualities.
The A Team had values, they had a mission. They wanted to help people, to use their special skills in service of the ordinary people who couldn’t fight for themselves. Teams need a mission to get behind, a cause to fight for. They need to have shared ambitions and goals.
The A Team had diversity. Although from not the most politically-correct decade, they had a black guy, a man with mental health issues, and a serial philanderer with commitment issues. But they accepted each other. These different personality types didn’t always get on, but each having their strengths and weaknesses they knew they were better as a team. Every team needs diversity. Diversity of opinion and experience, of approach and of skills are essential for a great team.
They had a strong leader. Colonel John ‘Hannibal’ Smith always had a plan. Hannibal knew his team members strengths and he knew how to get the best from them. The team could always rely on him to get them into trouble, and to guide them to work together to solve whatever problems they faced. He loved it when a plan came together.
Creativity and ingenuity
The A Team had creativity and ingenuity. They could be locked in a shed, surrounded by gun-toting bad guys, but they would always be able to build a tank out of a school bus and flamethrower out of a drain pipe. Being able to be creative, find new ways to solve problems and different ways to do things is important for a team to feel in control of itself.
The A Team had values, diversity, leadership, and creativity. They were a good team. That is why the A team never lost, or, if you apply it to real life, that is what you need in a great team and to do good work.
And yes, everything I know about life I learned from eighties TV.
Empathy and awareness
Ownership of the project
Relinquishment of ego