Many ideas fail because of poor design

Rob Go of NextView Ventures has a good blog post on how saying It’s been tried before is a bad excuse to dismiss a product or startup.

Rob says:

“I’ve said those words before as well, both directly to entrepreneurs as well as in our internal conversations about companies. But I’m convinced that “it’s been tried before” is a terrible way to dismiss a startup idea.

The reason is that this statement allows you to be way too intellectually lazy. It essentially says “I’m not going to think deeply about the challenges of the problem or proposed solution, I’m just going to assume it won’t work because others before it failed.”

Rob says that there are two reasons for not dismissing companies who are trying something that has been tried before:

  1. Technology changes. As technology improves at an amazing speed, so do our opportunities to use it to solve existing problems.
  2. Most companies fail as a rule. 90% of companies fail so you can’t dismiss a failure as a failure of the idea necessarily.

I’ll add another one to the list: Many ideas fail because of poor design.

Design is hard…designing a solution that fully realizes a great idea is incredibly hard. There are always constraints, always trade-offs, and choosing which ones to hold to is extremely difficult especially in the startup environment where you just don’t have a lot of time. You’ve got investors and friends urging you to go faster, you’ve got customers who are asking for the world, and you’ve got your own pressure to be a success as fast as possible.

But sometimes great design just takes time. Sometimes it takes looking at an existing market and redesigning it right. The entire Apple product line is a testament to this. MP3 players existed before the iPod. Mobile phones existed before the iPhone. And many digital watches existed before the iWatch. Apple is never first into a market, they are always late. They come in with great design and get an immediate foothold.

Apple is just one example. Look at Slack and the communications apps. Look at Instagram and picture sharing apps. Look at WhatsApp and texting apps. Look at Sketch and the UI design apps. Look at Evernote and note-taking apps. Look at Dropbox and backup apps. Etc… All of these categories are littered with failed startups who created clunky, poorly designed user experiences while working on what turned out to be good ideas.

Apple is different of course because they have time on their side…they can R&D as long as they want to be sure that their product is amazing at launch. This is the greatest benefit of having so much money in the bank…they can release products on their own schedule.

The big challenge for startups is time. Startups do not have the luxury of lots of time and are under extreme pressure to make something work quickly. That’s why so much discussion about product development is about learning from customers and not wasting time marketing until you have product market fit…because until you do it means that your design is failing…even if you have a great idea.

Three important points about listening to your customers

Great list by Braden Kowitz on why you should listen to your customers:

Several important points:

1) People love to say they talk to customers but rarely do. And some people talk to a couple customers, feel good about it, and assume their job is done. But the fact is that you have to go after feedback with a club. How do you know if you’re talking to your customers enough? Easy: You’re not surprised by what they say anymore.

2) Hiring a designer will not make you a design-first company. I’ve known lots of business owners who want to “get some design in here” by hiring a designer. This almost never works because that owner isn’t thinking about design in the right way. Being a design-first company means to actually change the process of product design to one that starts with users actual goals or a known problem and working outward. If you are hitting a wall and hoping a designer can get you out of it, it’s probably not going to work without a fundamental change to your product development process.

3) Customer research will actually speed you up. This is the most counter-intuitive one but is also true and probably the most important point Braden makes. Doing customer research seems like it will slow you down because it doesn’t feel forward-moving. You’re not actually building anything yet. But if you think about it as learning what to build then you can see how valuable it is.

Tips for doing Lean Research

A nice set of notes here: The Right Way to Do Lean Research, curated from a discussion panel of several folks who really know their stuff: Christina Wodtke, Laura Klein, Todd Zaki-Warfel, and Mike Long.

  • Right questions: Ask the right questions and save a tremendous amount of time by knowing what you want to learn before doing research.
  • Right people: Talk to the right people about your product: the people would actually pay for it.
  • Right test: The research method you choose depends on what you want to learn and where you are in the product development process.
  • Right place: You try to put yourself in the right place to do the best research on the budget you have…whether you’re in or out of the office.
  • Right attitude: Having the right attitude when doing research is extremely important…are you really in a listening mode or are you selling?
  • Right documentation: Doing a bunch of research is valuable but you can quickly lose important insights if you don’t record everything well.

How architecture can inform UI design

It is said that all designers wished they were architects…or something like that. Over at the Percolate blog former architect Melissa Mandelbaum has written
Applying Architecture to Product Design: Lesson 1 in which she points out the architectural principle of circulation is pretty much the same thing as navigation in UI design. Mandelbaum writes:

“The circulation of buildings not only affects your perception of them, but also your usage and behavior within them. Continuing the apartment example, stairs would likely lead you to go home less frequently than you would if you had an elevator in the building. The presence of an elevator would likely lead you to carry home bigger, heavier items. The lesson learned is that we make a lot of choices based on available circulation systems.”

I think about the commonalities between virtual and physical spaces and the movement between them a lot. One of the big differences is that in virtual space we conceptually move around (as opposed to physically move around). So when a user moves we as designers need to change the conceptual space, so to speak, so that it’s clear they’ve changed “places”. Tabs for navigation often do this well, but sometimes they don’t work in cases like when someone wants to deep link within one tab to another.

And often times it’s enough to use copywriting to do the conceptual change, like when you change nouns and verb tense to suggest that something has happened. In this way UI elements are doing the same thing as physical elements of design…opening passageways, blocking people, suggesting routes, slowing and speeding people up, etc. It’s a never ending problem that I find fascinating. I’m looking forward to the other installments of Mandelbaum’s series.

Why Apple doesn’t do MVPs

The Biggest Lesson I Learned as an Apple Designer is a thoughtful piece that pushes back on the standard advice given out today of creating an MVP (minimum viable product) and learning as you go. It comes from a former Apple designer, Mark Kawano (who also wrote about Apple’s design culture), and suggests that MVPs just don’t make sense within the Apple process. Instead of “launching and learning”, Apple waits until their products are much more mature and offer a more complete experience:

“Waiting to launch a product until its “magical” moment goes against the concept of MVP, or minimum viable product, which has become so trendy in business over the past few years. It’s part of the lean startup mentality that became mainstream with Eric Ries’s best-selling book, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

The idea goes something like this: Build a product to the point at which it’s good enough, launch it quickly into the marketplace, and then make iterations as you go while learning from your customers.

Though there is wisdom in Ries’s ideas, entrepreneurs need to be very careful in their interpretation of what a minimum viable product actually is. If you’re launching something in a space where there are a lot of people trying to do something similar–for example, a consumer product–then the bar for MVP should be ridiculously high.

I think the pendulum has swung too far toward the “launch to learn” end of the spectrum of product releases. You can and should learn a lot before you launch. Frankly, many of the pieces of software that I love best have not been built in a launch and learn environment and instead were refined internally by a thoughtful and critical team of designers. That’s not to say that the products aren’t iterated on, all products are, but they aren’t iterated and released continuously in public for the means of “learning”.

Now I’m sure you’re thinking “but Apple is Apple and nobody else is”. Yes, that’s true, but consider that this is just another process, albeit a different one. At Apple they have internal checks-and-balances about when to launch a product or not, and it stands in stark contrast to the lean approach. That’s what I find interesting here, and I think there are merits to both processes.

At the very least, the definition of “viable” should change depending on the maturity of competing software.

Secret, you keep using that word…

After calling the app “Secret”, letting everyone who uses it think it’s secret, the founder of Secret now acknowledges that the information you submit is not, in fact, secret:

“The thing we try to help people acknowledge is that anonymous doesn’t mean untraceable,” David Byttow, chief executive and co-founder of the Secret, told Wired in an interview this week. “We do not say that you will be completely safe at all times and be completely anonymous.”

I used Secret for a day, submitted one “secret”, realized it’s not good mojo and then assumed that in fact everything was traceable like everything else that’s digital, and so “deleted” my account. Who knows if it was really deleted.

Make no mistake…Secret is one of the darkest of the dark patterns.

Is your product a Hafta or Wanna?

In his insightful article, Why Behavior Change Apps Don’t Work, Nir Eyal brings up a crucial point about the habits we form (or fail to form) around the products we use.

“Unfortunately, too many well-intentioned products fail because they feel like “haftas,” things people are obligated to do, as opposed to things they “wanna” do. Schell points to neuroscience research showing “there are different channels in the brain for seeking positive consequences and avoiding negative consequences.”

When faced with “haftas,” our brains register them as punishments so we take shortcuts, cheat, skip-out, or in the case of many apps or websites, uninstall them or click away in order to escape the discomfort of feeling controlled.

I think this explains a lot about products in general, and specifically why app categories like todo list apps mostly go unused…they inevitably end up feeling like “haftas”. I distinctly remember that feeling the first time I used a todo list (Remember the Milk) that carried over undone todo items from one day to the next. At first it seems like a thoughtful touch…to automatically bring items from one day to the next. But after a day or two it becomes a burden…your list grows and grows because other tasks inevitably crop up during the day. It quickly became a management situation…I had to manage my todos rather than just keeping light track of them. It turned my todo list from a wanna to a hafta.

Note that any product person would love their product to become a “hafta”. That’s the lock-in you want…that your product is so valuable that it becomes something that people feel like they have to use to be successful. That’s why this is counter-intuitive and important. You want the product to be a “hafta” but feel like a “wanna”…to have your product be essential to their daily use while following the important design principle: keeping people in control.

Nir sums this up nicely:

“When our autonomy is threatened, we feel constrained by our lack of choices and often rebel against doing the new behavior. Psychologists call this “reactance.””

So people don’t resist a new behavior just because it’s hard to do (in fact new behaviors are often easy to do) It may be more about autonomy…by forcing a new behavior on people we suggest to them that they have less control over the situation than they had previously, creating a “hafta” situation where there was none previously.

Read the whole thing: Why Behavior Change Apps Don’t Work

Go after feedback with a club

Jack London, the author of The Call of the Wild, was talking about writing when he said “You can’t wait for inspiration. You have to go after it with a club.”

The product design equivalent is:

You can’t wait for feedback. You have to go after it with a club.

If you’re waiting for feedback, you’re only going to get 5% of it…as only a tiny proportion of people reach out unsolicited. It’s the hard conversations you need to have…like with your friends who don’t want to tell you the truth, that you need to hear.

Example: recently I was talking with a friend about how they use What to Wear and it occurred to me that her use had actually fallen off and so I asked why. Her response was interesting…something I could immediately fix (and subsequently did fix). I asked why she didn’t tell me and she said “I didn’t want to make you mad”.

Wow…I was floored. I couldn’t believe my friend had suppressed the most important feedback I needed to hear just so she wouldn’t hurt my feelings. I told her that I was actually more upset she didn’t tell me and that I want more than anything real, honest feedback about what’s working and what isn’t working. I can fix anything that’s wrong with the product…but I need to know about it! So that was an extremely important lesson for me to learn…I’ve got to go after feedback with a club.

Customer research = secrets?

An interesting article by Vinicius Vacanti, founder/CEO of Yipit: The Secrets Behind Many Successful Startups. In 2010 Yipit knew a secret about what was happening in the daily deals marketplace (that daily deals were exploding) and they were able to take advantage of it by creating a daily deals aggregator.

What struck me about the post, however, was that the other “secrets” weren’t really secrets at all. They were simply observations about customer behavior that signaled what people were interested in. The observation that people like sharing photos was the turning point for Burbn (now Instagram). The observation that people liked seeing what they were up to years ago was a turning point for Timehop. In the case of BlueApron, the team found out that there was already a solution people were using successfully:

“They started thinking about the food space and an interesting product idea that would deliver to people three great recipes and all the ingredients needed to cook the meals. Upon doing research, the secret they learned is that there was a company in Sweden that had been doing something similar since 2007 and had been extremely successful. That certainly gave them and investors confidence to pursue the idea here in the US which they called BlueApron.”

These observations (about both product and market) are what anybody doing any amount of product design should be able to find out. And pretty easily. I think the lesson here is that as a product designer you need to be observing and talking to your users enough to notice these things…and familiar enough with the market to know what’s going on there. Sure it may be a secret because other people don’t know…but from the standpoint of product research anybody in those spaces should be able to find them out with plain ol’ research.

We need to demystify user research. It’s not black magic…it’s really just talking to people.

Browse Archives