How to keep customer feedback from destroying your startup

You’ve launched your product. You’re getting some adoption. People seem to like it. You start to get some feedback. TechCrunch does a write up on your site. You get lots more feedback.

Sounds great, right? In many ways, yes. But feedback can destroy your company, if you let it causes you to thrash in what you are doing.

Your earliest adopters tend to be the most geeky, the techies who probably don’t represent your target customers. (Unless your target customer is techies.) The feedback they give you isn’t going to matter to the general market.

I heard Stewart Butterfield, the founder of flickr, talk about this early on. Some of his users wanted that ability to geotag photos by uploading tracklogs from Garmin hiking GPSes and syncing their timestamps with the timestamps on their pictures. Great idea. I loved it and would’ve used it. But me and 10 other people. It turned out not to be necessary in the long term because cell phones (which are the source of the vast majority of pictures online) automatically embed GPS information.

In the short term, geeks like me found tools like GeoSetter and iTag to embed GPS date into EXIF fields on photos.

There are a few other problems with customer feedback:

  • It’s not prioritized, even by the person giving feedback. Generally they don’t tell you whether it’s really important to them or just an “it would be nice.” Would it affect their likelihood of sticking around? Would they pay more for your service? Would it help you get the word out to more people? Who knows? Most feedback doesn’t come with that level of detail.
  • You don’t know who they are how they use the product. Without understanding the customer’s persona, feedback is less valuable.
  • It’s rarely the case that more small features will make or break your product. There are rapidly diminishing returns on many features. In a lot of cases, there are negative returns.
  • They are unlikely to know what your business model and goals are.

In order to make the most of the feedback you get, you need to organize it. See how much of a certain type of feedback you get. Group similar feedback. Have your product and business teams decide where it falls within the business goals.

This is especially true of business-to-business companies. You’re having one-on-one interactions with the buyer. He’s giving you some interesting ideas. Sales tells you that if you had “one more feature,” they’d close the deal.

Wait. When there are a small number of big customers, you risk becoming a captive development arm. You¬†definitely¬†don’t want to be that. It makes it easy to lose track of your other customers. If your product becomes too specialized for a specific customer, it can hurt your valuation.

You want to take in feedback and harmonize it with feedback you get from other customers and potential customers.

It can be hard when you’re working closely with someone to say “no.” Your sales team might keep nagging you for that feature. (In a future post, I’ll discuss how to deputize your sales team and sales engineers into mini product managers.)

Stay strong. Make sure what you’re doing aligns with your roadmap and will appeal to other customers.

There are somethings early customers will ask for that are no-brainers. Examples are GDPR compliance and SSO. You don’t have to do these right away, but be sure to have an answer prepared on how you will solve these problems.

Yesterday, I sent some feedback to the CEO of a company I’m looking to invest in. It’s an incredible feature. I know it will help them sell to new customers. Of course he should take my feedback: I’m a potential investor, reasonably well-known writer, have decades of product experience and I run UX quizzes on Twitter that people seem to value.

His response?

Sounds like a good idea.

That’s something that we can think about adding to the system. Thanks for the feedback.
That’s exactly the right response. It increases the likelihood that I will invest.

A startup’s guide to doing research on the cheap – usability testing

User research is an important part of the product design process. It can help you make sure you’re building the right thing for the right people and to continue to learn from what you’ve built.

I divide companies into two types: those that are driven by users and those driven by features. User-driven companies pay intense attention to the needs of their users and build products for them. Feature-driven companies focus on what they can do with technology and build those products. You don’t want to be the second.

Needs can be expressed or unexpressed. Some needs that users express may actually be counter to what they want. Important needs may go unexpressed because users don’t know exactly how to express what they want, or the research tools are poor.

There are many types of tools that you can use for research: usability testing, focus groups, ideation sessions, ethnographic research, user feedback, survey research, eye tracking, etc. Too often product managers confuse the roles of these tools and end up with bad interpretations.

Research can cost from nearly nothing to tens of thousands of dollars. In this series, I’ll go through research tools I think provide the biggest bang for the buck for startups.

Today’s topic: usability testing.

You need to assess whether people can understand what your product will do. Ideally, you’d do this shortly after the user flows have been built. Bring people in 1 by 1 and watch them accomplish a series of key tasks. Have the designer and product manager sit with the interview subject.

I like to just give the subject a task and see what happens. (After all, no one is going to be sitting with them while they are actually using the product.) “Order a large pepperoni-mushroom pizza and have it delivered to your house.” Then watch as he goes through the user flow. Have the interview subject articulate their thought process as they perform the task. Where did his eye go first? What was the overall flow?

Only when the subject gets stuck should the interviewer intervene. “Where did you expect to find it?” “Maybe try scrolling further down the page?”

Although ordering a pizza is a relatively simple task, there are a number of steps: finding the restaurant nearest your house, selecting your pizza, adding toppings, special instructions, delivery information, payment, etc.

Some people like to do the testing one step of the process at a time. I prefer to do it all in one pass. There are two primary reasons:

  • Time to completion is a key part of user success. If you stop the subject at every step, you aren’t going to be get a sense of how long he would have taken with your user interface. If it would have taken him 10 minutes to order a pizza, your interface has failed.
  • You get a sense of what other flows the user might see. That’s not necessarily a bad thing, but it’s important to get that sense.

Once the first pass is done, you can repeat the test step-by-test and ask for detail on what was confusing or not.

Usability testing can be done with static images linked together, but I really prefer doing it with live or close to live code.

You can also test a couple of different flows.

It’s important that the subject is told at the outset that he is not the one being tested; it is the user interface that’s being tested. There is no right or wrong answer.

Whom you choose to participate is key. On HBO’s Silicon Valley, the initial response to the compression tool was amazement. All of their friends loved it. Except for Monica, who hated it. Then, we saw the user interface:

0

The people who loved it, the initial test group, were friends of engineers who were also engineers. They loved this type of interface because it gave them control over every little detail of the compression. Most users don’t want this.

You want to get people who don’t do tech for a living, if at all possible. You want to get people who are as close to your target audience as possible. If your product is designed to be used by senior citizens, don’t have millennials do the testing. (In this example, you’ll miss things like font sizes.)

Usability testing doesn’t need to be a formal process and doesn’t require special equipment.

You can recruit test subjects via craigslist. $75 to $150 for 40 minutes is a reasonable amount to pay. If you sell a product, some of this could be in service credit. For example, a $75 AmEx gift card and $50 to use on your app. I’m also comfortable asking friends and family, if they would be in the target user group.

Usability testing isn’t survey research; you don’t need to interview 1,000 people. With ten people, you should be able to identify the biggest obstacles in your interface.