You discovered a problem of a group of people, and deeply understood this problem and its context. You discovered what motivates people to solve it, and analyzed the opportunity in detail in order to evaluate if it is worth building your software product. Finally, you developed the first version of your software product and launched it in the market following the recommendations of many books about startup, innovation, and software development.

Success! No…

In fact, that was your first step of a very long journey, that we will approach in the next chapters.

After the innovation stage, when you create and launch the first version of your software product, it comes the time you have to put more energy in understanding if your product in fact solves the problem of your clients. This is the time in which you either get into the growth stage or you cannot cross the chasm.

Actually, this is one of the most important moments in the lifecycle of your software product, the moment of truth, the moment in which your software meets the real world. You certainly provided a way for your users to get in contact and now you are starting to get their feedback. This feedback are going to tell if you are in the right direction to solve their problem.

Dealing with user feedbacks

Here are some tips on how to deal with this feedback:

Answer quickly

It is important to answer quickly to feedback. That will create a perception for those who are behind the software product that you care about the comments and the users of your system. This will build a positive image for your product.

Don’t make things up

Don’t tell your users that you are going to implement some feature at any given moment in the future if you don’t have plans to do so, or if this is a very remote possibility. If this is the case, only thank them for the suggestion.

Be polite

These people giving you feedback are providing very valuable information. Even if they don’t write polite words about your product, what they are saying is good for you to understand how they perceive it.

You must always be polite with your users, even with those who were not very kind. Your politeness while dealing with them can eventually help to erase the bad impression they had regarding your product.

Don’t implement every suggestion you get

Especially in the beginning, you will get lots and lots of feature suggestions: mobile version, more predictive operation, knowing the user and auto-filling data, and so on.

In this beginning, the recommendation is not implementing anything: you are still getting to know your users and understanding if your product solves a real problem for them. If you implement every suggestion you get, you can ruin the solution you created, and worse, you will start to complicate your product with many unnecessary features. In order to deal with all the suggestions, it is not necessary to create a system to write them down. After a while of getting them, you will remember which ones are most popular.

If you want to implement a suggestion system, there is UserVoice (http://uservoice.com), which is for free.

Feedback is not only what the user tells you

Although the feedback from your users is telling you a lot, you must not consider them your only source of learning. You must get into usage statistics of your software product as a tool to understand how it is being used. The number of times people access it, the amount of data they put into the system, after how long they come back, all that you must be able to extract from your database and from your access statistics report.

To build an access statistics report, a good solution is Google Analytics. Using a little piece of JavaScript code in your website and your web application, Google Analytics collects much information from people who access them, such as: through what page they access it; the last page they visited; how long they stayed in each page; where are they from (city, state, country); if they are accessing it from a computer, tablet or smartphone; in addition, it gives you the numbers of visits and several other useful information data, mainly in the beginning.

Another useful tool to check how people are using your product is ClickTale, which also uses a small JavaScript on your page, and gives you information on clicks, as well as on mouse tracking of people when they are using your product. Seeing this can provide you with much helpful information about your application.

Interact with your users through several media

There are other ways through which you can get feedback from your users. Your website holds a blog so you can tell the news about your product, doesn’t it? In the comments section, you will certainly get plenty of good information.

You can also create a Facebook page to be the place where your users meet and share experiences. If you have the opportunity, do a live talk with people using your system. Live chats are very enriching for they allow more interaction and exchange of information.

Example of hurry to act due to feedback

Soon after launching ContaCal, the software product I mentioned in the chapter Innovation: a lot of opportunities, many users commented that it would be cool to provide the possibility of controlling not only the number of calories ingested but also the number of calories spent. From hearing people asking for this feature, it got stuck in my mind as an important feature to be implemented. Maybe I could even be losing new users’ subscriptions for not having it, or users were giving up on using the system because of its inexistence.

I was getting organized to decide how to implement payment in the system, but due to this feedback, I decided to insert the feature of the physical activity record on ContaCal two months after its launch. I did it because it was simple to implement and for thinking that it could help to increase the number of people that would continue to use the product after the first access.

I’ve announced the feature to existing users, highlighted it as one of the features of the system, and started to show this new feature to new users. A lot of people thought it was cool, but the curve of new users who registered to try the system, as well as the users who decided to continue using it after the first contact didn’t change at all!

To confirm this percept of too much effort with little utility, it was just a matter of looking to the database to see that only 2.4% of registrations come from activities. I ended up postponing the billing implementation for a month to implement this feature. Today I see that I didn’t have to implement this feature and could have let ContaCal as an ingested calories record system only, without worrying about the calories spent in physical activities.

Recently I got an email from a user complaining that the graphic I present as a report does not show the physical activities, considering that the goal is only to show the evolution of ingested calories. That is, I added one more complexity to the system that I have to deal with today with practically zero gain, nor for the user, and nor for me, the software owner.

Be careful when implementing a new feature. Its creation produces complexity in the code, in the business rule, and in the interface. If the positive outcome for users and owners is not very clear, maybe it’s better to wait for a while before investing.

Crossing the chasm

Crossing the chasm that separates the first clients, those enthusiasts who love to test every new product, from the rest of the market is not an easy task. There is even a whole book talking about the subject, one that I’ve mentioned a few times, Crossing the Chasm, by Geoffrey A. Moore.

Although I have shown a lot of information about this book, it is good to focus on some observations about it, considering this moment of product growth and feedback collection.

The first part of the book is very good; a recommended reading for anyone who works in technology. In it, Moore shows the technology adoption curve in detail, the existence of the chasm in this curve, and explains the reason why this chasm appears.

In the second and last part of the book, Moore suggests how to cross the chasm. The problem is that he uses war analogies for it; again, I emphasize that is not the most appropriate way to address business matters. The first chapter of the second part is called “The D-Day analogy” and the chapters that follow use the same kind of titles (“Aim for the attack point”, “Assemble your invasion force”, “Define the battle”, and “Release the battle”).

In spite of the horrible analogies, the ideas are good. In short, he recommends a profound understanding of the user to guarantee that your product is, in fact, solving a problem. He recommends focusing on this single point for a group of users. It is better to be something really good for a group of people than try to be everything for everyone.

From the moment your product is a great solution for a problem of a small group, you will be able to look for more people who might have a similar or the same problem so you can adapt your product, and then reach for more market share.

Of course, it is much easier talking than doing it, but don’t forget: a good understanding of your user, the problem, the context in which it happens, and the motivation the user has to get it solved, are your best tools to cross the chasm and avoid the premature death of your software product.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.