Tag Archives: feedback

It might be a good thing if someone hates your product

Nobody likes getting an email message telling that that the end result of all their hard work is a piece of garbage (or worse). It is a bit of a shock, when it happens the first time. One negative piece of feedback can easily offset 10 positive ones. But, hurt feelings aside, it may not be all bad.

For a start, that person actually cared enough about your product to take the time to contact you. That is not something to be taken lightly. A large number of products fail because they solve a problem that no-one cares about. Apathy is very hard to iterate on. At least you are getting some feedback. Assuming the comments aren’t completely toxic, it might be worth replying. Sometimes you can turn someone who really hates your software into a fan. Like one of those romantic comedies where an odd couple who really dislike each other end up falling in love. Indifference is much harder to work with. The people who don’t care about your product enough to communicate with you, are the dark matter of business. Non-interacting. Mysterious. Unknowable.

Negative emails may also contain a kernal of useful information, if you can look past their, sometimes less than diplomatic, phrasing. I remember having the user interface of an early version of PerfectTablePlan torn apart in a forum. Once I put my wounded pride to one side, I could see they had a point and I ended up designing a much better user interface.

In some cases the person contacting you might just be having a bad day. Their car broke down. They are going through a messy divorce. The boss shouted at them. Your product just happened to be the nearest cat they could kick. Don’t take it personally. You need a thick skin if you are to survive in business.

But sometimes there is a fundamental clash between how someone sees the world vs the model of the world embodied in your product. I once got so angry with Microsoft Project, due to this sort of clash of weltanschauung, that I came close to throwing the computer out of a window. So I understand how frustrating this can be. In this case, it is just the wrong product for them. If they have bought a licence, refund them and move on.

While polarisation is bad for society, it can good for a product. Consider a simple thought experiment. A large number of products are competing for sales in a market. Bland Co’s product is competent but unexciting. It is in everyone’s top 10, but no-one’s first choice. Exciting Co’s product is more polarizing, last choice for many, but first choice for some. Which would you rather be? Exiting Co, surely? No-one buys their second choice. Better to be selling Marmite than one of ten types of nearly identical peanut butter. So don’t be too worried about doing things that polarize opinion. For example, I think it is amusing to use a skull and crossbones icon in my seating software to show that 2 people shouldn’t be sat together. Some people have told me that they really like this. Others have told me it is ‘unprofessional’. I’m not going to change it.

Obviously we would like everyone to love our products as much as we do. But that just isn’t going to happen. You can’t please all of the people, all of the time. And, if you try, you’ll probably ending pleasing no-one. Some of the people, most of the time is probably the best you can hope for.

Deciding what features to implement

This is a guest post from roving software entrepreneur, Steve McLeod.

Each feature you add to your software product takes time to implement, adds ongoing complexity, and is hard to get rid of later. So you need to choose wisely when adding new features.

Here are some tips on choosing which features to implement.

Does your product really need new features?

This question might be surprising, but it is an important one to ask yourself. A software product is never completely finished. There is always scope for improvement. This makes it hard to know when to stop working on it.

If your product is mature and has stable revenue, there might not be much opportunity to increase sales. Adding new features would please some customers, but would not be a good use of your time.

Products that should be considered “done” can still have a large backlog. Don’t be fooled into thinking that your product will only be done once all existing feature requests are done.

Your product might have great potential to grow, but not by adding new features. Perhaps you need to improve your sales and marketing efforts. Don’t use your feature request backlog as an excuse to neglect the other important parts of running your product.

It’s okay to ignore your backlog

Feature request backlogs seem to never shrink. Implementing improvements leads to even more feature requests.

Looking at your backlog can be overwhelming. You’ll see feature requests that are years old. There are others that you intended to implement, but never did. It is okay to ignore these.

Don’t feel that the entire backlog consists of promises that must be kept. Some requests are no longer relevant. Some are from customers who no longer need your product. Some are simply not worth the substantial effort.

Keep your grand vision in mind

Prefer to implement highly requested features. But before you do, make sure each feature fits your long-term plans. Ask yourself:

  • who is your ideal customer? Is the feature relevant to them? For example, your enterprise customers might be asking for “single sign-on”, whereas you are more interested in working with small businesses.
  • will this be an ongoing cost- and time-sink? For example, a particular feature could require HIPAA (a US health industry regulation) compliance, while you have no interest in the extra workload and costs of HIPAA compliance.
  • does this proposed feature agree with your marketing angle?

Each new feature has ongoing costs

Remember that each additional feature comes with ongoing costs in support and complexity. Each new feature is an additional place for bugs to hide, adding to your future workload. Take these future costs into account when deciding if a feature should be added.

Features interact with each other, sometimes in unexpected ways. Even one additional checkbox in a settings panel can lead to ongoing confusion.

Be wary in particular of features that require integration with third party products. For example, many a product owner was burned when Twitter turned off some parts of their public API. Another example is my own experience adding support for connecting to customers’ email inboxes. I then found myself supporting not just my own product’s problems, but those caused by customers’ email service provider.

Sales-blockers are high priority

Not all feature requests are equal. Requests for feature A might come only from long time customers of your product, while feature B is requested only by your trial customers. It sounds ruthless, but you should prioritise the feature requested by trial customers.

When running a business, you do need to care for financial concerns. Take into consideration that:

  • A trial customer is likely to report a showstopper (for them). When you implement features requested by several trial customers, you are likely to increase revenue.
  • An existing customer is likely to report an inconvenience. You probably won’t lose the customer by delaying the improvement they asked for.
  • You need new customers to keep your business healthy.

It is important, of course, to care for existing customers. Don’t take this as an argument to ignore existing customers altogether in favour of potential customers.

Identifying and fixing sales blockers as a matter of priority is especially important for new products. It takes time to find the right balance of features a new product needs to meet the demands of the market.

Prefer the easy things, but not always

Let’s say you are deciding which of two features to implement next. Both feature A and feature B have been requested dozens of times. Feature A will take a week’s worth of work, and feature B will take a month’s work. Which one do you do?

Feature A, right? Maybe not.

Feature A is usually the correct choice. But you’ll be repeating this scenario over and over. Your product will gradually gain many relatively trivial features, while never getting the important features you need to create a compelling product.

Sometimes you need to do the hard work to add the features that are difficult to implement.

Listen to your customers…

Your customers are a great source of ideas for improvements to your product. As they use your product they discover what’s missing and what’s poorly implemented.

Therefore make it exceedingly easy for your customers to get suggestions to you. Consider adding a “Suggest an Improvement” link to your support page and to your help menu, if applicable. This makes it clear to your customers that you are actively seeking suggestions. My experience has been that customers notice these links and use them.

A “Suggest an Improvement” link can be as simple as a “mailto” link. A basic dialog or web form also works well. If you are seeking inspiration on how to do this, look at the “Report an Issue” form linked from the Google Chrome’s Help menu.

Another way to get customer suggestions is by asking them via a survey. This is okay, but it requires people to imagine back to when they last used your product. Us humans tend to be pretty poor at recalling things. It is much better to encourage customers to send suggestions as they encounter difficulties, while it is foremost in their mind.

I found collecting and organizing feedback for my own product, Poker Copilot, to be a pain. So I launched a new product to help manage feature requests. It allows your customers to suggest and upvote improvements for your product.

…and not your competitors

You’ve probably already heard that you should “listen to your customers, not your competitors.” I’m repeating it, because forgetting this can be deadly to your business.

Feature-envy leads us to believe we have to add every feature our competitors offer. Like regular envy, it is best to ignore it.

When your competitor announces a new feature, it can be demoralising. You feel you are falling behind and unable to compete. If the feature looks impressive, you’ll be tempted to add it to your product as soon as you can.

But wait. Have any of your customers actually requested this feature that your competitor added? If not, it is probably because it is not all that useful to your customers.

Your competitor might eventually regret adding that feature, as it turns out that only a small but demanding percentage of their customers use it. By not adding it, you could be giving yourself an advantage.

I’ve discovered that customers often learn about the good features my competitors have. They then tell me that they want these features. Only then do I start considering adding them.

Small tweaks versus major features

I just recommended listening to customers. But be careful of only using customer requests as a source for improvements.

Your customers tend to ask for incremental improvements. Customers are more likely to ask for an additional option in a drop-down menu than they are for a innovative new way to view their data.

If you rely on customer suggestions alone, you’ll never get the innovative new features that can make your product something much grander.

Make sure you balance your customer-contributed requests with your own innovative improvements.

Beware of preferring “pet” features

I just argued in favour of choosing innovative improvements. However this comes with a warning. Innovation can be used to justify poor choices. When you are in charge of decisions for your product, you are in danger of choosing improvements that you find interesting instead of those that have a strong business case.

Be careful. You could spend months working on a feature that is not very helpful to your business.

This is the type of feature that only one customer requested, but because it sounds more interesting to you than anything else in your massive backlog of feature requests, you immediately start working on it.

My own experience with this: I added scripting to a product even though no-one had asked for it and my target customer was not the type of person who would be interested in custom scripting. When I announced the scripting feature, not a single person seemed to use it. I eventually got rid of it.

How do you decide?

The tips I’ve offered you in this article come from my own experience. Do you have tips of your own for deciding which features to implement? If so, please add them in the comments below. I’d love to read them!

Steve McLeod runs a small software company in Barcelona, Spain. His products are Poker Copilot, a desktop analytics app for online poker players, and Feature Upvote, a web app that allows your customers to openly suggest and upvote features they want to see in your product.

Getting website feedback with Kampyle

kampyleGetting good feedback from customers and prospective customers is essential to any business. I think I already do quite a good job of getting feedback from paying customers. But what about visitors who click around my site for a few minutes and then leave, never to return? I would love to know why they didn’t buy. This sort of feedback is much harder to come by, so I was interested to read about Kampyle in the article 14 free tools that reveal why people abandon your website.

Kampyle adds a clickable image to a designated corner of your webpage. If a user clicks on this image they are shown a simple (and customisable) feedback form. Any feedback is collected by Kampyle and presented through a dashboard on their website. All you have to do is register, customise your feedback form and add some javascript inside the <head> and <body> tags of each page. Best of all, the service is free. You can see it in action on Kampyle’s own website.

kampyle1

Click the floating image in the bottom-right corner to show the feeback form

kampyle2

Leave feedback

You can also have Kampyle pop-up a survey question for a given percentage of users as they leave your site. I find such surveys annoying and never fill them in, so I haven’t felt inclined to try this yet.

Kampyle sounds great. Users have a simple way to supply feedback which doesn’t distract them from my key goal (buying my software). Sadly, very few visitors actually supplied feedback through Kampyle. I ran it for a month on some of the highest traffic pages on my Perfect Table Plan site and got a grand total of 4 comments from 3 visitors. Only two of these comments had any really useful feedback and both were from a single paying customer who probably would have emailed support anyway. I don’t feel the feedback justified the ‘cost’, in terms of the potential distraction of visitors and another potential failure mode for my website. Consequently I am now only running Kampyle on a couple of peripheral pages. Maybe the results would be better for different types of site. It only takes 10 minutes of so to set up, so it might be worth a try.

Getting customer feedback

Lack of feedback is one of the most difficult things about caring for a small child. You know they are unhappy because they are crying. But you don’t know if that unhappiness is due to: hunger, thirst, too hot, too cold, ear ache, stomach ache, wind, tiredness, boredom, teething or something else. They can’t tell you, so you can only guess. Creating software without feedback is tough for the same reasons. You know how well or badly you are doing by the number of sales, but without detailed feedback from your customers and prospective customers, it is difficult to know how you could do better.

The importance of feedback is amply illustrated by many of the stories of successful companies in the excellent book “Founders at work” by Jessica Livingston. For example, PayPal started out trying to sell a crypto library for the PalmPilot. They went through at least 5 changes of direction until they realised that what the market really wanted was a way to make payments via the web.

So good feedback is essential to creating successful software. But how do you get the feedback?

Face-to-face meetings

Meeting your customers face-to-face can give you some detailed feedback. But is time consuming and doesn’t scale when you have hundreds or thousands of customers. You can meet a lot of customers at a exhibitions, but it hardly an ideal venue for any sort of in-depth interaction. Also, they may be too polite to tell you what they really think to your face.

Technical support

Technical support emails and phone calls are a gold-mine of information on how you can improve your product. If one customer has a particular problem, then they might be having a bad day. But if two or more customers have the same problem, then it is time to start thinking about how you can engineer out the problem. This will both improve the utility of your product and reduce your support burden.

In order to take advantage of this feedback the people taking the support calls need to be as close to the developers as possible. Ideally they should be the same people. Even if you have separate support and development staff you should seriously think about rotating developers through support to give them some appreciation of the issues real users have with their creation. Outsourcing your support to another company/country threatens to completely sever this feedback.

Monitoring forums and blogs

Your customers are probably polite when they think you are listening. To find out what they really think it can be useful to monitor blogs and relevant forums. Regularly monitoring more than one or two forums is very time-consuming, but you can use Google alerts to receive an alert email whenever a certain phrase (e.g. your product name) appears on a new web page. This feedback can be valuable, but it is likely to be too patchy to rely on.

Usability testing

A usability test is where you watch a user using your software for the first time. You instruct them to perform various typical tasks and watch to see any issues that occur. They will usually be asked to say out loud about what they are thinking to help give you more insight. There really isn’t much more to it than that. If you are being fancy you can video it for further analysis.

Usability tests can be incredibly useful, but it isn’t always easy to find willing ‘virgins’ with a similar background to your prospective users. Also the feedback from usability tests is likely to be mainly related to usability issues, it is unlikely to tell you if your product is missing important features or whether your price is right.

Uninstall surveys

It is relatively easy to pop-up a feedback form in a browser when a user uninstalls your software. I tried this, but got very few responses. If they aren’t interested enough in your software to buy it, they probably aren’t interested enough to take the time to tell you why. Those that I did get were usually along the lines “make it free”[1].

Post purchase surveys

I email all my customers approximately 7 days after their purchase to ask whether there is anything they would like me to add/improve/fix in the next version of the software. The key points about this email are:

  • I give them enough time to to use the software before I email them.
  • I increase the likelihood of getting an answer by keeping it short.
  • I make the question as open as possible. This results in much more useful information than, say, asking them to rate the software on a one to ten scale.
  • I deliberately frame the question in such a way that the customer can make negative comments without feeling rude.

The responses fall into five categories[2]:

  1. No response (approx 80%). They didn’t respond when given the opportunity, so I guess they must be reasonably happy.
  2. Your software is great (approx 10%). This really brightens up my day. I email them back to ask for permission to use their comment as a testimonial. Most people are only too happy to oblige.
  3. Your software is pretty good but it doesn’t do X (approx 10%). Many times my software actually does do X – I tell them how and they go from being a satisfied customer to a very happy customer. Also it gives me a pointer that I need to make it clearer how to do X in the next version. If my software doesn’t do X, then I have some useful feedback for a new feature.
  4. Your software sucks, I want my money back (rare). Thankfully I get very few of these, but you can’t please all of the people all of the time. Sometimes it is possible to address their problem and turn them from passionately negative to passionately positive. If not, I refund them after I get some detailed feedback about why it didn’t work for them[3].
  5. Stop spamming me (very rare). From memory this has happened once.

I consider them all positive outcomes, except for the last one. Even if I have to make a refund, I get some useful feedback. Anyway, if you didn’t find my software useful, I don’t really want your money.

Being pro-active like this does increase the number of support emails in the short-term. But it also gives you the feedback you need to improve your usability, which reduces the number of support emails in the longer term. I think the increased customer satisfaction is well worth the additional effort. Happy customers are the best possible form of marketing. Post-purchase emails are such a great way to get feedback, I don’t know why more people don’t use them. Try it.

If you make it clear that you are interested in what your customers have to say they will take more time to talk to you. If you act on this feedback it will improve your product (some of the best features in my software has come from customer suggestions). A better product means more customers. More customers means more feedback. It is a virtuous cycle.

All you have to do is ask.

[1] Only if you pay my mortgage. Hippy.

[2] The percentages are guesstimates. I haven’t counted them.

[3] My refund policy specifies that the customer has to say what they didn’t like about the software before I will issue a refund.