As a UX and product person I had to fight the urge to check if I’d joined the wrong event. I stuck with it, re-reading the data guidelines over and over, and asking the occasional softball questions. 

Did I waste my time? No. Not for the group and not for the room. Because of the Wisdom of Crowds.

Yes, I mention The Wisdom of Crowds by James Surowiecki. Often misread by your common-or-garden tech bro as involving throwing decision-making wide open, chucking things out on socials and seeing what the masses think, the book actually argues for something quite different.

What it says is: groups tend to make better and more accurate decisions than single experts.

And not just random groups made up of random people but groups made up of a diverse range of informed individuals.

Why diversity matters for teams

Diverse here doesn’t necessarily mean in the demographic sense, but rather that groups (and teams) should include people with different knowledge and insights. They should be diverse in terms of perspective and experience. They need to be diverse based upon their members’ specialism and access to information.

Time and time again, studies prove that the predictions and results of these informed and diverse groups outperform the predictions and results of solitary, highly specialised “experts”.

I won’t get into the studies that the author covers to demonstrate this, purely because their book does such a great job of explaining them. But I do love the book’s comparison of NASA today with the newly formed NASA of yester-year, whose new teams were so highly effective at solving terrifying problems (Apollo 13 anyone?) precisely because they were drawn from so many different and diverse walks of life.

But anyway. 

How did my presence, as a UX nerd, help the group at this event? And why does the diverse group perform better?

And what can we take from all this to designing products, building teams and running businesses?

1. If you build diverse teams they’ll be better able to consider and act on information

If a group (or team!) is made up of people whose experiences and access to information are all too similar (i.e. the team is quite homogeneous), then when evidence arises that goes against the group’s expectations, it is more likely to be discounted. 

With a more diversely built team, however, it’s more likely to be considered and factored into decision making. This in turn tends to lead to more accurate decision making.

So, business leaders, build your teams to include a range of skills and experience. Build teams that can bring different information to a challenge.

And take extra effort to do this particularly when it seems redundant to do so, when it seems ‘obvious'  that the work should belong in the remit of one particular skillset or job role. Because homogenous teams can do some very weird and risky things, as we’ll see next…

2. If you build diverse teams it will reduce the exposure to risk

This one surprised me.

Basically, homogeneous teams actually get more extreme in their decision making and predictions. Discussion itself amongst homogenous groups actually pushes the group towards adopting more extreme positions than the individuals within it would usually hold.

In other words, discussion in very same-y teams amplifies risk, as the group decides upon more risky courses of action. And this isn’t healthy for the business, the group, or the individuals within it.

And it’s not because of any sinister or selfish reasons, but rather because of the way that people subconsciously (and naturally) try to maintain their relative position amongst the people they’re surrounded by. For example, if an individual believes themselves to be more middle-of-the-road in their outlook on a particular issue, when the discussion in a homogenous group drifts toward taking on a more extreme position, that individual is more likely to shift the positions they support too, merely in order to retain their relative social position. They accept far more than what they’d usually view as acceptable were they not in this group.

And they do this just so long as they can still retain the feeling that they sit in the ‘middle’ of the group’s position. 

However by including a more diversely informed group of people, you create a buffer: the chances of this polarisation and the team adopting extreme, risky decision making is reduced.

3. If you build diverse teams, they’ll ask themselves more questions and better handle assumptions

Groups which are overly stuffed with experts from the same discipline don’t ask themselves as many genuinely open questions. Discussions in these groups - even though it still happens - tends towards reconfirming their original assumptions, and participants from minority disciplines feel less included to ask questions. Worse, they defer to the “experts”.

(Which is risky in itself, as research shows that all people have a natural tendency to be overconfident about their abilities. And worse, with experts this overconfidence is even more pronounced.)

Furthermore, homogeneously expert-stuffed teams can see their role as being to reach a decision as quickly and efficiently as possible. This is a mistake. Because by adopting this attitude, decisions tend to get made early - probably based on assumptions and the homogenous group’s past experience - and then any discussion that follows is primarily aimed at getting dissenters to agree.

What should be happening is carefully, structured discussion based on considering alternative evidence, which leads to informed decision making.

So, groups that are diverse and which include a broader range of informed participants are actually more critical and perform better. Perspectives or outside information that would benefit the overall decision making tend to be valued more, whilst natural tendencies to minimise and ignore new evidence are tempered. 

So go you! If you’re part of a group and you feel that you’re not the expert, take heart! Asking questions is the vital role that you need to play in order to help the group remain critical and productive. 

And go me too. My role at the data event, asking low ball questions, had value after all.

Okay. You’ve established a diverse team. What next?

If you’re building a well performing team, you need to ensure there are processes to impartially collect, aggregate and act on information

It’s no use building a diversely informed team if power and responsibility are still centralised within that team.

For example, if final decision making is made by one person in the group then that centralisation of decision making will tend to undo all the gains from having a diverse group. 

“No decision-making system is going to guarantee corporate success…. But the more power you give a single individual in the face of complexity and uncertainty, the more likely it is that bad decisions will be made.”

Or, if the way that the group functions tends to minimise or filter out new and divergent information, then this will also reduce the impact of the group. A classic example of this is when team members are posed questions which are worded in such a way that it’s implied there is a ‘correct’ answer, or that any responses counter to ‘the norm’ will be unwelcome or an effort to consider. (Simple examples being “Are we all agreed that X is the best approach?”, “What are the downsides to not doing Y?” etc)

Yet if there is a mechanism to collect and “aggregate” information without judgement, then the group will be more able to act and make effective decisions.

Simple ways to collect aggregate and act

There are some very common ways to help ensure aggregation, and they’re not magical and they won’t surprise anyone. However in the context of the above hopefully you’ll see why they are especially important.

1. Ensure discussions come first, then lead into decision making steps.

2. Make sure that everyone has a turn to speak.

3. Decisions should be made by voting (blind voting os even better)

4. Aim for consent rather than consensus.

More structural ways to increase collection and aggregation 

Less simple ways that help facilitate aggregation exist too. As an added win they also help build healthy work cultures. The following are some top level ideas - each worth a world of guides and posts on how to implement them - but I hope they get you thinking.

1. Increase decentralisation.

Just as removing decision-making from the hands of single individuals within a team will increase the chances that good decisions are made, so too removing the centralisation of power and decision making from single teams will help harness diversity of thought, bring more information into the decision making process, and protect against bias. In this scenario teams should be able to work independently in a way that avoids duplication of effort, and be trusted with power.

Toyota's Production System, the classic example of Lean manufacturing, whose teams of frontline factory workers can solve problems independently without referring things to higher ups - and even have the power to halt production altogether - is a great example of decentralisation of power and decision making.

2. Increase the flow of information between teams.

But it’s not enough to have more teams doing the same thing. You need to increase the overlap, the interchange of information and evidence between teams. So consider:

• How might your teams better communicate and share information with one another?

• How might they overlap, perhaps, with some members sitting across teams to facilitate the sharing of relevant information?

• And what will count as relevant? How might you ensure that you find the right balance between sharing only that which is relevant and informing, and sharing all the information and thus increasing duplication of work.

3. Reduce hierarchies and status, which restrict the flow of information.

How many people need to be involved vertically for your team to be able to make a decision? How might this be reduced? 

You might not be ready for a flat organisation structure just yet, but there’s still much you can do.

For instance, user-centered design has already identified that people closest to the problem often have the best insights, and so it aims to get end users involved in product design decisions. So when it comes to your teams and your hierarchies:

• How might you remove the distance between top levels and the problem faced by users?

• How might you empower and build trust in project teams so that upper levels of power aren’t needed to sign-off decisions? (Tip: get power holding stakeholders involved at the beginning, give them the equal voting powers as the rest of the team, and get them to approve / back the team’s forthcoming efforts at the beginning. I.e. get them to express their trust for the team to continue. Then their involvement can be tailored off through the project).

And when it comes to product design itself, how might you involve people who work with your customers on the frontline, no matter their official job title? It’s true that the realms of product, UX and design have all the sexy job titles - but don’t the people working hard in customer support or staffing the phone lines speak to countless numbers of users every day? They may not working sexy digital or product roles, but they can channel your users’ voices like no-one else can.

These last questions are all deserving of a deep dive and I wish you well in finding out more. If I see anything particularly relevant in my web travels I’ll add it in the comments.

Good luck building effective, empowered and diverse teams!

That’s not to say that we don’t have structure, we do. But there’s no upwards reporting or supervision. And it works for us. It helps us feel empowered, independent and productive.

Outlandish the Company

At Outlandish, we make websites and data tools for social impact organizations. But the important thing to note is that we’re a worker-owned cooperative; there are no shareholders or anyone else extracting value from the company.

As a cooperative, all employees are co-owners/co-directors of the company. And, of course, as employees, the company pays our income taxes, contributes to our pensions, and provides all the usual benefits of being an employee in a business..

Being a cooperative isn’t a requirement for flat-structure companies - I think pretty much everything I’m about to explain can be applied to non-cooperative businesses -  but it’s an ethos that aligns well with the structure we employ, and underpins its core practices.

Okay let’s get into it.

Structure 1: The People

To talk about structure at Outlandish is to talk about the people. And we’re all organized into circles; three of them, to be precise. These circles are arranged concentrically, one inside the other.

• Innermost Circle: Members
  The innermost circle represents the “Members,” what we call the employee-owners of the business. They are involved in project delivery as developers, designers, project managers and more. But Members also have legal responsibility for the business and make important business-critical decisions about finances, strategy, hiring, and other key areas.

• Outermost Circle: Collaborators
  Collaborators are trusted freelancers with whom we regularly work. Their focus is primarily on project delivery rather than internal business operations, but they are still involved in some of the internal teams and decision making.

• Middle Circle: Outlanders
  And in the middle we have Outlanders. Outlanders are freelancers who are increasingly interested in helping run the business. They’re attending some business decision-making meetings and taking on more internal work, and gradually moving toward becoming Members.

Status

From these circles, you’ve probably gleaned that there is some form of status at Outlandish. 

And that’s true; even though we are flat and non-hierarchical, there are roles and statuses. This is discussed most when we consider who gets to work on what.

Generally, Members are to be offered work first, followed by Outlanders, and then Collaborators. In other words, work radiates outwards from the central circle.

Now, the reality is that things don’t quite work like this in practice, for a number of reasons. Partly because everyone's got different skills, and when work comes through the door it’s sometimes obvious that a Collaborator is best suited for it over a Member. Or they have more availability to take it on than a Member, or whatever.

Also, we care about our friends at work, and we want them to be able to pay their bills and lead happy lives too, so we don’t like to horde work to Members only.

So any status at Outlandish is mild, and the flow of work doesn't happen according to strict rules. But in short the company exists to serve the Members, meaning there is a gentle and benign influence helping Members - who ultimately carry the legal responsibility of running the company - get the first choice of work. It also acts as an incentive for people to consider becoming Members..

Structure 2: Teams in Circles

Flatness at Outlandish is also created in the way that the teams are organised and how they intersect. I.e. not vertically, but horizontally.

Each team, serving a specific business function such as finance, business development, design, tech etc, is also called a “circle.” (Yes, there are all kinds of circles!) Additionally some larger projects, like our coworking and events space SPACE4, also have their own circles.

And each circle should have at least two Members, ensuring all circles intersect with the Member Circle.

Circles are self-organizing…

These circles are very self-organizing and self-empowered. Anyone can join a circle by bringing a proposal (supported by a Member) in which they outline the value they would bring to that circle. This proposal is then checked by - and potentially agreed to - by the participants of the circle. (Of course there needs to be budget available to accommodate a new participant too).

In this way Members, Outlanders and Collaborators are free to join and contribute to the work of any area of the business. You’re a project manager but you want to join the finance team and learn about doing month end accounts? Great - bring a proposal and the team would be glad to have you.

Circles are self-empowered

Circles are empowered to make decisions and perform their work independently. We do this by practicing sociocratic decision-making within each circle. This means people bring proposals (e.g. a proposal to increase our client fees), and then these are discussed to tease out questions and check for “consent” to proceed.

What’s consent? Well, it’s not consensus, that’s for sure. We don’t aim for everyone to agree this what is being proposed is the best idea. Instead we ask everyone, is this proposal “good enough for now and safe enough to try”. In other words, can each of us consent to giving it a go?

This approach ensures continuous progress, and if something doesn’t work, we adapt with a new proposal and a new approach. This not only creates self-empowered teams but fosters a lot of personal empowerment too - because anyone can bring a proposal.

(And if you’re developing tech like we do at Outlandish, this practice aligns really well with some of the key tenets of Agile software delivery: that development teams are self-organizing, choose best how to accomplish their work, and adapt as they go.

This Sounds Great. What’s the Catch?

I’m not going to lie, running a flat company is difficult. Issues of power and responsibility remain, even in a structure designed to be egalitarian.

One of the challenges we’ve faced at Outlandish is maintaining flatness without set responsibilities. We don’t have people with roles dedicated solely to tasks like finance or HR; instead, a developer might also handle month-end finances or help with business development. 

And the absence of set roles can create complications.

Freedom to work vs. the needs of the business

Firstly, some people naturally gravitate towards delivery work rather than the running-the-company work.

At Outlandish, where we blend roles and everyone is free to consent to work (rather than it being foisted upon them), this preference can become a challenge. For example, if a developer prefers to focus on coding, and they're free to do that and decline the internal work, it means someone else has to pick up the internal tasks. And this has been known to cause resentment.

Personally, I think we don’t make it easy on ourselves. In my opinion, members of the team who focus purely on client work are still delivering great value to the company in the form of delivered work, happy clients, and a decent margin so that we can keep on going.

The division of labour and accountability is something that we still need to work out. But then perhaps that’s the trade-off with trust and flexibility? 😉

Peaks and troughs

Secondly, because we don’t have anyone in the Member or Outlander groups who solely works on either internal or delivery work, our current practice means that important team members are forever switching between client work (which brings in income, but takes our eyes off the ball of maintaining the business) and internal work (which needs to be done, but doesn’t bring in income).

This can cause frustration, sure, but worse it can create ‘peaks and troughs’ of income or internal spend which create a financial rollercoaster. For example, peaks when we are all heads-down and rushing to deliver client work.

This seems great - income is coming in, and we’re delivering on our mission to deliver great projects for positive social impact.  But, when the work is all delivered, come troughs: because we were distracted from investing in securing new work for the future. And at this point we all switch to securing new work, and the spend on our internal work ramps up.

And so the cycle continues!

Indispensability

And the third issue is that there are those of us who enjoy organizing and running a company. They bring passion and ideas, sometimes taking on leadership roles in multiple circles. While their contributions are invaluable, and despite everyone’s best intentions, in the long run this can unintentionally create problems of power: these people can become indispensable to business-critical functions and are seen as holders of knowledge.

In the best case scenario this means that they can become bottlenecks for checking business critical decisions. In the worst case (and we’re glad this hasn’t happened at Outlandish, but it can happen at other cooperatives) they can have more status and importance than others. This risks un-flattening the structure. 

Phew! This has turned into a long post…

You can see why I haven’t written it all down before! It’s certainly easier to explain in person, laying it out over a coffee or in a side-conversation at one of our events (plug).

Let me just finish on a positive note.

Because despite the issues and risks above, our flat structure company at Outandish helps make it the greatest place I’ve ever worked. Because, whilst the structure introduces challenges, it also helps foster an empowering and inclusive environment. I’ve never had as much control, self-fulfilment and friendly working relations as I do at Outlandish. We see each other as people, and try to figure things out together.

We’re still making mistakes, sure. But we’re still finding the healthy balance in our company and working to ensure that everyone can contribute in ways that feel right.

I wouldn’t have it any other way.

Doughnut image: photo by Nathan Dumlao on Unsplash

Spices image: photo by Ameya Purohit on Unsplash

It's not very socially positive or helping to change the world, but I am so in awe of Shazam, the app that lets you “identify the media playing around you, explore the music you love”.

Because it has much to teach about designing products that deliver value.

Everything about it, the premise, the design, the usability, makes it feel like it just.. works. Hell, Shazam-ing songs has even turned into a verb.

But how does Shazam succeed in creating this feeling?

The Shazam iPad app. Just one, big button.

Shaz what?

If you haven’t used Shazam, on opening the app a logged-in user is met with the instruction “Tap to Shazam” and a large stylish button. Nothing else. 

Tapping the button, they are told that the app is “Listening”, and there is an animation indicating background activity.

Within a few moments it tells you the name of the song and offers purchase options. Or you can just do nothing and go back to Shazam-ing the next song.

Speeding value into the hands of users

One of the ways it ‘just works’ is that Shazam delivers value to users fast. User needs are met easily and quickly.

So what can we learn from Shazam and how can we speed value to our users?

1. Reduce the steps the user should take to start accessing value.

In Shazam, the actions are clear within the first seconds of opening the app.

2. Have the UI limit options to users

In Shazam, the instruction and the single big button call attention to the core utility of the app and nothing else.

3. Cut user effort

In Shazam there’s absolute minimum effort from the user. One button press, then automation does the lookup of the audio.

4. Allow users to undo actions

Okay, now this isn’t very obvious in Shazam but it kinda does it..

Basically, cutting user effort passes things over to the system to do. So you always need to allow the user to be easily able to understand what happened, understand what went wrong, and undo things if the outcome isn’t as expected.

With Shazam, not much can go wrong, but it’s clear that if the audio isn’t recognised as a song I can one-press Shazam agai, and I’m invited to do so. “We didn’t quite catch that. Try again.”

Signalling value creation

Shazam demonstrates another couple of concepts that we should embrace when building our own products:

1. Signal that value is coming

In Shazam, the background pulse animation when “listening” and “sending” audio for analysis demonstrate the system state, sure, but they also indicate that you’re about to receive value.

2. Reduce the path to delivering value

If the system took half an hour to return results, I would be disappointed. Equally, if I had to head over to my Gmail account to see a result posted out via email, or even (heavens!) click through to another screen, that would be waste. Results are returned here and now.

3. Make the path to potential future value obvious

With Shazam, at this point the path to complete the users goal (of identifying any song in the future) is obvious.

Users now know that, if they ever hear a song in the future that they like/recognise but want to know the name of, they need only whip out their phone, open the app and press the button, and receive the answer.

It becomes part of their toolkit for the future, kept on their phone because they know that they’ll likely be in a situation where they would benefit from this functionality.

In conclusion

I'm not going to assume that team Shazam just focused on these principles and made a great experience. They surely have paid close attention to how users have used the product over the years and they’ve continually focused on simplicity, based upon delivering on the main user need.

Shazam is also a great example of a product that performs a dedicated function. These are resistant to feature stuffing and certainly easier to keep lean, rather than those products which are more nebulous (e.g. LinkedIn: “Manage your professional identity. Build and engage with your professional network. Access knowledge, insights and opportunities.” Bleurgh…)

So there we are. Thank you Shazam for demonstrating some great product principles. Let’s play out with one of my recent Shazams (... and you just know it’s a good product when its name goes from from verb to noun again).

Recently I’ve been reading the truly excellent ‘A Civic Technologist’s Practice Guide’ by Cyd Harrell. And it’s got me thinking about how we can best work with organisations who are trying to achieve social impact but are early in their digital and UX journey.

Meanwhile, I am a huge advocate for Google Analytics. From a UX and product ownership point of view it gives you fantastic insights into users’ experiences, and it can truly help you understand how your digital activities help deliver your organisation’s mission.

However, so often I have struggled to get client organisations to embrace it.

Helping organisations embrace data and Analytics

This is because I have been making a fundamental mistake about how to upskill social impact organisations to use data for making product decisions.

This is because people need to be in charge of their own development. And our job as technical “experts” is to facilitate the curiosity and growth of others, whilst creating the conditions for their gradual development.

☝️ Cyd Harrell’s fantastic book, ‘A Civic Technologist’s Practice Guide’

Reducing disruption

Many organisations working in the social impact space are understandably not data mature. 

They may not have thought about collecting data on experience, let alone be interpreting it to inform product or programme decisions.

In the midst of their busy frontline work, their reporting and their donor management, they have minimal space to think about working with data. 

So if you want to help people to use Analytics (or indeed any new tool), then consider this by Cyd Harrell:

“Remember that every change you push [read: introduction of a new process or tool] means someone has to deal with a disruption of their work – so make sure you make it worth it for them”
Cyd Harrell, ‘A Civic Technologist’s Practice Guide’

In other words, as someone who is passionate about Analytics, data and UX, it’s your role to introduce the smallest possible changes to your clients work. Make the barrier to understand data and Analytics as low as possible.

If this means creating a simple emailed monthly report containing a couple of key metrics – say, as basic as number of users and acquisition channel this month – then that’s fine.

Incremental increases

The goal is to make incremental improvements to an organisation’s working practice.

As such, in the early days, give people a small amount of Analytics insights and the most simple training about what it means. 

If you have a budget for implementing Analytics, make room in it for iteration, no matter what its size.

For instance if you’ve managed to get just 2 days for Analytics work, split it up. Do the minimum amount of useful work that you can first (say, no more than a day), then produce those basic reports to the client. Save the rest of the time for a later check in with the client, to answer their questions and to add more to the reporting based on their curiosity and needs.

If you want reassurance that this is a good approach, consider this Medium post by Josh Gee ‘What I learned in two years of moving government forms online‘. (Again, thanks to Cyd Harrell for making me aware of this)

In the post Josh outlines the work he did transferring scores upon scores of print-and-post application documents into simple online forms, thus helping to streamline government services and saving thousands of person-hours.

For many of the teams he did this for, once their forms were made digital, they didn’t receive data submissions nor complex CRM data integrations. Instead they were very happy to receive something as low tech as a generated PDF of the form submission. Or at best a structured email with the submitted data.

In other words, there was minimum change to their current working practice of handling submissions manually. It just got a bit more efficient.

However, Josh put a lot more work into getting the buy-in and interest from people he was working for.

“On average, it took me about 30 minutes to make a digital form and five weeks to meet with, earn the trust of, and get buy-in from the employees who would use it.”
Josh Gee, ‘What I learned in two years of moving government forms online’

And when he had that buy-in and usage in place, and teams were getting their electronic submissions, soon his clients started asking for improvements.

“Early on I began to notice a pattern. A few weeks after I moved a form online, some departments would reach back out and ask for tools to help them manage digital submission, ‘This has been absolutely amazing. It would be great if I could approve it and then send it to Steve for his signature'”.
Josh Gee

In other words, from a simple start they were onboard and had started on the journey of iterative improvement.

In conclusion:

Sensitivity, iterative improvements and allowing people to own their own development. This is the approach to start with upskilling organisations clients who are not comfortable with thinking in terms of data and users.

Take a small step. Make it minimally disruptive to their work, their thinking, and their mental space. Let them get acclimatised to that, and then, when they are ready, they will be interested in taking it one step further.

Image: Dan Meyers on Unsplash

We’ve all been there. You’re working up something new for your organisation, and you’re thinking about how to involve your key decision makers. You’re conscious that if you don’t handle them right, or include them at the right time, then they could be a massive pain in the neck. 

The worry is they might kill your project or suck the lifeblood out of it. Because that’s what stakeholders do.

Okay I’ve stretched the Nosferatu metaphor as far as it needs to go.

Fundamentally what you are concerned about (and rightly so) is that the product you are developing doesn’t meet your stakeholders’ approval. Or worse still that it fails to meet their needs.

So the question should really be: when should you involve your stakeholders to help guarantee the success of your project?

What kind of stakeholders are they?

Product users as stakeholders

But the first important thing to do is agree who we’re talking about.

If the stakeholders are ‘users of the product’, they need to be involved from the start of the project. 

They are the drivers of need, upon which your attempt to deliver a solution are based. They need to inform it, from research to inception to development and launch, and at every stage in the product lifecycle.

These are not the stakeholders I want to focus on in this post.

Sign off / power holding stakeholders

If the stakeholders are NOT the end users, and instead they’re ‘power holders in the organisation’ who need to greenlight the project in some capacity (for instance, line managers, a non-profit’s directors or board, interconnecting teams, etc), then this is a slightly different scenario.  

And these are the stakeholders I want to talk about.

An unrealistic ideal

There is an idealised scenario here which you might have heard: that you agree with your power holders that they sign off the start of the project and then leave you alone, or that they have diminishing input as the project progresses.

But that rarely happens. I have yet to work in one role where a manager has said that they are comfortable to work in this fashion.

A more practical alternative

Instead, I advise that sign off stakeholders are involved at the outset and then their involvement reduced at a specific time, a time which both reassures them and aids the project. 

In order to know when this is, we need to look at the creative process and how ideas lead to products. 

The creative and decision making process

You include stakeholders at the early stages of a creative project to get their buy in. That much is obvious. 

After this point, you should picture a diamond. When you are the initial task of coming up with a solution or formulating a response, you are at its point.

As you launch into the creative process all the options become available. Research and discovered needs stimulate ideas, which are thrown into the ring. The possibilities and options widen.

What are you going to be actually making? Who knows yet, but it’s very exciting and there’s loads of ideas on the table. 

This is divergence. 

After a period you reach the point where the breadth of options is at its widest; and it’s now that the team realise:

1. these ideas are increasingly distinct and incompatible

2. the clock is ticking and you need to make some decisions

Making decisions

So now you need to hone in your ideas, reject some and consolidate others. The range of options shrinks until eventually you reach the final concept. This is the point at the other end from where you started and the diamond is complete.

What you went through was convergence. 

It’s a diamond of idea generation, opening and then closing.

Convergence is all about making choices and eliminating options so you can decide how to proceed.

Stakeholder commitment

But how it relates to stakeholders is this.

Implicit in convergence is the act of commitment. As you move along convergence you are saying, based on what we know now: ‘we commit to say that these ideas are good enough to keep working on’.

So the important thing to do is to include your sign off stakeholders both at the outset AND as far along the convergence process as you can. 

At least get them to the point where convergence begins, where decisions are made about what to cut or consolidate and some ideas are moved forward. 

Get them involved in convergence. Get them to hone down the choices. And in doing so you’ll get them to commit. 

Risks of non commitment

If you include stakeholders only in the divergence, the creative steps, then they are always going to ask

• “What happened to my idea,” or

• “What happened to that idea I heard which sounded good,” or

• “It was a great process, and that tells me that maybe there is more to be done and more great ideas to be found. Let’s run this again and bring in more people [etc]”

In conclusion:

When should you bring in stakeholders?

At the start, and definitely at the point of idea generation. Take them through the process (divergence) to the point where decisions have to be made and ideas consolidated or culled to move forward. This ensures their commitment. 

At this point risk of them killing or delaying your project starts to decrease. The longer you can keep them involved from here, the better. But make sure you can get them to hear at least.

The post Managing stake (through the heart) holders appeared first on Richard Edwards.

This is the third part in a series of three posts, focusing on teams. The first post focuses on users and society, and the second on businesses.

They are derived from a workshop I ran in June to look at what COVID-19 (and the future thereafter) means for products, users, teams and society. 

The resulting How Might We… questions are designed to be a stimulus for others to come up with solutions in their own context.

We’re going to be building a new everything. So we might as well build it right.

Teams

Right now, there’s an increased uncertainty in our team-members’ availability. Childcare, sickness, isolation and more all stand to have an impact and reduce their ability to contribute important work.

So we have to ask:

1. How might we… work and plan our projects to account for possible absentee-ism?

2. How might we… ensure flexible working is built into our operational core?

3. How might we… support team members who are less able to contribute?

4. How might we… ensure equity between those in the office and those who are forced to remain remote / at home?

5. How might we… ensure that our remote workers are being trained, upskilled and are excited about their futures?

A lot depends on our culture and our organisations’ support mechanisms. Maybe now is a good time to improve them.

Our team members’ private lives and available resources are affecting their ability to contribute.

Morale is being hit.

1. How might we… address inequity (i.e. avoidable differences) affecting our team members?

2. How might we… ask questions to find out what our team members need, whilst being aware of sensitivities and worries about how this information might be used?

3. How might we… collaborate with other organisations on a response to employee/contractor mental health issues?

4. How might we… help organisations and team members return to ‘normal’ in a way that feels natural rather than forced?

5. How might we… prevent Zoom burnout?

Whilst our teams are being affected, our team cohesion getting weaker.

However, team members don’t necessarily want to spend more of their free time checking in with managers and colleagues.

This is a very interesting topic, and Slate wrote a great article on the pressure on employees to participate in ‘mandatory fun’ and supportive activities that ultimately increase stress.

My favourite quote from that article:

I have a line-manager who I haven’t always had a great relationship with, and I’m exhausted by the constant “mental health check-ins” with someone whose intentions I don’t entirely trust and would much prefer to only interact with on work-based topics. Now I’m expected to discuss my mental health challenges with near strangers who aren’t paid professionals?!

Slate.com

So, in light of constant check ins:

1. How might we… protect people from good intentions?

2. How might we… provide mental health support, whilst admitting we are not impartial, mental health professionals?

3. How might we… just help people focus on the work?

4. How might we… allow people to opt out, without penalty? (Thanks, Slate).

5. How might we… enable our team members to communicate when and how they want ‘to talk’?

Teambuilding is hard. Right now, new joiners are even more on the outside. Because it can be harder to integrate into an established group.

And if you’re a new joiner to a company, course, or other community, you carry a lot of anxiety about how you might be perceived.

1. How might we… best onboard people into a team?

2. How might we… do the ol’ induction process office walkaround, when there’s no office?

There’ a loss of spontaneity and chanced upon discoveries, which always used to contribute to a project

As Pedro in our session pointed out, when we were all based in an office, a project in development would happen to be glimpsed, overheard about or generally stumbled upon.

The conversations and inputs from an ‘outside’ eye then would often contribute to a project.

This was so regular an occurrence you could even say these hallway and kitchen inputs were a part of the collaborative project development process.

So, now everything is remote…

1. How might we… formalise processes to include steps and occurrences that would have happened organically before?

(This has crossover with our first post on users and society: HMW… better replicate the chance meetings that allow for shared human connections?)

Lastly, above and around our teams, traditional hierarchies make it hard to work in this new normal (e.g. Leadership team / senior managers)

1. How might we… move towards more flat structures, collaborative ways of working?

2. How might we… find new ways to work with the Leadership team?

Moving on

That’s it. That’s the last of this series of articles focusing on products, users, society and businesses post Covid-19. Hopefully some of those will have inspired you and given you thoughts about how to adapt and move forward.

Stay safe and happy.

The post 20 useful questions on teams & team-building, post Covid-19 appeared first on Richard Edwards.

This is the second in a series of three posts on products and innovation in the New Normal, focusing on businesses. The first post focuses on users and society, and the third on teams.

They are derived from a workshop I ran in June to look at what Covid-19 (and the future thereafter) means for products, users, teams and society. 

The resulting How Might We… questions are designed to be a stimulus for others to come up with solutions in their own context.

We’re going to be building a new everything. So we might as well build it right.

Business

Obviously there are lots of issues here. And so many resolve around uncertainty.

What should our businesses adapt to? What should we strive to reach for? What is the most pressing problem to be solved and where should businesses place their resources?

In short, we’re not confident about our direction and our next steps. This lack of certainty can be passed on to our users.

So…

1. How might we… acknowledge the uncertainty around information we are providing to engender trust?

2. How might we…better understand our industry and how the pandemic could affect it?

3. How might we…document solutions to problems to better prepare for next time?

4. How might we… instil a sense of certainty/credibility in our supporter so that they in turn believe in us?

Meanwhile users have a lack of patience around tools that can be used for multiple purposes. This can affect those of us whose core products are tools rich with features and flexibility.

Our users are urgently looking for “one tool for one job”. (See also: Users are going with what they know and trust, even if it’s not necessarily the best tool for the job.)

So…

5. How might we… communicate our value proposition clearly to users?

6. How might we… diversify our products?

7. How might we… design/make a product that’s as easy-to-use and reliable as a fridge or a microwave?

And of course we are losing customers. Sales are being delayed. Users and clients are worried about their income and cancelling their accounts. So…

8. How might we… offer incentives to new customers, but protect our brand and perceived value?

9. How might we… maintain (or increase) retention of existing customers?

10. How might we… help them understand the value they’re receiving?

In response to a potential loss of income, there’s a drive to adapt and find new income streams. However it’s hard to know how much we should experiment and innovate vs. shut down and wait it out.

11. How might we… understand what’s realistically and financially possible when it comes to innovation right now?

12. How might we… we diversify to protect income streams?

13. How might we… encourage risk taking from our senior teams?

And our roadmaps are being thrown out of the window.

14. How might we… best roadmap and plan in a time of uncertainty?

15. How might we… do away with roadmapping entirely, and adopt a development process that focuses on rapid iteration, experimentation and alternatives?

Moving on

Hopefully some of those will have inspired you.

The questions continue in the third and final post in this series, on teams and team-building.

The post 15 useful questions for product-based businesses, post Covid-19 appeared first on Richard Edwards.

Image: Tobias Bennett on Unsplash

In June 2020 I ran an online workshop to look at what COVID-19 (and the future thereafter) means for products, users, teams and society. 

The impact of COVID-19 on products, UX and people, has been on my mind a lot since the lockdown began. I didn’t have many answers, but I wanted to bring people together to share what we know and see how we might make things better.

Basically, since the pandemic everything has changed. In particular, around these key areas:

1. How can we research, innovate and launch new ideas when there is so much uncertainty?

2. How are people’s behaviours changing? And their needs and expectations?

3. And, most importantly, how will society change (for the better?) and what can we do to help build it anew?

Because we’re going to be building a new everything. So we might as well build it right.

“How might we…” questions as a springboard for your solutions 🤔

Together we identified some of the challenges and (in true Design Thinking style) captured stimulating How Might We (HMW) questions that, I hope, will act as a springboard for others to adapt their products, to improve their team-working and to craft a new society in light of the pandemic.

I hope they are of some value.

Users

Since the pandemic’s arrival, our users' needs are rapidly changing.

• How might we… assess whether users’ needs right now will be the same in the next month, or post-COVID?

• How might we… adapt to user needs now, but protect against over-correction?

Meanwhile, working remote, we’re extremely separated from our target users.

• How might we… increase the time we spend and learn from actual users, even though we are remote?

All the while, our user groups are changing and fragmenting. So….

• How might we… identify and create new user segments in this time?

• How might we… improve our data gathering to identify new user segments?

On the loss of contact with each other 😔

Users themselves are missing the small, real-world interactions with their colleagues, peers and wider networks.

• How might we… replicate real world interactions in the products and systems we’re building?

• How might we… better unite humans and technology, in order that we might better express ourselves?

• How might we… better replicate the chance meetings that allow for shared human connections?

(The last of these a really interesting one...

During the workshop, one of the attendees pined for the the random yet productive conversations that might occur say, at a conference during in a queue for coffee.

This led to the discussion of someone’s experiences at a recent online workshop on Zoom. There, in the breaks, the hosts used breakout meeting rooms, putting everyone randomly into rooms with one other person.

This facilitated the chance conversations that otherwise rarely happen in the online world.

This also has crossover with the question of “How might we… formalise processes to include steps and occurrences that would have happened organically before?”. This featured in our discussion on Teams.

... Anyway, I digress.)

• How might we… build more informal communication into our digital products?

• How might we… use mixed modes of communication to diversify the way we stay in touch?

• How might we… we build play, fun and creativity into our core online communication?

Uncertainty

Our users are facing a precarious and uncertain future…

• How might we… acknowledge the uncertainty around the information we ourselves are providing, in order to engender trust?

… and those of us who are self employed or work in the gig economy are less secure than ever.

• How might we… build products that help users find each other and find opportunities. 

Users are finding themselves overworked in their wider lives, and it is hard for them to focus. Nor maintain progress in the things they start.

• How might we… build products that engage learners and help users focus?

• How might we… build products that convey clearly to users where they’re at within a product?

• How might we… build producers that give new users an idea of where to start? 

• HMW… use our marketing, and onboarding and retention to help users figure out what to prioritise

Social equity and fairness

And as for the vulnerable, the excluded and minorities, they are suddenly finding themselves even more disenfranchised.

(☝️ this article is here.)

So…

• How might we… ensure our products and processes are as inclusive as they can be?

And as locked down product owners, who are (tbh) likely not to be counted amongst the disenfranchised, we’re even less likely to be interacting with the same range of people and places as we did before.

• How might we… as product owners, identify and research the needs of diverse people who are now even further out of our (reduced) zone of contact?

Stepping up a level there’s lots of talk how the world and society will change after COVID-19.

• How might we… build on the sense of change and optimism for the future?

However, our society’s inter-connectivity has taken a hit. Our access to each other is limited, due partly to social network effects and, in some places, the politicisation of the pandemic. So the pockets we find ourselves isolated in grow deeper.

The result? There is greater polarisation even the smallest differences between us.

• How might we… design products that increase our contact with those who are now out of our typical zone of contact?

• How might we… design products that find and build on commonalities, across the pockets of the internet.

• How might we… go beyond the echo chamber?

And whilst we’re all working from home, it’s now recognised a legitimate thing to do. Even if we are working in the evenings and early mornings more, to make up for childcare.

• How might we… build more flexibility into the systems in our society? (Flexible train season tickets for part time workers? I’m looking at you)

• How might we… make more services available online and out of hours?

• How might we… ensure equity for those for whom part-time, flexible working is not an option?

However in the rush to move online, to ‘construct’ safety and support the vulnerable, privacy issues are being overlooked

• How might we… gather data on workers needs, to create more equitable systems, but better communicate the use of that data and guarantee its safety?

• HMW… use biometrics in privacy-protecting ways?

• HMW… apply better safeguarding / child protection in an online world?

• HMW… avoid a step towards a new authoritarianism?

Moving on

Hopefully some of these questions will have inspired you.

The post 30 useful questions for products & users, post Covid-19 appeared first on Richard Edwards.

There’s a new idea in town, and lots of talk about its potential to effect change or bring in revenue. So now the big guns in your organisation have made budget available for you to lead on its delivery. (Lucky you 😱)

The pressure’s on to get to work and go big… but you’re not convinced that this is the best way to get to success.

Meanwhile, you’ve heard about agile, Minimal Viable Products (MVPs) and failing fast, but you’re not sure how to sell your organisation on such an approach when the pressure’s on.

Or, perhaps YOU are the team and the money, and this is your vision that you’re bringing to the world. And you’re not convinced that an MVP is worth it when you’re ready to go all in, right now, on developing what seems like a dead cert.

So. Two scenarios but with one shared problem; how to give this idea the best chances of success.

Subscribe now

Getting to MVP

We do a lot of workshops that help develop MVPs and define products, but we know the MVP approach is not an easy one to embrace. Launching something sooner, with a much smaller scope, seems counter to big ambitions and targets.

In our work with clients we’ve discovered some common blockers to the MVP approach. So we’d like to raise some of them here and help you overcome them.

Share the solutions with your team, or better still share this blog post 😉, and hopefully they’ll help you get to ‘yes, we need an MVP. We need an agile approach’.

Common MVP blockers:

1. “Our idea needs to serve lots of different types of users, and they all need to be on board for it to be a success”

2. You’re trying to build an ecosystem, not a product, and that’s getting in the way

3. “Are we building an MVP, pilot, proof of concept?” Confusion abounds!

4. Creating your MVP is planned to take ages. Is it still an MVP?

5. People are wedded to the flashy tech approach

6. Your budget is ‘spend it now or lose it next year’. So go big now! (Actually, please don’t.)

1) “Our idea needs to serve lots of different types of users, and they all need to be on board for it to be a success”

The scenario:

The concept depends on a whole bunch of very different user groups embracing it and using it. For example, a new service for charities, businesses, consumers and policy makers.

This is a very risky situation. Everyone needs to get significant value from this concept in order for it to work. And the likelihood that you can deliver the right amount of value to each of these user groups, straight off the bat, is slim.

Moreover, the likelihood that you can do this AND market it to them all equally enough that they all want to sign up, before the other users are shown to be in place, is slimmer too.

Solution:

Focus on one user first. Choose the user with the greatest pain points to find out who will get the most value from your product.

Then refine the concept to focus on them, looking at how you can deliver value without the participation and contribution of the other user groups.

Develop, launch, and when you have built your user base from your first user group, look at how you can then provide value to the next most significant user group. Think about features that solve their problems.

Once you’ve done that you can look at how your product can internally connect these groups together.

If you need help doing this, consider a Design Sprint or a Design Sprint in a Day workshop.

See also…

2) You’re trying to build an ecosystem, not a product, and that’s getting in the way

The scenario:

There’s lots of visionary talk about how, when the idea is up and running, services and processes will connect in a successful, codependent harmony.

For example, the Great New Idea sees charities fundamentally changing how they work, and this will be feeding in to new governmental processes and policies. Meanwhile, businesses will be benefiting from these policies, and their end customers will start to undertake new behaviours, and they’ll feeding back to the charities via technical innovations.

Unfortunately, this visionary ecosystem of inter-connectedness is blocking any work from starting. Any proposal to focus work on X results in a chorus “ah, but we mustn’t forget about Y”. Worse still, there’s “if we only do that, then Y and Z can’t happen”.

You get the idea. The vision of an ecosystem is getting in the way of starting work on something small.

The solution:

See 1), above.

Also at this stage, you must recognise that there are huge assumptions being made about how these systems work and their points of connection.

In our example, it might be about how charities function, or how policymaking actually happens and the legal steps it must go through, or the types, amount and relevance of data that can be collected, etc.

It is also very likely that you and your team only really understand (at most) one of these systems. If you’re a charity, you know your own sector and processes, and perhaps a bit about policymaking, but its probable that you don’t really understand the realities of making a business work, or commercial consumer behaviour.

All the time that it takes to understand an unfamiliar sector is time taken away from developing your concept and getting it to market. Again, that’s a huge risk of wasted effort should your concept ultimately not be what the market wants.

Again, focus on one user group to begin with. Ideally those with the biggest pain points and hence the most value to be gained from your idea. It might also be wise to focus on the sector that you understand the most.

3) Are we building an MVP, pilot, proof of concept? Confusion abounds!

MVP? Pilot? What’s the difference? Do you need both?

In short, an MVP is about focusing on the core of your idea and getting it out the door with the minimum risk, whilst learning from its reception and initial usage as much as possible.

Ideally, if the intention is that this idea generates income, then the very first release should aim to do that too.

A pilot is about rolling out an idea (especially a service) to a large group. The scope for change based on learning is limited – little can be done after the pilot stage except minor tweaks.

I am of the opinion that thinking about pilots now is flawed, as it kicks the hard work of learning from users and making tough choices further down the road.

As such it increases risk for you of getting more wrong and wasting more initial effort.

It also moves you away from the agile approach. About working in risk-reducing, short, regular and repeated phases of learn -> devise solutions -> develop them -> launch -> test -> learn.

If your MVP is a success, you should avoid a ‘pilot’ phase and instead concentrate on scaling up from there. Successively look at how you might solve more problems for your users.

And if your product has been generating income early, you will get to financial security sooner.

Please note, neither of these are the same as a proof of concept. A proof of concept checks your idea is practically possible. For example, that your product can connect to a certain third-party API, pull some data from it, and do something with it.

4) Creating your MVP is planned to take ages. Is it still an MVP?

It’s going to take, like, 9 months ages.

That’s a lot of risk and expense and effort right there. Stop it. Really, just stop it. You can deliver solutions to problems (in some form) in a much shorter amount of time.

That said, the chances are that this is related to…

5) People are wedded to the flashy tech approach

(Also known as “please don’t tell me we can achieve the same results with a blog.”)

The scenario:

This is a really interesting one, and one that I love to discuss.

Here, perhaps you’ve already identified your key user and know what their pain points are. You know what value they seek from a successful product.

However, you’re very attracted to using a certain type of technology or approach. There a lot of talk about the tech. People seem wedded to a thing.

At this stage someone might propose (or you might realise) that there may be a simpler way of solving these problems. For example, you can give your users much of what they need via a blog. Or an email newsletter. Or a forum or meetup.

This might especially be true if their problem could be solved with better access to information or through connections with others.

In other words, you could achieve the same results  through doing something not particularly ‘innovative’.

However…

Too often innovation is presumed to relate to the technical sense. But real innovation is about getting audiences to do something different in a new way.

People tend to think innovation means using a new framework, rather than the hard work of guiding the audiences through a journey differently.

The solution:

This is a really hard one to accept. I know. So fine, if it makes you/your team excited and happy then aim to build something better than a blog or email list. In fact, I might actively recommend this if the platform itself is meant to deliver desire, because desire and emotional value can be core to a successful user experience.

Being on your sexy platform allows the user to tell a story to themselves and others about their engagement with the product, which reading a blog or chatting on a forum itself won’t provide.

But a blog, for all its lack of sex appeal, is a simple, risk free way to provide the same end goal and value.

Also blogs or info based products are great for another reason. They force you to focus on doing the actual hard work of engaging people directly and saying something.

You’re not researching tech stacks or planning and building features, but you’re actually putting yourself out there and saying something. It’s exposing and hard but it’s what you’re ultimately aiming to do – express your opinion and connect with people and create change.

6) Your budget is ‘spend it now or lose it next year’. So go big now!

The scenario:

Your budget is at risk. If you don’t spend it all, you might not be given it again.

This leads to big plans, big pressure, a rush to work and too much effort upfront, before you’ve tested and learnt from real users.

The solution:

If you really must spend it, commit your bosses to letting you run the project in an agile fashion. Demand that they hold you to spending only a quarter of the budget on an MVP, and insist they make you launch this early. And then you’ll divide the rest of the budget on at least three more iterations, post-launch.

If your budget is large, hell, make it 1/6th on the MVP, and then 5-10 more iterations after launch.

Tell your bosses that your MVP product will be a very basic and might even be a dud without much user uptake. But by Sprint 3 it might be showing real traction, and may well have already established itself in the market.

This is a much better place to be in than spending it all up front and launching with fingers crossed that your users will like it.

Also, our experience of working with clients on this sort of project tells us: no matter what your budget, breaking the work into a series of regular ‘sprints’ of activity produces huge efficiencies and better decision making.

This is a much better approach than budgeting for occasional splurges of spend that don’t run consecutively.

In conclusion

Working on your bosses to get to an Minimum Viable Product, seeking to launch and learn from it in the market, is critical. Once it’s launched, scaling it through successive phases of development is vital at cutting risk, reducing wasted effort and increasing the overall chance of success.

If you want to get yourself or your team on board with this approach, consider an Outlandish Design Sprint, which will take your idea through to prototyping stage and will test it with real users.

Or, if you need really to convince sceptical bosses of this approach and you’re working on a tight budget, try getting as many of your team as possible on one of our Design Sprint in a Day workshops. These intense sessions will help you build a unified team vision, define your key users, conceptualise your MVP and create your product roadmap.

The post How to encourage your team to launch an MVP first appeared first on Outlandish.com.

Recently I’ve been listening to Seth Godin’s excellent Akimbo podcast on enrolment and possibility. And these two concepts are so valuable when you’re thinking about new campaigns, products and content.

The crux is, to change culture, to find your core believers who will support a campaign or use a new product, you need two things. Possibility, how you sell the potential to have impact and change the culture, and enrolment: the system to facilitate buy in and to take people on that journey.

Why are these important?

Going beyond the same-old, same-old

They’re important because all too often we forget about what we are really trying to achieve through our campaign or with our product and so we fall into habitual behaviour: we focus on employing the same old tactics that we have used before and are expected to do now.

As a result our campaigns and our products are not as effective as they should be.

For example, let’s pretend we are launching a new online campaign.

(And a quick note: I’m going to use “campaigns” from hereon in, but a lot of this is applicable to thinking about new products too.)

If we’ve done online campaigning before we might think it’s a good idea to daisy-chain calls to action together (“sign this pledge”, then “thanks for signing the pledge, now can you share the campaign on Twitter?”, then “thanks again, now how about signing up for our mailing list?” and so on).

By why are we doing this? And if we are going to offer different levels of participation – because that’s what we are doing – what’s the best way of doing it?

Moreover, how can we treat people who participate respectfully, and not repeat the same old tactics that are done to supporters by so many other campaigns?

Now is a good time to think about possibility and enrolment. By doing so we can refresh our attitudes and be more effective in our ways of connecting with people and mobilising change.

Possibility

Possibility is the potential you have, your campaign has, to bring about real change.

Of the two concepts, possibility is the simplest to consider.

And of the two concepts, possibility is more important than enrolment because no matter how easy it is to take part in your campaign it won’t matter if it seems like the end change is an impossible one to achieve.

So ask yourself:

• How might your campaign and the messaging around it sell the idea of possibility?

• How might it evidence what is possible?

• And how might the campaign make the possibility seem attainable?
  Because (and this is a glib example), a campaign that aims to “end world poverty” feels like it is overreaching. But a campaign that aims to, say, put a new kind of safety net in place “to help prevent vulnerable people from falling into inescapable poverty”? Well, that sounds like it might be possible. It’s a future that we can visualise and a campaign that we can back.

• how might your campaign convey the increasing possibility of success as the campaign unfolds and people take part?
  In other words, how might it ratchet up its own chance of success?

If you can think about these questions when formulating your campaign, and if you can consider them when you’re crafting the language around it, then you can make sure you’re building possibility into your campaign for your audiences.

Enrolment

If possibility is the most important, enrolment is the most difficult to get working effectively. But done right it can be your engine to deliver the possible.

In short… how can people get started? How might the system you create facilitate their participation? How might the system you build help people deliver the possible in an engaged and active way?

This is why the idea of enrolment is so important. To be enrolled means to be an active, contributing part of the system. Enrolment is a way better analogy than sign up. Sign up is passive. Sign up is ‘take my email and maybe I will do something with your newsletters and updates’.

Showing up and doing the work

Enrolment recognises people’s role in the change they want to bring. It rewards commitment and effort and encourages being part of an active community.

And if you think the word ‘enrolment’ evokes college learning and working together: that’s the point.

At its heart, enrolment is about connecting people.

Let’s take an example.

LendWithCare is a fantastic campaign that gets people micro lending to small, local entrepreneurs in the global south. You can lend people £5 to help them start a new brick oven, to buy a new market stand, to purchase a motorbike to increase their distribution, etc.

You can browse who to support, see their photos and read their life and business stories. You get updates on the progression of their repayments. And when they have repaid you you get your money back, ready to reinvest with another person.

It’s fantastic in connecting you to those you are supporting.

And it connects you to others like you. You can create groups of lenders and come together to back people you believe in. You can gift LWC vouchers to get friends and family lending (which is the start of some great person-to-person conversations about the campaign and its possibility) and the LWC team are always present and on hand to chat.

As a result, the people who support LendWithCare are a fantastically enrolled and passionate bunch. The team at LWC could run a ‘what shall we do next’ event next week and they would have a room packed full of supporters, many of whom would have gladly travelled far to contribute their advice.

Give supporters the value they expect from their involvement

Which brings me to my final point about why people support campaigns.

We must recognise that when people contribute to a campaign, even if it’s a charitable one, they rarely contribute freely.

People usually give because on some level they expect to get value back. Deep down it’s worth more to them to give than not to give. This is true whether they are making a pledge, giving time or donating £100.

The value they receive from giving is emotional, spiritual or social.

Value comes through storytelling

And the value returned comes via the story they tell themselves about their own contribution. About their impact on the world and their personal role in delivering the possibility.

If you’re struggling to see what I mean, think about the LendWithCare supporters and the stories they must proudly tell themselves (and those around them) about how they’ve helped people in developing countries grow their own businesses and build their own livelihoods. This is worth so much more than their £5 loan.

So, as campaigners, we have an obligation to recognise that supporters who give us their time or money hope for something in return, and that this is perfectly fine, normal human behaviour.

Going beyond the daisy-chain

Which brings us back to the idea of daisy-chaining calls-to-action.

It’s not enough to just escalate calls to action. It’s not enough to just say thank you in the web browser, and gradually feed supporters towards subscribing to your email list. What story can they tell themselves and others about that?

So be kind. Give them the value they seek. Whatever type of campaign you are running, ask yourself:

• How might the system we are building give supporters the emotional, spiritual, or social value they seek?

• How might it help them to tell the best possible story about their own involvement?

• And most of all, how might the campaign help supporters to be enrolled, to reward their contributions, to actively connect with others and deliver a change that’s possible?

The post How embracing possibility and enrolment leads to better campaigns appeared first on Richard Edwards.

Recently I’ve been lucky to run a range of design and product workshops with Outlandish, the worker-owned tech agency. It’s something I love doing. From 5 day Design Sprints based on the Google Ventures handbook approach, to one day MVP planning, design sprint-in-a-day sessions and more.

Through this there are a few simple techniques that I’ve come to appreciate that can significantly improve the experience of those in the room and the output of the day.

Some of these have already been recommended by Jake Knapp, John Zeratsky and Braden Kowitz in their book Design Sprint. I reiterate them here because, when you’re reading the book prior to running your first sprint, it’s easy for their importance to be overlooked.

Others have been learnt the hard way or developed with input from Outlandish colleagues.

Okay, in no particular order, here we go:

If you say sketch, then sketch

In a design sprint there is a lot of sketching. There needs to be. However some people don’t feel comfortable sketching because they’re worried about presenting their drawing skills to their peers. Also they’re concerned they can’t capture what’s in their head.

They will want to write their ideas instead.

But you should avoid your participants writing instead of sketching at all costs.

A written response feels clear and complete. But the beauty of sketching is that it IS crude and unfinished.

A sketch invites more contribution and engagement. It leaves space for the idea to be explained by its drawer and interpreted or elaborated upon by the listener. Because of the space around a sketch the potential feels larger, and more gets opportunities are seen within it.

Sketches, crude flowcharts, stickmen – these are all fine. But written responses should be discouraged.

Reassure your participants that no-one is judging, we are seeking to be inspired. Use the explanation above if need be. Explain why sketching is so important.

Make them stand

There’s something about tables that puts lead in people’s butts and makes them want to sit. This is murder for a collaborative process.

Keep the space more space than table. Give plenty of room around the whiteboards.

Take as many tables out as you can. Leave enough for people to sit at and make notes, but ensure that it’s light on tables. Even a little cramped. People will feel inclined to get up and out of their seat.

Equally, direct them. Don’t be afraid to explicitly ask people to stand up. Ideally before explaining the rest of the activity instructions.

Tell them directly: “Okay, for this next activity I need everyone out of their seats. So, please stand.

“What we’re all going to do is take one sticky note, write on it a user type, and post it on the board. And we’re going to do that for as many user types as we can think of for the next 2 minutes.”

And know where to stand during their feedback

As the facilitator and someone who’ll probably doing the majority of the speaking during the session, attendees feel naturally inclined to address any feedback to you. Be aware of this. They need to be feeding back to their peers, not ‘reporting to teacher’.

So when people are feeding back, try to stand in the midst of the group. Even better, stand behind them, so others are between you and the person at the board explaining their work. This way eye contact is made with their peers, group engagement happens and feedback is taken board.

Be aware of the power in the room

The main client has a lot of power. They’re probably an important decision maker too and it’s important that they’re invested and involved.

However they’ve got a team with them, and some of them in that team have a very different status. The intern. The assistant. The new hire. The student help. And the reality is they’re likely to have just as valid input.

It’s probably imperative, in fact, that new thinking is required on this project – and perhaps even they’re closer to the product’s target user than the CEO.

However it’s easy for the CEO to have a louder voice and the intern to be excluded. So, ensure that everyone is given full chance to speak and participant. And make sure that the intern, the assistant don’t just get a turn at the end of an activity, after everyone else has spoken and now the clock is ticking to move on. But rather, mix them up. Mix everyone’s turn to speak up.

As an aside: Outlandish, where I spend much of my time these days, uses a consent-based decision making process on their projects called sociocracy. Using it in design sprints is a great way to help level the playing field. They offer training in how to apply sociocracy in your own work here.

Make those sticky notes work for everyone

There’s a reason why sticky notes are sticky, and that is so they can be unstuck. And moved.

The process of design requires that people form associations and take action.

Writing notes and sticking them to a wall allows us to immerse ourselves in the chaos of information. Our brains kick in and try to form associations, and soon enough we find ourselves making connections and spotting common themes.

Moving the notes and resticking them elsewhere allows us to spark ideas and conversation, and so on.

If an activity requires sticky notes (e.g. for an idea generation activity, or capturing insights and research), make sure that they go on sticky notes. And insist on one idea or insight per note. Then get them up on the wall.

Really, do push your team to do this. They’ll find it unusual at first, and you’ll need to guard against over-talking and discussion of the notes as they’re created, but soon they’ll see the value of doing this.

Use the board to cut down discussion

A simple yet effective trick: partition a slice of your board off at the start. Draw a line to make a column to one side of your board.

This is your park board.

Here you’re going to park any questions that are taking up too much time.

In my experience they’re usually questions about what-ifs. I.e. other things that the project may or may not need to connect with in the future and how this challenge might be resolved; what other stakeholders who are absent might say; and risks.

Although these can’t be resolved in the room right now, you will find that one or more people will start discussing it like it’s part of the output of the day. It isn’t

I like to capture these things as questions, and refer back to them in the Design Sprint How Might We…? session, if you’re running one.

And when the day is over, you should also refer back to the park board to see if any of the issues and questions parked are still valid and actionable after the sprint.

You can also use the park board to list vocabulary that your team might be unfamiliar with, key dates, or other headline insights, and so use it to reduce the cognitive load on your participants.

Show the running order

Let’s think about the setup for a minute.

In the Design Sprint book Jake Knapp recommends showing the agenda at the start of the day, indicating all the different stages and activities you’ll be running.

There is something so fundamental about doing this, but it’s easily forgotten as you strive to get everyone settled and to get going.

Sure you can just launch into the day and try to take people on a creative journey, but attendees derive confidence in you if they know there is a grand plan. That things are heading in a certain direction – even if they don’t understand what the items on the running order mean or what they’re going to be doing.

Showing a topline running order means they relax. They give themselves over more to the activity. And your day just got a lot easier.

Ask permission

Another simple win. After the introductions and showing the order, check the understanding of your guests. Then, explain your role and the desired outcome of the day.

Finally, ask your attendees to allow you to lead. That’s all. Just ask your attendees something along the lines of “if I have your permission, I will be running through these activities and taking us towards this goal. How does that sound?”

They will say it sounds good – yes, you have their permission. And of course they’ll say this. But in this moment there is a transaction that takes place and trust is imparted to you.

Speak less

It’s scary to speak to a room, to lead a workshop. There is the fear that you won’t be understood. You feel a pressure to fill the air and over-explain. You feel that people expect you to have all the answers.

But that’s not true. It’s mostly in your head.

So breathe. Take a moment before you speak. Talk a little slower than you usually might in a conversational setting. Actively listen to yourself as you talk.

And when you’ve said what you have to say, lean into the pause. Leave it hanging in the room.

Generally your attendees will want to help you or rise to your challenges.

And as for questions: recognise that you don’t need to have the answers. If someone asks a question, open it to the room. You are there to help the day run beautifully and the attendees to be as productive as they can be.

When you do these things, you pay more attention to what you’re saying. You see where your tongue is taking you and how to finish the idea you’re halfway expressing.

Prepare. Prepare prepare prepare…

And finally, preparation is key.

When I was teaching English, I liked to have a running order, by the minute. For example, prior to running a class I’d make notes like this.:

• 3 minutes – warm-up activity the ‘eee’ and ‘i’ game

• 5 minutes – write past-perfect example sentence; elicit other examples; elicit grammar points

• 15 minutes – set questions

• 5 minutes – check answers and understanding

• … etc

At every step I would also prepare what I needed say, almost like a script.

And I do the same thing with running workshops.

However I know that we will probably stray from this. I know that I can’t keep referring to the running order every few mins – it’s impossible. I accept that I will get sidetracked, or I’ll forget something.

But that’s okay, because the act of preparing helps me really get comfortable with the activities and feel relaxed. And in the room, it helps me have a better awareness of time.

So there you are! A few tips to help you run sessions. Hope they’re of use

The post How to run effective Design Sprint workshops appeared first on Richard Edwards.

The change in life that an upgrade makes, is it even still noticeable? Compare that to how it felt when you first bought a smartphone. Or your first car?

The impact of successful products

As a product actually develops from idea to reality, the potential directions it could go in rapidly narrow. The potentialities evaporate as decisions have to be made and things start to be laid in place. Once build begins, the cruft – the assorted debris, the complexities, leftovers and impacts of design and build choices – increases.

Gradually it becomes harder and harder to improve upon the product, and the effort required to continue to develop new features or apply improvements increases.

Meanwhile, something worse is happening.

The addressable market for your product is shrinking. Or because I like to focus on people rather than market numbers, I prefer to phrase it another way: the potential emotional value that your product supplies is shrinking.

The product value / product development trade off

The users whose pain point you solved with the launch of your MVP and first few iterations, are still around, but their scale of problem has reduced. You’ve (hopefully) already addressed it somewhat and provided some level of solution.

And therefore the emotional value that updates to your product can deliver is steadily shrinking too.

Gradually, the effort to update your product is going to greatly outweigh the emotional value updates can bring.

So what’s to be done?

Innovating whilst managing expectations

As CEOs of product based businesses, you should be looking to diversify and innovate. Find new problems and deliver solutions.

As Product Owners, you should keep updating your roadmap but beware of the diminishing returns that your product is likely to deliver. Feed this up.

And don’t feel bad! Feel good for every bit of value delivered in this increasingly complex situation.

As suppliers and agencies building products, you’re in a difficult position.

On the one hand you’re trusted to improve a product on behalf of a client. On the other hand, you are at risk of being viewed increasingly unfavourably over time (quietly, unfairly blamed?) as your work fails to bring the same returns as those early, giddily successful releases.

The best approach for you is to be open and supportive of your client. Highlight the diminishing returns they will eventually face. Help them avoid the risk of ossifying, losing out to new, smaller, focused products whose teams can move faster and deliver more emotional value than your clients 18th update can.

Encourage your clients to diversify, look for new emotional problems and product opportunities, and work with them to ideate and build these new products.

In 2013 Lamborghini, the car firm founded by the Italian industrialist Ferruccio Lamborghini, produced 2,121 cars. By hand. And these cars sold for about $200,000 apiece.

Meanwhile in the same year Fiat, the Netherlands-based manufacturer, produced over 2 million cars, with mid-range Fiats costing about $25,000.

As a product they broadly serve the same function. But the question is, which is the more desirable car? Which would you rather own, a Fiat or a Lamborghini?

And how do we choose?

Once asked that question we find ourselves assessing the qualities of the two cars. We rationalise the miles-per-gallon and insurance costs, sure. But with the Lamborghini we find ourselves thinking about the speed, the design, the workmanship, the materials, the aesthetics. We visualise it.

And very quickly we realise that one of the main factors in our decision-making is desire.

Desire in UX

Desirability is established in users – and instilled in a product – through brand, image, identity and aesthetics.

But aren’t brand and identity separate disciplines to UX? Does adding brand, identity and image into the remit of UX design stretch the concept of UX until it becomes too broad and unworkable?

Such questions lead us down the wrong path. And in order to show why, let’s break it down a little…

Aesthetics, brand, image and identity

The aesthetics: Lamborghini cars have a very strong aesthetic – you can always recognise a Lamborghini. A Fiat, probably less so.

Their brand is clear too: luxury and high end. Lamborghini cars are expensively finished, highly-engineered and probably have way higher quality parts than would typically be required of an everyday driver.

They also come with – and impart to their owners – a strong image: the cars have associations with the world of motor-racing (and shh… a historical connection to the world of tractors, but that’s another story).

Through this they allow their buyers to attain a certain identity: only a few thousand Lamborghini cars are made each year, so owning one means being part of a highly exclusive club.

Finally, all of these aspects of desirability mean Lamborghini cars, as products, instil strong emotional feelings in their users. This is likely to include pride and confidence, but overall it’s satisfaction.

Satisfaction in the UX formula

Satisfaction is the elusive quality that sits alongside utility and usability to create the user experience.

User Experience = utility + usability + satisfaction

Just one of the many UX formulae out there…

So back to the right way of thinking about this issue….

The question we should be asking ourselves as product designers and UX professionals is: what elements of brand, identity and image can we include in our product world that increase the satisfaction of our user?

There’s a lot of opportunity here: from major features that build tribes, that create exclusivity and reward power users; to the aesthetic decisions we can make on interaction animations, transitions, the colour palette, imagery, content tone/language and more.

Window Seater

This is a question I’m thinking about as we grow Window Seater. For a travel app, how can we leverage brand, identity and image in the user experience?

At Window Seater, Pete and I believe that, as travellers, we should build connections to the people, history and cultures through which we pass. And we believe in a new approach to storytelling: handmade, high quality stories that better connect us to the world and its people.

So how can we build desire around this and bake it into Window Seater’s products? How can we make users desire to be a part of our tribe?

Desire in the digital world

An example we can all learn from is Maptia – ‘home to a world of stories’ about the world and its peoples – and see how they’ve employed thinking about brand, identity and image in their UX.

Take a look at Maptia’s journey from 2014 to present day. Notice the enhancements to its design and the creation of a high-end feel via its typography, imagery and palette. Notice too the visual priority given to the Maptia community in the 2018 design.

And of course, the focus and pull of its improved mission statement, from:

At Maptia, we believe that if people from every country, every culture, and every background shared the stories of their lives and of their travels, then the world would be a more understanding and empathetic place. We also believe that this would encourage people to get out there and make the most of their short time on this planet. Our mission is to gather these stories together and create the most inspirational map in the world.

Maptia’s Mission Statement circa 2014

To:

At Maptia, our mission is to foster empathy through storytelling.

We aim to provide a platform for those who document and capture the world around us, bringing them together to create a lasting record of life on Earth; so that people everywhere can experience the cultural and natural wonders of our planet, can feel more connected to the biggest issues facing the world today, and can be empowered to create a better future.

Maptia’s Mission Statement circa 2018

Notice how the vision is now so much grander.

Also the focus has moved from 2014 team’s internal ambition, to 2018’s focus on appealing to and servicing an existing tribe: the photographers, writers, explorers and those passionate about our planet.

For us Maptia’s approach is hugely inspiring and definitely something to learn from.

So what exactly can we learn from all this?

As product managers and UX professionals, when we’re building products we need to factor desire into our product world to increase the satisfaction of our users.

When building our product we need to identify early on, what are the brand values it stands for. We need to consider the image it presents, and the identity that it will impart to its users and which delivers them emotional satisfaction.

Seth Godin, in his writing on marketing and his excellent podcast Akimbo, talks about the refrain that people repeatedly tell themselves. Namely:

People like us do things like this.

Seth Godin

Or, taken another way, “people like us use products like this”.

Seth explains that anyone involved in marketing needs to reach out to these people, to this audience. Because these are the true believers and advocates for your product.

Before we can do that though, we need to know what the “this” is.

We need to think about image – or the reflective qualities of our product (thanks Don Norman!). What are the stories that the product tells about itself, and which the user can then tell about themselves?

Whether it’s a travel app that signals that we, the users, believe in fundamentally connecting to the places and people through which they pass, or a luxury sportscar that signals their owner has status, that they’re powerful and part of an exclusive group.

When we do this, we’re on the right path to deliver satisfaction and increase the chances of a successful product. So yes. Yes desirability is 100% part of UX.

This post first appeared at Richard Edwards.

Recently I’ve been running roadmapping sessions and MVP planning sessions with Outlandish, the worker-owned tech agency.

Combining elements of design thinking practice as championed by IDEO and Stanford’s d.school, and mixing it together with great advice from Jon Kolko on how to think about emotions and roadmaps, they’ve gone pretty well.

Here’s a process for running something similar with your own teams:

When to use this:

• Planning the future for an existing product, particularly one which might be underperforming.

• Or planning a new product’s MVP (Minimum Viable Product).

If you’re working on a new product, you could run these activities as part of a Design Sprint. Some good places to do it are after the creative activities (sketching out initial ideas), or after the user testing of the prototype at the end of the Sprint.

Time required:

~ 0.5 day with your team

Step 1: Identify the users

Ask the team to identify who they think are the important users of the product. What do I mean by users? Not demographics, but rather people in situations.

No: An English woman in her mid 20s.

Yes: A press officer in a mid-sized NGO.

Yes: A press and PR team manager in a mid-sized manager.

Get everyone to write as many as they can, one per sticky note. They can hang on to their sticky notes for now, no need to gather them up.

Include the internal users

Whatever you’re building you’re likely going to have a few extra, critical users to think about. There’s the end user/customer, that’s for sure, but maybe you’ve got some wider stakeholders who connect with your product in some way to address; for example, other teams, external services, funders, CEOs and more.

Who do you have to convince your project is worth partnering with, building upon or funding?

Make sure that these people are captured as users too, because even though they might not be using the product directly, they still have an experience that relates to it.

Make sure you have a diverse range of users

In this situation, and if you’re running this process with a team, different team members will likely choose the most important users from their point of view.

On the off chance that everyone picks the same user, or if you’re running this with just one person, then encourage the identification of a few more users.

Step 2: Pick the most important user

Ask everyone to individually choose what they think is the most important problem and user. It’s good to say “important” rather than “biggest” or “urgent” or such here, as it leaves this open to interpretation. The criteria of “important” is up to each team member.

Everyone should make a note of their problem on another sticky note. Again, they can hang on to these.

Step 3: Turn the problem into a Point of View Problem statement

Championed by the Stanford Design School, a point-of-view (POV) “is your reframing of a design challenge into an actionable problem statement that will launch you into generative ideation”.

That sounds like fluff, but the key here is “actionable statement”. Rephrasing the problem into such a statement really does help stimulate creative activities. So here’s how we do it:

Everyone thinks about the user and problem they just captured. Take the problem sticky note and use it write a statement about your user, in this format:

[USER] needs to [USER’S NEED] because [SURPRISING INSIGHT]

One of the best examples I’ve seen of this, also from Stanford’s Design School, runs:

The project: Redesign the ground experience at the local international airport

The user POV: A harried mother of three, rushing through the airport only to wait hours at the gate, needs to entertain her playful children because “annoying little brats” only irritate already frustrated fellow passengers.

Note the surprising insight part. It’s not something broad and basic such as “because children annoy other people”, but something that believably conjures a real scene and is empathetic to the user (we’d all hate our own kids to be thought of as brats).

Ask your team to create their own POV Problem Statement for their chosen user on a third post it. Once this is done they can trash the problem sticky – they don’t need it anymore.

Ask everyone to read out who their main user is and their POV Problem Statement.

Step 4: Identify the value

We’re going to put the work done so far aside for a moment (we’ll come back to it shortly), and now think about value.

Jon Kolko, in his book Well-Designed: How to Use Empathy to Create Products People Love, has a great explanation about value and it’s worth getting his book to understand the importance of ‘value’ on a deeper level.

In short, there are many types of value: economic, social, personal, spiritual, emotional. Value is whatever the user feels it to be.

We’re going to ask our team to take a moment to think about the value that their user gets from using the product. For example, is it monetary savings (economic)? Increased influence in their network (social)? And so on..

Give it a few minute or so….

Turn value into an emotional statement about value

Now it’s not actually the value that someone receives from a product which is important, but rather their perception of and emotional reaction to this value which is most crucial. This is crucial to the idea of satisfaction, which, along with utility and usability, is a key component of UX.

So everyone needs to take the value they’ve identified and turn these into an emotional statement, from the point of view of the user.

In other words, everyone writes how the user feels after using their app.

It doesn’t matter that we don’t know what the solution is or what we’re building yet. But we can still imagine a future where our product exists and users are engaging with it.

And if we can imagine this, we can imagine how they feel after using it.

For example:

“After using our financial advice tool, the user feels comfortable and secure that they are making the best investment decisions with their savings.”

Everyone write a Value Statement on a sticky note.

Create swimlanes on the board

That’s already a lot of work and a lot of sticky notes! Now is the time when we come together and start to work more collectively.

Each member of the team takes their sticky notes for User, POV Problem and Value Statement, reads them out and puts them up on the board.

As facilitator, make sure they go up on the far-left of the board, with plenty of space to the right (you’ll need a lot of space in later steps). Also, make sure they are arranged in swimlanes, so it looks like this.

User | POV Problem | Value statement

User | POV Problem | Value statement

User | POV Problem | Value statement

The ordering and tidiness are important here, because things will get messy later!

If there are any duplicate users that’s fine, they can be merged. Talk about it with the team.

If there are duplicate users and duplicate POV statements, you might want to combine these into the same swimlane.

Step 5: Generate feature ideas

Now this is actually one of the hardest parts of the process, so stick with it and you’ll see some real gems come out at the end.

In short, you need the team to generate ideas for what their solution to this problem may involve.

If you’re doing this after already working up some solution ideas….

E.g. you’re running this as part of a traditional, Google Ventures style Design Sprint – then you’ll probably have some ideas and sketches already created to draw upon.  Maybe you’ve already tested a prototype and have some feedback too.

… else if not, and this is an existing product:

It might be worth pausing to:

• show the existing product, just to refresh everyone’s minds about what it looks like and can do

• review any user testing research already undertaken

• pull out that ever-increasing list of ideas, suggestions and anything from the old backlog

Tip: to help facilitate this and ensure that momentum is maintained, avoid crowding around a screen. Instead, prep the room in advance:

• post screenshots of the product up all over the place

• put up quotes from users and test subjects

• generally, provide a lot of eye candy around the room

… or if this is for a completely new product

If you’ve launched straight in to this and haven’t done any idea/solution generation yet, such as you might do in a traditional Design Sprint, that’s fine. However you’ll need to pause at this point to run some activities to generate some of these creative solutions.

I recommend taking a flip through the Design Sprint book and running the activities for Crazy 8s and Solution Sketches here.

1. Crazy 8s: a brain-dump sketching exercise, each person making rough sketches showing a possible solution, 1 per minute), leading to…

2. Solution Sketches: taking one of these ideas and, over a good hour or so, each person sketching out some key screens to show what the user sees.

3. Then a presentation of each person’s work and the team decide which idea (or aspects of the various ideas) to take forward.

These will help decide the overall concept to be used in the next steo=p.

Capture the ‘epic’ feature ideas

Using everything that’s been researched and discussed so far, and the ideas proposed and decided upon, everyone jots down the large-scale features (here it is the user-facing functionality) that need to be built.

Write one feature per sticky note.

For example, for a financial advice app, large scale features might include:

• Show customer finances

• Share data with accountant

• Email updates

• Show market data

• Live chat with financial advisor

• Printable reports

• … etc

Get the team up, read them out one by one and slap them on the board to the far right of your post notes.

Any duplicates or overlaps can be grouped together.

Tip for facilitators: People often forget to allow for building the common product features, so it’s worth prepping a few extra sticky notes in advance. Some typical examples include:

• Update account information

• 2 step verification / account security

• Alerts

• Social sharing

• Charts, visualisations

• … etc

If they’ve not already been added, make sure these go up on the board too.

Step 6: Get ready to roadmap

Identify the MVP or first phase features

Now, really channeling Jon Kolko’s great roadmapping exercise, each team member takes a note and asks their colleagues: can we achieve value for our chosen key users (and solve their problems) without this feature?

If yes, leave it where it is on the board. If no, move it to the left side and place it in the appropriate swimlane next to your User. POV and Value statement.

It’s a bit of an about-face and abstract way of looking at features, and you might have to explain it a few times to the team.

After all the team have reviewed these, you’re going to end up with a stack of sticky notes and features on the left hand side swimlanes, near the appropriate User, POV problem and Value Statements.

Well done! You’re halfway to having a list of features for your MVP or first phase of work. Draw a line to make sure these are all in a nice, tidy column. Then draw an axis along the bottom of the board to show time.

Break it down

However, in reality I’ve found that there are often still too many features for an MVP / Phase 1 of work, and many of these features aren’t minimal enough to be truly considered MVP features.

So what works now is to separate them out further and put them into a series of phases.

Draw some more columns on the board after the MVP / Phase 1 column. Each of these columns represents phases in your project’s lifecycle (not Sprints, Agile fans, we’re not at that level yet).

Now brief your team to think more about the features that are in the MVP column. Ask them to think carefully about each of these and spread them out more. Ask them to consider:

• The extent to which this feature delivers the value – compared with other features, does it deliver a huge amount of the value, or only a small amount

• The market size –  what % of your users are going to benefit from this feature

• The return (or if you’re looking at income, the margin) on delivering that feature

• Feasibility of delivering it (how challenging does it feel in terms of tech, resources, organisation buy-in etc…)

• Can any of these epic features be broken into parts, (e.g. ‘send text message alerts’, then later ‘users can edit alert settings’)

And remember, the team need to keep asking: how critical is this? Is this feature really something that must be delivered in order for the first phase to work/deliver value/succeed?

It’s likely that once you get everyone thinking along these lines, they’ll start to realise that the features already placed in the MVP / Phase 1 column aren’t all critical, and many can be moved along to later phases.

You’re aiming to end up with a spread of features across the many phases of your project. This will take some time and needs good, relaxed discussion. So make sure it stays on the feet and at the board.

Hopefully at this point you’ll see a good list of feature ideas broken out along the board. There’s probably still going to be quite a few, so now is the time to channel your inner Design Sprint facilitator: break out the voting dots!

Choosing what to do:

Give people 3 or so dots, and ask each person to vote on which ones they think are the priorities. That should help agree priorities for work and effort.

And that’s it! At this point you’ll have a roadmap! You’ve identified your core users and who your roadmap serves; you’ve captured their challenges and value they’ll get from your product, when it is launched; and you have a roadmap of phased work and features to launch.

All that is left to do now is take it to your teams and stakeholders, and begin

And, of course, update it. Regularly.

Good luck with your products!