Product review: Range

Braden Kowitz is a great product designer, having established his craft at Google and Google Ventures. He’s worked on products such as Gmail and with successful startups such as ClassPass. So when I heard about Range, the startup that Kowitz is a co-founder of, I was keen to learn more about the product.

My quick summary of Range before using it? I expect Range to be a tool that helps companies engage more effectively with their employees.

How does Range explain itself in the first minute? “Teamwork simplified” is the strap-line above the fold on Range’s homepage, explaining how “Range helps you stay in sync and feel like a team, so you can do your best work together.”

 

It looks like Range addresses three main areas of employee communications and engagement:

  1. Check-ins – Enabling teams to run virtual stand-ups on a daily basis.
  2. Objectives – Setting and monitoring of OKRs.
  3. Meetings – Helping people to run more effective meetings.

 

 

Scrolling down, the homepage explains how Range is all about team work, helping its users to feel like a true team – even if the team is distributed across multiple locations.

 

 

Getting started: After I’ve clicked on the “Try free” call to action on the homepage, I’m directed to the first step of an on-boarding flow. It’s good how Range assures me that I can sign up for an initial 30 day period, without a credit card being required. I need to sign up via a Google account and I can request a demo in case I don’t have a Google account. It would be good to understand why I can only sign up via my Google account.

 

 

I use my personal Gmail account, since we don’t use Google for work email, and I receive below error message which explains how “Range is meant for work”. I’ll request a personal walkthrough instead …

 

 

When I click on the “Request a demo” call to action, I’m directed to a standard sign-up page, which worries me that I’ll be receiving a lot of emails before and after my demo. It’s therefore reassuring that Range mentions “Don’t worry, we hate spam too.” Not sure though whether Range will be able to fulfil my demo request since we use Microsoft Outlook at work.

 

Did Range deliver on my expectations? Not yet. I hadn’t realised that Range only works if you’re a G Suite Google user. Ask me again after my personal Range walkthrough 🙂

 

 

My product management toolkit (36): Google’s HEART framework

Measure. Measure. Measure. Tracking the impact of a product is crucial if you wish to learn about your product and your customers. I’ve written before about the importance of spending time on defining the right metrics to measure, avoiding the risk of succumbing to data overload. That’s all well and good, but what do you do when the key things to measure aren’t so tangible!? For example, how do you measure customer feelings or opinions (a lot of which you’ll learn about during qualitative research)?

A few years ago, Kerry Rodden – whilst at Google – introduced the HEART framework which aims to solve the problem of measuring less tangible aspects of the products and experiences we create (see Fig. 1 below). The HEART framework consists of two parts:

  • The part that measures the quality of the user experience (the HEART framework)
  • The part that measures the goals of a project or product (the Goals-Signals-Metrics process)

 

Fig. 1 – The HEART framework combined with the Goals-Signals-Metrics process – Taken from: https://medium.com/@dhruvghulati/google-s-heart-framework-a-critical-evaluation-a6694421dae

 

Both parts are very helpful tools to have in one’s product management toolkit as they’ll help you to measure product performance through the lens of the person using your product:

HEART framework

  • Happiness – Measure of user attitudes, often collected via surveys or interviews. For example: satisfaction, perceived ease of use, and net promoter score.
  • Engagement – Measures the level of user involvement, typically via behavioural proxies such as frequency, intensity, or depth of interaction over some time period. Examples include the number of visits per user per week or the number of photos uploaded per user per day.
  • Adoption – New users of a product, feature or a service. For example: the number of accounts created in the last seven days, the number of people dropping off during the onboarding experience or the percentage of Gmail users who use labels.
  • Retention – The rate at which existing users are returning. For example: how many active users from a given time period are still present in some later time period? You may be more interested in failure to retain, commonly known as “churn.”
  • Task success – This includes traditional behavioural metrics with respect to user experience, such as efficiency (e.g. time to complete a task), effectiveness (e.g. percent of tasks completed), and error rate. This category is most applicable to areas of your product that are very task-focused, such as search or an upload flow.

Certainly, the HEART framework isn’t bullet proof (nor does it have to be in my humble opinion). For example, Dhruv Ghulati has written up some valid concerns about how the HEART metrics could easily contradict each other or shouldn’t be taken at face value. I do, however, believe that the HEART framework is a valuable tool for the following reasons and use cases:

  • Learning how customers feel about your product.
  • Correlating these learnings with actual customer behaviours.
  • Does the product help achieve key customer tasks or outcomes? Why (not)?
  • What should we focus on? Why? How to best measure?

The HEART framework thus works well in measuring the quality of the user experience, making intangible things such as “happiness” and “engagement” more tangible.

Goals-Signals-Metrics process

The HEART framework goes hand in hand with the Goals-Signals-Metrics process, which measures the specific goals of a product. I came across a great example of the Goals-Signals-Metrics process, by Usabilla. This qualitative user research company applied the HEART framework and the Goals-Signals-Metrics when they launched a 2-step verification future for their users.

Fig. 2 – Usabila’s application of the HEART framework – Taken from: https://usabilla.com/blog/how-to-prove-the-value-of-your-ux-work/

This example clearly shows how you can take ‘happiness’, a more intangible aspect of Usabilla’s authentication experience, and make it measurable:

  • Question: How to measure ‘happiness’ with respect to Usabilla’s authentication experience?
  • Goal: The overarching goal here is to ensure that Usabilla’s customers feel satisfied and secure whilst using Usabilla’s product.
  • Signals: Positive customer feedback on the feature – through a survey – is a strong signal that Usabilla’s happiness goal is being achieved.
  • Metrics: Measuring the percentage of Usabilla customers that feels satisfied and secure after using the new authentication experience.

The Usabilla example of the HEART framework clearly shows the underlying method of taking a fuzzy goal and breaking it down into something which can be measured more objectively.

Main learning point: The HEART framework is a useful tool when it comes to understanding and tracking the customer impact of your product. As with everything that you’re trying to measure, make sure you’re clear about what you’re looking to learn and how to best interpret the data. However, the fact that the HEART framework looks at aspects at ‘happiness’ and ‘engagement’ makes it a useful tool in my book!

Related links for further learning:

  1. https://www.interaction-design.org/literature/article/google-s-heart-framework-for-measuring-ux
  2. https://www.dtelepathy.com/ux-metrics/
  3. http://www.rodden.org/kerry
  4. https://medium.com/uxinthe6ix/how-we-used-the-heart-framework-to-set-the-right-ux-goals-4454df39db94
  5. https://library.gv.com/how-to-choose-the-right-ux-metrics-for-your-product-5f46359ab5be
  6. https://www.appcues.com/blog/google-improves-user-experience-with-heart-framework
  7. https://clevertap.com/blog/google-heart-framework/
  8. https://medium.com/@dhruvghulati/google-s-heart-framework-a-critical-evaluation-a6694421dae
  9. https://gofishdigital.com/heart-framwork-plan-track-measure-goals-site/
  10. https://www.youtube.com/watch?v=vyZzbsL_fsg
  11. http://www.jjg.net/elements/
  12. https://usabilitygeek.com/combining-heart-framework-with-goals-signals-metrics-process-ux-metrics/

Book review: “Autonomy”

Lawrence Burns is a veteran of the automative industry. Having worked his entire professional career in the car industry – in Detroit, the birthplace of modern car manufacturing no less – you might expect Burns to be apprehensive about ‘change’ and modern technology. The opposite couldn’t be more true of Burns, since he’s been an advocate for driverless cars for the past 15+ years, starting his foray into this field whilst at General Motors.

In his latest book, “Autonomy: The Quest to Build the Driverless Car – and How It Will Reshape Our World”, Burns and cowriter Christopher Shulgan paint a picture of driverless cars dominating our streets and roads, and having a positive impact on the environment and transportation as a whole. For those sceptics out there who dismiss driverless cars as science fiction, I recommend they read “Autonomy” and take note of the technology and societal developments Burns describes:

Getting started, the DARPA Challenge and Google’s “Project Chauffeur”:

The book starts off with the story of the “DARPA Challenge” in 2004 and how this helped shaped learning and development with respect to driverless cars. Burns gives the reader a good close-up of the experiences and learnings from one of the teams that took part in this challenge. At this first DARPA challenge, every vehicle that took part crashed, failed or caught fire, highlighting the early stage of driverless technology at the time.

Image taken from: https://www.wired.com/story/darpa-grand-urban-challenge-self-driving-car/

Driverless cars are the (near) future:

Bob Lutz, former executive of Ford, Chrysler and General Motors, wrote an essay last year titled “Kiss the good times goodbye”, in which he makes a clear statement about the future of the automotive industry: “The era of the human-driven automobile, its repair facilities, its dealerships, the media surrounding it – all will be gone in 20 years.” There’s no discussion that driverless cars are coming, especially that both car and technology giants are busy developing and testing. When I attended a presentation by Burns a few months agogo, he showed the audience  examples of both self driving cars and trucks:

Image taken from: http://www.autonews.com/article/20170316/MOBILITY/170319877/bmw-says-self-driving-car-to-be-level-5-capable-by-2021

Image taken from: https://newatlas.com/volvo-vera-self-driving-truck/56312/

In “Autonomy”, Burns brings Lutz’ predictions to life through the fictitious example of little Tommy and his family. In this example, Tommy steps into a driverless which has been programmed to take him to school in the morning. Tommy’s grandma will be picked up by a driverless two-person mobility pod to take her to a bridge tournament. Burns describes a world where car ownership will be a thing of the past; people using publicly available fleets of self driving cars instead.

Image taken from: https://www.thenational.ae/business/technology/autonomous-pods-the-future-of-city-driving-1.730283

Together with Chris Borroni-Bird, Burns has done extensive research into the potential impact of an electronic self driven car, looking at metrics such as “total expense per mile”, “cost savings per mile” and “estimated number of parts”. Borroni-Bird and Burns provide some compelling stats, especially when contrasted against conventional cars. Reading these stats helps to make the impact of driverless technology a lot more tangible, turning it from science fiction or future music into a realistic prospect.

Main learning point: “Autonomy” by Lawrence is an insightful book about a driverless future, written by a true connoisseur of the car industry and the evolution of driverless technology.

Related links for further learning:

  1. https://spectrum.ieee.org/cars-that-think/transportation/self-driving/auto-consultant-lawrence-burns-dishes-the-dirt-on-waymo
  2. https://www.youtube.com/watch?v=-pLM-2bxNMc
  3. https://www.youtube.com/watch?v=SJVKY1DtZ84
  4. https://www.forbes.com/sites/greggardner/2018/08/23/an-interview-with-self-driving-visionary-larry-burns-co-author-of-autonomy/
  5. http://www.autonews.com/article/20171105/INDUSTRY_REDESIGNED/171109944/industry-redesigned-bob-lutz
  6. https://lucidmotors.com/
  7. https://electrek.co/2017/01/02/lucid-motors-autonomous-tech-all-electric-sedan-mobileye/
  8. http://www.thedrive.com/opinion/9024/who-is-really-1-in-self-driving-cars-you-wouldnt-know-it-from-navigants-controversial-report
  9. https://news.stanford.edu/2017/05/22/stanford-scholars-researchers-discuss-key-ethical-questions-self-driving-cars-present/
  10. https://www.thenational.ae/business/technology/autonomous-pods-the-future-of-city-driving-1.730283
  11. https://www.wired.com/story/darpa-grand-urban-challenge-self-driving-car/
  12. https://spectrum.ieee.org/cars-that-think/transportation/self-driving/google-has-spent-over-11-billion-on-selfdriving-tech

Michael Margolis: “user research, quick and dirty” (1)

Why do I keep coming across businesses that struggle to engage with their (prospective) customers, to learn about their needs and behaviours? Too often for my liking, I hear comments like:

“Marc, we’re a startup, we don’t have the time and budget to do customer research!” 

“I’m not allowed to talk to customers.” 

“In my old place, we used to have a dedicated user research team and they’d just give me their research report on a platter, after them having spoken to users.”

It therefore felt quite timely when a colleague pointed me in the direction of Michael Margolis, UX Research Partner at Google Ventures.  Back in 2013, Margolis delivered a great Startup Lab workshop in which he covered the ins and outs of “User research, quick and dirty”. The recording of the 90 minute workshop is available on YouTube and you can find Margolis’ slides here (see also Fig. 1 below).

Fig. 1 – Michael Margolis’ Startup Lab workshop: “User Research, Quick ‘n’ Dirty” – Published on 26 February 2013 on https://youtu.be/WpzmOH0hrEM

I watched Margolis’ workshop in full and these are my main takeaways:

Seeing through users’ eyes

Margolis started off his session by talking about the importance of continuously learning about users, seeing things through their eyes. In a subsequent Medium post, Margolis writes that in his experience, startups will typically use UX research to achieve one of these objectives:

  1. Improve a process or worklflow
  2. Better understand customer shopping habits
  3. Evaluate concepts
  4. Test usability
  5. Refine a value proposition

Two types of user interviews

It’s great to hear Margolis making a distinction between two types of interviews:

  • Usability: A usability interview is all about learning whether users can actually use your product and achieve their goals with it. Can users do it? Can they understand it? Can they discover features?
  • Discovery: Discovery type user interviews tend to be more contextual, and delve more into the actual user. Who? Where? When? Why? How? All key questions to explore as part of discovery, as well as the user’s existing behaviours, goals, needs and problems.

Margolis then talks about combining the two interview types and highlight two sample questions to illustrate this combination:

“How do you do things now?”

“How do you think about these things?”

The distinction between “usability” and “discovery” isn’t just an artificial one. I love Margolis’ focus on objectives, acknowledging that objectives are likely to vary depending on the type of product, its position within the product lifecycle and the learnings that you’re looking to achieve. I’ve found – at my own peril – that it’s easy to jump straight into defining user tasks or an interview script, without thinking about your research objective and what Margolis calls “North Star questions” (see Fig. 2 below).

Fig. 2 – Michael Margolis’ 5 studies startups needs most- Taken from:  https://library.gv.com/field-guide-to-ux-research-for-startups-8569114c27fb – Published on 5 May 2018 

Margolis provides some very useful pointers about discovery and usability questions, which you can use to create a research plan and an interview guide:

Sample discovery questions – as suggested by Michael Margolis:

  • What are users’ behaviours, attitudes and expectations towards the product?
  • Who are the key user groups? What are their needs and behaviours?
  • What are the pros/cons of different designs? Why?
  • What are the pros/cons of competitor products?
  • How are people using existing/competitor products? What features are mots important and why?
  • What barriers hinder users from adopting <product>?

Sample usability questions – as suggested by Michael Margolis:

  • Can users discover feature X?
  • Are users able to successfully complete primary tasks? Why (not)?
  • Do users understand feature X? Why (not)?

In a similar vein, I believe it’s important to distinguish between problem and solution interviews. There’s a risk of your customer insights becoming muddled when you mix problem and solution interviews, especially if you alternate problem questions with solution questions.

In a problem interview, you want to find out 3 things:

  • Problem – What problem are you solving? For example, what are the common frustrations felt by your customers and why? How do their problems rank? Ask your customers to create a top 3 of their problems (see the problem interview script in Fig. 1 below).
  • Existing alternatives – What existing alternatives are out there and how does your customer perceive your competition and their differentiators? How do your customers solve their problems today?
  • Customer segments – Who has these problems and why? Is this a viable customer segment?

Fig. 3 –  Outline of a problem interview script – Taken from: Ash Maurya – “Running Lean”

In a solution interview, you want to find out 3 things:

  • Early adopters – Who has this problem and why? How do we identify and engage with early adopters? (see Fig. 3 below)
  • Solution – How will you solve their problems? What features do you need to build as part of your solution, why?
  • Pricing/Revenue – What is the pricing model for your product or service? Will customers pay for it, why?

Fig. 4 – Outline of a solution interview script – Taken from: Ash Maurya – “Running Lean”

Main learning point: In his Startup Lab workshop, Michal Margolis, drops a lot of very valuable tips on how to best keep customer research quick and simple, whilst still learning the things about your customer and/or product that you’re keen to learn. So much so that Michael Margolis’ tips warrant another blog post, which I’ll share soon!

Related links for further learning:

  1. https://library.gv.com/field-guide-to-ux-research-for-startups-8569114c27fb
  2. https://library.gv.com/user-research-quick-and-dirty-1fcfa54c91c4
  3. https://www.slideshare.net/LauraKlein1/shut-the-hell-up-other-tips-for-learning-from-users
  4. https://www.youtube.com/watch?v=WpzmOH0hrEM
  5. https://library.gv.com/tagged/design
  6. https://medium.com/@maa1/book-review-just-enough-research-2d714d447eda
  7. https://medium.com/@maa1/my-product-management-toolkit-23-customer-empathy-a1e66ff15012

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/