Growth: financial metrics

When I talked about the importance of being a data geek in the previous chapter, I explained the conversion funnel, which is formed by a set of data that we can consider short-termed, because within a few days (or even hours) you can notice trends, take conclusions, create hypotheses and validate them, whether talking to your users or making experiments and measuring the results.

I also talked about engagement metrics, which show how your users interact with your product, and about churn, both from the client and revenue. That will help you to understand how many clients are no longer clients, why they gave up, and what is the impact of it on your revenue.

Aside from these data, there are other ones that take more time to be established and start to show some tendency, but that should be monitored from your product’s first month. These are the financial metrics, that can be categorized in global numbers (revenue and costs) and individual numbers: CAC (Customer Acquisition Cost), LT (Lifetime), and LTV (Lifetime Value).

Global numbers: revenue and costs

Revenue is the money you get when people use your product. Cost is any money that has to be spent or given up in order to get your product going. Basically, this revenue will be used to pay for your costs. When you can afford to pay for your monthly costs, the surplus will be used to offset the investment of the months when the monthly revenue doesn’t cover the costs.

Both revenue and costs should be checked out month over month. It is important to categorize your costs, so it can help you to understand where you are spending the most and where you can save. I use to put costs under 3 categories:

  • Infrastructure: it’s all the necessary costs to keep the service running. In this category, I include website and app hosting costs, domain register, tools for e-mail marketing, SEO, A/B tests, online chat system, etc. Usually, these costs are recurrent; therefore, they require a lot of attention every time you hire a new service like the above.
  • Development: here are all the costs to develop and implement new features in your website or application, including programming, interface development, visual design, logo design, etc.
  • Marketing: every investment you do to attract clients, such as AdWords, Facebook ads, ads on websites, magazines, newspapers, and TV. We should also include here the costs of flyer printing and distribution, coupons, folders, etc. In the beginning, you will very likely need to invest time in free tools to attract clients who, in spite of being long-termed, will help through the months to save on marketing expenses or, if you decide to continue to invest in paid publicity, will help you to increase your revenue.

In order to have a profitable product, the monthly income should be higher than the monthly expenses. It is as simple as that. However, it is easier said than done.

Individual numbers: CAC, LT, and LTV

The revenue and the costs are global indicators of your web product’s health. It is important to have individual indicators, that is, one for each client of yours.

There are three very important indicators:

  • CAC: is the Customer Acquisition Cost. It is the sum of the associated costs with finding and getting the attention of potential clients, bringing them to your site, converting them into users of your web product, and later, into paying users. For example, imagine that you have only invested on Google AdWords and, on a given month, you have spent $1,000 and got 10 new clients in that month. Dividing $1,000 per 10, you’ll have a CAC of $100. That is, your cost for getting each client is $100.
  • LT: it’s the Lifetime of your client. That is, how long on average a client is your client. This number only makes sense when you have a recurrent revenue stream. Using the previous example, let’s imagine that the LT of clients you have acquired is 20 months.
  • LTV: it’s the Lifetime Value, or the value of a client while he stays as your client. It’s the revenue this client generates while still your client. Following the previous example, let’s imagine this client generates monthly revenue of $8. Multiplying the LT of 20 months by the $8 per month gives us an LTV of $160.

In these definitions, it’s easy to see that your product will be as profitable as higher is the LT and the LTV and that you need your LTV higher than your CAC.

In this example, we have an LTV of $160 and a CAC of $100, which shows that we have a profitable situation. It is necessary to follow up closely on these numbers, month by month. If in a given month the LTV continues at $160 and the CAC goes up to more than $160, it’s necessary to review the client acquisition efforts. Also, you should study ways to increase the LTV, augment the LT, and/or augment the monthly value.

Revenue churn

Revenue churn is a measure of the lost revenue for a business model based on subscriptions, calculated in terms of client churn and the total revenue over a period.

You can calculate it as follows:

Monthly revenue churn = revenue from clients who canceled on the month / total revenue of the month.

In order for your product to grow, it is necessary to have an increase in the monthly revenue higher than your monthly revenue churn.

There is an important difference between revenue churn and client churn. Client churn will always be a positive number, but the revenue churn can end up being negative. How? The revenue growth from your existent clients must be higher than the revenue churn from clients who are canceling the service on that month, without considering the revenue from new clients on that given month.

Client churn is the number of clients who are no longer users or clients. It is important to know how many are they, and the reasons why that happened, because you need this data to improve your product, to reduce the churn.

See in the following picture the difference between client churn and revenue churn:

Negative churn

How is it possible to have negative churn?

The negative churn occurs when your existing clients use more of your software product and they have to pay for it, and revenue gain exceeds revenue loss from existing customers who purchase less over time, including clients churn. For example, when clients upgrade a service plan with more features, when they hire additional services, when they pay for additional use, or when they buy more access accounts.

This will make your product grow more than the number of new sales per month, because with a negative churn, even if you don’t have any new sales, your revenue will grow due to the revenue increase from existing clients. That’s why negative churn is considered the “Holy Grail” of products that have a business model based on subscriptions.

In the next chapter, we’ll see the best metrics of all, in my opinion: the loyalty metrics.

Mentoring and advice on digital product development

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

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.

Growth: Engagement and churn

Once you get to bring in users (free or paid) to use your product, your next concern is related to the engagement from these users, that is, are they using the product? Are they solving the problem that the product is supposed to solve? How many times a day (or a week, or a month) your product is being used? For how long? How is it being used?


It is very important to find metrics to measure engagement. For instance, for a product to send e-mail marketing, some engagement and usage metrics are:

  • how many times per day does the person access his/her inbox,
  • how many campaigns go off per month,
  • how many clicks this campaign had,
  • how many messages were sent with the incorrect e-mail address,
  • how many messages generated complaints.

Note that each product has different engagement and usage metrics. Each product manager must select metrics to track his/her specific product.

Have you ever stopped and thought about how many times a day you use your cell phone? What do you use to access it? WhatsApp? Facebook? Instagram? Can you tell that you are deeply engaged with these applications?

Promoting engagement should be one of the concerns of the product manager. In 2013, Nir Eyal launched his book called Hooked: How to Build Habit-Forming Products, in which he explains the theory behind these products that just end up entering our daily lives. It is a great book to understand more about this theme.

There are some strategies that can help you to increase your product’s engagement and usage. These techniques are called lock-in.

  • APIs: Short for Application Programming Interface, API is a way of giving access to your product, to the data that are stored and to the routines it executes to other software. When someone creates a new software using the APIs of your product, there’s a great chance of increasing the engagement with it.
  • Incentive to use: you can do promotions to incentive the use of your product. For instance, if your product has usage quota, you can increase this quota as the time goes by. be one of the concerns of the product manager. In 2013, Nir Eyal launched his book called Hooked: How to Build Habit-Forming Products [^hooked], in which he explains the theory behind these products that just end up entering our daily lives. It is a great book to understand more about this theme.
Churn example

Despite the fact that churn was greater than 20% every month, growth in the year was 73 new customers.

Why is it possible to grow even with a high monthly churn?

There are two reasons. The first, which I have already mentioned, is that it is necessary to have a greater inflow of customers than the amount that goes out.

The second is that churn varies based on the age of the customer. It is common to have cases where churn is high in the first month, because the customer did not like the service and decided to cancel right away. Or in the third or sixth month if your billing is quarterly or semi-annually. Some people call it premature churn.

Premature churn, despite being common, is something that can and should be reduced. You do this:

  • Aligning the customer’s expectations that you created in them by promoting your product with what they will find when they start using it.
  • Ensuring that the first experiences of using your product are very good and that your customer can achieve their goals in these first experiences.
  • Keeping your product useful to your customer over the months and years, investing in understanding your customer and their problems, and updating your product so it continues to solve your customer’s problems.

The concepts of churn and engagement go hand in hand, because the more engaged a user is, the less likely they are to cancel the service. So, a good way to predict the churn of a given customer is to track their engagement.

For example, if you’ve launched a distance learning product and track the usage of that product, you’ll likely see that the churn rate is higher for customers who have never attended the class. Review the previous lock-in thread for tactics to increase engagement and decrease churn.

Data science, machine learning, and product management

In recent years, the terms data science, machine learning, and artificial intelligence have appeared recurrently and abundantly. These terms are quite important for product managers. No wonder I dedicate 5 chapters of the book to subjects related to data and metrics.

As I mentioned in the previous chapter, the product manager must be a data geek, that is, a person who is always thinking about how to learn more from data. What is a person’s behavior in the months and days before unsubscribing to your product? And the behavior of a person who upgrades? What is the behavior of a user who says he is satisfied with your product? And what do you say very satisfied? If your product has multiple features, which is the most popular? Which generates greater satisfaction? What is the typical usage pattern for your product? If an atypical usage pattern appears, what does it mean? These are examples of some questions that the product manager can ask and that will have their answers in the product metrics. And with each new answer obtained, it is very likely that the product manager will want to ask more questions.

To find the answers to your questions, it is important that the product manager knows data science techniques and knows how to extract the answers to his questions himself, whether through data extraction and visualization tools or by running SQL in the product database. If the product manager does not have this independence and needs other people to extract the data for him, this can hinder the evolution of the product.

As this learning from the data takes place, it is likely that the product manager will begin to see opportunities to embed these learnings into the product. For example, a product manager of a CRM software may notice, after analyzing the usage and engagement data of the product, that customers end up canceling less when they are using the commercial proposal generation functionality. Once that discovery is made, he can make a change to his product to make it easier and more immediate to use this functionality and, in doing so, decrease customer churn by making them more engaged. This is a way to infuse data science into your product.

Machine learning, which is nothing more than a way of implementing artificial intelligence, is when we program machines to learn from data, and the more data the machine has in its hand, the more it will learn. In other words, it’s a way to insert data science into the product to make it better. The more you use a particular product, the more data is available to the team that develops the product to get to know your user and how they use that product. For example, the more purchases you make at an online store, the more it learns about your shopping habits and the easier it is for the store’s software to make recommendations that interest you. The same goes for Netflix and Spotify suggestions. In these cases, it is common for the store to compare its use with the use of people who show similar behavior to make suggestions such as “whoever bought this item also bought these other items”.

That’s why the product manager and the entire team that develops the product must know and know how to use data science, machine learning, and artificial intelligence in their daily lives. They are powerful tools to help you increase your chances of building a successful product.

In the next chapter, we will continue with the topic of metrics, focusing on financial and long-term metrics. Let’s also understand the concept of negative churn, the “Holy Grail” of products with a subscription-based business model.

Mentoring and advice on digital product development

I’ve been helping several companies to get more value and results from their digital products. Check here how I can help you and your 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 on their titles above.

Another example of an MVD – Minimum Viable Discovery

Lopes is the biggest real estate company in Brazil, where I’m leading the digital transformation efforts. A new hire who came from an e-commerce site mentioned that app push notifications generated more leads and had greater conversion rates than SMS and email marketing. We got interested in testing this hypothesis, but always with the MVD – Minimum Viable Discovery mindset that I explained earlier.

How could we test this hypothesis as fast and cheaply as possible? Building an entire native app with all the features of our existing website would take months. Even if we scoped it down a lot, with the minimum to deliver some value to the user, it still would take many weeks.

Since our website is responsive, we devise a simple solution to test the hypothesis. We decided to create a webview app, a simpler solution than building a native app, eve if we scoped it to a minimum.

By the way, this is how Facebook and Linkedin launched their first mobile apps as well. Only when they the results generated by a mobile app, and proved that a native version would bring even more results, they decided to invest in building their native apps.

Here’s Lopes’ mobile app:

With this mobile app we were able to confirm that push notification generated more leads and had greater conversion rates than SMS and email marketing. We launched this app in early 2021.

I already heard that MVP doesn’t scale, it is just to test a solution hypothesis and then, if the solution hypothesis, we should work on delivering the solution in a scalable manner. As with everything related to product management, it depends! In our case, untill now we haven’t had the need to build a native version of this mobile app. The webview version is working quite fine for our needs and users seem to be ok with it as well. Maybe in the future we’ll have the need to build a native app but, at least for now, after more than one year that we launched our webview mobile app, there’s still no need to build the native mobile app.

You cantry Lopes App for Android or iOS.

Summing up

  • MVD – Minimal Viable Discovery mindset is essential to deliver results as fast as possible. For instance, why building a native mobile app to test some hypothesis if a webview is enough to test it?
  • The “MVP doesn’t scale” affirmation is not necessarily true. As everything related to product management, it depends. In our case, after more than a year after launching the MVP we created to test our Discovery Solution hypothesis, our webview app, we haven’t had the need to build a native app.

Mentoring and advice on digital product development

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

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.

Why business people hate discovery

There are basically two reasons, one of them has to do with mindset and the other one has to do with the discovery process.

The one that has to do with mindset is clear when we hear phrases like “Why do you want to do a discovery? I’m the business person so I’m the person that understands the most about our business problems/needs and how to solve them. You just have to implement what I say”.

Sometimes this aversion is rooted in the “business demands => technology implements” mindset that I mentioned earlier. This was how things were made in the past, without any need for discovery, because “business people are the ones interacting with customers so they always know what is best for the customers”.

However, most frequently this aversion to the discovery process is motivated by the business person’s past experiences where the discovery process was too long. The business person needs the solution to his problems implemented as quickly as possible, so she can benefit from the results that this demand may generate. The business person can’t afford lengthy discovery processes.

It’s very difficult, but not impossible to change this mindset. It requires patience and repetition:

  • Ask why: by asking why the business person is demanding the implementation of a certain feature, we have the opportunity to show this person a very simple discovery tactic that helps both the product manager and the business person to find other solutions hypotheses to the problem. We change to a discovery mode without using the word discovery. After a few times applying this tactic, we can mention to the person that understanding the why of a certain demand, generating solution hypotheses, and testing these solution hypotheses is the process of discovery and it’s based on the product manager and the product development team needs to find the easiest and quick to implement the solution.
  • Learn about the business: sometimes the business person believes that she knows more about the business than the product manager. This normally happens when a new product manager joins a company and still doesn’t know much about its business. To solve this perception from the business person, the product manager needs to find ways to learn about the business as quickly as possible. Talk to business people, talk to customers, read about the business, attend short-term courses about the business, and go to conferences about the business topic. Product managers need to understand the business in order to discuss business issues with the business person.
  • Shorten the discovery process: sometimes discoveries take quite long. A few weeks, one month, more than one month. Meanwhile, the business person has a problem that needs a solution as quickly as possible so she can benefit from the expected outcome that the solution of the problem may generate. This happens especially when the discovery process is focused only on the problem discovery. If the product manager is able to cycle fast between problem discovery and solution discovery, the business person may see the product development team working sooner rather than later on a solution hypothesis for the problem and may have her expectations for a solution calmed down.

MVD – Minimal Viable Discovery

Unfortunately, this third reason, the lengthy discovery process, happens quite often and this is our fault, especially when we aim to understand everything about a problem prior to testing solutions.

As I mentioned earlier, the discovery process has two sides, problem discovery, and solution discovery. We don’t need to know everything about a problem prior to testing, i.e., discovering solutions. The solution discovery is a powerful tool for us to understand more about the problem. For this reason, we need to cycle as quickly as possible between problem discovery and solution discovery. The faster we do so, the faster we understand the problem and the faster we discover a solution for the problem.

Also, if we do a complete problem discovery to understand everything about the problem, we may end up with so many sub-problems that will make the solution discovery process also very lengthy and the delivery will take a lot of time to be completed.

The product development community talks a lot about MVP, the minimal viable product, but we cannot forget this is not only about fast delivery of a minimal product, but also a lean discovery process. It’s time to adopt an MVD – Minimal Viable Discovery mindset, i.e., what’s the minimal problem discovery we need to make in order to test the minimal solution hypotheses and deliver the one that works and actually solves the problem?

Lopes’ broker app

A good example to illustrate this is the Lopes’ broker app. Lopes is the biggest real estate company in Brazil, where I’m leading the digital transformation efforts. When I joined the company the team was working on an “MVP” of this app. I put in quotes because it was under development for 5 months and there were still 2 to 3 months to go. When I dig a bit deeper into the process and why it was taking so long, I’ve learned a few things:

  • The discovery process took anywhere between 7 to 10 months!
  • The discovery process was focused only on the problem discovery.
  • The discovery process was internal, i.e., demand gathering from business areas and benchmarking with other broker apps available in the market.
  • The “MVP” was scoped as having 58 requirements/features and there were already 90 requirements/features scoped for future releases.
  • The main pain point was based on a hypothesis that, if the broker received the lead, i.e., a potential customer interested in a property, the faster she received this lead and interacted with the customer, the greater the chances of closing a deal.
  • Then, the team analyzed the broker journey and realized that when a lead arrives, the broker needs to search Lopes potential customers database to check if the potential customer is already in our database and if it is not, register the user data in our database.
  • And then, from this broker journey analysis they realized that, if the broker was able to send a few other property options to the potential customer, it would potentially increase the chances of closing a deal.
  • This created the scope to be implemented that took 7 to 10 months of discovery plus 7 to 8 months of delivery to build the app “MVP”.

There are a few points to highlight from the process above:

  • The discovery process was too long, which created a huge list of problems to be solved.
  • The solution discovery phase was not performed. The team went from problem discovery directly to delivery, without any opportunity to test some solution hypotheses.
  • The huge list of problems to be solved impacted directly the delivery process making it very long too.
  • If the solution discovery was used as soon as the main problem was discovered, the hypothesis that the faster she received this lead and interacted with the customer, the greater the chances of closing a deal, probably the team would be able to devise a simpler solution, that probably would take days, not months to be implemented.

Regarding this last point, after a few discussions, we thought about an app with only a push notification for each lead and the broker could continue the tasks as she already did them. And it could be even simpler to test the solution hypotheses by not to even building an app, but by sending an SMS or a WhatsApp message to the broker. An A/B test could be made to compare the closing rates of the brokers who received SMS notifications versus the closing rates of brokers that didn’t receive them.

We actually ended up implementing the SMS notification, it took us 10 days to implement, and right after that, we were able to test the hypothesis that the faster a broker received a lead and interacted with the customer, the greater the chances of closing a deal.

The best discovery method is called delivery

I already mentioned that one of the reasons to deliver early and often is that the moment of truth for your product is when a product is in front of its users, being used in the context where it is supposed to be used. It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

So the best way to discover if a solution hypothesis works is actually implementing it and presenting it to potential users that may have the problem that you discovered during the problem discovery.

For many solution hypotheses, we don’t need to build a complete product to test. Today there are many low-code and no-code tools that allow us to build simple solutions. And some of these tools exist for quite a while, like presentations and forms. At Gympass we tested some solution hypotheses that we had to solve the problem we discovered of bringing new options to people that didn’t want to go to the gym but wanted to pursue a healthier lifestyle.

The solution hypothesis was to partner with wellness apps and provide this app to our users for a monthly subscription fee. This new idea had two main hypotheses that we needed to test:

  • Application providers willingness to partner. Application providers, like gyms, are used to the recurring monthly revenue model. Would they accept to be paid per day of use?
  • Our user base willingness to pay. Is our user base interested in paying a monthly fee to access the applications?

To test our first hypothesis, we built a deck with the value proposition that we planned to deliver to the partners and talked to some potential partners. We presented the opportunity to 8 potential partners, of whom 6 showed interest and 4 decided to join our proof of concept. NEOU, a workout app, 8fit, a workout and nutrition app, Tecnonutri, a nutrition app, and ZenApp a meditation app.

Okay, our first hypothesis was validated with just a simple slide deck. No product was built. Now we needed to validate the second hypothesis, the willingness to subscribe. Is our user willing to pay to access these applications through Gympass?

To test our second hypothesis, we built a simple form, where we described the product and asked for the user’s name, email, and company. After the user provided this information, he was directed to a Paypal subscription page, where he had to provide his credit card details to subscribe to the service. The user would receive an email with the activation link for each application. There was no real product, no logged-in area, just a form to test interest and an email with links to the applications.

The first version of Gympass Wellness

So use the no-code or low-code tools options available to build your solution hypothesis to make it easier and faster to go through the solution discovery. As a side-effect, business people will start to understand, appreciate and even want to participate in your next discoveries.

Summing up

  • Business people dislike discoveries because of 3 main reasons. (1) They believe they know more about the business, the clients, and what they need. (2) They may have had past experiences where the discovery took too long. (3) They are used to a “business demands => technology implements” model.
  • Changing this mindset requires patience and repetition. Three things a product manager should do continuously to help change this mindset. (1) Ask why the person is asking to implement the demanded feature. (2) Learn about the business. (3) Shorten the discovery process.
  • In order to shorten the discovery process, we should think in terms of an MVD mindset, i.e., minimal viable discovery, where we discover enough about the problem in order to generate and test the solution hypothesis as fast as possible.
  • The best discovery method is called delivery. The moment of truth of any solution hypothesis is when we are able to present it to the potential user in her own context where she faces the problem we want to solve. Today we have many low-code and no-code solutions that help us build our solution hypothesis to make it easier and faster to go through the solution discovery.
  • As a side-effect, business people will start to understand, appreciate and even want to participate in your next discoveries.

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.

Mentoring and advice on digital product development

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

Growth: be a “data geek”

Take a close look at the data that your product generates! Aside from talking to your users and hearing their feedback, a mandatory way of knowing your product and how your users interact with it is through data. To take advantage of these data you must become a data geek, a person who knows in depth the data generated by the application and their meaning.

In God we trust. All others bring data. — W. E. Deming

William Edwards Deming is an American engineer, statistician, and professor known for his work in Japan right after World War II when he taught about statistic management of quality and helped the Japanese to become the second larger economy in the world in only 10 years. It’s all about collecting and trusting valuable customer data.

Which data is important?

Every data is important, but depending on your goal, some are more important than others. Knowing your data is a continuous task because at each new information you acquire, new questions appear that are going to need more data to understand it.

One of the first pieces of information that you will want to know is how many visits you get to your product’s website. To know these numbers, you can use some statistic reports that your hosting provider offers. Another very common option is Google Analytics.

With a report like that in hand, you get some important information, such as the number of visits, amount of unique visitors, amount of page views, among others. Depending on the statistical system you are using, you will also check:

  • what is the first and the last page visited during the access to your website;
  • where (which country and city) your visitors come from;
  • if they accessed your website due to a Google AdWords or Facebook campaign;
  • or some other online campaign that you are running;
  • or if they found your website organically, that is, typing the address directly;
  • or searching for something in some search system.

It is good to remember that it is important to hold these reports not only for your website but also for your entire software product.

Be careful. Many of the visiting report systems show a great amount of information, and it is easy to get lost in this sea of data.

Along with the number of visits and access that your website holds, other important data you must know about your web product is:

  • Amount of people who discover your product: it is possible to differentiate the way people discover your product by dividing them into two categories, paid and free. The paid ones are those which you have to invest some money, such as on Google AdWords, Facebook ads, ads on content websites (preferably those linked to the theme of your product), and ads on magazines (also preferably linked to the theme of your product). The free ones are those in which you invest time and work to get to be known, such as creating relevant content on the theme of your website, interacting on blogs related to the theme of your product, making it easier for people to recommend your product to others, etc. The return in this case comes slower but holds the advantage of not having any financial cost, only time and work.
  • Amount of clicks generated by ads or other sources: this is information a little more difficult to obtain because depending on the strategy to attract people to your website, it will not be available. The online ad systems such as Google AdWords, Facebook ads, and ads on content sites usually have that information available, and the price they will charge usually will be set on a price per click.
  • Amount of unique visitors: they are the new visitors that your website gets. It is different from the number of visits: one single person can visit your site more than once until he/she decides to buy anything.
  • Amount of visitors who become users: from these unique visitors, some will register to become a user of your system. If you offer a free trial period or a free version with no expiration date, this number can be reasonably big.
  • Amount of users who become clients: by the end of the trial period, some of your users will want to become a client, that is, will want to pay to use your service. If you are offering a free version of your product, with no expiration date, you must have a paid version that pushes your users to leave the free version and pay for using your product.

Conversion funnel

Napoleon Bonaparte, a French political leader and military officer known for the Napoleonic Wars — through which he was responsible for establishing the French supremacy over the major part of Europe at the beginning of the 19th century –, had a great defeat in 1812, in the Russian Campaign. This campaign was a huge military operation designed by the French and their allies that had a great impact on the Napoleonic Wars, setting the beginning of the decay of the First French Empire. In this campaign, Napoleon brought 580,000 soldiers, but only 22,000 survived, and the rest perished in the way from France to Moscow due to the difficulties found on the way (cold, rain, rivers, etc.).

Russia’s campaign

This image resembles very much a conversion funnel of a website, which can be built with the data we discussed previously. The conversion funnel shows us how many potential clients we are losing on the way of attracting people to the site until the point someone pays to become your client:

Conversion funnel

The funnel displays several opportunities for you to better understand how your users interact with your product. Each part of the funnel has its specific characteristics and can be expanded in different ways. Focus on one piece at a time and test it. In the worst-case scenario, if the test goes bad, you can always come back to the previous situation. For a data geek, the funnel must be the very first data focus to be collected and analyzed.

In the next chapter, we will see two other metrics that are the natural consequence of the conversion funnel: engagement, which shows how the user utilizes your product; and churn, which shows how many users are not using it anymore, helping to identify why this happens.

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.

Mentoring and advice on digital product development

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

Growth: how to prioritize the roadmap?

This is a frequent question from every product manager. Whether is a new product that’s is being created now, or a fully operating product full of suggestions from clients and users, how to prioritize, that is, how to decide what to do first?

There is a great number of techniques. I’ll talk about a few here and, in the end, I’ll tell which one is the best. I only ask you not to jump to the end of this chapter so you won’t ruin the surprise… 😛

Value versus effort

One of the simpler ways of prioritizing a roadmap is making an analysis of all items, seeking for estimating: the value (benefit) of each one for the business and for the users, and the cost of implementing each item. With these data in your hands, it is possible to even build a graph with two axes and put each and every one of the items in it based on the value and on the cost. The idea is to always prioritize what has the bigger value and lower cost, for the benefit will be obtained more quickly.

Value versus cost chart

Kano Model Analysis

Kano Model was created by professor Noriaki Kano, from Tokyo University, to classify the items of a product based also on two dimensions, the need of an item and the excitement that it provides to clients. With this, it is possible to classify the items into three types: basic; satisfies, and delighters.

Kano Model Chart

For instance, in a car, the wheel is a basic item, for there is no car without wheels. The sunroof is a satisfier item if your client does not consider it valuable. Being very silent is an item that delights a client that appreciates it. The recommendation is to have all basic items, some satisfiers, but do not leave some delighters out if you want to positively impress your client.


When I arrived at ContaAzul, I came across another prioritization method adopted by the product team, RICE. RICE stands for Reach, Impact, Confidence, and Effort. The first three items of the matrix are scored and, in the end, divided by the last.

Reach refers to how many people that task will reach over a given period of time, which should be the same for all features being compared. Impact estimates how many people will be impacted (use 3 for a massive impact, 2 for a large impact, 1 for a medium impact, 0.5 for a small impact, and 0.25 for a minimal impact). Confidence addresses how confident you are about your estimates (choose from 100% for high confidence, 80% for medium, and 50% for low). In Effort, enter how many person-months the task will take to complete with a minimum of 0.5, ie one person per half month.

The mathematical calculation is very simple:

RICE = (Reach x Impact x Confidence) / Effort

Feature Sequencer

Feature Sequencer was created by Paulo Caroli, from ThoughtWorks, to plan a product based on deliverables and its features. The sequencer rules, such as three cards per line, foster the prioritization conversation.

According to the Lean Inception: How to Align People and Build the Right Product book, the Feature Sequencer helps you organize and visualize the features and their relation to the deliverables. The sequencer organizes and plans the product releases beyond the first deliverable. Typically, teams using the feature sequencer will dazzle the product evolution via a clear understanding of the features contained by each deliverable, and the release order.

Sample feature sequencer

The previous image has a sample feature sequencer; each feature is represented by an index card. The post-its on the right-hand side represent the deliverables.

Product tree

The idea is kind of like the Kano analysis: classifying items of the roadmap according to the parts of a tree. Roots are the infrastructure; the stalk provides support; the branches are the different paths in which you can put your product in; the leaves are the features themselves, and the flowers and the fruits are the features that are going to delight the customer. Every product has to have roots, stalk, and some branches with their respective leaves, but it’s important to always add on some flowers and fruits in order to make your product delightful.

Example of product tree

Buy your features

In this technique, you make everyone play a game. You show all the items in your roadmap and set a value for each one based on how much is going to cost to build it. Then, invite some clients and tell them they have X to spend. This X must be substantially less than the sum of the value of all your items.

With this X, each client has to buy the most important features and, as the money is limited, everyone is forced to make choices such as “Do I take these two features or trade them for this more expensive one?”. It is a very interesting exercise and provides good knowledge of client behavior.


UserVoice is a suggestion system that you can put in your product. With this, your user will be able to make suggestions about it, and will also be able to vote for suggestions from other users. You can still limit the number of votes, forcing them to make choices, like in the previous method.

Example of suggestion in UserVoice

The one you remember first

Jason Fried, the founder of 37signals, now renamed as Basecamp, said in his book Getting Real[ that in his company the option was to prioritize based on remembrance. They receive several suggestions every day and simply decided not to write them down so they won’t spend time counting and classifying them.

As suggestions come up every day, they hear them every day. From time to time, they get together and discuss the suggestions they remember, and these are the ones that are approached and eventually prioritized in the product’s roadmap.

The best prioritization technique

As you can see, there are many ways of prioritizing a roadmap, all very useful. In other words, what we can conclude is that if there are so many ways of prioritizing a roadmap and if all prioritizing ways can be useful, it means that prioritizing a roadmap is not an exact science.

We are eager to find a prioritization method that justifies our choices. However, every time this method fails in a certain item that we are sure it is best to do it before (or after) then the method tells us to do, we end up tempted to follow our certainty, ignoring and not following the method.

However, there are several roadmap prioritization techniques and methods, and the best method is common sense. That is, the ability the product managers have of analyzing the available options and, by using their empathy, they prioritize these options taking into account the company’s goals and the users’ needs.

What to do with special requests?

During the lifecycle of your product, you will certainly meet requests of new features coming from clients (or the commercial team) that, explicitly or not, come with a threat that if you don’t build this feature you will lose them. On the other hand, if you meet this demand to the detriment of all roadmap planning already made, you are risking to delay the delivery of important features to the rest of the clients and to the strategic goals of the software product owner.

What to do?

The answer to this question depends a lot on your product and your client base. I’ll explain this answer with an example.

At Locaweb, we have two e-mail marketing products. One of them is called ** Locaweb’s E-mail Marketing** (very original name, hum?), and the other one is the All-In Mail. To understand the dimension of each product and the type of client that each one of them attends, here are some figures.

Comparative table of different e-mail marketing product offers from Locaweb

In this table, we can see that although the E-mail Marketing from Locaweb has 75 times more clients than the All In Mail, it sends only 16,7% of the total messages sent with All In Mail. In other words, Locaweb’s E-mail Marketing holds much more clients than All In Mail, but they are small clients that use the product very little compared to All In Mail’s clients.

For that reason, the product manager of Locaweb’s E-mail Marketing cannot afford to attend to special requests. The manager cannot favor the request of one single client to the detriment of the other 29,999. The product manager in this case must be concerned with implementing features that attend to as many clients as possible. And the product manager of All In Mail not only can but must pay full attention to special requests. There are a few clients, but all of them are special and demand customized attention.

The problem of saying yes to everything

When we talk about prioritizing a roadmap, one thing that happens is that we end up answering to every request, from everyone. That is, everything is important because everything is added to the roadmap, and then the less important things are postponed. The person who requested has the confidence that “it’s in the roadmap”, although it was pushed upfront on the line, and has good chances of being pushed even further if some more important item comes up.

Why does this happen?

The product manager ends up saying yes to requests he/she gets for several reasons:

  • Needs to please everyone: this is a very common problem of product managers, the need of pleasing everyone. When product managers see that the answer “I’ll put it in the backlog” calms down people who are requesting something, they start to use this answer indiscriminately. Then, the roadmap will become huge and very complex to manage. In addition to that, when people realize that being in the backlog doesn’t guarantee that it will be done soon, they won’t be happy… :-/
  • The data show that we must do: more and more I see companies focused on making decisions exclusively based on data. Therefore, soon we can be replaced by algorithms that will make all decisions, since it is enough to make them all based on data. It happens that data are not always correct. They can be insufficient, or even wrong. Another problem of decisions based in data is the risk of falling in a great place. The suggestion is to use data as one of the inputs to make a decision, but not forgetting the qualitative data, your intuition and your judgment.
  • But it is such a small feature: every feature, as small as it is, will imply in more code and more interaction. More code means code complexity; as the code gets more complex, it is more difficult to maintain it. More interaction means more complexity for its user to work with, that is, more chances of offering a bad experience to the user. No feature is so small for not bringing code and interaction complexity, so think carefully if this additional complexity will bring benefits for your user and for the software owner.
  • The client requested and, if we don’t build it, he’ll leave: this is the moment of making tough decisions. If you want to please all your clients, you’ll end up pleasing none of them. You have to choose to whom you are building your product. A product cannot have more than two or three primary personas. By the way, the recommendation is to have only one primary persona; having two or three will be quite difficult to manage. If the client’s request does not attend your primary persona, you have to have the courage to say no.
  • We can always turn this new feature into one more option in the configuration: one more time, we are creating pointless complexity. As we said, every feature implies in code and interaction complexity. Putting all new features as options to be configured in a set up screen will turn this screen into something very difficult to its user.
Set up screen of a software
  • Our competitors already have it: this is a very common mistake, to base yourself on competition and not on your client/user. Remember: a product manager has to worry about making the software meet the goals of the company that owns it, at the same time he/she solves a problem or fulfil a need of the clients. It is important to know what the competitor is doing, but if it has nothing to do with your company’s goals, nor the problems or needs of your client, then you don’t have to do the same.
  • The boss wants: there are bosses and bosses. If your boss is extremely up to date regarding the clients, it is important to listen. But if your boss wants a certain feature just because he/she saw it in some competitor, or someone told him/her to do so, you should remind him/her of the company’s goals and the problems and needs of your clients that you are trying to meet with your software product.

Learning how to say NO!

In spite of all the reasons we saw here, in order to say yes to each and every feature request, a product manager has to learn how to say NO.

Saying NO seems difficult, but not if you have your product goals very clear, that is, which company goals your product must reach, who is your main client and what is the problem of this client you are trying to solve, you’ll have the necessary arguments to say NO to certain demands.

Be kind to the person who is bringing the demand and say something like:

How to say no

Your suggestion is interesting and I can see why you are giving them. However, let me show you what we have already planned in our roadmap, and which are the goals of each item in it. For this reason, we will not be able to pay due attention to your request right now. Remind me in the future so we can talk about this again, ok?

Pass on the responsibility for remembering the conversation again in the future for the person who is requesting the new feature. If he/she does not remember, it is because his/her request was not that important. If he/she remembers, evaluate the request again and, if necessary, say NO again.

Dealing with B2B customers’ special requests

I mentioned earlier that if you have a B2B product focused on bigger customers, the product manager “must pay full attention to special requests. There are few customers, but all of them are special and demand customized attention. The product manager must be careful and not implement features that will be used by only one customer. However, requests from one customer, especially the bigger ones, will always be a priority in this scenario.”

How to manage these special requests

So this means that the product manager should do everything that big customers demand?

The short answer is *NO! You are still managing a product, so two important aspects of product management still apply:

  • Demand normally comes in the shape of solutions, and big customers can be quite incisive describing the solution they want. It’s the product manager’s job to understand what’s the underlying problem that made the customer request that specific solution. Quick tip: ask why the customer needs that solution and what she will do as soon as she gets that solution. This will give you lots of insights on the customer’s problem.
  • You are managing a product, not a tailor-made software. If you implement each and every feature request from customers, you’ll be building a tailor-made software for each customer or, what’s even worse, a “frankenstein software” product.

The longer answer is no, but you’ll still have to manage the special requests. There are some techniques that can help you deal with these special requests:

  • Modularization: if you are able to build your product as modules that work together in different combinations to deliver different types of solutions, this will enable your sales team to mix and match the modules to fit the needs of your customers. And whenever a new feature request comes, and you figure out the underlying problem and decide to build a solution for that problem, you can build it as a separate module. You can even charge this customer for the development of this new module. Charging a customer for the development of a new solution, even considering that this new solution can be offered to other customers, is a good way to test the real need of this customer. If he is willing to pay you to deliver this solution, he really needs this solution and trust you to build it. SAP is a good example of modular solutions.
  • Advanced configuration: another way to customize your product without making look like a “frankenstein software” product is through advanced configuration. For instance, for a certain customer, feature X can be delivered as the sequence of step A, step B and step C. For another customer, that doesn’t want feature X, but needs feature Y, it can be delivered by the sequence of step C, then step E, and you turn off feature X for this customer. Depending on the complexity, it is possible also to deliver this advanced configuration through programming languages. Some examples are, again SAP, with its ABAP (Advanced Business Application Programming) and Salesforce with Apex, which enables developers to add business logic to most Salesforce system events, including button clicks, related record updates, and Visualforce pages.
  • Integration: another common need from big companies is to have your product integrated with other products they already use. For instance, let’s imagine your company provides ecommerce solutions. Your customer hired your ecommerce product and they will have all of their product catalog, and also data on customers and their purchases in your ecommerce product. This big customer will certainly ask you to integrate your ecommerce solution into their ERP, so they can invoice customers and manage their inventory. This integration can be done in many ways, completely manual through re-typing of data, through file exchange or using an API integration. The best solution is through API, since it provides an error-free and real-time solution for the data integration between systems. For this reason, it is very important that your product has APIs with the endpoints needed to connect with other systems.

Technical Sales (or Sales Engineering)

New special requests come up during the sales process. Each of these special requests will take time from the product manager as well as the product development team. The team needs to understand the special request, the underlying problem and design solution options that can be used with other customers. This will take time from the product manager and the team.

At a certain point, the team will use the above-described techniques to cope with the special requests in a scalable way. As soon as the team starts using these techniques, the need to interact with customers for each request will probably persist or even increase. The sales team will ask the product manager to have meetings with the customer and help them show the customer what are the technical options available in order to address the request.

The first step is to train the sales team. However, this won’t be enough. The product manager will continue to be asked to join meetings to answer technical questions. To help with this issue, we should create a new role, the technical sales, also known as a sales engineer or pre-sales, someone with a technical background who will engage in technical discussions with the customer during the sales process.

Sometimes this role, since it has the sales word in it, is placed under the sales leadership. It’s a possibility but can lead to misalignment of incentives. Under sales leadership, the incentive is the number of sales. So, if a tech seller is taking too long to design the solution, and other requests get delayed, a new tech seller is hired, increasing headcount and, consequently, the cost of selling. An alternative is to place this position under product management leadership so the focus is on sales enablement, i.e., to provide the sales team with the needed tools to conduct sales without the need for a tech seller.

Professional Services

Supposing everything goes well with the negotiation and the customer decides to buy your product, if there are customizations to be made, additional work is required, no matter if it will be through modules, through advanced configuration, and/or through integration. This work may end up falling into the product development team backlog, which is not ideal since this work is specific to address a certain customer request, while the product development team should be working on things that could be used by the majority of customers.

To help with this issue, we should create a second role, called professional services. A person with this role works on this type of project, setting up a new customer using the customization techniques from the product (modules, advanced configuration, and/or integration). They should be people with technical skills able to do the customization work needed to set up the new company. Professional services can be done by a team within the company that offers the product and/or by third parties. For instance, to implement SAP, Salesforce, or Zendesk, you can choose to use professional services from them or from certified third parties that have knowledge and experience in implementing and customizing their software in many customers. This work is normally billed as a setup fee.

Summing up

We saw many techniques to prioritize a roadmap. Prioritizing a roadmap is not an exact science and we learned that the best way to prioritize a roadmap is pure and simple common sense, i.e., building a roadmap that aligns the company’s goals and objectives while solving a problem or fulfilling a need of clients and users. We also learned how to say no to prioritization requests and what is and how to deal with special requests.

Dealing with special requests may be a need of your market, especially if you are in the B2B space with bigger customers. It is possible to build a product that fits these special requests without building a “frankenstein software” product. In order to do that, the product manager and product development team should use one or more of the known techniques to deal with special requests, modularization, advanced configuration, and integration. Having these techniques in place won’t probably be enough, since the sales team will still need help in order to present the options to the customer and, after the sale, to implement them. Then two new roles come up, that should be close to product management: technical sales – or sales engineer – and professional services, which could be internal, could be done by third parties or both.

Next topic: Data!

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.

Mentoring and advice on digital product development

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

Uncertainty and digital transformation

One aspect of digital transformations that seems to be common-sense among people who are in or who help companies go through this process is that what is most difficult is not the digital and technology changes, but the cultural and mindset changes needed to make a successful transformation. In this article, I’ll go a bit deeper in these needed cultural and mindset changes in the hope that we can better understand and tackle the obstacles that hinders the journey through successful digital transformations.

I worked almost my entire career in tech companies, i.e., companies where technology was the product. My own company, back in the early 1990s, was an internet service provider. Then I worked at a data center called .comDominio which was eventually acquired by Equinix. After that, I worked at Locaweb, the biggest internet service provider in Brazil, and Conta Azul, an ERP platform that connects small business owners to their accountants and everything they need to run their business. I joined Gympass in 2018. Gympass sells a corporate benefit to companies, so they can offer to their employees access to a network of gyms and studios, and more recently other well-being services like meditation, nutrition, and mental health support. For Gympass, the technology is not the product, it is a tool to potentialize their core product. That got me thinking about the power of digital to substantially potentialize non-digital businesses. And that was my main motivation to join Lopes, the biggest real estate company in Brazil, a company founded in 1935 that made a follow-on offering in the stock market in late 2019 to raise funds to invest in their digital transformation. I’ve been working at Lopes since mid-2020 and I’ve been learning a lot in this digital transformation journey.

The impact of uncertainty in different industries

An interesting article on HBR about The Industries Plagued by the Most Uncertainty presents a chart where many industries are shown according to their technology uncertainty, measured by the industry’s research and development (R&D) spent as a percentage of revenue, and its demand uncertainty, measured as an equal weighting of industry revenue volatility, or change, over the past 10 years and percentage of firms in the industry that entered or exited during that same time period.

Demand and technology uncertainty by industry

As we can see, in the top right region of the chart we can find Computer and Software industries, next to Pharma, Medical Equipment and Transportation industries. These are the industries where we have to invest the most in R&D and the demand is the most uncertain. Computers and Software are the newest ones. Pharma, Medical Equipment, and Transportation are more traditional ones, having Technology and Demand uncertainty similar to Computer and Software industries.

When we look into other more traditional industries, like Banking, Insurance, Retail, Entertainment, Real Estate, and Construction to cite a few examples, they present lower technology and demand uncertainties.

Digital transformation is more about transformation than about digital

When a traditional company decides to enter the route of digital transformation, one thing that needs to be clear is that this route is more about transformation than it is about digital. The digital aspect is very important since technology is central in any digital transformation. However, it’s relatively easy to find knowledge and experts that can help understand and tackle the technical aspects of a digital transformation. On the other hand, the transformation aspect of any digital transformation requires business and cultural changes which are considerably more difficult to implement. And to make things even harder, there is not much knowledge available about this topic, so we tend to credit its difficulty to a somewhat generic cultural and mindset cause, which is correct, but insufficient to help us deal with the matter.

The demand and technology uncertainty chart can help us understand why the business and cultural changes in a digital transformation can be so difficult. The traditional company is normally used to a certain level of technology and demand uncertainties. However, when entering the digital world, the level of demand and technology uncertainties increases considerably:

  • Computer and Software industries demand uncertainty is very high, one of the highest of all industries, which means that the software produced not always achieve its objectives. This success rate has been improving in more recent years with the evolution of digital product development and management techniques and mindset, but there are still many digital products that either fail completely or partialy in achieving the expected results and strategic objetives. This can be very frustrating to a company in an industry with less demand uncertainty. In order to minimize the demand uncertainty we’ve been using the realease early and often mindset, which people from more traditional industries need to understand and adopt in order to cope with the demand uncertainty of the computer and software industries.
  • The technology uncertainty will require from the traditional company an understanding that (1) it will have to invest and (2) investment in digital products are multi-year investments. To illustrate this need for investment and it’s multi-year aspect, I’ll use 2 examples. The first one is Amazon. It was founded in June, 1994 and started operating in July, 1995. Had an $8M Series A investment round in Jun, 1996. IPO was in May, 1997 and then Amazon received a $100M in a post-IPO Equity investment in Jul/2001 and only showed a profit in 4Q2001 results report. So, from founding to profit it took 7,5 years and $108M investment plus money raised from angel investors and in the IPO. The second example is Nubanlk, a Brazilian digital bank founded in May, 2013 which started operating in 2014. Raised $1.87B from Series A through Series G. IPO was in Dec, 2021, and then Nubank received a $1B in a post-IPO Equity investment in Feb, 2022. Its 1st post-IPO report presented a $66.2M loss for 4Q2021. So, from founding to its IPO, it took almost 8 years and $2.87B plus money raised from angel investors and in its IPO. Even after all this time and money invested, Nubank still doesn’t show postive results. Please note that both companies are what I normally call “traditional born-digital” companies, i.e., companies which its core industry is not computer or software, but who were founded already with digital as part of their satrategy to potentialize results. Amazon is in the Retail Industry with low technology uncertainty and mid demand uncertainty and Nubank is in Banking industry witgh low technology and demand uncertainties, based on the demand and technology uncertainty by industry chart presented above.

The more distant an industry is from the Software Industry in the chart, the bigger the transformation change needed, i.e., the company needs to (1) understand that digital product development may not bring the desired results and (2) digital products take time to provide a return on the investment.

People also face digital transformation

I’m talking here about companies going through digital transformation and the challenges theses companies face during this transformation but companies are made of people, so the digital transformation actually happens to people who need to understand the demand and technology uncertainties that charechterize a digital transformation.

This fact that people go through digital transformation seems obvious when we talk about traditional companies, specially the ones that have decades of existence like bank, retail, drugstore, bookstore, real estate, insurance, restaurant and so on.

However, besides traditional companies, there are also two other types of companies:

  • tech companies which sell technology, i.e., technology is their core. Some examples are Google with its main product, Google Search and GMail. Amazon Web Services. Facebook. Instagram. WhatsApp. SAP. Salesforce. Zendesk. The companies I worked for (Locaweb and Conta Azul).
  • born-digital traditional companies which have traditional products or services that can exist without technology. However, as they have included technology since their beginning as a strategic capability, they look like digital companies. Examples are Amazon and Nubank that I cited above. Additional examples are listed in the image below:
Born-digital traditional companies

When we consider that digital transformation happens to people who are part of a company, it’s clear to see that born-digital traditional companies and even tech companies also face digital transformation. Many people who work in these companies probably came from more traditional industries with less demand and technology uncertainties and will have to adapt to a more uncertain context. For instance, to build Nubank, many of its employees, including C-level and founders, came from the banking industry like Cristina Junqueira who worked for Itaú prior to founding Nubank. Another interesting example is Google’s CFO Ruth Porat who worked at Morgan Stanley prior to joining Google.

Being able to understand the previous context of the people who are working on a digital transformation may help cope with the struggles and issues that we may face in a digital transformation, especially with its transformation aspect.

Summing up

  • The digital aspect of digital transformation is relatively easy since there are tons of knowledge and many experts to help design, develop and implement digital products. Product management and development techniques have been evolving at a rapid pace.
  • The transformation aspect of a digital transformation is harder since there’s not much knowledge about it and we tend to credit its difficulty to a somewhat generic cultural and mindset cause.
  • Demand and technnology uncertaintIies of the software industry is what makes digital transformation difficult. Traditional companies that are in more certain contexts struggle to understand, and consequently to cope with, these uncertainties.
  • Born-digital traditional companies and even digital companies also face digital transformation issues since the people who work in these companies, including C-level and founders, may come from companies in contexts where demand and technology are less uncertain.
  • Being able to understand previous context of the people who are working on a digital transformation may help cope with the strugles and issues that we may face in a digital tyransformation, specially with its tranasformation aspect.

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.

Mentoring and advice on digital product development

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

Cone of Uncertainty is another reason why we need to deliver early and often

I already wrote about 3 reasons why it is important to deliver your product early and often to your users. Now I want to give you a 4th reason, based on the Cone of Uncertainty concept from the project management world.

First, let’s understand what is the Cone of Uncertainty:

In project management, the Cone of Uncertainty describes the evolution of the amount of uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease. (Wikipedia)

In an image, we can picture it like this:

Cone of Uncertainty

This image shows that the farther away we are from the end of a project, the bigger the uncertainty. At the beginning of a project, the uncertainty ranges from 0.25x to 4x. For instance, if we are estimating the delivery time for a specific project as 4 months, at beginning of the project this estimation will range from 1 month to 16 months. This is A LOT of uncertainty!

However, this is the theory. When we analyze projects in real life, the majority of them have their estimation smaller than what actually happens. It’s quite rare to see projects being delivered before their original estimation. So we can better represent the Cone of Uncertainty as follows:

Cone of Uncertainty in real life

This picture shows that the probability of an estimation being 2x to 4x times what was originally estimated is greater than the estimation being right or even greater than what actually happens. That’s the reason why many people, when providing an estimation, tend to increase this estimation to increase the chances of the estimation being more accurate.

The solution: releasing early and often

The best way to reduce uncertainty is to release early and often. Besides the 3 reasons I already explained previously:

  • Moment of truth: you will only get real feedback when your product is in front of people using it in their own context.
  • Too many features: the more feature you add to the product, the bigger the chances to add unnecessary features.
  • Return on investment: the earlier you release some part of your product, the earlier you’ll start to recover your investment in you building this product.

To add to these 3 reasons, let’s check what happens to the Cone of Uncertainty when we release early and often:

The iterative approach to the Cone of Uncertainty

As we can see, when we deliver early and often, we are lowering the range of uncertainty. In the example above we lowered the range of each delivery from between 0.25x and 4x to 0.8x to 1.25 times. This approach is very well suited to digital products because we can break down deliveries to the smaller delivery possible.

So there we are, the fourth reason to deliver early and often is the Cone of Uncertainty, the earlier you release some part of your product, the smaller will be its uncertainty.

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.

Mentoring and advice on digital product development

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

What’s the difference between product and project?

I already wrote about the difference between product management and project management but I believe there’s room to go a bit deeper on the differences between product and project. So, a quick remembering of the definitions of product and project:


A project in business and science is usually defined as a collaborative venture, often involving research or design, that is carefully designed to achieve a particular goal.

Source: Wikipedia


The term product is defined as “something produced by work or effort” or as “the result of an act or process” and has its origin in the Latin verb produce(re), ‘make exist’.

Source: Wikipedia

That is, while the project is a process with a beginning, and an end; the product is the result of a process.

Product and project differences

The above definitions can be expanded to help understand a bit more the differences:

  • While in a project we focus on the delivery with a well defined path, in a product we focus on the result with well defined objectives.
  • While in a project we have a clearly defined scope during the planning, in a product we use tests and idea validation to define next steps.
  • While a project approach may work in predictable situations, a product approach is useful in more volatile contexts.
  • While a project has clear and well defined end, a product is not designed to have a finite end in the foreseeble future.

To help us better understand these differences, I’ll provide one example from the tech world and two analogies from our daily lives.

  • At Locaweb, from the very beginning to around 2007 we used third-party Data Center services to host all of our services. As we grew, it made more sense to build our own data center and move our servers to this new data center, where we had better control and lowered costs. Building Locaweb’s own data center and moving all the servers to this data center can be easily identified as a project. On the other hand, all Locaweb services (Hosting, E-mail, eCommerce, etc.) can and must be managed as products. Even the data center, after being ready, was (and is) managed as a product.

And now the two analogies from our daily lives to help illustrate the difference between project and product::

  • A new apartment building construction is typically a project, including all the planning needed not only to build the building but also to sell all its apartment units. On the other hand, as soon as the building is ready for use and families move into their new apartments comes a phase where we can view the building as a product: apartment maintenance, condo management, renting, acquisition.
  • When two people get married, it’s easy also to see a project and a product. The marriage ceremony, party, honeymoon, moving in together, all of these events must be managed as projects. On the other hand, your daily life with your marriage partner, living together, growing a family, having children, grandchildren can be seen as a product.

Finite and infinite games

Simon Sinek, author of “Start with Why” and “Leaders Eat Last”, launched in 2019 a very interesting book called “The Infinite Game” where he built on top of the argument from the classic book “Finite and Infinite Games”, by James P. Carse, an American academic who was Professor Emeritus of history and literature of religion at New York University. In his book, Carse explains that while a finite game has an end and a clear winner, like sports, politics, and war, infinite games, like our life, cities, countries, carreer, are those activities that has no clear and defined end and not necessarily a winner. According to Carse:

A finite game is played for the purpose of winning, an infinite game for the purpose of continuing the play.

Sinek “started to see that many of the struggles that organizations face exist simply because their leaders were playing with a finite mindset in a game that has no end. The leaders who embrace an infinite mindset, in stark contrast, build stronger, more innovative, more inspiring organizations.”

It’s easy to see that projects are finite games while products are infinite games.

When I’m asked about the difference between a project and a product, I’ve been using the two analogies above, apartment building and marriage to help illustrate these concepts, with good feedback. Hopefully now that I was able to write down these concepts and analogies, they can help more people.

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.

Mentoring and advice on digital product development

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

Growth: listening to your users’ feedback

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

Success! No…

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

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

Lifecycle of a digital product

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

Dealing with user feedbacks

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

Answer quickly

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

Don’t make things up

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

Be polite

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

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

Don’t implement every suggestion you get

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

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

If you want to implement a suggestion system, there is UserVoice (, which is for free.

Feedback is not only what the user tells you

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

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

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

Interact with your users through several media

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

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

Example of hurry to act due to feedback

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

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

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

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

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

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

Crossing the chasm

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

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

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

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

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

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

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

Digital Product Management Books

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

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

Mentoring and advice on digital product development

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