Successful products succeed uniquely but failed products all fail for the same reasons.
In this post I’ll describe the 5 most common product fails I’ve encountered and what I’ve learned to do when I see them coming.
When the Hollywood film is made about the Volkswagen emissions cheating scandal my bet is the story it will tell is one where the senior executives of the company made promises to investors that engineering could not keep. This is a classic version of the top down fail.
This root of this failure mode is a good idea, actually, a great idea. In fact, you cannot have a top down failure without first having an idea that is so brilliant, so simple, and so obviously true that it can’t be wrong — except that it is! …
Technical people monitor metrics — numbers that report change over time — to keep systems running smoothly. This is not news.
What is news is that as streams of data continue flow into and alter every aspect of modern life, UX designers are increasingly being asked to create experiences anyone can use to monitor systems they care about.
The framework is simple:
Yesterday evening I went for an urban hike in San Francisco.
I do that a lot, and have for years.
Yesterday’s hike was different. Really different. The trails, stairs, and open spaces I usually have nearly to myself were crowded like I have never seen them before.
Hikers, couples, families — everyone was out, walking, exercising, promenading. Social distancing was respected: family groups moved together maintaining space from other groups; teen-agers were shooting hoops, each player with his own ball. People in the sidewalk talked with people on balconies. Despite the unreal conditions people were sharing smiles, greetings, and an acknowledgement that we were all having the same upsetting, confusing experience. …
Awesome! Your timing is great. The employment picture is bright for folks who know how to create products for programmatic or declarative developers. Your first step is to develop empathy for these people by learning what it is like to spend your working life inside a computer.
Inside a computer is an odd place. Everything is literal, nothing is implied. A thousand words are worth more than a picture and being creative means following strict rules perfectly. …
In 2001 the fallout from the dot com bust was making it hard to find software development work anywhere in the Bay Area. I was out of work for seven months before a connection my father had made for me a few months earlier turned into a paying gig as Director of Design at Pharsight, a start up that developed statistical software for Big Pharma.
My father was a scientific advisor to Pharsight; in fact, the company’s science was entirely based on theory and methods he had invented as a professor at UCSF. This was nepotism of a fairly benign sort: I needed a job, Pharsight needed a designer, and my dad was thrilled for me to be learning the “family” business. …
By “works” I mean:
1. Build great products
2. Everyone involved has fun doing it.
How do you do this?
A partnership of business, design and engineering.
The partnership has 2 rules:
A partner can require either an outcome or a schedule from another partner. One or the other, never both at the same time.
A partner may not ever, under any circumstances, require a process of another partner.
The partners collaborate on the product like this:
Business owns the value model.
Design owns the interaction model.
Engineering owns the data model.
Everyone owns the object model.
(I explain these models in this post: Designing Digital Products with Mental Models.) …
In April 1992 I returned from living in Barcelona and got my first real job after design school with MenloCare, a medical products start up. My time there was effectively an apprenticeship that enabled me to grow from a green design grad to a (semi-)seasoned product designer. Among the many, many things I learned there, two stories from that time that I tell here became the basis for the ethical framework I have used to guide my career ever since.
At MenloCare, product designers also designed and built manufacturing equipment. My most complicated project was a pneumatically powered robot that, on the push of a button, executed a series of automated movements to assemble product. …
Years ago while traveling in India I bought an inexpensive English translation of Dostoevsky’s Crime and Punishment. I was excited to read this famous piece of Russian literature but after slogging my way through it, I was not impressed and couldn’t understand why it was so revered. The answer, it turned out, was that the words I had read did not convey Dostoevsky’s original meaning. I discovered this only when I got to Bangkok and tried to sell the book to a used book dealer who refused to buy because, as he told me, that translation was awful!
This anecdote highlights the challenge of translation: not only is it hard to do well, only an expert can tell when it is done badly. Developing digital products that automate tasks for people involves solving a very difficult version of this challenge. First there is the fundamental issue of translating an analog, observational understanding of human work into a digital representation that a computer can interpret. Second, there is the equally difficult problem of coming up with words to describe the analog-digital mapping that mean the same things to the engineers, designers, product managers on your team who each use different vocabularies to describe ideas. As the story above illustrates, preserving meaning through one layer of translation is hard enough, and digital product development requires getting past two! …
Here is an example.
I was negotiating a temporary contract with a unicorn and was asked to provide my hourly rate.
My gut feeling was I could ask $150 but I wasn’t sure. My negotiating strategy is to open at the top of a reasonable range, but I also know I have blown deals by opening too high. Actually losing a deal like this is mostly a problem at large companies where individuals have little room to negotiate. And this was a large unicorn.
I messengered two design manager buddies, both working at large organizations, what they thought I could charge. …