In my last article, I discussed about innovation, the first phase of the lifecycle of a software product.

The first step to create a new software product is to understand the problem. It is very tempting, as you begin to understand the problem, go on and seek for solutions. The human nature is to solve problems. 

Every software developer has some story to tell about demands that goes like this: “So, I need a system that does this and that, I need to have a field so I can type this information and it should give me a report that shows this.” Then, when the system is delivered, the person says “Well, this helps me, but now I also need a field to insert this other data and I need the system to export a csv file with this and that info.” In other words, demands come in the shape of solutions and don’t even mention the problem to be solved. 

Next I’ll share some techniques to focus on the problem.

Interview

It is a good way to understand customers, the problems they have, the context in which these problems happen, and what motivates them to seek for a solution. However, it is necessary to be careful, because the respondent will try to hand out the solution of what is thought to be the problem. You must be careful not to belittle the suggestion, but should always keep the conversation focused on the problem. 

The interview in which you talk directly to your customer is considered a qualitative method, that is, you ask a few questions but get the opportunity to deepen the answers. 

Next, there is a set of questions that will help to keep the conversation focused on the problem:

• Tell me more about your problem.
• What is the greatest difficulty you have regarding this problem?
• What motivates you to wanting this problem solved?
• Where does this problem usually happen?
• When it happened for the last time? What happened?
• Why was it difficult/complicated/bad?
• Did you manage to find a solution? Which one(s)?
• What didn’t you like about the solutions you found?

For instance, let’s go back to the subject of Henry Ford’s car. Now imagine a dialogue between Henry Ford and a hypothetical Mr. Smith, a possible buyer for Ford’s product at that time:

> Ford: Mr. Smith, what distresses you the most?

> Smith: Mr. Ford, the most distressful thing for me is that I donít spend too much time with my family.

> Ford: And why is that?

> Smith: Because I spend too much time in the cart going from one place to another. If I could put one more horse to pull my cart it would go faster and I could spend more time with my family. 

> Ford: Oh, I see your problem, and I have a even better solution for you. It’s called car.

Do you think that Henry Ford got the problem? Or he understood the solution Mr. Smith presented to him, and developed a solution based on Mr. Smith’s solution? Do you think the real problem of Mr. Smith was that he didn’t spend too much time with his family?

Let’s try using the same questions showed previously to see if we can get the problem:

> Ford: Mr. Smith, what distresses you the most?

> Smith: Mr. Ford, the most distressful thing for me is that I don’t spend too much time with my family.

> Ford: And what is the greatest difficulty you have regarding this problem?

> Smith: I spend too much time at work, going from one place to another, without talking to people. 

> Ford: What motivates you to wanting this problem solved?

> Smith: I have small children and, because of work, I spent too much time out of home. When I get home, my kids are already asleep. 

> Ford: Where this problem usually happens?

> Smith: At work.

> Ford: When did it happen for the last time? What happened?

> Smith: Practically everyday. It happened yesterday. I think I manage to get home in time to see my kids woke up once a week…

> Ford: Why was it difficult/complicated/bad?

> Smith: Because it took me away from the kids.

> Ford: Did you manage to find a solution? Which one(s)?

> Smith: I got off from work earlier.

> Ford: What didn’t you like about the solutions you found?

> Smith: The work piled up on the other days.

Note that this conversation can generate a solution such as the invention of the car to help Mr. Smith to get home faster. However, it could be also the motivation for creating a more efficient work process, or a machine that would do the work for Mr. Smith.

You might have a solution in mind. But consider having a real interview, focusing on the questions for really understanding the client’s problem.

Survey

Another way of obtaining information from clients is through surveys. This method is considered quantitative because it seeks to survey a considerable amount of people in order to get what is known to be statistical relevant. This is, for being confident that the results weren’t obtained by chance. 

For example, in case you ask in a survey if a person has iPhone or Android, and only get two people to answer, that is, only two answers – being both iPhone, both Android or one iPhone and the other Android – it is very difficult to reach a conclusion. But, if you have many more answers, you have bigger chances to picture the real world in your survey. 

There are great tools for online surveys, such as Google Form and Survey Monkey. There is also a Brazilian tool called OpinionBox that, besides building your questionnaire and collect the answers, allows that you to select people for responding it based on the profile criteria you specify

Surveys don’t have to be necessarily taken online. You can also perform them by phone or live. There are companies that can help you to collect the answers. 

Deciding to do a survey is easy, but building the questionnaire is hard. The first step is having your survey goal very clear. Then, create your questions with these two main rules in mind:

1. Be brief. The shorter your survey, the bigger are the chances of getting a good number of answers and guaranteeing a highest statistical relevance. 

2. Be clear. Especially in online surveys, when you are not interacting with the respondent, there are big chances of the person misinterpreting your question. One good way of testing your questionnaire live with some people. Check if they understood each question, or if they had some difficulties in comprehending some part of it. 

Check some examples of bad questions that could bring up some misguided interpretations or mix up the quality of the answers, and suggestions of how these questions can be improved:

> Original question: How short was Napoleon?

> Improved version: What was Napoleon’s height?

> Original question: Should concerned parents use compulsory child seats in the car?

> Improved version: Do you think the use of especial child seats in the car should be compulsory?

> Original question: Where do you like to drink beer?

> Improved version: Break into two questions: Do you like drinking beer? If yes, where?

> Original question: In your current job, what is your satisfaction level regarding salary and benefits?

> Improved version: Break into two question: What is your satisfaction level with your salary in your current job? What is your satisfaction level with your benefits in your current job? 

> Original question: Do you always have breakfast? Possible answers: Yes / No.

> Improved version: How many days a week do you have breakfast? Possible answers: Everyday / 5-6 days / 3-4 days / 1-2 days / I donít take breakfast.

Observation

Another very useful technique to understand the problem is to observe. Seeing the client facing the problem or having a need, in the context that it occurs can be inspiring!

Observation is a qualitative way of understanding a problem. In order to make a good observation, be prepared; that is, hold in your hands a set of hypotheses. In each round of observation, re-evaluate your hypotheses and adjust them, if necessary. Usually, after 6 or 8 observations, you can already notice a pattern. 

Observation may or may not be interfered by the observer. For example, if you are observing consumption habits in a drugstore, you can watch people without them noticing you. But in a usability test, in which you invite people to test your software, people will know that you are observing them. The observations can be complemented with interviews, helping to improve the quality of the findings.

A very useful technique to find out problems in the use of software is to observe what the user does 10 minutes before and 10 minutes after using it. For example, if the user catches information in some other system to insert in the software. Maybe here there’s an opportunity for you to catch information from the other system automatically. And if, after using it, the user pastes information to a spreadsheet for building a graphic, eventually your software could spare the user from this work and automatically build this graphic. 

Observation usually is depicted as a qualitative method. But you can and should also use quantitative observation. For such, observe the user and some important metrics such as access and use statistics, engagement, NPS, revenue, new clients, churn etc. In other words, metrics are a way of observing your users’ behavior while they engage with your software. 

Final remarks

I put aside, on purpose, a technique called focus group, in which we gather a group of people (between 6 and 15 individuals) to discuss a certain problem. It is a technique considered qualitative as it enables to deepen in the questions that are being discussed. 

The reason I put it aside is that, in these discussion groups, there’s a strong social influencer element in which more assertive and extrovert people tend to dominate the discussion and end up polarizing the group’s opinion. In my point of view, individual interviews are generally much more relevant, unless in situations when the goal is to research exactly the influence and social interaction of the group. 

Another important point to consider during your discovery of the problem is who are the people holding this problem and which characteristics they have in common. Besides understanding very well the problem, it is important to know for whom we are intending to solve it and what are their motivations and aspirations. It is important to keep this in mind during the process of discovering the problem. 

You might be asking yourself “Why is so important to invest that much time and effort in understanding the problem?” The answer is simple: developing a software product is expensive. Investing in a good comprehension of the problem, of the people who hold the problem, of the context in which it occurs and the motivation people have to see it solved, is essential for not wasting time and money building the wrong solution. 

Lastly, as I mentioned before, the methods are not exclusionary, they can and must be used together, for they are complementary. An observation is complemented with an interview. The findings in observation and interviews can be confirmed (or confronted) with the results of a survey or the analysis of collected metrics. 

Product Management: how to increase the success of your software

In 2015 I wrote a book on Software Product Management in Portuguese. In 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

• Definitions and requirements
• Life cycle of a software product
• Relationship with other areas
• Product portfolio management
• Where to use software product management

This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedbacks are not only welcome, but needed!