Review: Shift

March 10, 2019March 11, 2019 marcabrahamLeave a comment

Having worked on a number of online marketplace products, I’m always curious about other online marketplaces out there. So you might be able to imagine my excitement when I came across Shift, a US-based marketplace for new and used cars. Having bought used cars before, I feel that the used car industry is ripe for disruption and my hunch is that Shift is aiming to do just that.

I can see plenty of room to improve transparency and trust when it comes to buying and selling used cars and I’m keen to learn more about how Shift tries to tackle both areas:

My quick summary of Shift before using it: I expect a platform that enables consumers to discover, compare and buy used cars. Unsure whether cars are bought from dealerships or from Shift directly. Also, wondering whether I can get finance through Shift to help purchase my car.

How does Shift explain itself in the first minute? The landing page of the site shows two women, seated in a car and looking happy. The main strap-line on the site reads “Simplified car buying”, followed by “Great cars. Better prices. Test drives delivered to you.” The main navigation bar in the top right hand corner of the page shows “Financing” as one of the options for people to consider.

How does Shift work? Shift’s “Concierges” deliver test drives to customers on-demand. After a test drive one can arrange finance and purchase the car on the spot. Shift applies three driving principles to its business, as it aims to “bring trust and simplicity to the peer-to-peer used car market”: convenience, value and trust. Shift sees the Concierge as a pivotal actor as part of this experience as it’s the role of the Concierge “to be your guide. It’s not their job to sell you a car, it’s to help you buy one.”

When, for instance, I look at a used Mercedes GLE 350 to buy (see screenshot below), a few things stand out to me:

“No-haggle list price” – So there’s no room for a potential buyer to bring the price down!? From a peer-to-peer perspective, I can see how a fixed price creates a lot of clarity and trust for both parties involved in the transaction, car buyer and seller.

Compare price – I would have loved to compare prices for the specific car I’m interested in. When, however, I click on “Compare” for a a number of different vehicles on Shift’s site, I keep getting a message stating that price comparison info isn’t available.

Mechanical inspection – Would love to learn more about Shift’s process that precedes the mechanical inspection as shown for each model on the site. I deliberately looked for cars that didn’t just have a perfect list, i.e. all green marks, and I found one (see below). This Toyota Prius (2010) has three body related issues. When I click to see details, the three issue are being explained clearly, as well as their impact on both the exterior and the drivability of the car.

Wear & tear photos – For this nine year old Toyota Prius, Shift offers seven wear and tear photos so that I can see clear evidence of the body related issues listed in the mechanical inspection report. I can thus make up my mind – before arranging a test drive – whether I can live with these issues or not.

Having looked into buying car, I now want to see how one can sell a car through Shift:

These three steps involved in selling a car through Shift feel very similar to selling through Vroom:

Get an estimate – Getting a Shift estimate for a car to sell feels pretty straightforward (see screenshot below). My only question is how car sellers can quickly figure out whether they’re getting a good price for their car, and how this estimated price compares to what they could get elsewhere.

How and when do I get paid? Shift will initiate payment to the the car seller at the end of the appointment in which they evaluate one’s car to sell. This approach made me think of real estate platforms such as Opendoor and Nested. These companies will buy your property off you (Opendoor) or pay an advance (Nested) after they’ve thoroughly inspected and valued your home. The comparison with real estate made me wonder whether Shift refurbishes the interior of car or improves the exterior once it has bought the car off you.

Screen Shot 2019-03-11 at 09.18.27.png

Did Shift deliver on my expectations? Yes. Refreshing to see the level of simplicity and transparency into an experience which has traditionally put the (uninformed) car buyer or seller on the back foot.

Related links for further learning:

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

March 6, 2019 marcabrahamLeave a comment

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:

My product management toolkit (34): product principles

January 11, 2019 marcabrahamLeave a comment

“Values are like fingerprints. Nobodies are the same but you leave them all over everything you do.” Elvis Presley

“Values” – each organisation has got them. Whether they’re explicit or implicit, strong company values underpin everything a business does (and doesn’t do). “Serve Our Users” for instance is a core value articulated in the Google Code of Conduct: “Our users value Google not only because we deliver great products and services, but because we hold ourselves to a higher standard in how we treat users and operate more generally.”

As product managers we use product principles, a clear set of standards and goals that connect company values with the outcomes that we’re trying to achieve, both for customers and our company. Before we look at example product principles, I believe it’s important to cover some terminology first:

Product principles – Specific principles that affect product development and decision-making.
Design principles – Specific principles that drive product design, both in terms of the user interface and the experience. For instance, companies have design principles around their app content or navigation.
General product principles – Those principles which apply to building great products and whicvh are agnostic to company values and apply to every product.

Granted, lots of of people seem to talk about design and product principles interchangeably, but I treat them very much as two distinct concepts. For instance, “we’re always 100% transparent with our users” I see as a good example of a product principle, and one that which subsequently drive the design of the product or service as well as many other aspects of the product. Here are some key things to bear in mind with respect to product management principles:

What to use product principles for? – Product principles can be very valuable at each stage of the product lifecycle, whether the product is at the idea stage or being considered for termination. In my experience, product principles ultimately help with decision making. Questions such as “should we add feature A or B?” or “which channels should we use for this product?”, can all be determined with the guidance of the overarching product principles.
Who should use product principles? – Everybody in the business. Just as much as company values apply to all employees, I believe that product principles work the same. To think that product principles sit exclusively within the domain of a product person feels limiting. People across the business are involved in the product and should therefore at least be aware of the product principles.
What do good product principles look like? – In essence, good product principles should (1) link closely to the overall company mission and values (2) be concrete enough to enable decision making (3) be easy to remember and (4) be specific enough within the context of customer outcomes. For example, at ecommerce platform Shopify the mission is “to make commerce better for everyone, no matter where they’re located or their level of experience.” From this mission statement, Shopify has derived its (product) principles: (1) put merchants first (2) empower but don’t overwhelm (3) build a cohesive experience and (4) be polished but not ornamental.

Taken from: https://polaris.shopify.com/guides/principles

Main learning point: Whilst I appreciate that values, design and product principles are often being talked about in the same breadth, I do recommend looking at product principles as its own concept. Well defined product principles can add a lot of value to product development and collaboration throughout the product lifecycle.

Related links for further learning:

My product management toolkit (33): launch and learn

November 23, 2018 marcabraham2 Comments

“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:

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.
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.
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.
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:

Book review: “Autonomy”

November 16, 2018 marcabrahamLeave a comment

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:

What product managers can learn about Design Systems

September 7, 2018 marcabraham1 Comment

What makes a good product? What makes a well designed product? A few years ago, I learned about design principles and how principles such as “not getting in the way (of the user)” and “content first” can drive product design. Imagine my initial confusion and intrigue, as a non-designer, when I first heard about a “design system”. Chris Messina – former designer at Uber – has come up with a useful definition of what a design system is:

“Design systems provide a convenient, centralized, and evolving map of a brand’s known product territories with directional pointers to help you explore new regions.”

Later, Messina went on to add that “Design never was just how it looks, but now it’s also how it sounds, how it speaks, and where it can go.” Apart from capturing how brand and product communicate, look and feel, a design system is also a critical component when it comes to scale. Just take this statement by Vikram Babu – product designer at Gigster – for example:

“The problem facing design today isn’t a shortage of skills or talent but that design doesn’t scale when you move from a few screens of designed components to a platform of developed patterns where adding people only complicates the problem… hence design systems.”

The key thing I learned about the value of design systems is that they intend to go beyond just a collection of design elements. Typically, companies will have a style guide. However, more often than not these style guides contain a bunch of design elements or patterns, but not create a fully comprehensive design language or tone of voice, as Nathan Curtis – owner of the EightShapes design firm – explains:

“A style guide is an artefact of the design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.”

This raises the question how one goes about creating a design system. Some things that I’ve learned in this respect:

Before you get started

What’s your company vision look like? And is mission?
Which problem is your company looking to solve and why? For whom?
What are the company values which underpin your company culture, product and service?
What problem(s) are we trying to solve through the design system? Why?
What’s the desired impact we expect the design system to have on the way we work?

Getting started

What does the current design and design look like? What works and what doesn’t? Identify the gaps.
Define some underlying design principles, which underpin a fluid and developing ‘design ecosystem’ (see Airbnb as a good example; Fig. 1 below).
Create a visual design language, which comprises a number of distinct but ever evolving components (I loved Adobe’s Nate Baldwin breakdown of some of these components; see Fig. 2 below). Common components of a visual design language are: colour, typography, iconography, imagery, illustrations, sizing and spacing.
Create a User Interface and pattern library.
Document what each component is and how to use it.

Fig. 1 – Airbnb design principles – Taken from: https://airbnb.design/building-a-visual-language/

Unified: Each piece is part of a greater whole and should contribute positively to the system at scale. There should be no isolated features or outliers.
Universal: Airbnb is used around the world by a wide global community. Our products and visual language should be welcoming and accessible.
Iconic: We’re focused when it comes to both design and functionality. Our work should speak boldly and clearly to this focus.
Conversational: Our use of motion breathes life into our products, and allows us to communicate with users in easily understood ways.

Fig. 2 – The foundation of creating a Visual Design Language by Nate Baldwin – Taken from: https://medium.com/thinking-design/what-is-a-design-language-really-cd1ef87be793

Clearly defined semantics (and no, “error”, “warning”, “success”, and “info” aren’t nearly enough)
Thorough and mature mapping of core elements of design with clear purposes and meanings
A solid family of UI components and patterns that effectively support the semantics, and use design elements (based on theirmeanings) to support the meaning of the components
Thorough, comprehensive documentation about the visual communication system

To make this a bit more concrete, I’ll look at three good examples of design systems, by Google, Bulb and Salesforce.

Google Material Design

Bulb

Salesforce Lightning Design System

Main learning point: It’s important for product managers to understand what a Design System is and the purposes it serves. Even if you’re not directly involved in creating or applying a Design System, it’s key to understand your company’s design language and how it applies to your product.

Related links for further learning:

App review: Forest

August 29, 2018 marcabrahamLeave a comment

My quick summary of Forest before using the app – I think I first heard Nir Eyal, who specialised in consumer psychology, talk about Forest. Given that Nir mentioned the app, I can imagine Forest impacts people behaviour, helping them achieve specific outcomes.

How does Forest explain itself in the first minute? – “Stay focused, be presented” is Forest’s strap line which I see first. This strap line is followed swiftly followed by a screen that says “Plant a Tree” and explains that “Whenever you want to focus on your work, plant trees.” This suggest to me that Forest is an app which aims to help people focus on their work and eradicate all kinds of distractions.

How does Forest work? – The app first explains its purpose in a number of nicely designed explanatory screens.

After clicking “Go”, I land on a screen where I can adjust time; presumably the time during which I want to focus and avoid any interruptions.

I set the time at 10 minutes and click “Plant”. I love how, as the time progresses, the messages at the top of the screen keep alternating, from “Don’t look at me!” to “Don’t look at me!” to “Hang in there!” Nice messages to help keep me focus and not fall prey to checking my phone. At any stage, I can opt to “Give up” which presumably means that the tree that I’ve been planting – through staying focused – will be killed.

I’m motivated to see this through and plant my first tree. When I complete my 10 minutes of uninterrupted time, I expect to see a nice tree right at the end of it. Try and imagine my disappointment when I don’t see a tree but instead am encouraged to create a Forest acount

Did Forest deliver on my expectations? – I can see how Forest helps people to focus and avoid checking their phone constantly. Just want to explore the gamification element of the app a bit more.

As I learn …

This site is about everything digital, giving an update on new things as I learn

Tag: UX

Review: Shift

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

HEART framework

Goals-Signals-Metrics process

My product management toolkit (34): product principles

“Values are like fingerprints. Nobodies are the same but you leave them all over everything you do.” Elvis Presley

My product management toolkit (33): launch and learn

Book review: “Autonomy”

What product managers can learn about Design Systems

App review: Forest