My product management toolkit (33): launch and learn

“Build it and they will come!” I used to work once with a senior executive, who was of the opinion that a product or feature should just be launched, without any testing with customers beforehand. “I know that once it’s out there, people will want it” she’d explain to me, adding that “it’s what people want”.

 

 

Hearing this “build it and they will come” mantra time and time again did annoy me ūüôā At the same time, it did make me wonder whether it might be a good idea to (continuously) release product features without prior customer discovery … What if this executive is right and any new product, feature or service should just be launched, as a way of learning as quickly as possible!?

Being able to ‘launch and learn’ is a vital tool in any product person’s toolkit. I strongly encourage you to avoid ‘one-off product releases’ at any time; what are you going to learn from shipping a product only to then move on to the next thing!? One can debate about when to best learn – should you learn pre-release? – but the main point is that you’ll need to ship early and often to learn continuously.

Basecamp, a project management software compare, does take ‘launch and learn’ to the extreme, they don’t show customers anything until every customer can see it. In the book “It doesn’t have to be crazy at work”, Basecamp’s co-founders Jason Fried and David Heinemeier Hansson describe how at Basecamp:

  • “We don’t beta-test with customers.”
  • “We don’t ask people what they’d pay for something.”
  • “We do the best job we know how to do and then we launch it into the market.”
  • “The market will tell us the truth.”

Fried and Heinemeier Hansson argue that anything you ask or test with customers prior to launch is hypothetical: “Real answers are uncovered when someone’s motivated enough to buy your product and use it in their own environment – and of their own volition. Anything else is simulated answers. Shipping real products gives you real answers.” Whilst I do agree with this line of thinking, I don’t believe in simply launching some crappy product or feature and see if it sticks (just as much I don’t believe in “build it and they will come”).

 

 

My suggestion would to ‘launch confidently and learn’. This means that for each new product or feature you determine – based on your confidence level – whether it needs some form of customer research before launch:

  1. Deliver value in order to learn¬†– You want to be smart about the things you want to learn. The best opportunity to learn comes when you’re confident about the value that you’re delivering to the customer. Naturally, people might not buy or use your product despite the value it intends to deliver, but that’s a learning in itself.
  2. Minimum Level of Confidence (1) – How confident are you? What exactly are you confident about (and why)? The main reason why I believe in product managers adhering to a confidence treshold is to avoid launching products that don’t work or provide an awful user experience. The Newton MessagePad which came out in 1993 is a good example of the launch of an incomplete product, which didn’t live up to its promise. Larry Tesler, senior exec at Apple at the time of of the Newton MessagePad, described Apple’s promise about the Newton’s handwriting capability as a large nail in the Newton coffin. The lesson learned here is that you shouldn’t launch when you’re not confident about the capability and value of your product or feature.
  3. Minimum Level of Confidence (2) – I’ve come up with a number of basic questions and criteria to apply when you’re thinking of launching a product (see Fig. 1-2 below). In my experience, identifying your Minimum Level of Confidence shouldn’t result in ‘analysis paralysis’. In contrast, it’s an important conversation to have throughout the product lifecycle to ensure that everyone fully understands what risks or unknowns are associated with the upcoming release. As an outcome of such a conversation you can decide whether to get customer feedback pre-release.
  4. Make sure you learn! – Whether you do or don’t engage with customers before launch, being clear about what you’re looking to learn from a release is paramount. Like I mentioned above, I view releasing something without learning from it¬† as a cardinal sin. It’s very important to continuously learn from real users and actual usage (or not) about your key hypotheses. These learnings – both quantitive and qualitative – will give you the data points to iterate or terminate a product.

Fig. 1 – Questions and criteria to check your confidence about launching a product or feature:

  • Internal quality assurance¬†– Have you tested your product feature to ensure there are no obvious bugs or gaps in the user experience? Even if you don’t test with customers prior to launch, you should test some key acceptance scenarios internally before launch to make sure the product works as intended.
  • Does the feature or product touch on core user experience? – If “yes” is the answer to this, then I recommend you do test with customers prior to launch to identify any major usability issues worth solving before launch. You typically need to test with no more than five customers to unearth any critical usability issues.
  • How confident are you?¬†– The combination of low confidence in something which your business has got a lot riding can be deadly. Yes, one can always try to do damage limitation, but it might already be too late at the time of you trying to repair things! The idea behind determining your confidence levels upfront isn’t a scientific one. Instead, it enables a conversation, making sure that people have got their eyes wide open and understand the level of risk and unknowns involved in an upcoming product launch (see Fig. 2 below).

Fig. 2 – Basic confidence levels to consider before launch:

  • High Confidence: Our confidence in the upcoming release is high because we tested it thoroughly internally, have launched a similar product or feature before or if there’s an issue the fallout will be small.
  • Low Confidence: Our confidence in the upcoming release is low because we haven’t fully tested it, it’s based on new technology or creates a totally new user experience.

 

 

 

Main learning point:¬†Even if you decide not to generate customer learnings before a product launch, make sure you at learn after launch. Launch and learn. Don’t launch without learning!

 

Related links for further learning:

  1. https://www.mindtheproduct.com/2017/02/the-life-of-a-product-manager-learning-by-doing/
  2. https://www.intercom.com/blog/shipping-is-your-companys-heartbeat/
  3. https://medium.com/@joshelman/a-product-managers-job-63c09a43d0ec
  4. https://uxplanet.org/10-things-i-learned-from-jason-fried-about-building-products-5b6694ff02aa
  5. http://time.com/13549/the-10-worst-product-fails-of-all-time/
  6. https://twitter.com/jasonfried/status/935555293014036480
  7. https://247wallst.com/special-report/2014/03/03/worst-product-flops-of-all-time/2/
  8. https://www.macworld.com/article/2047342/remembering-the-newton-messagepad-20-years-later.html
  9. https://www.nytimes.com/1993/09/26/business/the-executive-computer-so-far-the-newton-experience-is-less-than-fulfilling.html

Book review: “Radical Focus”

Christina Wodtke’s latest book, “Radical Focus”, is probably the most valuable ‘business’ book which I’ve read thus far this year. The full title of the book reads “Radical Focus – Achieving Your Most Important Goals with Objectives and Key Results” and Wodtke¬†provides a great story – literally – as well as useful tips about the importance of goal setting. The book starts with a fable about a Silicon Valley startup, and offers a good narrative about how (not) to use of objectives and key results (‘OKRs’). This fable, which felt very close to the reality of being in startups – sets the scene for the practical tips that Wodtke offers with respect to using OKRs effectively, irrespective of whether you work in a startup or at Amazon.

 

 

What are some of the most common reasons why key things don’t happen? Wodtke offers a number of insights here:

  1. No prioritisation or stack ranking of goals – Everything is deemed important and critical things don’t get done as a result.
  2. No obsessive and comprehensive communication of the goal – Wodtke suggests that for key goals to be achieved, it’s important to reiterate the goal daily and having regular¬†commitment meetings, where the team talks about the key goal and commit to specific activities directly related to the goal.
  3. There’s no plan to get things done – Often, companies will have lofty goals but no plan or process to actually achieve these goals. Wodtke introduces a number of useful ceremonies which teams can use to keep goals relevant and top of mind: commitment meetings, check ins and celebrations.
  4. No or insufficient time carved for what really matters – Love how Wodtke refers to the “Eisenhower Box” which helps identify and prioritise those things that must be done (see Fig. 1 below).
  5. A tendency to give up instead of iterating – Business often give up at the first attempt, canning a goal if it isn’t achieved (fully) first time around. Instead, Wodtke urges, try to avoid a lack of followthrough by¬†iterating constantly.

Fig. 1 РThe Eisenhower РTaken from: https://jamesclear.com/eisenhower-box/eisenhower-box-2

As the book title clearly suggests, Wodtke advocates the use of OKRs to achieve focus and making sure that key goals are being realised:

  • Objectives are bold and qualitative – Set a bold, inspirational and qualitative Objective each quarter. Wodtke provides examples of both good and poor Objectives (see Fig. 2 below).
  • Key Results are tangible and quantitative – Each Objective will have three quantitative Results that let you know when you’ve hit your Objective (see Fig. 3 below). Wodtke stresses that Key Results are “hard goals, the kind where you only have a 50/50 shot of achieving.” These ‘stretch goals’ are hard to achieve but not impossible, and you indicate for each Key Result how confident you are of achieving it.
  • OKRs and health metrics – In the book, Wodtke makes a helpful distinction between OKRs and health metrics. OKRs are “the thing you want to push, the one thing you want to make better.” I’d add an emphasis on the word “one” here as I find working with a single business Objective to be most effective. In my experience, having multiple business Objectives starts muddying the water in terms of focus and prioritisation. Instead, start with setting one Objective for the company. Secondly, set OKRs for each team that ty back to the company goal. Health metrics are the key things to continue to watch, these metrics are more concerned with ‘hygiene’.
  • Set OKRs together, pick Key Results as a team – Identifying and agreeing on Objectives and Key Results is a collaborative process. Clearly articulating and sharing the business Objective is a critical first step. The different teams can then set those Key Results which they believe will contribute to the business Objective.
  • Progress monitoring – I particularly liked the 4×4 matrix that Wodtke suggests as a way of monitoring progress with respect to achieving your business and associated team OKRs (see Fig. 4 below). This matrix is a very simple but effective way of committing to (weekly) priorities and capturing progress.
  • Setting a rhythm¬†of execution – Wodtke introduces a number of weekly ceremonies which you can use to keep OKRs relevant and to ensure that you keep to them (see Fig. 5 below). The risk with goal setting is that it remains a one off exercise and I believe that having weekly ‘commitment’ and ‘win’ sessions will help massively keeping OKRs front of mind.

Main learning point:¬†In “Radical Focus”, Christina Wodtke does a great job of explaining the role and value of OKRs. Not only does she provide valuable tips on how to best define OKRs, Wodtke also offers useful methods of keeping track of progress against OKRs. If you feel that you and your business are doing too much of everything, or not achieving anything, then Radical Focus is a must read!

Fig. 2 – Examples of good and poor Objectives – Taken from: Christina Wodtke, Radical Focus, self-published, 2016, p. 110

Here are some good Objectives:

  • Own the direct-to-business coffee retail market in the South Bay.
  • Launch and awesome MVP.
  • Transform Palo Alto’s coupon using habits.
  • Close a round that lets us kill it next quarter.

and some poor Objectives:

  • Sales numbers up 30%.
  • Double users.
  • Raise a Series B of 5M.

Fig. 3 РKey Results РTaken from: Christina Wodtke, Radical Focus, self-published, 2016, pp. 111 Р112

Key Results can be based on anything you can measure, including:

  • Growth
  • Engagement
  • Revenue
  • Performance
  • Quality

For example, if your Objective is to “Launch an Awesome MVP” you could have the following Key Results:

  • 40% of users come back 2X in one week
  • Recommendation score of 8
  • 15% conversion

Fig. 4 – Example of Christina Wodtke’s 4×4 OKR matrix – Taken from:¬†https://medium.com/@cwodtke/one-objective-to-rule-them-all-1058e973bfc5

Fig. 5 РSetting a rhythm of execution РTaken from: Christina Wodtke, Radical Focus, self-published, 2016, pp. 120 Р123

Monday Commitments

Each Monday, the team should meet to check in on progress against OKRs, and commit to the tasks that will help the company meet its Objective.

  • Intention for the week – What are the 3-4 most important things you must get done this week toward the Objective? Discuss if these priorities will get you closer to the OKRs.
  • Forecast for the month – What should your team know is coming up that they can help with or prepare for?
  • Status toward OKRs – If you set a confidence of five out of ten, has that moved up or down? Have a discussion about why.
  • Health metrics – Pick two things you want to protect as you strive toward greatness. What can you not afford to eff-up? Key relationships with customers? Code stability? Team well-being? Now mark when things start to go sideways, and discuss it.

Fig. 6 РOKR Fundamentals РTaken from: Christina Wodtke, Radical Focus, self-published, 2016, pp. 109 Р112

Your Objective is a single sentence that is:

Qualitative and Inspirational

The objective is designed to get people jumping out of bed in the morning with excitement. And while CEOs and VCs may jump out of bed in the morning with joy over a 3% gain in conversion, most mere mortals get excited by a sense of meaning and progress. Use the language of your team.

Time Bound

For example, doable in a month, a quarter. You want it to be a clear sprint toward a goal. If it takes a year, your Objective maybe a strategy or even a mission.

Actionable by the Team Independently

This is less of a problem for startups, but bigger companies often struggle because of interdependence. Your Objective has to be truly yours, and you can’t have the excuse of “Marketing didn’t market it.”

An Objective is like a mission statement, only for a shorter period of time. A great objective inspires the team, is hard (but not impossible) to do in a set time frame, and can be done by the person or people who have set it, independently.

Fig. 7 – Quick tips on OKRS use – Taken from: Christina Wodtke, Radical Focus, self-published, 2016, p. 153

  • Set only one OKR for the company, unless you have multiple business lines. It’s about focus.
  • Give yourself three months for an OKR. How bold is it if you can do it in a week?
  • Keep the metrics out of the Objective. The Objective is inspirational.
  • In the weekly check in, open with company OKR, then do groups. Don’t do every individual; that’s better in private 1:1s.
  • OKRs cascade; set company OKRs, then group’s/role’s, and then individual’s.
  • OKRs are not the only thing you do; they are the one thing you must do. Trust people to keep the ship running, and don’t jam every task into OKRs.
  • The Monday OKR check in is a conversation. Be sure to discuss change in confidence, health metrics and priorities.
  • Encourage employees to suggest company OKRs. OKRs are great bottom up, not just top down.
  • Make OKRs available publicly. Google has them on their intranet.
  • Friday celebrations is an antidote to Monday’s grim business. Keep it upbeat!

 

Related links for further learning:

  1. http://eleganthack.com/the-art-of-the-okr/
  2. https://medium.com/@cwodtke/one-objective-to-rule-them-all-1058e973bfc5
  3. https://www.youtube.com/watch?v=8aW5gdRRn_U
  4. http://fortune.com/2018/05/21/john-doerr-measure-what-matters-okr/

Lessons learned from Uri Levine, Co-Founder of Waze

Last Friday, I attended a talk by Uri Levine, Co-Founder of Waze, a community-based traffic and navigation app that was sold to Google for $1.1 billion. In a two-hour session, Uri shared some of his key learnings from the Waze startup journey; from starting from scratch to a successful exit. I felt that his¬†talk was packed with valuable insights, and I’ve selected some key ones to share:

Focus on the problem – I loved how Uri concentrated on the problem that you’re looking to solve. He talked about problem solving being a key driver for him and the different startups that he’s (been) involved in. For example, Waze originated from Uri’s frustration with traffic jams … Uri then talked us through the “Adjusted Startup Curve” to illustrate the typical journey of a startup, starting with a problem to solve (see Fig. 1).

Fig. 1 – Knife Capital’s “Adjusted Startup Curve” – Taken from:¬†http://ventureburn.com/2013/07/the-startup-curve-south-africa-wiggles-of-realism/

Don’t be afraid to fail – I always find it incredibly refreshing when other people speak openly about failures and not being afraid to fail. As Uri rightly pointed out, the fear to fail (and therefore not trying) is a failure in itself (see Fig. 2). He was also keen to stress that creating and managing a startup is never a linear, upward journey. By contrast, you effectively go from failure to failure, but you might win in the end – if you’re lucky that is (see Fig. 3).

Fig. 2 РMichael Jordan quote about failure РTaken from: http://www.quotezine.com/michael-jordan-quotes/

Fig. 3 – “Journey of Failures” by Douglas Karr – Taken from:¬†https://twitter.com/douglaskarr/status/333027896241299457/photo/1

Passion for change – Uri’s points about entrepreneurs and their passion for change really resonated with me. I’m not an entrepreneur, but I feel that I’ve got some innate restlessness which is usually fed by change, learning and trying new things. It was interesting hearing Uri talk about how this passion usually doesn’t sit with well with fear of failure or loss. “Move fast and break things” was one of Uri’s mantras in this regard.

Honest validation of your ideas – As an entrepreneur, Uri explained, you need to fall in love with your idea. However, he also highlighted¬†the importance of being able to critically assess your own idea. He suggested asking yourself “who will be out of business if I succeed?” If you don’t know the answer to this question, Uri explained, your idea probably isn’t big enough.

Iterate based on user feedback – Uri reminded me of the mighty David Cancel¬†as David is¬†also very focused on solving¬†customer problems and listening to customer feedback (see Fig. 4). Like David, Uri didn’t get overly zealous about Agile or lean development methods. Instead, Uri talked about constantly iterating a product or service based on customer feedback.

Fig. 4 РDavid Cancel at Mind the Product conference, London 2016 РTaken from: http://www.mindtheproduct.com/2016/12/importance-listening-customers-david-cancel/

Main learning point: I found Uri Levine’s talk hugely inspiring; he was honest about the challenges involved in creating or working at a startup whilst at the same encouraging us to solve problems and try things.

Related links for further learning:

  1. http://www.tellseries.com/events/uri-levine/
  2. http://uk.businessinsider.com/how-waze-co-founder-spends-his-money-2015-8
  3. https://www.ft.com/content/49857280-8eaf-11e5-8be4-3506bf20cc2b
  4. https://www.crunchbase.com/person/uri-levine#/entity
  5. https://www.theguardian.com/media-network/2015/may/28/waze-uri-levine-tips-startup-google

My product management toolkit (17): Assess market viability

Whether you’re a product manager or are in a commercial or strategic role, I’m sure you’ll have to assess market viability at some point in your career. For that reason, I wrote previously about assessing markets, suggesting tools that you can use to decide on whether to enter a market or not.

A few weeks ago, I listened to a podcast interview in which Christophe Gillet, VP of Product Management at Vimeo, gave¬†some great pointers on how to best assess market viability. Christophe shared his thoughts¬†on things to explore¬†when considering market viability. I’ve added my sample questions related to some of the points that Christophe made:

  1. Is there a market? – This should be the first validation in my opinion; is there a demand for my product or service? Which market void will our product help to fill and why? What are the characteristics of my target market?
  2. Is there viability within that market? ¬†Once you’ve established that there’s a potential market for your product, this doesn’t automatically mean that the market is viable. For example, regulatory constraints can make it hard to launch or properly establish your product in a market.
  3. Total addressable market РThe total addressable market Рor total available market Рis all about revenue opportunity available for a particular product or service (see Fig. 1 below). A way to work out the total addressable market is to first define total market space and then look at percentage of the market which has already been served.
  4. Problem to solve – Similar to some of the questions to ask as part of point 1. above, it’s important to validate early and often whether there’s an actual problem that your product or service is solving.
  5. Understand prior failures (by competitors) – I’ve found that looking at previous competitor attempts can be an easy thing to overlook. However, understanding who already tried to conquer your market of choice and whether they’ve been successful can help you avoid some pitfalls that others encountered before you.
  6. Talk to individual users ¬†I feel this¬†is almost a given if you’re looking to validate whether there’s a market and a problem to solve (see points 1. and 4. above). Make sure that you sense check your market and problem assumptions with your target customers.
  7. Strong mission statement and objectives of what you’re looking to achieve ¬†In my experience, having a clear mission statement helps to articulate and communicate what it is that you’re looking to achieve and why. These mission statements are typically quite aspirational but should offer a good insight into your aspirations for a particular market (see the example of outdoor clothing company Patagonia in Fig. 2 below).
  8. Business goals¬†¬†Having clear, measurable objectives in place to achieve in relation to a new market that you’re considering is absolutely critical. In my view, there’s nothing worse than looking at new markets without a clear definition of what market success looks like and why.
  9. How to get people to use your product – I really liked how Christophe spoke about the need to think about a promotion and an adoption strategy. Too often, I encounter a ‘build it and they will come’ kind of mentality which I believe can be deadly if you’re looking to enter new markets. Having a clear go-to-market strategy is almost just as important as developing a great product or service. What’s the point of an awesome product that no one knows about or doesn’t know where to get!?

Main learning point: Listening to the interview with Christophe Gillet reinforced for me the importance of being able to assess market viability. Being able to ask and explore some critical questions when considering new markets will help avoid failed launches or at least gain a shared understanding of what market success will look like.

 

Fig. 1 РTotal available market РTaken from: https://en.wikipedia.org/wiki/Total_addressable_market

1000px-tam-sam-market

Fig. 2 – Patagonia’s mission statement – Taken from:¬†http://www.patagonia.com/company-info.html

screen-shot-2017-01-20-at-07-21-29

Related links for further learning:

  1. http://www.thisisproductmanagement.com/episodes/assessing-market-viability
  2. http://www.mindtheproduct.com/2013/05/poem-framework/
  3. http://smallbusiness.chron.com/determine-market-viability-product-service-40757.html
  4. https://en.wikipedia.org/wiki/Total_addressable_market
  5. https://blog.hubspot.com/marketing/inspiring-company-mission-statements

Book review: Sprint (Part 6 – Day 5)

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)

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)

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/