Menu

Posts tagged “product management”

Netflix and the problem with established interface mental models

There were some interesting Netflix articles over the past week or so. First, Nathan McAlone writes that Netflix wants to ditch 5-star ratings:

The problem, [CPO Neil] Hunt tells Business Insider, is that people subconsciously try to be critics. When they rate a movie or show from one to five stars, they fall into trying to objectively assess the “quality,” instead of basing the stars on how much “enjoyment” they got out of it.

Here’s an example. Let’s say you had fun watching a crappy movie, but still gave it a two-star rating because you know it’s not a “good” film. That presents Netflix with a problem. The system thinks you hated the movie.

I think embarrassment plays a part in this as well. Even when ratings are private, we’re worried that word might get out. For example, I’d be happy if all my Netflix recommendations consist of “Movies similar to Battleship”, but I certainly don’t want any of you to know how much I liked that terrible movie.

Related to this, McAlone also wrote about Netflix’s most important metric:

That means that the most important economic metric for Netflix is how much a TV show or movie contributes to Netflix’s ability to sign up and retain customers.

The problem is that the current star rating system doesn’t give them that metric because it’s associated with “quality”, not “enjoyment”. So I might rate Out of Africa 5 stars because I objective know it’s a good movie, but if Netflix starts recommending “Boring movies with Meryl Streep” to me, I’m out of there.

Netflix has a very difficult product design challenge ahead of them. They have to change an established user mental model (“stars=quality”) to something different (“tell us what you enjoy watching”) that will help them provide a better and more compelling service.

Why projects fail if they neglect research

Erika Hall’s The Secret Cost of Research is a great explanation of why research is essential for products to succeed:

The reason design projects that neglect research fail isn’t because of a lack of knowledge. It’s because of a lack of shared knowledge. Creating something of any complexity generally requires several different people with different backgrounds and different priorities to collaborate on a goal. If you don’t go through an initial research process with your team, if you just get down to designing without examining your assumptions, you may think your individual views line up much more than they do. Poorly distributed knowledge is barely more useful than no knowledge at all.

I can definitely attest to this. It’s exactly why I’m such a big fan of Product Discovery:

This phase always—without fail—produces insights the team finds incredibly valuable. Startups gain clarity about what to say “yes” and “no” to in their product, and large corporations learn how to go beyond customer-centricity buzzwords and discover which benefits they should be selling to their users. As just one of many examples, I was once in a workshop that revealed the executives had a completely different vision for the company than the designers and developers. It was an awkward two hours, but in the end they agreed on the tough but correct decision to suspend their e-commerce plans until some of the content areas on the site had been sorted out. It’s great to see a statement of purpose emerge from these sessions—one that finally gets an organization to agree on what the product’s focus should be.

It’s pretty remarkable how different people’s visions for a product can be, especially since there’s such a simple two-step program to fix that:

  1. Understand user needs and business goals.
  2. Talk about it, together.

The real purpose of a Minimum Viable Product

In Jim Brikman’s post A Minimum Viable Product Is Not a Product, It’s a Process he explains the real purpose of following an MVP approach:

An MVP is a process that you repeat over and over again: Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct.

When you build a product, you make many assumptions. You assume you know what users are looking for, how the design should work, what marketing strategy to use, what architecture will work most efficiently, which monetization strategy will make it sustainable, and which laws and regulations you have to comply with. No matter how good you are, some of your assumptions will be wrong. The problem is, you don’t know which ones.

And the crux:

The only way to find that out—the only way to test your assumptions—is to put your product in front of real users as quickly as possible. And when you do, you will often find that you have to go back to the drawing board. In fact, you’ll have to go back to the drawing board not just once, but over and over again.

This is one of the major problems with MVP-thinking as I see it in many organizations today. For many product managers MVP is unfortunately not a learning process, but just a fancy way of saying “v1”. And as we all know, the biggest lie in the enterprise world is “v1”. There’s never a v2. So many hide behind the “MVP” moniker to obscure the fact that they just want to get a thing out the door and move on. We’d do well to remind our teams that the real purpose of an MVP is to learn, not to complete.

The product forces that keep people on Facebook

Ben Thompson wrote a characteristically astute analysis of How Facebook Squashed Twitter. The whole essay is worth reading, but it’s this part in particular that stood out for me:

Facebook has developed its own interest graph that is far more powerful and effective and easier-to-use than Twitter’s ever was. Yes, Twitter still owns niches like NBA Twitter, and news hounds like myself (and most of you reading this article) will continue to find it essential, but for nearly everyone else in the world it is Facebook that is the first thing people check, not just in the morning but in all of the empty spaces of their lives. In short, it’s not simply that Twitter needs to convince users to give the service a second-chance, something that is already far more difficult than getting users to sign up for the first time; it’s that even if the service magically had the perfect on-boarding experience leading to the perfect algorithmically-driven feed, it’s not clear why the users it needs would bother looking up from their Facebook feeds.

This is a perfect example of The forces at work when choosing a product. In short, the progress-making forces that might push people from Facebook to Twitter are not nearly as strong as the progress-hindering forces that keep them on happily on the “good enough” that is Facebook.

Don't clean your ears

Did you know that you’re absolutely, positively, not allowed to use Q-tips to clean your ears? Not only that, but you’re not even supposed to clean your ears at all. From Roberto A. Ferdman more-fascinating-than-it-should-be The strange life of Q-tips, the most bizarre thing people buy:

“People have been led to think that it’s normal to clean their ears — they think that ear wax is dirty, that it’s gross or unnecessary,” [Dennis Fitzgerald, an otolaryngologist in Washington, D.C.] said. “But that’s not true at all.”

Fitzgerald likens ear wax to tears, which help lubricate and protect our eyeballs. Wax, he says, does something similar for the ear canal, where the skin is thin and fragile and highly susceptible to infection.

“Your body produces it [ear wax] to protect the ear canal,” Fitzgerald said. “What you’re taking out is supposed to be in there. There’s a natural migration that carries the wax out when left alone.”

Even if our ears were meant to be cleaned, the truth is that Q-tips would still be a terrible thing to use, he says. The shape, size, and texture of cotton swabs is such that inserting them into your ears tends to push wax inward, toward your ear drum, rather than woo it out.

The article explains a true marvel of product design: perhaps the only “major consumer product whose main purpose is precisely the one the manufacturer explicitly warns against.” It’s so interesting how it took the manufacturer decades to start warning against this behavior on the packaging.

How to deal with difficult stakeholders

Daniel Zacarias has some tips for How to Deal with “Sinatra” Stakeholders—those people (usually HiPPOs1) who only want to design and build things their way. At the end he makes an important point:

These stakeholder attitudes don’t come out of the blue or from malfeasance. They result from misalignment and even when you can’t change your entire organization, you can definitely affect change around your product.

This is something I constantly have to remind myself about. If someone isn’t buying into our vision or “getting” the design, it’s not their fault. It’s ours. It is our responsibility to bring people along on the journey. We can’t blame them if they come into a project context-less and then ask difficult questions.


  1. Highest Paid Person’s Opinion 

Using ethnography to build better products

Craig Mod’s essay on doing design ethnography in Myanmar is so far my favorite piece of writing of the year. In The Facebook-Loving Farmers of Myanmar he shares some notes about the team’s visits and interviews:

There is a phrase repeated over and over again during my time in Myanmar: From no power to solar, from no banks to digital currencies, from no computers and no internet to capable smartphones with fast 3G connections. It is the mantra of consultants working in these emergent economies. And these emergent economies have one colossal advantage over the entrenched and techno-gluttonous west: There is little incumbency.

There is, however, instability—in government and currency. It’s one of the reasons why a country like Myanmar is just now getting these connections, these devices. The instability significantly increases risk for outside investors and companies. But the residual effect of that instability is a lack of incumbency and traditional infrastructure. And so there is no incumbent electric giant monopolizing rural areas to fight against solar, there is no incumbent bank which will lobby against bitcoin, there are no expectations about how a computer should work, how a digital book should feel. There is only hunger and curiosity. And so there is a wild and distinct freedom to the feeling of working in places like this. It is what intoxicates these consultants. You have seen and lived within a future, and believe—must believe—you can help bring some better version of it to light here. A place like Myanmar is a wireless mulligan. A chance to get things right in a way that we couldn’t or can’t now in our incumbent laden latticeworks back home.

It’s a long article, and it should be. There’s so much insight here, just from spending a few days with people observing, listening, understanding. I don’t understand why this truth is so hard for some product leaders to understand:

A common mistake in building products is to base them on assumptions around how a technology might be adopted. The goal of in-field interviewing in design ethnography is to undermine these assumptions, to be able to design tools and products aligned with actual observed use cases and needs.

Just imagine how different the world would be—and what incredible products we’d be able to build—if we always took the time to understand users and their needs in this way first.

The convergence of Product Management and User Experience Design

Melissa Perri in Changing the Conversation about Product Management vs. UX:

Product Management with no User Experience Design creates functional products that don’t make users excited. User Experience Design with no Product Management produces delightful products that don’t become businesses.

I have a few quibbles with this article (including the idea that the role of UX is to make users excited…), but I like this quote because it ties in with a common theme I write about: the importance of combining both user needs with business goals to create successful products.

The handicap of big product teams

Most businesses don’t admit how costly things like company wide announcements, project management, interviewing, internal politics, and large scale collaboration are on productivity. They all work against flow, and should be considered a handicap on product teams. Small teams substitute process with trust, eliminating overhead.

— Kyle Neath, Million Dollar Products

Utility is more important than usability

I’ve long held Jakob Nielsen’s Useful = usability + utility formula in high regard. The Introduction to Usability article it comes from is still one of the best intros to user experience I’ve seen. That said, I’ve recently started to wonder about the ideal ratios on the right side of the equation. What combination of usability and utility results in the most useful product? Is it a 50/50 split? 70% usability, 30% utility? It’s a purely academic exercise because there’s no way to prove any of it, but it did lead me to a theory:

I believe that utility (whether a product provides the features users need) is initially more important than usability (how easy & pleasant these features are to use) in product design.

Let me say right up front that I’m not saying usability isn’t important. I’m just saying that when it comes to a product being used extensively (and payed for) by users, it is more important to get the utility right from the start. Users will struggle through bad usability (up to a point), but they won’t use a wonderfully usable product that doesn’t serve a real need (see Path).

I’ll give two personal examples to back up this view1. My favorite social network at the moment is Goodreads. The site is slow, the UI is confusing, and the mobile apps make me feel completely lost, and yet I keep coming back to it. Because Goodreads is extremely good at what it does: helping me find books I’d enjoy, and letting me share good books with friends.

Goodreads

The second example is Pinboard. If I could take only one website with me to a deserted island it would be Pinboard. I use it more than any other online service. It helps me save, categorize, and find all the useful articles I’ve read over the 5 years I’ve been using it. The UI has tons of little weird quirks, and it’s very much barebones. But that doesn’t matter. It’s indispensable to me, so I care very little about its usability.

Pinboard

These two examples lead me to a second theory:

The more utility a product has, the less its usability matters.

I like Goodreads, but at some point if the usability becomes too frustrating, I’ll just leave. For Pinboard, on the other hand, I’ll walk through usability hell and back just to keep using it. It’s that essential to my work.

I’ve said this a few times in this article, but let me reiterate: I’m not, for a second, saying that usability isn’t important. I’m proposing that if you have a product that has insane levels of utility, its usability becomes a secondary factor in its success. To put it another way, the ROI on increasing utility is probably much higher than the ROI on improving usability.

The moral of the story is this: first find an idea that people can’t live without, then make it a beautiful, usable product. It’s very difficult to do it the other way around.


If you liked this article, you can sign up to get an email every Friday with all new posts that appeared on the site that week. You can, of course, unsubscribe at any time.

#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */


  1. That’s how science works, right?