Death by a thousand paper cuts ….

In my last post, I discussed the benefits of doing an on-site customer visit where you get to observe customers/prospects use your product or competitive products to get their job done. In my experience doing these visits, I often discover what I call “death by a thousand paper cuts” issues. These issues are essentially annoyances that your users have to put up with when using your product. By itself, each of these issues will sound trivial. If your users call you up to complain about any one of these issues or to propose a solution, you could easily laugh it off as trivial.

But when you are on-site observing these customers, you will notice that these trivial issues quickly add up to cause significant loss of productivity for your users, especially when your users have to encounter them each and every time they use your product. But these to me are the slam dunk features – they are so trivial and hence are usually very easy to fix, but when you fix them you will be able to significantly improve the user experience. Your customers will notice these small improvements because they will reap significant benefits especially if these issues were in the way of a frequently performed task.

I have had many instances where such simple fixes have generated the loudest applause from the audience where as the big feature we were so proud of was met with very muted applause (to our chagrin, if I may add). Have you experienced something similar?


If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

4 thoughts on “Death by a thousand paper cuts ….”

  1. This is a real problem with most software. For B2B software, when these issues are raised, the inevitable debate happens about whether “fixing” those issues will generate more revenue, and the cost will be NOT implementing something new. I find this to be a really annoying debate, because those issues shouldn’t have been introduced into the product in the first place.

    I wrote about this topic here for Progmatic a while back.


  2. Loved this post. It reminded me of a very similar experience I had and provided me with lessons I apply to this very day in managing new and existing product releases. Your post inspired me to blog about my experience as well:

    M. Garlington

  3. Very good post. I have noticed this many times in my work as a field worker for major electronics and services co. Fortunately, being a smaller and more agile company allowed us to make changes quickly to accommodate user’s reported difficulties. What I found with a larger company I worked for was that they were unwilling to accept input from the field as reason to initiate engineering change most of the time, relying heavily on their own intuition and momentum. I suppose the larger the customer base, the harder it gets to affect change because of scale.

    One thing’s for sure though, customer’s love to interact with their suppliers in regards to fixing stupid little irksome problems with products. The challenge is turning that kind of time intensive focus into real ROI for the business.

    Don F Perkins

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: