Innovation: a lot of opportunities

It is likely that, after focusing on the problem and understanding the job to be done, as described on the previous chapter, you will find not only one but a few opportunities to develop a new product or new features for your software product.

I’ve never seen in any organization a situation in which there was an abundance of resources and scarcity of opportunities. Usually, there are always a lot of opportunities ahead, and we don’t know which ones to pursue, because we can’t go after all of them since we don’t hold the necessary resources (time, money and people) available.

In these situations, I like using the opportunity assessment model, proposed by Marty Cagan in his book Inspired: how to create products customers love. Cagan is ex-VP of product management at eBay and currently, he works as a product management consultant.

By answering these 10-questions set, we can gather more information to decide if it’s worth pursuing a given opportunity or if it’s best to re-evaluate it in the future. The questions are very simple:

  • Which problem will it solve? — value proposition;
  • To whom this problem will be solved? — target market;
  • What is the size of this opportunity? — market size;
  • What are the alternatives? — competition scenario;
  • Why are we better qualified to pursue this opportunity? — our uniqueness;
  • Why now? — window of opportunity;
  • How are we going to take this opportunity to the market? — launching strategy;
  • How are we going to measure success and make money with this product? — metrics and revenue;
  • What are the critical factors for success? — essential requirements;
  • After answering the above, what is the recommendation? — go or no-go.

Questions 1 to 4 will help to understand the opportunity.

Questions 5 and 6 are very interesting because it is not enough to understand the opportunity and find it a good one. It is necessary to be sure that this is the right moment and that we have more expertise to pursue it.

From 7 to 9, there are what-if questions, that is, considering that the decision is to pursue this opportunity, how is it going to be presented to the market, how the success will be measured and what are the critical factors for success.

Answering these questions is good not only to decide if it’s worth developing a given product, but it also helps the partnership opportunities, opportunities to develop new features, and opportunity to attend a special client that needs changes in the product. Ultimately, every opportunity will require your or your team’s effort and should be analyzed to see if the revenue compensates for the required investment.

How many opportunities to pursue at the same time?

Another important tip is not pursuing many opportunities at the same time; otherwise, you and your team will lose focus and end up not getting return in any of the pursued opportunities.

In an ideal world, the recommended is to pursue one opportunity at a time. However, knowing that this is utopic, we will end up pursuing more than one opportunity simultaneously. Try to limit this amount to a few units (2, 3 or 4, maximum) reminding that, at any time, you and your team can only concentrate in one thing at a time.

In other words, if you are working on more than one opportunity simultaneously, every time you want to work in one of them you’ll not be working in the other ones momentarily. Therefore, stick yourself to pursue a few opportunities, preferably one at a time.

New opportunities vs. existing product improvements

This is a very common question. Should I pursue new opportunities? And what do I do with the pains of current customers? Should I develop a new product or new feature? Or should I solve current customer pain by developing improvements to my product? How to balance between pursuing new opportunities and implementing improvements to an existing product?

Here the solution is simple, at least in theory. Current product is current product, new opportunities are new opportunities. Each has to be treated separately. Ideally, they should be treated even by different teams. The thing is that is not always possible.

In such cases, if we want to pursue new opportunities, this team needs to be able to clearly separate work on existing products versus work on new opportunities. For example, two weeks for the existing product and one week for the new opportunity, until it is justified to create a new team for the new opportunity.

Warning: It’s not a bug team

This is an important point. The idea is not to separate teams to have one team doing new things and the other fixing bugs in the existing product. This does not work as it will create a very large separation between the two teams.

Anyone who does new things will eventually believe that they can do anything without worrying so much about quality, as there is a bug-focused team. On the other hand, the “bug team” will find it doing janitorial work, cleaning up the mess that other people do.

Opportunities vs. improvements

Before investing in a new opportunity, it is very important to understand why you are investing in it. A great tool for this is the opportunity assessment, described earlier. Without a clear understanding and the right engagement of everyone involved, one can put the opportunity to waste without even starting to explore it.

An important point that everyone involved should understand is that a new opportunity is a new opportunity, that is, it should generate results that aggregate to the current ones. These results should be sufficient to justify the creation of a new team to pursue this new opportunity. At least two software engineers.

Ideally, besides two engineers, it would be good to have a product manager, a UX designer, and a product marketer dedicated to this new opportunity. It will be a new product or a new feature. When this new product or new feature is ready and launched, those who worked on its development will take care of its bugs and enhancements.

Meanwhile, the other team takes care of the current product, that is, improving the current product so that it continues to achieve its goals. Improving the current product means fixing bugs, but it also means doing new things on the existing product. Improvements to make the product better, more useful and more usable.

If it is not possible to create a new team, you can share the time of the same team. Something like a week or two for bugs and enhancements to the current product, and a week for the new opportunity, until it is justified to create a new team for the new opportunity.

How to tell if it’s an improvement or a new opportunity?

It is the responsibility of the product manager, along with the team, to understand if this new thing that came up to be done is an opportunity or an improvement. But how to discern between improvement and opportunity? Especially when the new thing to do is a new feature of the existing product, should we look at it as a new opportunity or an enhancement of the existing product?

It depends on the effort and return involved. A new opportunity must have a high return to make sense of pursuing it. Remember that a new opportunity will eventually have a team just to take care of it, so the return must be sufficient to justify this new team. If the return is uncertain, it is best not to draw energy from the existing product to pursue it.

On the other hand, if there is the prospect of a good return, what is the effort to create something to exploit this opportunity? And what will be the effort to maintain this something? These two questions should guide the way you look. If the effort is low, this new thing can be treated as an improvement and developed by the current team. If the effort is high, it is recommended to treat it as a new opportunity and consider having a separate team to do the development.

Validating opportunities

After analyzing opportunities, the next step is to validate them, that is, to see if there are people interested in this product of yours that will solve the problem you researched. There are some ways of doing that. The first one is going back to the street and talking to possible clients. This will be an exploratory conversation in which you expose the problem to people who probably deal with it. Later, you tell about the solution that will be developed and evaluate the reaction. Just like that. The problem of telling about a solution is that, as better as it is the description, it is still not a ready product, and forces the person to imagine something that can be quite different from what you are conceiving.

In 2011, I decided to perform a little more realistic validation. At that time, I’ve conducted a startup experiment, did my initial research and ended up with 3 product ideas to develop. Having a hard time choosing in which of the 3 ideas to invest my money, my energy, and my time, I decided to take a simple test. I chose a name and a domain for each one of the ideas and registered them. Later, I created a webpage for each of the ideas of web products I’ve had. As I’m not a designer, nor have any skills to build beautiful pages, I used a site called unbounce, which enables us to create simple pages and even A/B tests in a very easy way. Using unbounce, I created the following page:

Sample website on unbounce

Note that this page only has 3 points that describe the product: one to talk about the problem; another one to talk about the solution; and a third one to inform the price.

The email form was useful to gather the amount of people interested. I’ve made a Google Adwords campaign of $ 10.00 per day per product that I wanted to text, during a month.

Below is a partial result of this validation:

Partial result on unbounce

This image is a screen of unbounce. After 30 days of tests, I ended up with 216 email addresses interested on ContaCal — the product I launched in 2011 that is running until today — and 1,043 pageviews, giving me 20.7% in conversion rate.

The other two ideas also kept the same trend of this partial result. But I preferred to let them unreadable in order not to influence anyone to bet in any of them without further validation.

For those who don’t know, ContaCal is a nutrition journal in which users record their eating and the system informs the total amount of calories, with a twist. Aside the total amount of calories, it also informs the quality of calories through a color system. The colors indicate how healthy that food is. If the calories are red, it is best to avoid them. Yellow calories can be ingested moderately. And the green calories have no restriction.

The total cost of this test was R$ 990.00:

  • AdWords campaign: $900.00.
  • Domains: $90.00.
  • Unbounce site: free for 30 days; after this period, $ 85.00 per month for up to 5 different domains that I would want to test at the same time.

Each new idea costs $ 30.00 by domain .br, and other $ 300.00 per month with a Google Adwords campaign if we make an investment of $ 10.00 per day.

A very important point to notice is that ContaCal was not necessarily the best of opportunities, but the best one for me to communicate. Therefore, this validation is interesting, for it helps not only to test the idea of a product but its capacity to communicate as well.

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:

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

Innovation: the job to be done

Professor Clayton Christensen teaches at Harvard and wrote several books — among them The Innovator’s Dilemma: the revolutionary book that will change the way you do business[^InnovatorDilemma], a must-read for all those who work in technology –, and he developed a technique to find out problems to be solved, called “the job to be done”.

[^InnovatorDilemma]: The Innovator’s Dilemma: The Revolutionary Book That Will Change the Way You Do Business, by Clayton M. Christensen, Harvard Business Review Press; 1st edition (1997)

The idea behind “the job to be done” is that we must understand for which job our clients have “hired” our products. In other words, the job our clients expect that our products will perform.

Clayton illustrates this technique with a very interesting example. He was hired to evaluate a specific product of a diner, the milkshake. The company had already surveyed clients asking what they wanted: creamier milkshakes, with cookies crumble, fruit or chocolate, or with more syrup. The answer of the research pointed out to a preference, which was implemented. However, this preference didn’t increase the sales, the main goal of the company.

Clayton decided to do the survey differently. Instead of asking what the clients wanted, he looked for understanding what was the work for which people hired the product, in this case, the milkshake. After many conversations with clients, he discovered that they passed by at the diner before going to work and spent a lot of time in the traffic. The milkshake was creamy and you could drink it using a straw, so it would take time to finish it. It would take the whole time of the trip to work, that is, it would entertain the client during the whole trip to work. People hired the morning milkshake before driving to work to have something to get entertained on the way.

They have already tried with other competitors, such as fruit juices, but they ended up very fast. They tried with bagels, but the work and mess to eat it didn’t compensate. The milkshake was perfect for this job to be done!

After understanding the job to be done, the diner could improve the milkshake, making it creamier and putting little fruit pieces and/or cereal in it, in order to add small surprises while the clients savor it. In addition, it set an attendance system that minimized lines to guarantee a minimum waiting time, for understanding that its clients were in a hurry and didn’t want to wait in the diner. These adjustments did bring sales improvements.

The “job to be done” market research

Clayton himself argues that, in traditional marketing, it is common to associate a certain product to a certain demographic group. For example, in the previous case, if we were responsible for the product management of the diner, we could relate milkshakes to people of a certain age who work and, consequently, always look for creamy milkshakes that last long. It happens that, using the technique “job to be done”, we have a wider view of where the product stands.

Clayton extended his survey to other periods of the day and caught the same people going back to the diner later in the afternoon, but now with their kids, for a quick meal. Often, the kids asked for a milkshake. The diner served the same milkshake: creamy, large and that lasted long. But parents didn’t want to wait that long for kids to finish their milkshakes; it was only a quick meal.

In this case, in spite of being the same client, the job to be done was another: to please the client’s kid quickly. Therefore, the milkshake could be smaller, maybe half of the size, and less creamy so it wouldn’t last long.

That is, the same client wants the same product doing different jobs, depending on the situation. That’s the importance of understanding the job to be done.

Understanding problems and their context

In the previous chapter and on this one, we learned how to understand more about a problem of a group of people; to deeply understand their problems and the context in which they take place, and to understand the motivation people have to want it solved.

Eventually, by using the technique of the job to be done, the suspicion appears: do we have a good opportunity in our hands? Or still, we can find more than one problem. So, how do we choose among all these problems? What is the best opportunity to be explored? This is the topic of the next chapter, stay tuned!

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:

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

Innovation: Focus on the problem

The first step to creating a new software product is to understand the problem. It is very tempting, as you begin to understand the problem, to go on and seek solutions. 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 these other data and I need the system to export a file .txt with commas and that end of line marker.” In other words, demands come in the shape of solutions and normally don’t even mention the problem to be solved.

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


It is a good way of understanding clients, the problems they have, the context in which these problems happen, and what motivates their 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 client 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 did it happen 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 the car and the cart of Henry Ford. Now imagine a dialogue between Henry Ford and a hypothetical Mr. Smith, a possible buyer for Ford’s product at that timeframe:

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 an even better solution for you — it’s called car.

Do you think that Henry Ford got the problem? Or that he understood the solution Mr. Smith presented to him and developed a solution based on that suggestion? 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 shown 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, and 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 spend too much time out of home. When I get home, my kids are already asleep.

Ford: Where does this problem usually happen?

Smith: At work.

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

Smith: Practically every day. It happened yesterday. I think I manage to get home in time to see my kids still awake once a week…

Ford: Why was it difficult/complicated/bad?

Smith: Because it has taken 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 also be 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.


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 of statistical relevance. That is, for being confident that the results obtained weren’t got 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 collecting the answers, allows 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 collect the answers.

Deciding to do a survey is easy, but building the questionnaire is hard. The first step is to have 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 high 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 is to test it live with some people. Check if they understand each question, or if they have 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 questions: 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 have breakfast.


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 have the observer’s interference. 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 the 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 into 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 treat it as a quantitative observation. For such, observe the user and some important metrics such as statistics of access and use, engagement, NPS, revenue, new clients, churn, etc. In other words, it is a way of observing the users’ behavior while they engage with your software.

Problem mindset vs solution mindset

When we hurry to launch an MVP, we are creating a solution for a problem. However, a very important step to creating a good solution is the understanding of the problem.

It is human nature to jump into solution mode when we learn about a problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution and good chances are that this solution will be simpler and faster to implement than the first solution we think about.

Here’s a great Albert Einstein quote:

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”

Einstein believed the quality of the solution you generate is in direct proportion to your ability to identify and understand the problem you hope to solve.

Fischer Space Pen

Let me tell you a short story to illustrate this. During the space race, scientists were faced with the issue of writing in space where there’s no gravity to make the ink go down in a ballpoint pen. Americans started their R&D efforts and after some time and a few million dollars, they built a pen with a small engine that pumps ink to the paper, even with no gravity. Meanwhile, Russians decided to use pencils, which can do the job of writing in no gravity environments.

That focus on solutions, without a good understanding of the problem and the motivation to have this problem solved, can be quite harmful. It can make us spend unnecessary time and money to get to sub-optimal solutions. This is a cultural issue, i.e., a behavior that we can and must change. The first step to changing a behavior is recognizing it when it happens. When you, as a product manager or a product development team member, receive a request to implement something, ask the person who brought the request what is the problem that this “something” is supposed to solve and why there’s a need to solve that problem.

Here are some examples from the companies I worked for.

At Locaweb, a web hosting provider in Brazil, the hosting and email services may stop working due to external factors such as the domain associated with the hosting and email not being renewed.

  • Original solution:, the Brazilian registrar for .br domains released an API to allow Locaweb to charge the customer domain on behalf of At first, the idea seems good, since Locaweb billing the domain looks like the easiest way to guarantee that the customer knows that it has to pay for the domain registration to maintain the hosting and email services functioning properly. However, when we analyzed deeper, we saw that this solution could generate some problems. The customer would be billed twice for the same domain registration because the would continue billing the domain. What happens if the customer pays both bills? And if she pays only And if she pays only Locaweb? In addition, implementing a new type of billing where we will bill for a third party service was something new to the Locaweb team. New processes would have to be carefully designed.
  • Actual solution: we started to wonder if there would be simpler ways to solve the problem of helping our customer not to forget that he has to pay for her domain registration at Since it would be possible to charge for services, it was possible to access the information about the about-to-expire domain. We decided to design a simpler solution: we will implement a communication sequence with this customer advising him of the importance of paying to ensure that the email and hosting services continue to operate normally. This is a much simpler solution than implementing a double billing process. If provides us with the billing URL, we can send this link information to the customer and the chances of solving the problem will increase even further. And a communication sequence is much simpler and faster to implement than a duplicate billing process.

At Conta Azul, a SaaS ERP for MSE (micro and small enterprises) we used accountants as one of our distribution channels and wanted to increase sales through accountants.

  • Original solution: batch purchases, where accountants would acquire a fixed number of Conta Azul licenses to resell to their customers. A system to manage batch purchases would take around 3 months to be implemented since it should allow accountants to buy Conta Azul licenses in bulk, but should only start billing the accountant’s customer when she actually activated the license.
  • Actual solution: accountants didn’t care about batch purchases. What they wanted was to provide a discount to their customers so they could subscribe to Conta Azul with this exclusive discount provided by their accounts. The cost to implement this was zero since the system already had a discount management feature.

At Gympass, a fitness partner who was joining our fitness network requested us to present their waiver to everyone who check-in in their facilities.

  • Original solution: change our app to ask end-users who go to this fitness partner to read their waiver in our app and to check a box stating they read and are ok with it.
  • Actual solution: no change to our app. Use a customizable text field in the gym set up in our system that is normally presented to users who will check-in in that gym to present the following text: “By checking in, you agree with the waiver located at”.

Don’t get me wrong, it is really good that everyone brings solutions to the table whenever we want to discuss something to be done by the product development team. The more solution ideas we have, the better. However, we need to educate ourselves to have a deeper understanding of the problem behind that solution, so we have a chance to find simpler and faster to implement solutions. And it is ultimately the product manager and all product development team members’ job to ask what is the problem and why we need this problem solved.


In concluding this chapter, I’ll make some final considerations on this stage of understanding the problem that is crucial for your software product’s success.

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 having 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 good comprehension of the problem, of the people who have them, 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.

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:

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

Leading and lagging indicators

During a mentoring session about a data concept that I think is very important, I noticed that I hadn’t written about that concept yet, so here it is. Anyone who knows me knows the importance I give to metrics. They are essential to understand what is happening and to help with decision-making. There is a way to classify metrics that helps a lot in understanding the potential impact of the metric. The terms used are leading and lagging.

Churn prediction

To explain what they are and what the difference is between leading indicators and lagging indicators, I’ll tell about a work we did both at Locaweb (web hosting and internet services provider) and Conta Azul (ERP for small business) to find ways to predict churn, that is, predict which customers were more likely to cancel the contracted service. We did a lot of analysis to find out which behaviors were most likely to indicate that a customer would cancel and we found a number of interesting behaviors like, for example, that if a website hosting customer redirects their domain to point to a website hosted elsewhere, she probably did it because she is changing the hosting service. Or if her website had high access volume and that volume has drastically reduced, chances are good that she will cancel the website hosting service as well. Or if a Conta Azul customer who used to register 50 sales per month, decreases the number of sales registered to zero, there is a high chance that this customer will cancel her account in the Azul Account.

Churn is an example of a lagging indicator as it tells what happened – customers canceled. Lagging indicators are metrics that help us assess a company’s bottom line. Examples of lagging indicators are churn, revenue, profit, number of customers, and NPS. These are metrics that must be tracked frequently, in some cases even daily or even more than once a day, but they are the consequence. They show the result, but they do not show how that result was obtained.

To understand how a result was obtained we must use leading indicators. In the above example of churn and the understanding of factors that help predict churn, customer behaviors that were detected as predictors of churn, ie, the number of visits to a website or number of sales recorded are the leading indicators. This type of indicator helps to predict an outcome, that is, it helps to predict how a lagging indicator will behave. And it is on the leading indicators that we should focus our energy so that we can see the lagging indicator hand move.

Cause and effect

For example, what should we do to decrease the churn of a product? Ensure that the product is being used and being useful, that is, solving a problem or meeting a need of its user. At Locaweb, in the website hosting product, the website has to be useful to the website owner. What does this website owner or online store expect from this website? Visits? Customers? Purchases? How to help the website owner achieve her goal? This is the way to avoid churn. At Conta Azul, what is the expected behavior of a customer who is solving their small business management problems using the product? How many times a week does she access? What does she do when she logs into the system? How can I help the customer get the most out of the product?

So whenever I see product teams setting churn or even NPS goals, I recommend including engagement goals and leaving churn and NPS not as goals but as metrics to track. If you have a product that generates engagement according to what you had planned for that product, you will most likely have low churn and good NPS.

One way to help understand these concepts is to think about cause and effect, that is, cause and effect indicators. While churn and NPS are effect indicators, engagement can be seen as a cause indicator.


Thinking about OKRs, one way to use leading indicators and lagging indicators is to think about lagging indicators, or effect indicators, as objectives and leading indicators, or cause indicators, as key results.

Using OKR’s classic losing weight example, losing 3 kilos is the goal, and it’s a lagging indicator or effect indicator. While the key results of exercising 3 times a week, not eating sweets, and limiting daily calories to a certain value are leading indicators or cause indicators.

Summing up

  • An important way to look at metrics is to understand if the metric is a lagging indicator, that is, an indicator that is a consequence such as, for example, revenue, profit, churn, number of customers and NPS, or if it is a leading indicator, an indicator that is a cause, such as the engagement of a customer with a product, is the cause of a lower churn and a higher NPS.
  • Leading indicators can be seen as the cause while lagging indicators can be seen as the effect.
  • In OKRs, objectives are the lagging indicators, while key results are the leading indicators.

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:

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

What is innovation?

Of all stages of the lifecycle of a software product, innovation is the one that uses to present the greatest amount of questions. But what is innovation? How to find a problem to be solved? How to find out if this problem is, in fact, an opportunity to be looked for? And how to obtain a return with your software product?

These are the themes that I’ll approach in the next pages.

Innovation is a very common term, but if you ask different people about it, each one will give you a different definition. Some will define it by focusing on creativity, that is, they will say that innovation is something creative, something that didn’t exist before, something different from what you find usually.

There are many products, not only software, that are very creative. There are stores specialized in these creative products. In the United States, a very well-known store of creative products is Sharper Image.

Portable air conditioner

Without a doubt, this portable air conditioner from Sharper Image is a very creative product.

Another company that sells creative products is SkyMall. The company distributes a catalog full of different and creative products on local flights in the United States.

However, are these products really innovative? How many people do you know that really need a portable air conditioner? Does it solve a problem or need of a group of people?

Besides people that associate innovation to creativity, others understand innovation as being the latest technology. Quantic computer, wireless electricity transmission, genome editing, virtual reality, augmented reality, nanotechnology and the internet of things are some examples of the latest technologies.

Whereas, once again, I have the same question: Are these really innovations? How many people need these technologies? Do they solve some problem or need of a group of people?

Defining innovation: Innovating is not just simply being creative or knowing the latest technology. It is necessary to know the available technologies and how to use them to solve a problem or serve a need of a group of people, this has the potential of really producing innovation.

This definition makes clear that innovation – and we can consider creating a new digital product as innovation – should start by discovering and understanding the problems and needs of a group of people.

But how can we do this? Do clients know what they want?

Of course clients know what they want!

“Clients don’t know what they want.” Unfortunately, It’s common to hear such a sentence in conversation about products and clients. At a certain point, someone will utter the famous quote from Henry Ford, the automobile inventor:

“If I had asked people what they wanted, they would have said faster horses.” – Henry Ford

Steve Jobs, Apple’s eternal CEO, enjoyed repeating this sentence to exhaustion.

Nevertheless, I disagree. Clients do know what they want. They want a solution for their problems. That’s where Henry Ford, Steve Jobs and us, mere mortals, come in, willing to develop products to solve these problems.

The first steps to creating a good product are:

  • To realize that there are people with a problem or need to be solved;
  • Understand very well what this problem or need is;
  • Understand what motivates people to want this problem or need solved.

When you talk to people with problems or needs, some will even say that this problem could be solved like this or that; however, in this initial moment, the priority is to find out if there really is a necessity to be solved. You must decouple the problem from the suggestion of solution your interlocutor is trying to give.

People used to take a long time to move. This was the problem to be solved at Henry Ford’s time. No matter how.

It could be more horses in front of the carts, it could be horses trained to walk on rollerblades, it could be using genetically modified horses that would ride faster, it could be the invention of the car, the invention of the airplane, even the invention of tele-transportation.

The specific solution for the problem didn’t matter, as long as it was solved. Many people probably gave solutions, like the fastest horses from Henry Ford’s quote, but this is just a suggestion. The problem to be solved is that people spent too much time moving from one place to another. The problem was not that they wanted to move faster. That’s already part of the solution.

In the next chapters, we will approach some techniques that will help us to find out and understand the problems or needs.

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:

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

Let’s remove the product from the center?

I have been working with digital products for over 30 years. I graduated in computer engineering at ITA in the early 1990s and since then I have worked for companies whose core business is technology. Starting with Dialdata, my internet services startup from the time when new tech companies weren’t called startups yet. Then I worked with technology products at .comDominio, a data center that became Alog and was later acquired by Equinix. Then I went through Locaweb, Conta Azul, and more recently Gympass. All technology companies, i.e., that use technology to deliver value to their customers.

Beyond the product

At Gympass I started to understand the mechanics of a company where technology and the digital product are not the core business. Gympass product is a corporate benefit that companies hire to provide their employees access to a network of gyms and studios. At the end of 2019, there was an effort to digitalize – and diversify – Gympass product portfolio, but even so, the main product continued to be to provide wellness services as a corporate benefit for companies to offer their employees.

Even technology companies have a mission to do “something” through technology. Locaweb’s mission is:

Making businesses grow and prosper through technology.

And Conta Azul’s mission is:

Boost small entrepreneurs’ success by bringing to small businesses more organization, control and time through technology.

And well-known tech companies don’t even mention technology in their missions:

Our mission is to empower every person and every organization on the planet to achieve more. (Microsoft)

Organizing the world’s information and making it universally accessible and useful. (Google)

Give people the power to share and make the world more open and connected. (Facebook)

In other words, technology and technology products are not the mission of technology companies, they are the vehicles used by these companies to fulfill their mission.

When I joined Lopes, Brazil’s largest real estate company, founded in 1935, long before computers and the internet existed, I began to better understand something I was already noticing during my time at Gympass. The digital product is not at the core of a company. The company does not revolve around the product, but the other way around, i.e., the digital product is there to serve the company and its customers, to leverage its results, and to help fulfill its mission. Lopes’ mission is:

Help people conquer their place.

When the product is at the center

One of the products that was under developement when I joined Lopes was the “MVP” of the brokers’ app. I put the MVP in quotes because this app was already in development for 5 months and still had another 1 or 2 months to finish and be available for use.

When I started talking to people to understand what was the main problem that the app would solve, I found that the main focus was to make the lead, that is, the information about a person interested in a property, be as soon as possible in the hands of brokers, because the faster this broker get in touch with that person and engage in a conversation about their needs, the greater the chances that this engagement would evolve into a possible sale of a property. Hence the idea of ​​making an MVP of an app with push notification to alert the broker about the lead.

At this point, an app for brokers development team was created and they started thinking about the journey of the broker receiving this lead through push notification. When the broker receives this lead, she needs to consult the data of this potential customer in Lopes’ system and, if the person is not registered yet, register their data in the system. And then, there was one more feature that “MVP” had to have before it was released, the search and registration of new potential client. Thinking more about the broker’s journey, it is very common when receiving the lead and understanding the needs of this potential client, to do a search in the real estate firm database to be able to send other propety options. And voila, one more minimal mandatory feature for the “MVP” of the broker app, the property search. To the point of having been developed for this “MVP” the possibility of drawing the region for the property search with your finger on a map.

Screen drawing functionality to mark theproperty search region in the app for brokers.

By putting the product at the center, people start to care about the product and its features. And that’s where the demand for delivering features comes from. Designing the minimal scope of an MVP may lead to discussions revolving around “minimal” features. Even when we use the term MVP, the focus is on the minimum product.

Removing the product from the center

Ok, it’s clear that by putting the product in the center, we end up potentializing some pitfalls that can hinder our delivery of results. So what should we put at the center? The expected result. In the example above, the expected result was to get leads as quickly as possible into the hands of brokers so they could contact the potential customer as soon as possible and engage him in a conversation with potential for sale of property.

If we notice in the description of the expected result, there is no mention of app, push notification, customer registration, or property search. The expected result is to make the lead reach the brokers’ hands as quickly as possible. If we focus more on the problem we will see that there are other possible solutions besides the app for brokers. We can send notifications via SMS or WhatsApp, something much simpler and faster to develop than an app. And probably with greater reach, as all cell phones accept SMS and most people in Brazil have WhatsApp, while a new app needs to be downloaded by the user. We implemented SMS notification and within 10 days all brokers started to receive these notifications. Delivery of value to brokers, potential customers and Lopes much faster than thebroker app 5 month “MVP”.

Product is means, not the end

That is why I have often repeated that product, app, website, technology, data, algorithms are not the end, they are not the goal, they are vehicles to achieve the goal of delivering value. And they must be treated as such. Making the lead reach the brokers’ hands faster can be done by push notification in an app for brokers, but it can also be done by SMS notification or WhatsApp. The vehicle matters less than the value, and the result delivered.

When we have an app team for brokers, with people from engineering, design and product management, the main vehicle that people on this team know to deliver value to brokers is the app they are developing. For this reason we made a change at Lopes in the team structure. We went from teams by product like the app for brokers team to teams focused on the actors of our business, and we created the brokers and franchises team that focuses on delivering value to brokers and franchises, regardless of the delivery vehicle for that value. It can be via a web system, an app, an SMS notification, a chatbot, etc. What matters is delivering value, and results, to brokers and franchises as quickly as possible.

Summing up

  • Product, app, website, technology, data, algorithms are not the end, they are not the goal, they are vehicles to achieve the goal of delivering value, and results, for customers and for the company.

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:

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

Lifecycle of a digital product

I’ve talked a little about what is digital product management, the main characteristics of a product manager, and about some leadership and organizational culture tips for helping managers to lead without being “the boss”.

Now, let’s talk about the lifecycle of a software product and its different stages: innovation, growth, maturity and end of life.


From all the lifecycle stages of a software product, innovation is the one that holds the biggest amount of doubts. It is also the topic that has the biggest number of books. Just go to Amazon and search for books on innovation and startup. On the next pages let’s explore the following questions.

  • What is innovation?
  • How to find a problem to be solved?
  • How to find out if this problem is, in fact, an opportunity to be pursued?
  • How to get payback with your software product?


In the growth stage, when the product has been developed and launched, we should worry about how to manage the product during its growth, that is, how to manage feedback? What is a roadmap? How to prioritize demands? What to do with special requests? How to say no? What metrics we should follow?


After growth, comes maturity. In this phase, we will figure out when it happens and what to do if the product has survived this far.

End of life

After maturity, or when the product is developed but it does not work, comes the stage known as end of life of a software product. Let’s see how to detect it and how to handle it.

Shall we begin?

How does the lifecycle of a software product work?

Before we see how the lifecycle of software works, we need to understand the technology adoption curve. This concept came up for the first time in a book in 1962, called Diffusion of Innovations, written by Everett M. Rogers, sociologist, and professor at Iowa State University. In this book, Rogers explains that technological innovations are adopted according to the curve shown in the following picture:

Technology adoption curve

In the beginning, innovators are the first to get interested in new products and novelties. They even accept incomplete or defective products just for the pleasure of being the first ones to use this new product. In second place we find the early adopters, also known as visionaries or enthusiasts, who accept the risks of testing a new product, not for the pleasure of coming first but because they see the potential in it. Usually, they are influencers within organizations and communities in which they participate.

The early majority also called pragmatics, buy new products only after they got references. The late majority are the conservatives, in other words, those who buy only after the price has dropped substantially. Lastly, we have the laggards, who only buy a new product if it is the only option available.

By calculating the integration (who remembers the calculus classes?) we can obtain the famous S-curve regarding technology adoption.

S-curve of technology adoption

This S-curve can be broken into three stages: the slow beginning, which is the innovation stage; later comes the growth stage, when the early majority and late majority adopt the product; and, lastly, the maturity stage, in which the product has already conquered practically the whole market.

S-curve and the 3 stages

Check out some examples of the S-curve.

S-curve in real life

S-curve in real life

It is not always so perfect as the theoretical curve, but close enough. The TV curve is the closest one and explains why the television manufacturers are always inventing something new, and then selling it to us.

In the first place, there were black and white TVs; then, the colored ones. Then, there were the ones with remote control, flat screen, plasma screen, LCD, LED, 3D and SmartTV. All that, so manufacturers could keep getting revenue out of their clients, even after the TV market has matured about 30 years after it had been invented.

The internet and cell phones curves seem to grow the same way. The curves from PC, electricity, airplanes, telephone, and cars have some alterations in their designs but, in general, they are very similar to the theoretical S-curve.

Another example of the S-curve, closer to who is involved with software development, is the curve regarding the amount of .br domains registered.

.br domains registered

domains registered in Brazil (.br)

Notice the typical acceleration in the innovation stage that happened between 1996 and 2008. From this year on, we’ve entered into the growth stage. It seems that, from 2013 on, a new deceleration has been taking place. In 2017 it seems we’ve entered into the maturity phase. People and businesses seem to not be registering domains anymore since there are other ways to be present on the internet (market places, Facebook, Instagram, etc.).

However, due to COVID-19 pandemic, the business digitalization re-accelerated, as we can see in the chart below:

.br domain registration acceleration after COBID-19 pandemic

The chasm

There is always a but. In 1991, Geoffrey Moore wrote a book called Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers.

In his book, Moore explains that among the early adopters (enthusiasts) and the early majority (pragmatics) there is a chasm that many products can’t cross. This happens because the pragmatics need good references for buying a new product and the enthusiasts usually are not the best reference. Hence the difficulty of some products for crossing this chasm.

Crossing the chasm

In his book, Moore also presents strategies to cross this chasm but, unfortunately, the strategies proposed are all based on war tactics that, as said in the previous chapter, I don’t think make much sense for the business world.

The proposed strategy, except for the war reference, is summed up in focus. In other words, try to focus in one single type of client and solve their problem with your product. When these clients are very satisfied, then it’s the moment for you to seek new types.

The chasm described by Moore shows one out of two ways possible for the software product:

  • It is not going to cross the chasm: the company can’t get its product to go beyond the enthusiasts and, consequently, will not have clients to guarantee its survival. This is one of the reasons that many startups close their doors prematurely.
  • Mature: your product is going to work and the company will eventually reach the top of the S-curve, and will decelerate until some other company comes up with a product to replace yours. Take a look at Kodak that, until today, hasn’t recovered from the invention of digital cameras, for its revenue came primarily from the sales of camera films and photographic material.

And here we are in the fourth stage of the software product lifecycle: the end, or, in nicer terms, sunset.

So, we have the four stages in the software product lifecycle: innovation, growth, maturity, and sunset.

Lifecycle of a digital product

Now we’ll see each one of these stages with more details and understand the role of product management in each one of them.

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 almost 30 years of experience in creating and managing digital products:

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

2 leadership tips for product managers

Product managers have the hard task of leading the product’s evolution without being anyone’s “boss”. In other words, they must convince everyone who works with their product that the path they defined for the product is the most adequate.

In several texts about product management we find the definition that product managers are the product’s CEO. I’m not very fond of this definition because CEOs have at their disposal the direct leadership of everyone in the company and can, in spite that it is not the most adequate way, use hierarchy to achieve their goals.

On the other hand, product managers work within a matrix relation, i.e., they are not hierarchically in a position of being the manager of anyone involved in the product creation. By the way, this matrix relation is an excellent leadership exercise to showing an extremely important quality for a product manager: leading without being anyone’s manager.

Even though they work in completely horizontal relationships, with no hierarchy, they must hold some leadership in order to convince people to develop the product in the direction they visualized.

So, here are two leadership tips that product managers, or any leader, should remember in order to lead efficiently.

Set the context

This first tip has a more strategic aspect. Product managers are required to:

  • Understand, communicate and explain the context in which they are working.
  • Help the team to understand what’s the role of the product in the company strategy and in the market.
  • Know how customers use the product and what they expect from it.
  • Understand how a certain feature is inserted in the product strategy.

This tip may be simple and obvious, but is not uncommon to find people who work not knowing exactly why they are doing their job. Helping people to see the impact of their work makes them understand why it is necessary.

Try to bring software engineers in your next client meeting. Better yet, take them to a usability test so they can see their users using the software they created. This will help them to understand why the software they’ve developed exists, what problem it solves and to whom it solves this problem.

Setting the context helps to engage people who are involved with the product. They will understand the product’s relevance both (1) to the company who owns the product and (2) to the product’s users. This engagement is important not only to the product’s core team (engineers, product managers and UX designers) but also to everyone involved with the product, such as marketing, sales, legal, finance and customer support.

As I mentioned in an article yet to be translated to English about creating a product vision, knowing and communicating the context where the product is inserted helps the product manager build, together with the product team, the vision and strategy of her product.

At Locaweb we have some old systems that, as any legacy, are hard to handle: little test coverage, old programming languages, code built with practices from more than 10 years ago. It is a struggle every time we need to touch the legacy code.

We’ve been working for quite some time in order to minimize the amount of legacy code and to build new code that replaces “the legacy”. However, the business cannot stop, and, sometimes, the only way out is to work on “the legacy”. Every time that there’s a demand to make a change to “the legacy” the engineering team asks to wait for the new code that will replace it, since building the demand on “the legacy” will cost too much time and in the new code will be a matter of a few days, if not a few hours.

At the beginning of 2015 a demand that required changes to “the legacy” appeared. It was necessary to change the limits and prices of our web hosting plans to follow up with changes in the market, which has become more competitive with new entrants with more attractive offers. Initially, there was some resistance from the developers to work on the legacy code, but when we explained the motivation behind the changes, they went for it and got their hands dirty in the old code.

As soon as the changes were implemented, we constantly updated everybody who worked in this project about the positive results. The comprehension of why something is needed and should be done is fundamental both for motivating who is working on it and for the quality of what is going to be delivered.

Why context is so important in software development

I want to propose a thought experiment. Let’s use empathy, the main characteristic of a digital product manager, to put ourselves in the position of a software developer who has received the following story from his team’s product manager:

When it reaches 39, an alarm should go off.

Although it appears to have enough information, when you start implementing it, you will see that information is missing. What are 39? Does the alarm go off when it gets to 39 coming from 38 or coming from 40? Or both ways?

Let us now see the same story with the proper context:

We are developing a system that monitors body temperature and this system should sound an alarm when the temperature rises over 39ºC.

With the context, it becomes much easier to understand what the number 39 is and why you were asked to sound the alarm. And it is easier to code the right software.

So, in your next planning session with the team, take the proper time to explain the context of the stories. This will increase the chances of success of your software!

Remove obstacles

This tip has a more tactical aspect. Removing obstacles is fundamental so team members can work on the product. We must feel we are moving forward, that we are doing something, building something. The article What Really Motivates Workers from Harvard Business Review has some interesting data on satisfaction at work. They put together a study in order to find out what happens in an excellent day of work. The answer was in a word: progress.

The advice by the end of the article sums up well the second tip:

You can proactively create both the perception and the reality of progress. If you are a high-ranking manager, take great care to clarify overall goals, ensure that people’s efforts are properly supported, and refrain from exerting time pressure so intense that minor glitches are perceived as crises rather than learning opportunities. Cultivate a culture of helpfulness. While you’re at it, you can facilitate progress in a more direct way: Roll up your sleeves and pitch in. Of course, all these efforts will not only keep people working with gusto but also get the job done faster.

What obstacles?

So, here are some examples of obstacles that a product manager can remove:

  • Be present: the team needs you. During the product development process they’ll need to talk with you about their discoveries and what they are delivering, so you need to be present, otherwise the team may make decisions that could not be aligned with your product vision.
  • Make your product vision clear: even though you’ll be present, sometimes you simply can’t be present. For this reason, and also to set the context as explained above, you need to define your product vision and strategy.
  • Remove excess from stories: the sooner you are able to put your product or feature in front of real users, the earlier you’ll have feedback, so you need to remove all the excess from what you and your team are building, and focus only in the minimum required to get this feedback.
  • Manage expectations and anxieties: expectation management is a big part of a product manager’s job. By expectation management I mean managing the expectations of all of your product stakeholders, internal and external. Having stakeholders asking questions directly to the team can be a big distraction and it means that you were unable to properly align your product vision and strategy with your stakeholders.
  • Help the entire the team perceive themselves as owners of the product: everyone in the product team is a product owner and you have a big role in helping them perceive themselves as such. Show them the context where your product is inserted. Build the product vision and strategy together with them. Share your product numbers, discuss with your team how to improve these numbers.
  • And everything else that hinders the team’s progress! the above list is not comprehensive. The day-to-day product development work is full of obstacles and distractions that can move you away from your main objective, building a successful digital product that helps your company achieve its business goals as well as solves your customers and users problems.

Summing up

So, there you have the 2 leadership tips for product managers and for anyone who is leading a project:

  1. Set the context;
  2. Remove obstacles.

I have been using them throughout my professional life and they have been guiding my success as a product manager.

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 almost 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

7 essential characteristics of a product manager

What does a person need to have in order to be a good product manager? There are some important characteristics and I’ll talk about them here. But the most important of all is, certainly, the one that illustrates this article, empathy.

Empathy is the ability someone has to walk in someone else’s shoes in order to understand her aspirations, motivations, needs, and problems. This characteristic is important to understand customers and users of the product, to know how they relate to the product, and what problem they expect to be solved, or what needs they want to fulfill. This will help the product manager to better understand his user in order to design the best product along with UX and engineering.

However, empathy must not be used only with the customer or the user. The product manager must use it also when relating with other areas of the company and must understand the impact the product has on their work as well. Did legal problems increase because a feature of the product was launched or changed? What is the impact on the sales team, on support, operations, finances, and marketing? Regarding the product team, engineers, and UX analysts, how does the product interfere with the work of these professionals?

The second most important characteristic is communication. In order to be empathetic, the product manager needs to communicate with people in several scenarios: in one-on-one conversations and in small groups or making presentations for small and big groups of people, internal (inside the company) or external communication (in conferences, user groups, etc.).

The product manager must also be good in written communication (e-mail, blog, documentation, chats, social networks, etc.) and be able to distinguish about what is the most appropriate way of communication in a given moment, to a given audience and using a specific media; and communicate in a way he gets understood by different audiences: technical and non-technical.

As if all this was not enough, the product manager must also be able to communicate with confidence and believing in what he’s communicating; after all, the product manager is the spokesperson of the product.

However, talking is not the only communication task of the product manager. Communication is a two-way street, in other words, the product manager must be very good at listening and understanding what others are saying, and understanding their aspirations and needs; and this has everything to do with the first characteristic, empathy. 

The third most important characteristic is time management. The day-by-day of a product manager can get quickly filled with tasks and he needs to be able to notice and distinguish what is urgent from what is important to guarantee that he will always have time to know more about the customer and the user of his product. It is very easy for a product manager to face his daily schedule full of meetings, with people from different areas to discuss several subjects: product backlog, customer support, marketing communication, operational problems, forecast review, legal matters, collection, etc.

The product manager has to take care of his product as a whole. For the user, there’s no engineering, operations, finance, legal and collection departments. He sees everything as part of the product that the product manager takes care of, and he does have to care about everything. However, caring about does not mean that he should go to all these meetings. If he does so, he will take the focus out of what is most important to his product.

As a product manager, he must focus his time on:

  1. With how many clients and users did you talk this week?
  2. Do you have a long term strategy and view for your product?
  3. How is it going and what are the last changes in the competition scenario of your product?
  4. Which insights did you have about your product this week?
  5. Do you know which is the motivation and the metrics for each item of your roadmap?
  6. What new technologies do you see coming up that could influence or even compete with your product?
  7. Which new skills are you trying to learn?

Some meetings are important, and I advise you to participate when possible. In spite of that, you won’t have much to contribute in these meetings if you don’t focus on the 7 items I’ve just listed. Do save some time in your schedule to focus on that, and you will see your participation in meetings get more useful and productive.

Aside from these three characteristics (empathy, communication, and time management), there are four other ones that will help the product manager to do a better job:

  • New technologies: the product manager must be aware of new technologies to know how they can impact her product. How does mobile access impact the product? The user wants to access via smartphone? To do what? Social networks, how can the product take advantage of them? Non-relational databases, what are the benefits and shortcomings? Go, Google’s new programming language, where is it better than the language used in the product? And where is it worse? Smartwatches, smartglasses, how does this impact the product? How do you expect to interact with the product on these new interfaces?
  • Business skills: every product exists to fulfill the user needs while reaching the company goals for the product. The product manager needs to understand what are these company goals, and needs to be sure that the product is evolving toward these goals. If it is margins, revenue and costs are under control? If the goal is revenue growth, is it evolving as expected? If the goal is number of users, how is the product compared to the target? Besides being concerned about company goals for the product, the product manager must understand how each area of the company works and how the product affects these areas. How the legal department works? How the product impacts it? And how the legal department impacts the product? These questions can be asked for every area of the company: support, operations, finances, human resources, marketing, sales, engineering and UX. 
  • Keen curiosity: the product manager must be able to learn fast in order to have insights and make judgments on the product. He must be able to learn both the soft side of the product (what is the motivation of the business, what is the problem of the client that the product solves etc.) and the more technical side (which technology do we use, what is the impact of this technology, what metrics can we obtain etc.).
  • Product theme: last but not least, the product manager must know the theme of the product. It it is a medical product, the product manager must understand a little about medicine. If it is a financial product, he must know a little bit about finance. For instance, at Locaweb, we have more technical products (such as Cloud Server) and less technical ones (such as Virtual Web Store). The need for technical knowledge is quite different regarding the two products. The product manager from Cloud Server must have a good technical knowledge while the product manager from Virtual Web Store does not have to know about technical questions, however he must have knowledge on online sales matters.

We can see that this list is a set of characteristics that not all people have. It is common for people from other areas that decide to try the product manager career, but after a while, they realize that they don’t have all that it takes.

If you are a product manager or wish to be one, do a self-analysis on each one of these characteristics. And if you are lagging behind in any of them, then focus on developing it. If you are responsible for identifying and hiring product managers, use this list as a guide to know if the candidate has the necessary characteristics for succeeding as a product manager.

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 almost 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

Product manager or product owner?

Product manager or product owner? Which term should we use? Are they different roles? Are they complementary? Is there overlapping? Is it better to have two distinct individuals, one for each role? Or is it better to combine two roles in one single person?


First of all, let’s see some other concepts.

“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.” says the Scrum Guide, and then it continues: “The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog items priority
must address the Product Owner.”

“The Product Owner represents the stakeholders and the voice of the customer,” says Wikipedia. “He is accountable for ensuring that the team delivers value to the business. The product owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog.”

By the definitions displayed, it is clear the product owner’s focus on:

  • Managing backlog priorities based on inputs from stakeholders and clients; and
  • Maximizing the deliveries from the development team.

On the other hand, in the chapter [ref-label what-is-product-management], I’ve defined digital product management as:

A> The function responsible for all aspects of a software product, during all lifecycle of the product, from its conception to the end of its life.
A> It is the function responsible for connecting the company’s strategy and the problems and needs of clients using the software product, which must help, at the same time, (1) the company to accomplish its strategic goals, and (2) solve the problems and needs of clients.

In other words, product managers need to know very well their business and what are the goals they intend to reach with it, as well as who is going to use the software and what are the goals their users intend to reach by doing so. Based on it, the product managers define how their software is going to be.

On the one hand, the definitions of product owner are strongly focused on the process, meaning they prioritize the backlog and maximize the production of the development team; while the definition of product management is strongly focused on results, meaning they prioritize the software goals for its business and for its users.

The definitions of product owner focus on the process, as all agile methodologies focus on the software development process. The Agile Manifesto itself ( states that “We are discovering better ways to build software”. Notice that the concern is about discovering better ways of building it, and not discovering ways of building better software. Is a subtle but important difference from the grammar’s point of view.

While “discovering better ways of building software” is focused on the process of developing software, when we talk about “discovering ways of building better software” we immediately focus on the results of software development: the software! That’s why my definition of product management focuses on the software and the goals of its business and its users, while the definitions of product owner focus on how to improve the software development process.

So are they different roles?

The short answer is no. Although they have a distinct focus, it is valid to say that they are two sides of the same coin. You cannot have one without the other. In other words, we can’t focus on improving the process of software development without thinking of improving the software that is being built; the same way that is not possible to think of improving it without investing on improving the process of software development.

I’ve interviewed dozens of IT directors and asked them how they design their software development organization. The results: there are product owners who are a part of the software development team, and responsible for managing the backlog and detailing the items of this backlog, and there are the product managers who are not part of the development team, they are responsible for the software business view and provide to the team great epics which will be detailed by a product owner.

Founded in 1998, Locaweb is a pioneer and leader in IT hosting services in Brazil. I worked there from 2006 through 2016 and I’ll use some examples from my time there. The company currently has over 250,000 clients and partners with more than 14,000 developers. Locaweb products are designed for everyone, from the common user to major corporations. Some of Locaweb’s products are website hosting, domain registration, hosting reseller, e-mail services, and e-mail marketing, e-commerce, and infrastructure for audio and video streaming, cloud computing, dedicated servers, and specialized IT outsourcing services.

At Locaweb, we chose for using the terms product manager and product owner as synonyms because, as said earlier, for us they are two sides of the same coin. You can’t prioritize the backlog and maximize the deliveries of the development team if you don’t have profound knowledge of the goals of the business and the users of the software. In addition, in order to build the software that meets both the goals of the business and of the users, you must prioritize the backlog and optimize the development process.

One side of the coin is the development team’s “what” and the other side is the “how”. One doesn’t exist without the other.

So, if you’re in a company where the product manager and the product owner roles are divided in two distinct people, you must keep on reading. The next session explores your situation.

What to do if your company has product managers and product owners?

I know some companies that operate with this role division between two distinct individuals and that, by reading this book, you’re now thinking you have staff to spare. :-O

Please don’t. Very likely, some other role is missing in your software product development team. My recommendation in such cases:

  • Don’t go radical: don’t go on firing people thinking that there are overlapping roles. It is necessary a more careful look because other roles might be missing in your organization.
  • Product marketing: probably there’s a lack of people taking care of the product marketing, someone who has complimentary goals but different from the product manager. In the chapter about Product Marketing, I’ll write about the difference between product manager and product marketing manager.
  • Analyze what is being done today: it is probable that your product manager, sometimes called business manager, is doing more stuff than a product marketing manager. In this case, it is interesting that this person starts to work as an actual product marketer and leave the product manager activities for the product owner eventually. This one, thus, can take care of the product management.
  • Use a new product to experiment the new role division: another way to experiment this new role division and responsibilities is to use them only in a new product. When you start to develop a new product, experiment this new role division and see how it goes. If it works, you can unroll it to other existent products.

Now that we understand a little bit more about what is a software product manager, let’s see which are the main characteristics of this role.

BA, PO and PM

In August 2016 I took over the management of product management at ContaAzul, and when I arrived I came across a structure with business analysts (BAs) and product managers (PMs), a new scenario for me. I spent some time talking to people to understand the roles and responsibilities of each function and the motivations for the creation of such a structure. After these conversations, it became clear to me the difference of roles and responsibilities of each of the functions, which I try to translate into the image below.


This image shows some important aspects:

  • POs do what BAs do (specification) plus the prioritization of what needs to be done. And PMs, in addition to prioritization and specification, are responsible for the development, communication, and execution of product vision and strategy. There is an increase in scope and responsibility as you move from BA to PO to PM.
  • Although PM is responsible for developing, communicating and executing product vision and strategy, it is also responsible for prioritization and specification.
    It may make sense for some companies to have BAs and PMs, or POs and PMs, or even BAs, POs and PMs. However, there cannot be companies without someone as PM, developing, communicating and executing the vision and strategy of the product.
  • If in a company, in addition to the PMs, there are people in the role of BA and / or PO functions, it is possible to place the PMs as managers of the BAs and / or POs. However, this creates an extra burden for the PM who, in addition to managing the product, will have to worry about managing people.
  • My preference is for not having this separation of roles and having only PMs. If there are BAs and / or POs in a certain organization, my recommendation is for treating those roles as intermediate career steps that will evolve to reach the PM level, with increased scope and responsibility. The rationale for my preference is that by leaving the roles separate, the PM may make little or no specification and / or prioritization, delegating those responsibilities to BAs and / or POs. By doing so, the PM will lose important input to developing the vision and strategy of her product.

I believe that with this image I was able to clarify the differences and similarities of the functions of BAs, POs and PMs.

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 almost 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