Category: Agile

Book review: “Overcoming The Five Dysfunctions of a Team”

marcabrahamLeave a comment

You might have come across “The Five Dysfunctions of a Team”. Patrick Lencioni, a consultant and speaker, wrote this seminal business book back in 2002. In this book, Lencioni identified the common root causes behind teams and companies underperforming:

Dysfunction #1: Absence of Trust:

The fear of being vulnerable with team members prevents the building of trust within the team.

Dysfunction #2: Fear of Conflict:

The desire to preserve artificial harmony stifles the occurrence of productive ideological conflict.

Dysfunction #3: Lack of Commitment:

The lack of clarity or buy-in prevents team members from making decisions they will stick to.

Dysfunction #4: Avoidance of Accountability:

The need to avoid interpersonal discomfort prevents team members from holding one another accountable.

Dysfunction #5: Inattention to Results:

The pursuit of individual goals and personal status erodes the focus on collective success.

Fig. 1 – Patrick Lencioni’s “The Five Dysfunctions of a Team” – Taken from: https://www.tablegroup.com/books/dysfunctions

 

I recently read Lencioni’s followup book to “The Five Dysfunctions”;  “Overcoming The Five Dysfunctions of a Team” is all about how to best solve common team dysfunctions. There a number of things one can do to overcome the different team dysfunctions that Lencioni identified all those years ago:

1. Building trust

Lencioni stresses the importance of trust: “no quality or characteristic is more important than trust.” Trust and vulnerability are closely interlinked, as Lencioni explains. Vulnerability-based trust comes from people not being afraid to admit the truth about themselves.

People being open and honest with themselves and each other, instead of wasting time and energy on politics. Building up this level of trust is by no means an easy feat or one off exercise. In contrast, it’s best to start small – with The Personal Histories Exercise, for example and continue maintaining trust.

Fig. 2 –  Patrick Lencioni’s “The Personal Histories Exercise” – Taken from: https://www.tablegroup.com/imo/media/doc/AdvantagePersonal_Histories_Excercise(4).pdf

2. Mastering conflict

Mastering conflict comes back to vulnerability-base trust, according to Lencioni. He explains that “When people who don’t trust one another engage in debate, they’re trying to win the argument.” In contrast, when vulnerability-based trust exist, team members say everything to each other that needs to be said and things don’t need to be discussed further behind closed doors.

Let’s make no mistake about it; conflict is supposed to feel a bit uncomfortable. Lencioni explains that if team members “never pushing one another outside of their emotional comfort zones during discussions, then it’s extremely likely that they’re not making the best decisions for the organization.”

Conflict Profiling is a great way to understand where you and your colleagues sit on the Conflict Continuum (see Fig. 3 below). What’s your appetite for healthy conflict? How does your appetite compare to Joe or Kathy’s on the team? Once you’ve figured out the different conflict profiles on the team and understand the differences, the best thing is to just talk about it within the team.

For example, what to me might feel like a good discussion, might to you feel like we’re butting heads … Once we understand our individual conflict profiles, we’re in a much better position to talk about how we best have a constructive discussion. One could, for example, agree that when we ask what might sound like difficult questions, these questions aren’t meant as personal attacks. Instead, these questions are only being asked because we want the best for the team, the business or the product.

Fig. 3 – Patrick Lencioni’s “Conflict Continuum” – Taken from: http://www.corporategames.com/whats-new/leadership-training/good-leaders-can-use-conflict-build-great-team/

3. Achieving commitment

The next dysfunction to overcome is the lack of commitment by team members. Lencioni makes the point that “commitment is not consensus.” There seems to be this misconception that everybody needs to agree intellectually on a decision, and that you’re bound for failure if you don’t … Lencioni argues the opposite: “Waiting for everyone on a team to agree intellectually on a decision is a good recipe for mediocrity, delay, and frustration.”

 

 

I totally agree with Lencioni’s points about most meetings being boring due to a lack of conflict. As counterintuitive as this may sound, I think we can all think of at least one regular meeting where we all just turn up and go through the mentions. However, meetings don’t have to be dull and unproductive.

In the words of Lencioni: “Team members can indeed become engaged in a meeting, but only when there is something at stake, a conflict worth caring about.” There is an important role for team leaders here, since they’re in great position to give team members a reason to care at the beginning of a discussion or a meeting.

In contrast, commitment is about “Buy-In”, defying a lack of consensus. It’s about getting a group of individuals to buy into a decision especially when they don’t naturally agree. Lencioni identifies two critical steps to achieve buy-in for a decision:

  1. Extract and explore team ideas – Good leaders drive team commitment by first extracting every possible, idea, opinion and perspective from the team. This is why I believe that good product leaders and managers need to be able to facilitate these open ended conversations or brainstorming sessions, especially since product people need to be able to influence without authority.
  2. Stick your neck out and decide – Once you’re comfortable that all options and perspectives have been explored, then the team leader needs to step up and make a decision. I know from experience that this is easier said than done, because our instinct is to try and get everybody to be happy about your decision. However, it’s unlikely that you’ll please everyone with your decision and that’s fine, as long as you explain the decision and why you made it – especially to those people with an opposite view. Lencioni refers to this process as “disagree and commit” and suggests the “Commitment Clarification” exercise to ensure that everyone in the team is clear about what exactly has been decided in the meeting or conversation (see Fig. 4 below).

Fig. 4 – Patrick Lencioni’s “Commitment Clarification” – Taken from: https://www.tablegroup.com/imo/media/doc/Commitment%20Clarification%20Exercise.pdf

4. Embracing accountability

Are you prepared to “enter the danger”? It’s the key question that comes out of Lencioni’s chapter about embracing accountability. Lencioni defines accountability as “the willingness of team members to remind one another when they aren’t living up to the performance standards of the group.” In an ideal world, this kind of accountability should be peer-to-peer and require the team leader to hold people accountable.

In reality though, and for peer to peer accountability to become the norm, the team leader needs to be prepared to call an individual on their behaviour or performance, and thus “enter the danger”. I totally agree with Lencioni where he observes that most leaders he knows “have a far easier time holding people accountable for their results than they do for behavioural issues.” This can be problematic because behavioural problems almost always precede results.

As daunting as it may seem at first, it is possible to have a constructive conversation about their behaviour. In my experience, the key is to be very specific about the behavioural issues that you’ve observed and describe the impact that these issues have caused (I highly recommend reading “Radical Candor” by Kim Scott if you’re keen to learn more about this topic).

The next step would be to run what Lencioni call a “Team Effectiveness Exercise”:

Fig. 5 – Patrick Lencioni’s “Team Effectiveness Exercise” – Taken from: https://www.tablegroup.com/imo/media/doc/AdvantageTeamEffectiveness_Exercise(8).pdf

 

5. Focusing on results

Lencioni raises the questions about what makes it so hard to stay focused on results? He answers the questions by talking about self-interest and self-preservation. To avoid these human pitfalls, Lencioni suggest the team picking one goal the whole team can focus on:

“On strong teams, no one is happy until everyone is succeeding, because that’s the only way to achieve the collective results of the group. Of course, this implies that individual egos are less important than team achievements.”

In this scenario, the team will know that it’s being successful when it accomplishes the results it sets out to achieve. This requires team members to prioritise team results over their individual or departmental needs. To stay focused, teams must publicly clarify their desired results and keep them visible.

Main learning point: “Overcoming The Five Dysfunctions of a Team” is a valuable resource for anyone interested in creating or being part of effective teams. In addition to studying the factors of successful teams, the book  offers a number of helpful exercises to overcome these dysfunctions.

Related links for further learning:

  1. https://www.tablegroup.com/books/dysfunctions
  2. https://www.tablegroup.com/books/overcoming-the-five-dysfunctions-a-field-guide
  3. https://www.tablegroup.com/imo/media/doc/AdvantagePersonal_Histories_Excercise(4).pdf
  4. http://www.corporategames.com/whats-new/leadership-training/good-leaders-can-use-conflict-build-great-team/
  5. https://www.truity.com/blog/personality-type-conflict-style
  6. https://www.tablegroup.com/imo/media/doc/Commitment%20Clarification%20Exercise.pdf
  7. https://www.tablegroup.com/imo/media/doc/AdvantageCascading_Communication_Exercise(6).pdf

My product management toolkit (24): ‘pre-mortem’

marcabraham3 Comments

As helpful as ‘post-mortem’ sessions can be, how often do you find yourself wondering: “if I’d only thought about that beforehand!” In a medical environment, a post-mortem creates the opportunity for health professionals and the family to establish the patient’s cause of death. With digital products, a post-mortem typically happens at the end of a project or after a big product release. It’s similar to Agile retrospectives which often take place more regularly; the goal is to reflect on areas for improvement and related actions.

With a pre-mortem, the idea is to think about a project or a piece of work before commencing it. A pre-mortem can be done either as a group or as an individual exercise, and participants need to imagine the product or project to have failed (see Fig. 1 below).

For example:

“This product has failed because nobody wanted to pay for it”

“The product was never released in the end because the regulator refused to approve the product and its underlying business model” 

“The product has failed because many of its users complained about its poor user experience”

“The product failed because we the design & build project had to be rushed in the end to get it over the line?”

A pre-mortem thus enables you to start working backwards, and look at the individual factors that could lead to failure as well as the actions to take in order to pre-empt failure. Once you’ve identified these factors, you can start thinking about how to best avoid or mitigate these risks from occurring.

Naturally, it’s up to you to figure out how to best structure your pre-mortem, but these are some aspects that you might want to consider:

  • The product has bombed – Rather than consider the possible failure of a product or a project, in the pre-mortem the product is assumed to have failed. Similarly, if you’re doing a pre-mortem at the start of a project, it’s really helpful if all the participants in the pre-mortem think of any reason why the project could fail dramatically.
  • Categorise failures – When getting people to think about the reasons for failure, I always find it helpful to think about failures in specific areas, dependent on your product, market or organisation (see Fig. 2 below).
  • Does this mean that nothing will go wrong!? – Of course, things will not go according to plan and unexpected things will still happen. However, right from the get go, you’re creating an environment that allows people to think about and continuously talk about risk. You’re effectively creating an environment where people can speak freely about potential risk scenarios, without fear of being seen as impolite or difficult.
  • Identify threats and risks – There are a number of ways to elicit risks and threats from the pre-mortem. You could do a simple ‘brain dump’ for example. Alternatively, you could try a more structured approach whereby people need to come up with risks within certain areas (see “Categorise failures” above).
  • Analyse likelihood – Once you’ve collated threats and risks, you can use a simple scale ranging from “highly unlikely” to “highly likely” to assess likelihood of a specific risk or threat materialising. I’ve found that the activity of placing risks against the aforementioned scale, helps creating a shared understanding of the biggest risks. It also focuses the mind on the actions that need to be taken or things that need to be in place to mitigate risk.
  • Are the right people in the room? – When running a pre-mortem session with a number of people, it’s important to make sure you’ve got the right people in the room. For example, if you’re looking to work on a digital product, it’s important to have developers and designers present. Similarly, if you’re working in a highly regulated industry, having a compliance person brainstorming upfront about potential risks will go a long way.
  • Brainstorm and assess preventative actions – Once you’ve collectively established your highest risks, you can start thinking about ways to mitigate these risks. Realistically, you might not be able to stop all risks from happening  (think about a garden party being impacted by a sudden rain downpour …). In these scenarios, you can still figure out how to best reduce the impact of a risk happening and come up with a ‘plan B’. For example, if the heavens open during your garden party, people could always seek shelter in the tent that you put up ‘just in case’.
  • Not a one off exercise! – The risks and actions that you identify during your pre-mortem are something that you can use as ongoing reference point. “How are we doing we against risk X?” or “We can see risk Y materialising soon, how can best pre-empt things?” A regular product retrospective offers a great opportunity to take a step back from the day-to-day and look at the risks involved with your project or product.

Fig. 1 – Pre-Mortem by Dave Gray – Taken from: http://gamestorming.com/pre-mortem/

Fig. 2 – Possible failure categories to consider:

  1. Marketing – Think upfront about what could go wrong with your product’s go-to-market strategy and the marketing channels that you’re looking to use. For example, what would be the impact be if product messaging fails to resonate with your target audience?
  2. Customer – What if customers don’t want to pay for our product? What if we’re addressing the wrong customer segment? What if we’ve got customer needs wrong?
  3. Technology – The chosen technology implementation doesn’t work, what do we do? The technology isn’t scalable!? At this stage, it’s very valuable to explore the complexities or unknowns related to the technical implementation. As a group, you might agree on running discovery sprints to test certain technologies or non-happy path scenarios to deal with some of the ‘unknown unknowns’ being discovered early on.
  4. Stakeholders – I know some people like stakeholder mapping, but the pre-mortem can also help in figuring out who the relevant stakeholders are and how they’d need to be communicated with. Also, when look at the different risk areas, it can be very helpful which stakeholders have the most knowledge in a particular domain.
  5. Cost – What if our budget gets slashed halfway through the project? What if costs spiral because we failed to budget properly? What if the technology we’ve chosen turns out to be far too expensive or complex to implement?
  6. Compliance – Compliance and regulatory aspects are easy ones to forget at the start of a project. However, compliance can have a massive impact on a product or a project. For instance, I was involved in a project where we only found out halfway through that launching in China would be very tricky from an internal compliance and external regulation point of view. This proved to be a major stumbling block and it would have been good if we could have identified this as a major project risk beforehand.
  7. Competition – What if your direct competitor launcheds the same product as yours, but just a bit quicker? Or we imagine a situation where the product has failed because the competitor lowered its product price. Do we need a plan B for when this scenario happens? If so, what should this plan look like?

Main learning point: Running a pre-mortem isn’t a substitute for fully planning projects upfront. You can do the best pre-mortem possible but things will still happen, and to which you’ll need to adapt. A good pre-mortem, however, will get people to think and be open about risk. It will help significantly in identifying and addressing risk early and often.

Related links for further learning:

  1. https://zapier.com/blog/project-retrospective-postmortem/
  2. https://www.cmcrossroads.com/article/when-postmortems-meet-retrospectives-improving-your-agile-process
  3. http://retrospectivewiki.org/index.php?title=Retrospective_Plans
  4. https://en.wikipedia.org/wiki/Pre-mortem
  5. https://hbr.org/2007/09/performing-a-project-premortem
  6. https://simplicable.com/new/premortem
  7. http://gamestorming.com/pre-mortem/
  8. http://www.springer.com/gb/book/9783319490663

Book review: Yes To The Mess

marcabrahamLeave a comment

In May last year, I attended a great talk by Ken Norton – partner at Google Ventures – titled Product Managers: Make Yourself Uncomfortable. In his talk, Ken talked about the book Yes To The Mess: Surprising Leadership Lessons from Jazz by Frank J. Barrett, a management consultant and jazz pianist. Ken talked about feeling uncomfortable, his point being that uncertain and unstable times call for embracing uncertainty, improvising, learning and improving.

In “Yes To The Mess” Frank J. Barrett highlights the leadership lessons that can be learned from jazz music and jazz greats. These are the main lessons I learned from reading this fantastic book:

There’s no such thing as making mistakes

quote-if-you-don-t-make-mistakes-you-aren-t-really-trying-coleman-hawkins-54-15-31

Fig. 1 – Coleman Hawkins “If you don’t make mistakes, you aren’t really trying” – Taken from: http://izquotes.com/quote/81208

How often do people get chastised for he mistake(s) they’ve made!? Having to lower one’s tune because of having tried something that ultimately failed? Or trying to cover up a mistake or an error? In contrast, jazz music is all about ‘failing’. Like the great saxophonist Coleman Hawkins once said: “If you don’t make mistakes, you aren’t really trying” (see Fig. 1 above). In jazz music and in business, Barrett argues, there’s no such thing as making a mistake.

Instead, the focus is on not missing opportunities and embracing errors as a source of learning. For me, Miles Davies is the ultimate embodiment of the courage to make mistakes; “If you’re not making a mistake, it’s a mistake” is one of Davis’ famous quotes. “Do not fear mistakes. There are none” is another one (see Fig. 2 below). As Barrett points out, Davis was talking about the importance of continuing to take risks and to try new possibilities. Because when you do, something new and unexpected is likely to happen.

milesdavis

Fig. 2 – Miles Davis “Do not fear mistakes. There are none” – Taken from: http://www.ideachampions.com/weblogs/archives/quotes/

Informed risks and constructive learning

If mistakes don’t exist and we should all learn by trying, does this mean that we can just act recklessly and stop caring about what could happen!?

Absolutely not. Barrett explains how well conceived plans not always pan out as expected. “Everyone has a plan until they get punched in the mouth” as Mike Tyson once said (see Fig. 3 below). I came across an organisation once where project people probably spent a good 40% of their time drawing up great detailed project plans and 60% of their remaining time continuously adjusting timings on their project plans and “controlling the message” towards their stakeholders. Perhaps if they’d read “Yes To The Mess” they might have instead embraced unexpected factors or errors, and built on them. In jazz, the artists don’t correct mistakes as much, opting to recognise and ride with them instead.

quote-mike-tyson-everyone-has-a-plan-till-they-get-6007

Fig. 3 – Mike Tyson “Everyone has a plan ’till they get punched in the mouth” – Taken from: http://quotes.lifehack.org/quote/mike-tyson/everyone-has-a-plan-till-they-get/

What I like about this approach is that jazz players will learn by leaping in, learn from taking action and adjust accordingly. Barrett describes this approach as taking informed risks, taking action based on something that happen before and discover as you go. Jazz bassist and composer Charles Mingus once famously said: “You can’t improvise on nothing. You gotta improvise on something.” Even improvisation needs rules and some kind of order. As a result, especially in jazz bands, improvisation will lead to collective discoveries.

In my experience, improvisation isn’t easy. It can be pretty daunting when something doesn’t go according to plan – or when there isn’t a plan to begin with. An understandable first reaction is to try and fix the error, make sure the plan can still be executed upon. However, the results of not following this instictive response can be amazing, and can lead to new insights and approaches.

Generous listening

A key point Barrett makes is how improvisation requires jazz musicians to do lots of listening. Jazz players need to be attentive not only to the music they’re playing, both individually and as a group, but also to what isn’t being played. When Miles Davis was asked how he went about improvisation, he explained that he listened to what everyone in the band was playing and would then play what was missing.

Although I’m not yet great at it, generous listening is all about listening more then talking, or asking questions even when you might already know the answer. As a product person, it means not trying to be a rockstar or to push through your opinion. In contrast, it’s about truly listening to what someone else is thinking or might have to offer. In jazz, there’s even a term for this: “comping” – the rhythms, chords, and countermelodies with which the other players accompany a solo improvisation.

screen-shot-2017-03-05-at-07-17-11

Fig. 4 – Duke Ellington “The most important thing I look for in a musician is whether he knows how to listen” – Taken from: https://www.apassion4jazz.net/quotations4.html

Affirmative competence

Taking informed risks and listen generously leads to organisations developing “affirmative competence”, where the organisational system is no longer top down and deliberate, but much more emergent. As Barrett stresses, “an emergent system is smarter than the individual members.” Andy Grove applied this approach whilst at Intel when being faced with the challenge of Intel’s existing business drifting away. Since that experience, Grove’s advice is to “set aside everything you know.” Organisations and teams will thus learn while doing and by building up an underlying confidence in the competence of their group of people, taking the following steps in the process:

  • Take action
  • Revise assumptions
  • Value learning from failures
  • Try again
  • Discover as you go

Main learning point: I absolutely loved both Ken Norton’s talk and “Yes To The Mess” by Frank Barrett. The idea that well conceived plans are fallible and that that it’s ok to learn from one’s mistakes really resonates with me. Even if you’re not a jazz lover, it’s really worth reading “Yes To The Mess” and studying the lessons we can learn from jazz and its musicians.

 

Related links for further learning:

  1. http://www.mindtheproduct.com/2016/05/product-managers-please-make-uncomfortable/
  2. http://www.forbes.com/sites/susanadams/2012/08/10/leadership-lessons-from-the-geniuses-of-jazz/
  3. https://hbr.org/2012/08/what-leaders-can-learn-from-ja
  4. https://www.theguardian.com/music/2011/jun/13/grand-wizard-invents-scratching
  5. http://pubsonline.informs.org/doi/pdf/10.1287/orsc.9.5.543
  6. http://fortune.com/2012/09/10/what-biz-leaders-can-learn-from-jazz/
  7. http://jazztimes.com/articles/134503-beyond-the-music-what-jazz-teaches-us

Book review: Sprint (Part 6 – Day 5)

marcabrahamLeave a comment

The fifth and final day of the sprint is all about interviewing your (target) customers and learning from how they interact with your prototype.

Interview

“Five is the magic number”, is the point that Knapp, Zeratsky and Kowitz are making in Sprint with regard to the number of people to interview. The value of this number of interviewees was proven by usability expert Norman Nielsen who found that typically 85 percent of problems were observed after just five people (see Fig. 1). “The number of findings quickly reaches the point diminishing returns,” Nielsen concluded. “There’s little additional benefit to running more than five people through the same study; ROI drops like a stone.”

When it comes to conducting the actual interview, having a structured and consistent way of running these conversations is critical. Knapp, Zeratsky and Kowitz write about the “Five-Act Interview”, which consists of the following stages (see Sprint, p. 202):

  1. A friendly welcome to start the interview
  2. A series of general, open-ended context questions about the interview
  3. Introduction to the prototype(s)
  4. Detailed tasks to get the customer reacting to the prototype
  5. A quick debrief to capture the customer’s overarching thoughts and impressions

The book also provides some useful tips for the interviewer, asking open-ended and ‘broken’ questions (pp. 212 – 215):

  • DON’T ask multiple choice or “yes/no” questions – “Would you …?””Do you …?””Is it…?”
  • DO ask “Five Ws and One H” questions – “Who …?””What …?””Where …?””When …?””Why …?””How …?”
  • Ask broken questions – The idea behind a broken question is to start asking a question – but let your speech trail off before you say anything that could bias or influence the answer. For example: “So, what … is …” (trail off into silence)

Fig. 1 – Why You Only Need To Test With Five Users – Taken from: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

 

20000319-user-testing-diminshing-returns-curve

Learn

Ultimately, this is what the fifth and final day of your sprint is all about: finding the end to your sprint story. Once you’ve had a chance to see how your customers react to your prototype, you’ll be able to answer your sprint questions and decide on next steps. For example, if you and your team take interview notes as a group during the five interviews, you should be able to do a good recap of all your learnings, answer the original sprint questions and decide on what to next. For example, a common next step would be to make a go/no go decision about a particular product idea.

Main learning point: In “Sprint”, Knapp, Zeratsky and Kowitz offer a very cost-efficient way to explore product questions and solutions before committing to an idea (and a large investment of time, money and effort). The reality is that as a product manager you’ll almost always will have to take a punt, but being disciplined about doing sprints and continuous discovery will help you make better informed decisions, based on real customer feedback.

Related links for further learning:

  1. https://marcabraham.wordpress.com/2015/06/24/interviewing-customers-to-explore-problems-and-solutions/
  2. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
  3. https://marcabraham.wordpress.com/2014/04/20/how-to-do-effective-user-interviews/
  4. https://marcabraham.wordpress.com/2014/11/21/julia-shalet-explains-about-user-research-at-the-mobile-academy/
  5. https://marcabraham.wordpress.com/2015/10/19/collaborative-user-research-learning-from-erika-hall/

Book review: Sprint (Part 5 – Day 4)

marcabraham1 Comment

Once you and your team have created storyboards, you’ll spend the fourth day of the sprint creating a prototype. In “Sprint”, Jake Knapp, John Zeratsky and Braden Kowitz talk about a “fake it” approach to turn a storyboard into a realistic prototype.

Fake It

The fourth day of your sprint is all about illusion; instead of taking weeks, months, or even years to create the real thing, you’re going to fake it. Knapp, Zeratsky and Kowitz talk about building a facade (see Fig. 1 below). The main acceptance criterion for a successful facade is that it needs to be real enough to test with real customer on the fifth and final day of the sprint.

Fig. 1 – Building a realistic prototype – Taken from: https://heleo.com/jake-knapp-jake-knapp-sprint/6499/

 

prototype-1

facade-1

You and your team are only allowed to spend a single day on creating a facade, and that’s deliberate. Knapp, Zeratsky and Kowitz explain that the more time you spend on creating a prototype the more likely you are to become attached to it, and less likely to make any changes based on customer feedback (see Fig. 2 below).

Fig. 2 – Becoming attached – Taken from: https://heleo.com/jake-knapp-jake-knapp-sprint/6499/

attachment-1

 

Similar to what Josh Wexler and Mike Fishbein talk about in their book, there’s an explanation of “the prototype mindset” in Sprint (pp. 168 – 170):

  1. You can prototype anything – If you go into the fourth day of your sprint with optimism and a conviction that there is some way to prototype and test your product, you’ll find a way.
  2. Prototypes are disposable – Don’t prototype anything you aren’t willing to throw away. Remember: this solution might not work.
  3. Build just enough to learn, but no more – The prototype is meant to answer questions, so keep it focused. You don’t need a fully functional product. You just need a real-looking facade to which customers can react.
  4. The prototype must appear real – To get trustworthy results in your test on the fifth and final day of your sprint, you can’t ask your customers to use their imaginations. You’ve got to show them something realistic. If you do, their realistic. If you do, their reactions will be genuine.

I loved the concept of “Goldilocks quality”, which was introduced by Daniel Burka. Burka argues that the ideal prototype should be of Goldilocks quality. If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night and you won’t finish. You need Goldilocks quality; not too high, not too low, but just right (see Fig. 3 below).

Fig. 3 – “Goldilocks quality” – Taken from: https://heleo.com/jake-knapp-jake-knapp-sprint/6499/

goldilocks-quality

Once you’ve created the right prototype, you and your team should do a quick trial run on the afternoon of the fourth day of your sprint. This will give you a chance to fix any mistakes or issues with your prototype, before you test it with real customers the following day.

Main learning point: Don’t get too hung up on the realness of your prototype! It needs to be real enough to test with customers on the final day of your sprint, no more and no less.

Book review: Sprint (Part 4 – Day 3)

marcabraham1 Comment

Once you’ve starting to think about possible solution – during Day 2 of the sprint – the next step is to take your huge pile of solutions and decide on which solution(s) to prototype. In the morning, you’ll review and critique the different solutions and select those solutions which you feel have the best change of meeting your long-term goal. In the afternoon, you’ll take the winning scenes from your ‘solution sketches’ and convert them into a storyboard. The goal behind this storyboard is to have a clear plan in place before you create a prototype to test with customers.

Decide

The main objective for the third day of your sprint is to decide on which solutions to prototype. In “Sprint”, Jake Knapp, John Zeratsky and Braden Kowitz suggest a number of techniques to optimise your decision-making process:

  1. Art museum: Put the solution sketches on the wall with masking tape.
  2. Heat map: Look at all the solutions in silence, and use dot stickers to mark interesting parts.
  3. Speed critique: Quickly discuss the highlights of each solution, and use sticky notes to capture big ideas (see Fig. 1 for a breakdown of how speed critique works).
  4. Straw poll: Each person chooses on solution, and votes for it with a dot sticker.
  5. Supervote: The Decider makes the final decision, with more stickers.

Fig. 1 – How speed critique works – Taken from “Sprint”, p. 136:

  1. Gather around a solution sketch.
  2. Set a time for three minutes.
  3. The Facilitator narrates the sketch. (“Here it looks like a customer is clicking to play a video, and then clicking over to the details page …”)
  4. The Facilitator calls out standout ideas that have clusters of stickers by them. (“Lots of dots by the animated video …”)
  5. The team calls out standout ideas that the Facilitator missed.
  6. The Scribe writes standout ideas on sticky notes and sticks them above the sketch. Give each idea a simple name, like “Animated Video” or “One-Step Signup.”
  7. Review concerns and questions.
  8. The creator of the sketch remains silent until the end. (“Creator, reveal your identity and tell us what we missed!”)
  9. The creator explains any missed ideas that the team failed to spot, and answers any questions.
  10. Move to the next sketch and repeat.

Rumble

A “Rumble” is a test whereby two conflicting ideas will be prototyped and tested with customers on the final day of the sprint. Instead of having to choose between two ideas early on, a Rumble allows your team to explore multiple options at once. If you have more than one winning solution, involve the whole team in a short discussion about whether to do a Rumble or to combine the winners into a single prototype. Knapp, Zeratsky and Kowitz suggest a good decision-making technique, “Note and Vote”, which you can use at any point throughout the sprint where you and your team need to make a decision (see Fig. 2).

Fig. 2 – Note and Vote – Taken from “Sprint”, p. 146:

  1. Give each team member a piece of paper and a pen.
  2. Everyone takes three minutes and quietly writes down ideas.
  3. Everyone takes two minutes to self-edit his or her list down to the best tow or three ideas.
  4. Write each person’s top ideas on the whiteboard. Ina  sprint with seven people, you’ll have roughly fifteen to twenty ideas in all.
  5. Everyone takes two minutes and quietly chooses his or her favourite idea from the whiteboard.
  6. Going around the room, each person calls out his or her favourite. For each “vote”, draw a dot next to the chosen idea on the whiteboard.
  7. The Decider makes the final decision. As always, she can choose to follow the votes or not.

Storyboard

Creating a storyboard is the final activity on the third day of the sprint. The goal here is to create a plan first before you start prototyping. You’ll take the winning sketches – see “Decide” above – and combine them into a single storyboard.

Fig. 3 – Example of a storyboard – Taken from: http://www.chadbeggs.com/storyboards.html

storyboards_02

From experience, creating a good storyboard will take a good couple of hours. What makes a ‘good’ storyboard? Knapp, Zeratsky and Kowitz list a good set of rules to help you and your team to fill out your storyboard:

  • Don’t write together – Your storyboard should include rough headlines and important phrases, but don’t try to perfect your writing as a group. Group copywriting is a recipe for bland, meandering junk, not to mention lots of wasted time.
  • Include just enough detail – Put enough detail in your storyboard so that nobody has to ask questions like “What happens next?” or “What goes where?” when they’re actually prototyping on the fourth day of the sprint.
  • The Decider decides – You won’t be able to fit in every good idea and still have a storyboard that makes sense. And you can’t spend all day arguing about what to include. The Decider can ask for advice or defer to experts for some parts – but don’t dissolve back into a democracy.
  • When in doubt, take risks – If a small fix is so good and low-risk that you’re already planning to build it next week, then seeing it in a prototype won’t teach you much. Skip those easy wins in favour of big, bold bets.
  • Keep the story fifteen minutes or less – Make sure the whole prototype can be tested in about fifteen minutes. Sticking to fifteen minutes will ensure that you focus on the most important solutions – and don’t bite off more than you can prototype. (A rule of thumb: Each storyboard frame equals about one minute in your test.)

Main learning point: The third day of your sprint is all about ending the day with a storyboard that you can use as a starting point for a prototype, that you and your team will be creating on the fourth day of the sprint.

Related links for further learning:

  1. https://uxmag.com/articles/why-we-need-storytellers-at-the-heart-of-product-development
  2. https://uxmag.com/articles/book-excerpt-the-user-experience-team-of-one
  3. http://www.chadbeggs.com/storyboards.html
  4. http://www.sarahdoody.com/3-ways-storytelling-can-improve-your-product-development-process/

Book review: Sprint (Part 3 – Day 2)

marcabraham1 Comment

Once you’ve set a target as part of Day 1 of your sprint, the next step is for you and your team to look at solutions. On the second day of the sprint, you’ll be coming up with solutions, and sketching them. This day consists of two key activities: (1) review ideas to remix and improve, and (2) create solution sketches to feed into your plan for a prototype and customer testing.

Remix and Improve

In “Sprint”, Jake Knapp, John Zeratsky and Brad Kowitz suggest a good technique to collate and assess ideas: Lightning Demos. With this exercise, your team will take three-minute tours of their favourite ideas or products: from other products, from different domains, and from within your own company. The idea here is to encourage the team to throw everything in the mix, but to do so in a short and snappy way. Each person who has suggested an idea will do a three minute demo, showing the team what’s great about his or her solution. As a facilitator, you might want to use a timer to make sure each team member sticks to the their three minute time slot.

The key thing with these three minute ‘lightning demos’ is that you capture the big ideas from each presentation. Start by asking the person who’s doing the tour, “What’s the big idea here that might be useful?” You can then make a quick drawing of this big idea, write a simple headline above it and add the source underneath. I’ve included an example of a way to capture big ideas in Fig. 1 below.

Fig. 1 – An example of capturing ‘big ideas’ from lightning demos, by Karsten Neben – Taken from: https://medium.com/@karstenn/what-we-learned-in-just-5-days-our-design-sprint-report-b9ada5b7f19a#.27wb5fv4e

Lightning Demos

 

Sketch

In the afternoon of the second day of your sprint, the focus is on coming up with solutions. Instead of doing collective brainstorming sessions – which in my experience run the risk of becoming shouting matches or can be dominated by very vocal people – Knapp, Zeratsky and Kowitz suggest each team member coming up with ideas on their own. People will work individually, thinking about and sketching solutions. I’ve included a simple example of a sketch in Fig. 2 below.

The sketches that people create will act as an important driver for the rest of the sprint. On Wednesday (Day 3), you’ll critique everyone’s sketches and pick the best ones.

If you’re worried about the quality of your sketches, don’t! Knapp, Zeratsky and Kowitz introduce the four step sketch technique. This approach makes it easy for everyone to take some rough solutions and turn them into a detailed solution sketch (see Fig. 2 below):

  1. Notes – As a first step, the team walks around the room and takes notes from looking at all the post-it notes, whiteboards, flip-charts that you have collated over the first day and a half of your sprint.
  2. Ideas – Each team member individually will look at his or her notes and jot down rough ideas, simply filling a sheet with doodles, headlines, etc. The aim here is not to come up with fully fledged ideas or solutions. It’s purely a way for each person to drop down their thoughts.
  3. Crazy 8s – Crazy 8s is a fast-paced exercise. Each person will take his or her strongest ideas and rapidly sketches eight variations in eight minutes. What I like about Crazy 8s is that it stops you from dwelling on your first possible solution for too long. Instead, the eight minute deadlines forces you to quickly decide whether to move on from your first reasonable solution or to stick with it but iterate (see Fig. 3 and 4 below). I’ve found Crazy 8s to work particularly well if you end up sketching several variations of the same idea, exploring alternative versions. Similarly, you can use Crazy 8s to refine a marketing headline or messaging.
  4. Solution sketch – The solution sketch is each person’s best idea, put down on paper in detail. Up to this point, each team member will have worked individually on creating notes, ideas and Crazy 8s, and won’t have shared anything with the rest of the team. This all changes with the solution sketch; each solution sketch is an opinionated hypothesis for how to solve the challenge at hand. These sketches will be looked at – and judged – by the rest of the team. They will therefore need to be detailed, thought-out, and easy to understand (see Fig. 5 and 6 below).

Once each team member has put together a solution sketch, the sprint facilitator will collate them all and put them in a pile. The team will only be allowed to start looking at these solution sketches on the third day of the sprint.

Fig. 2 – Four step sketch technique – Taken from: https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas

4-stage sketch

Fig. 3 – How to do Crazy 8s – Taken from: “Sprint”, pp. 112-113

  1. Each person begins Crazy 8s with a single sheet of letter-size paper.
  2. Fold the paper in half three times, so you have eight panels.
  3. Set a timer to sixty seconds.
  4. Hit “start” and begin sketching – you have sixty seconds per section, for a total of eight minutes to create eight miniature sketches.
  5. Go fast and be messy: As with the notes and ideas, Crazy 8s will not be shared with the team.

Fig. 4 – Crazy 8s example – Taken from: https://www.fastcodesign.com/1672917/the-8-steps-to-creating-a-great-storyboard

1672917-inline-crazy8s

Fig. 5 – Important rules to keep in mind when creating a solution sketch – Taken from: “Sprint”, pp. 114-118

  1. Make it self-explanatory – Your solution sketch needs to explain itself. Think of this sketch as the first test for your idea. If no one can understand it in sketch form, it’s not likely to do any better when it’s polished.
  2. Keep it anonymous – Don’t put your name on your sketch, and be sure that everyone uses the same paper and the same black pens.
  3. Ugly is okay – Your sketch does not have to be fancy (boxes, stick figures, and words are fine), but it does have to be detailed, thoughtful, and complete.
  4. Words matter – Strong writing is especially necessary for software and marketing, where words often make up most of the screen. So pay extra close attention to the writing in your sketch. Don’t use “lorem ipsum” or draw those squiggly lines that mean “text will go here.” That text will go a long way to explain your idea – so make it good and make it real!
  5. Give it a catchy title – Since your name won’t be on your sketch, give it a title. Later, these titles will help you keep track of the different solutions as you’re reviewing and choosing. They’re also a way to draw attention to the big idea in your solution sketch (see the example in Fig 6 below).

Fig. 6 – A solution sketch from Blue Bottle Coffee’s sprint; each sticky note represents one screen – Taken from: https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas

Sketch example

Main learning point: The second day of the sprint is very solution oriented. Instead of long brainstorm sessions, the day is filled with more individually oriented activities, encouraging team members to think about ideas and to come up with their own solution sketch.

Related links:

  1. https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas
  2. https://www.youtube.com/watch?v=_ITJ5lAXQhg
  3. https://medium.com/@karstenn/what-we-learned-in-just-5-days-our-design-sprint-report-b9ada5b7f19a#.atwi36cd7
  4. https://library.gv.com/the-product-design-sprint-diverge-day-2-c7a5df8e7cd0#.7zmlxd9aq
  5. http://www.yaellevey.com/blog/how-to-use-crazy-8s-to-generate-design-ideas/
  6. https://www.fastcodesign.com/1672917/the-8-steps-to-creating-a-great-storyboard