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 details in order to evaluate if is worth to build your software product. Finally, you developed the first version of your software product and launched it in the market following the recommendations of the many books about startup, innovation and software development. 

Success! Not…

In fact, that was your first step of a very long journey, that we will approach in this and the following articles.

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 get in contact and now you are starting to get your feedbacks. These feedbacks 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 these feedbacks:

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 you are going to implement some feature in 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 for the suggestion. 

Be polite

These people giving you feedback are providing a 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 getting them you will remember which one are most popular. 

If you want to implement a suggestion system, there is UserVoice, that you can try for free. 

Feedback is not only way a user tells you something

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 statics of your software product as a tool to understand how it is being used. The amount of times people access it, the amount of data they put into the system, after how long they come back, all that must be able to extract from your database and from your access statistics report. 

To build you 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 several 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, mainly in the beginning. 

Another useful tool to check if how people are using your product is ClickTale, that also uses a small JavaScript in 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 many 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 article Innovation: a lot of opportunities, many users commented that it would be cool to provide the possibility of controlling not only the amount of calories ingested but also the amount of calories spent. From hearing people asking for this feature, it got stuck in my mind as an important functionality to be implemented. Maybe I could even be missing new usersí subscriptions for not having it, or users were giving up of 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 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 existent 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 test the system, as well as 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 register come from activities. I ended up postponing the charging 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 with the calories spent in physical activities. 

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 up to today with practically zero gain, nor for user, nor for me, the software owner. 

Be careful when implementing a new feature. Its creation creates complexity in the code, in the business rule and in the interface. If the positive outcome for users and owners are not very clear, maybe itís better to wait a little 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 showed lots 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 details, 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 focus 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 to talk than doing it, but donít forget: the good understanding of your user, of the problem, of 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? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.