Uber tipping and the dangers of competing against creepy
Frictionless surfaces don’t actually exists
As we go about our day we hit moments of friction. Sometimes this friction is really useful and sometimes it’s not. Sometimes the friction in our lives snaps us out of our routine and helps us become aware of needed nuance and other times friction snaps us out of our routines and requires us to choose something we thought we already decided.
When we build products it is beguiling to think that we will make a frictionless experience where once there was only headache and pain. We envision the iPhone 3, with it’s perfect fit in our hand, as the experience cousin of what we’re building. However, appropriate application of friction in a user’s experience is often the difference between a horrible product and an amazing product.
For my part, I can say that my instincts on where to apply friction in a product are so consistently wrong it’s actually useful to write down the experience I think should happen and then try and do the opposite.
I don’t think I’m that abnormal. When we build a product we revisit the same processes and experiences so many times we don’t even realize that we are not only missing the forest for the trees but the trees for the pine-needles strewn along our path. I think it’s actually very difficult to pinpoint exactly where to allow the user to experience friction and how that friction should manifest.
I’m trying to nail down a way to hold myself accountable for the design choices I’m making. In our little startup we don’t have resources or time to be fumbling through the dark one tiny iteration at a time hoping we’ll stumble into the optimal product by iteration 1,000. Unlike the deep-learning models at the core of our product we can’t task a GPU to exhaust millions of cycles looking for a brute-force solution to our problem. Like most product teams we have to guess and we’d better guess right or someone else will beat us to it.
For me having a framework and/or assessment I can hold up to what I’m working on is super helpful because it gets me out of my head and out of my felt experience (i.e. examining pine-needles along the path) and back to something like the reality users will experience when working with what I’ve built. And yes, of course we have to test what we’re working on with users but even deciding what to put in front of users to test could exhaust all our time and resources.
Here are the two dimensions of product development that plague me the most:
- In designing a product to complete a task I forget that my users may be “hiring” my product to complete a job only tangentially related to the task it completes. Misunderstanding the job they’re hiring it to do often means misapplying friction throughout the process of completing a task.
- At the center of all software products (i.e. my reality) is some form of automation and automation is very hard to do right.
I found a really useful framework to suss out the job a user is hiring my product to do but I’m still at a loss as to how to crack the problems with automation.
What is my product being hired to do?
I’ve been taught by and hopefully learned a little bit from Chris Spiek and Bob Moesta about how to identify the jobs my users are hiring my product to do. Their work is amazing. Their work has been cited by Clayton Christensen as being at the root of the most important question he has looked into throughout his career. “Innovator’s Dilemma” is actually the “easy” problem of understanding which business strategies will succeed when it comes to understanding innovation in the marketplace — he really wanted to understand which products would succeed but couldn’t get the data.
If you’ve not looked into Chris & Bob’s jobs-to-be-done framework and you’re building a product then you’re likely signing-up to build your whole product many multiples of times before getting it right — assuming you have the runway to do so. This usually just means you have to be lucky. Good luck!
Don’t want to trust luck? Check out Chris & Bob’s work: jobstobedone.org.
What about automation?
At the center of all great software and tech products is some form of automation and like most things it manifests on a spectrum. At one end of the spectrum are codified processes that should never deviate from expected or directed norms (e.g. “exceeding the maximum dosage will cause brain-damage and may result in death”) and at the other end there’s more of a general sense of what’s expected but room for novelty and even room for multiple right answers (e.g. using Waze to plot my commute home and saving me 12 minutes that I would otherwise have spent in stand-still traffic).
I want a framework for understanding automation that is a little more actionable than things like Uncanny Valley which exist in the same place as The United States Supreme Court’s framework for identifying porn:
“… I’ll know it when I see it… ”
— Stewart Potter United States Supreme Court Justice
I think we can start with “I’ll know it when I see it” or rather end with it but for ideas I’m considering today and tomorrow and in-between tests I need a framework with some nuance.
Uber & Tipping
Regardless of what you may feel about the news that Uber added tipping to their app there is no disputing that in so doing they added friction to the user experience. Building great products is very hard but I think instrumenting social change for the better might actually be harder. So let’s put aside the social good arguments and just focus on this additional friction from a user experience perspective.
I think from a product perspective this was a bad move. It might be a necessary move given the optics surrounding Uber in 2017 but this decision was unlikely made because the overwhelming majority of users were clamoring for one more decision to make when hailing a ride.
Uber, taxis, and even cars are first and foremost are a means of getting from here to there. You nail that task and you’re in the running for building a successful service. Looking at it through Jobs-to-be-done it becomes readily apparent that while a lot of products and services exist that get you from Point A to Point B: cars, taxis, public transportation, planes, legs, scooters, etc., etc. there’s more to it than just transporting your body. The job you hire Uber to do is much different than the job you hire Delta to do and it’s quite different from the job you hire Ford or Tesla to do.
I think Jobs-to-be-done might actually be able to suss out all the nuance needed to understand why adding tipping will entice some to use Uber and turn others off of the service but I really want to dig into the “Push” and “Anxiety” elements of that framework as it pertains to a mediated experience like software or an app.
When I consider those two dimensions: “Push” and “Anxiety” my mind can’t help but immediately jump to my own work in machine learning and automation where good ideas are shot down because they are too “black boxy” or “seem like magic… but not in a good way”.
What I’m getting at is that something happens to a service when it goes from competing with commuter light-rail to also playing in the same place as diner wait staff. I’ll grant you that tipping a taxi driver is an acceptable enough practice and it’s an option in the competing service Lyft so what Uber’s doing is not earth-shattering. It should, however, give anyone curious about product evolution reason to pause and really understand what’s the impact of what they’ve done.
The job of transporting your body needs to be done safely and reliably and Uber does a better job delivering on the promise of safe and reliable than taxis because it has commoditized trust. Taxis have a reputation for being unreliable (i.e. on-time and available anywhere) even if they are considered safe enough and they are unlikely to become more reliable compared with Uber and the like since ride-share services leverage shared data across the globe to ensure reliability. Taxis are luck-of-the-draw when it comes to reliability of any given taxi-driver.
So here’s how I see it. I believe we can understand quite a bit about product and service successes and failures through the lens of automation. When a product does a job that has to be safe and reliable it’s often because the alternatives are potentially very dangerous, even lethal. On a scale of 1–10 how murdery to do consider an Uber-driver/rider vs. stranger/hitch-hiker?
There’s a power law on that 1–10. I’m looking for a sub 2 maybe even a sub 1.5 in my transportation interactions. When a product or service only has to be helpful (e.g. “Siri what’s the weather like today?”) and it fails it’s just annoying (e.g. Siri: “I’m sorry I didn’t understand you.”). I want a framework that really makes me grapple with the reality that a task exists simultaneously on a continuum of predictability of outcomes and one of unintended and intended consequences.
The diagram at the beginning of this post is my first attempt at capturing those simultaneous tensions.
It’s a sketch of an idea right now but I believe there’s important understanding that can benefit product development from developing a theory about automation.
Uber adding tipping takes a high-stakes but highly predictable activity — having someone drive you from Point A to Point B — and introduces a complicating dimension that attempts to quantify the Pleasantness of the experience. Giving a driver “stars” was really about reliability of the experience — the assumption is that no rating is good and a high rating is also good but a low rating is really bad. A driver that provides snacks or mints may not elicit a rating from me because the safe assumption when lethality is on the line is: “no news is good news”. I can hire a convenience store to provide me with mints and I hired the driver for reliability — no amount of mints is going to make up for failing at reliability.
So, Uber or anyone delivering us to our destination in a timely fashion succeeds at Safe & Reliable. Yes, not getting there is catastrophic but there are a lot of options we can hire to do this job and most of them do that job with the same level of safety and about equal reliability so the economics of the situation dictate that you can’t make a grundle of money getting people to and from a bar.
What’s interesting to consider is that by adding a dimension that quantifies “Pleasantness” I have to also have to deal with the option that things will get “Creepy” — am I a creep for not tipping the driver? The driver is definitely acting creepy if they keep the doors locked and hold out an expectant hand. Suddenly, with the addition of tipping I’ve added tension to an equation with a ton of competing alternatives. How will this pan out for Uber? Time will tell but it’s opening up Uber to a lot more competition than it’s shutting down.
A good framework gets me to ask better questions about what I’m working on. Hopefully, the points of potential struggle that surface as the predictability of a task decreases help you to ask better questions about your product and to make more informed decisions.
- Do you want to compete against “Creepy”?
- How about “Counterfeit”?
- Do you really want to put yourself in the position to defend against both
- Can you make small adjustments to your product strategy that essentially eliminate annoyance?
I’m sure your attorney would love for you to take on Lethality — they’ll be set for the year if you fail on that dimension.
If Disruption Theory predicts that cheaper simpler products will eventually displace expensive complex ones then Automation Theory predicts that process automation by machines will first displace industries where humans are relied upon for safety and reliability before displacing labor focused on pleasant user experiences because the former co-occurs with predictable task outcomes and the later with less predictable outcomes.
This might strike you as counter-intuitive given that the price of getting Safe & Reliable wrong is so high but consider that those same areas are where alternatives have already figured that out at scale. While arenas where Helpful is being performed by humans (i.e. administrative assistant or software developer) still struggle to source enough competent laborers.
I’ll keep working on this. Let me know if it helps and definitely let me know where it falls short.
