How to measure a company’s digital maturity?

In my last article, I discussed the digital maturity of a company, which means how much the company has been investing in digital products to potentialize its results and how much the results have been actually potentialized by digital efforts.

Even though it is a clear definition, we can go a bit deeper to understand and even quantify the digital maturity of a company.

Digital maturity and product culture

Product culture means the set of values and behaviors that enables the digital product to generate the best results for the company while solving customer problems.

There are 4 main values/behaviours that are mandatory to any company that builds successful digital products:

1. Release early and often

The sooner we present the product to our users, the better, as we can receive feedback from real users who will be able to use the product in their own context. In this article, I explain the 4 reasons why it is so important to release early and often: (i) this is the moment of truth, (ii) so you avoid the excess of features, (iii) to accelerate the return of the investment and (iv) to avoid the perils of the cone of uncertainty.

To measure if the product development team is releasing early and often, we need to measure the number and frequency of deploys. A company called DORA (DevOps Research and Assessment), acquired by Google in 2018, have been researching the DevOps and SRE practices used by companies since 2015 and was able to categorize companies’ software delivery and operational performance based on 4 factors:

  • Deploy frequency: how often does your organization deploy code to production or release it to end users?
  • Lead time: what is your lead time for changes (that is, how long does it take to go from code committed to code successfully running in production)?
  • Time to restore: how long does it generally take to restore service when a service incident or a defect that impacts users occurs (for example, unplanned outage, service impairment)?
  • Change fail percentage: what percentage of changes to production or releases to users result in degraded service (for example, lead to service impairment or service outage) and subsequently require remediation (for example, require a hotfix, rollback, fix forward, patch)?

Based on the answers, it is possible to have a software delivery performance metric, as detailed below:

Software delivery performance metric

DORA was able to gather during the seven years of research more than 32,000 survey responses from industry professionals and noticed an interesting evolution:

Evolution of the software delivery performance metric over the years

You can answer these questions directly on their site to check how your team is doing.

The more a product development team gets closer to the elite level described above, the more the company is digitally mature in this value/behaviour.

2. Focus on the problem

As explained in this article, a very important step in creating a good solution is understanding the problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution, and chances are good that this solution will be simpler and faster to implement than the first solution we thought of.

Solution implementation teams are teams working on implementing a solution designed by someone else. Problem-solving teams are teams that work to deeply understand the causes of the problem, the context, and the motivation that people have to solve it. In doing so, they are able to implement the best solution for the problem at hand.

I’ve been working for quite some time in companies undergoing a digital transformation or which have people, including C-level, not familiar with digital product development methods. One of the biggest challenges in companies undergoing digital transformation is moving from a “business demands => technology implements” mindset into a “business brings problems/needs => technology works on understanding these problems/needs with the user, testing solution hypothesis, and implementing a validated solution hypothesis” mindset.

How can we measure how much a product development team is focused on problems? My suggestion is to look into the past 10 to 20 things that the team implemented and check how the need for each of the things implemented arrived for the product development team. Did it arrive as a feature request, i.e., a solution implementation request? Or did it arrive as a problem to be solved? The more things arrived to the product development team as problems to be solved, the more the company is digitally mature in this value/behaviour.

3. Result delivery

Besides being able to deliver early and often and be focused on problems, the product development team has to deliver results. Business results as well as results for the client and user of the product. I discussed this value in this article, where I made it clear that delivering features is not a result. All features are a means that serves an end, the achievement of a business objective. It is very important that we have clear business objectives. Ideally, business objectives should be connected to the bottom line, i.e., increasing revenue and/or decreasing costs.

How can we measure how much a product development team is delivering results? My recommendation is to take a look at this product development team’s OKRs. The objectives and key results must be connected to the company’s results and the customers’ results. If we find OKRs that are tasks or OKRs that are metrics, but metrics that are not connected to the company and customers’ results, it is clear that the product development team is not focused on delivering results. Normally, a product development team has more than one objective and more than 3 key results. We can analyze all objectives and key results to check their connection with company and customer results as a yes or no. The more yes we find, i.e., the more objectives and key results we find connected to company and customer results, the more the company is digitally mature in this value/behaviour.

4. Ecosystem mindset

This value/behaviour means making decisions that create value for all actors of the ecosystem where the business operates. These decisions cannot harm any of the participants of the ecosystem. In this article I explained it at length with an example from Gympass. If the company is a platform or a marketplace, this value/behaviour is quite easy to understand, but it also applies if the business does not operate as a platform or marketplace. If you are a business with one type of customer, the ecosystem is formed by the customer and the business, and this value/behaviour means that you cannot make decisions that benefit the business but harm the customer or vice-versa. You can make decisions that benefit that business and doesn’t affect the customer, but you cannot harm the customer. And vice-versa, you cannot harm the business in benefit of the customer. This value/behaviour builds on top of the customer-centric concept but expand it to include all different customers and the business in this mindset.

How can we measure if the company has an ecosystem mindset? My suggestion in this case is to analyze the last 10 to 20 decisions made and check to whom they brought value and if any of them generated a negative impact in any of the participants of the ecosystem.

How to measure a company’s digital maturity?

Usijng the above values and behaviours, we can assess how digitally mature is a company and, more importantly, define what should be our focus areas to improve it digital maturity. Answer the 4 questions below to self-assess your digital maturity.

Release early and often: after taking the DORA’s DevOps quick check on the 4 factors (deploy frequency, lead time, time to restore and change fail percentage), how do you rank?

(a) Elite

(b) High

(c) Medium

(d) Low

Focus on the problem: how much of the product development team deliveries originated from solution implementation requests?

(a) 0%

(b) Less than 5%

(c) Between 5% and 50%

(d) More than 50%

Result delivery: How much of the product development team’s OKRs are connected to company’s objectives?

(a) All of them!

(b) More than 90%

(c) Between 50% and 90%

(d) Less than 50%

Ecosystem mindset: How much of the latest decisions impacted negatively one of the actors of the ecosystem?

(a) 0%

(b) Less than 5%

(c) Between 5% and 50%

(d) More than 50%

Now, for each (a) add 4 points, for each (b) add 3 points, for each (c) add 2 points and for each (d) add 1 point. The total indicates your digital maturity:

Digital maturity
13 or more pointsHigh: Congratulations. You have high digital maturity. This means that your company has been investing in digital products to potentialize its results and your company’s results have been greatly potentialized by digital efforts. Your focus now should be on constantly evolving you digital capabilities.
Between 12 and 6 pointsMedium: You are on the right path. Your company is starting to invest in digital products to potentialize its results and you are starting to see your company’s results being actually potentialized by digital efforts. Hopefully, by answering the above questions, you now have a good understanding on where to focus to increase your digital maturity and, consequently, improve your results from your digital products.
5 or fewer pointsLow: You are starting your digital journey. Your company is investing a bit in digital products to potentialize its results and you have not yet seen much of your company’s results being actually potentialized by digital efforts. The recommendation for you is that you should continue investing in building your digital product culture so you can get more and more results from your investment.

So there you have it, a simple way to assess your digital maturity.

Real life examples

I joined Gympass in mid-2018 and when I joined, it was clear there was room for improvement on our digital maturity. The same happened when I joined Lopes in mid-2020. In both cases we focused on improving the behaviours that could bring us to an incresced digital maturity.

Disclaimers and final remarks:

  • The examples above are from what I recall from the time I worked in these companies. Ideally, this type of assessment should be done considering current behaviours with answers from the leaders of the company and the product development team. This assessment should be made periodically, every 6 months or every year.
  • It is possible to have companies with the same digital maturity score, but with different behaviours to focus in terms of what to do to improve the digital maturity, as are the cases of Gympass and Lopes in the examples above.
  • More important than to know the digital maturity stage a company is or the score it has, is to know what are the main areas that the company and the product development team should focus to improve its digital maturity.
  • Knowing and improving digital maturity is just a tool, not an objective. It is a tool to help a company extract more its digital efforts. It’s a tool to help a company achieve its objectives and resultts.

Summing up

  • Digital maturity of a company means how much the company has been investing in digital products to potentialize its results and how much the results have been actually potentialized by digital efforts.
  • To measure digital maturity, we need to assess how the company is in each of the 4 values and behaviours of its digital product culture. Release early and often. Focus on the problem. Result delivery. Ecosystem mindset.
  • Knowing and improving digital maturity is just a tool, not an objective. It is a tool to help a company extract more from its digital efforts. It’s a tool to help a company achieve its objectives and resultts.

Digital product education, coaching and advisoring

I’ve been bridging the gap between business and technology through education, coaching and advisoring on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter:Email

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.

3 digital transformation lessons from Disney

Q2 2022 results from Netflix and Disney showed Disney with more streaming subscribers than Netflix. The chart below shows how the numbers evolved until this amazing milestone:

Disney and Netflix number of subscribers (source: EEAGLI)

This is an interesting case of an incumbent company, Disney, being able to face the competition of a disrupting tech company, Netflix.

During my career, and specially during my years leading Gympass and Lopes digital initiatives, I’ve been learning about the power of digital to potentialize the results of a company. When I heard about Disney’s results compared to Netflix, I wanted to check if my learnings apply to this situation, and it seems they do.

Lesson 1: the digital product is not at the center

There are 3 types of companies, as I explained in this article:

  • Digital: The product sold by the company is the software or technology developed by the product development team. AWS, GMail, Instagram, etc.
  • Traditional: The product sold by the company has probably existed for many years without the technology, but the company is beginning to understand how technology can power the product. Banks, airlines, media companies, etc.
  • Digital-born traditional: The product sold by the company could exist without the technology, but the technology greatly enhances the product. Netflix, Youtube, Amazon, etc.

When analyzing Disney and Netflix we are comparing companies of 2 different types, Disney as a traditional company and Netflix as a digital-born traditional. For these types of companies, technology and the digital product are not the core business. They are potentializers of the core business. So, when we discuss digital transformation we need to have business experts together with technology experts working together to figure out how to use technology to potentialize the business. It’s not technology subordinate to business, neither business subordinate to technology. It’s a collaboration.

Some traditional companies make the mistake of placing IT subordinate to the business, which I have already shown in another article that doesn’t work. On the other hand, some digital-born traditional companies may think that technology is more important than business, which is also wrong, and that brings us to Lesson 2.

Lesson 2: core business experience matters as much as tech experience

Technology is very important. It can change how we do business. It can disrupt how we do business. Blockbuster, once the leader in video rental, was disrupted by Netflix, a digital-born traditional comnpany.

Netflix and Blockbuster revenue between 1998 and 2016

However, technology alone is not enough. A deep understanding of the business is also needed.

Lopes is 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.worked at Lopes between 2020 and 2022 leading this digital transformation and learning a lot in this journey. Lopes is a traditional company, and is facing the competition of 2 very well funded digital-born traditional companies called QuintoAndar and Loft. Lopes has a lot of experience in the real estate market. Both QuintoAndar and Loft had to acquire this experience. Both acquired very traditional real estate companies in order gain this real estate business experience.

Disney was founded in 1923, and it has A LOT of experience in the media and entertainment market. Having the ability to combine this core business experience with technology experience is a sure path to good results, as it was for Disney in its streaming endeavours.

Lesson 2: technology investment takes time (and costs a lot)

Investment in technology takes time, due to the technology uncertainty, as I explained in this article with examples from Amazon and Nubank. Both Amazon and Nubank are digital-born traditional companies and they understand that investing in technology takes time.

For traditional companies it’s a bit more difficult to bear this long time investing without having clear results. This uncertainty makes people from traditional companies uncomfortable, which is natural. To be able to cope with this uncertainty, people from traditional companies need signs that the investment in technology – which is not low – will generate results in the long run.

Disney seems to be investing in internet technology for quite some time. Since its first website from 1996:

Disney’s first website, from 1996 (source: webarchive)

In 1999, Disney acquired Infoseek, a search engine, and Starwave, a web content producer, and started to gain some knowledge about internet. In 2015, Disney launched a streaming service in the United Kingdom called DisneyLife to test the streaming market. During 2016 and 2017, it acquired BAMTech, a streaming technology business. ESPN, a company acquired by Disney in 1996, launched Espn+, a streaming service, in 2018. Disney acquired Hulu, another streaming service, in 2019. Then, in November 2019, Disney+ was launched, and 2,5 years later, Disney was able to have more subscribers than Netflix in its 3 streaming services (Disney+, Hulu and Espn+). It may look that it’s a 2,5 years endeavor but if we consider that Disney has been investing in digital and internet since 1996, it’s more than 25 years!!! And it costs a lot, BAMTech acquisition alone was $2.58B, besides all other acquisitions, and investment in people, infrastructure and tools.

Summing up

  • Disney’s recent result report showed a number of streaming subscribers bigger than Netflix. An interesting case of an incumbent being able to face the competition of a disrupting tech company. This gives us 3 interesting lessons on digital transformations:
  • Lesson 1: the digital product is not at the center.
  • Lesson 2: core business experience matters as much as tech experience.
  • Lesson 3: technology investment takes time (and costs a lot.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) 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.

Delivery date is another source of conflict between business and tech

In the same that discovery seems to be a source of conflict between business people and product development teams, as I explained in the article Why business people hate discovery, the term delivery date also seems to generate some conflicts. On one side, business people are constantly asking for a delivery date for a product or a feature. On the other side, the product development team has many difficulties setting a delivery date due to many reasons. Let’s better understand both sides:

Why we need a delivery date

There are a number of reasons that makes having a defined delivery date important:

  • Some events don’t change and if the product or feature we are working on is supposed to be used prior to this event, it is very important it is up and running by then. For instance, if we are working on some new features that will improve user e-commerce shopping experience, it is important that it is available a few weeks prior to the Christmas shopping season and, ideally, prior to Black Friday shopping season.
  • There are some regulatory dates that also don’t change. Some examples are IRS tax filing deadline, new invoice layout determined by the government, etc.
  • Company events. For instance, suppose your company has an annual conference for its customers every October which is a perfect date for announcing new releases and new features. Ideally, the product development team should work to deliver the product or feature prior to this date.
  • Marketing campaigns also have set dates to start. If this is a campaign to announce a product or a feature, we definitely need this product or feature ready prior to the campaign launch date.

Certainly there are more reasons why a product or a feature needs to be delivered by a certain date. In all of these cases above it is clear that there are fixed dates that can not be changed and we need to figure out a way to deliver something prior to the fixed date.

Why it is so difficult to set a delivery date

The same way as there are a number of reasons that makes having a defined delivery date important, there are also many reasons why it’s difficult to set a delivery date:

  • The product development team is new or has new members so the product development capacity is still unclear. The team needs to work together for some time in order to better understand its pace. It’s the Tuckman’s stages of team evolution that I mentioned in the article on team structure. And there can be changes in the team also, like people leaving to join other teams or people changing functions. This can also impact the ability to set a delivery date, since the team does not know its product development capacity, and this capacity will change over time as people on the team get know each other and how to work together.
  • The bigger the product or feature to be delivered, the more difficult it is to estimate a delivery date. The team may be able to break down the feature or product into many small chunks that can be easier to estimate a delivery date, which could be a few days or weeks. The smaller the thing that needs to be developed, the easier it is to be more accurate in estimating its delivery date. The issue here is that by breaking down the product or feature into smaller chunks we can better predict what’s closer to be delivered, but things that are more distant are harder to predict a delivery date.
  • Changes of scope are another source of delay and uncertainty on delivery dates. If the scope is increased or, even worse, unrelated work get higher priority, the original delivery will need to be changed.
  • Technical debt can be another source of delays, specially if its unknown or undocumented technical debt. When we encounter a technical debt that prevent us to deliver a feature or a product, we may need to spend extra time to fix that specific technical debt, which will certainly generate delays in the delivery date.

The examples above make it clear that there are a number of factors that can negatively impact the delivery date of a product or feature. Again, this is not an exhaustive list. I’m pretty sure you can list more reasons that impact our capacity to set delivery dates.

There’s a very good article from the team at Apptio with a diagram that maps many things that impact positively (green, like focused work), negatively (red, like multi-tasking) or positively to some extent (yellow, like technical debt).

What impacts development speed? Source: Apptio Blog

Product development speed is a complex matter, that’s why it’s so difficult to estimate delivery dates.

So, what should we do?

On one side, business people are constantly asking for a delivery date for a product or a feature and there are very good reasons to need a delivery date defined. On the other side, the product development is a very complex matter and the team has many reasons why setting a delivery date is so difficult. So what should we do?

The first step is to understand that business people and product development team are parts of the same team and, as such, must have the same objectives, achieving the company goals while solving a problem for its users. For this reason, they should work together to achieve these objetctives.

The second step is to understand that behind every product or feature there’s a result expectation. So, when we discuss about a product or feature delivery date, we are actually thinking about when we will benefit from the expected results that this product or feature is set to generate.

The thing is that more often than not we end up talking so much about the new product or feature and its delivery date that the expected result becomes less discussed and, consequently, forgotten.

I already mentioned that product and features are means to an end, and not the final objective. They are vehicles to achieve the goal of delivering value, and results, for customers and for the company.

So, instead of discussing about product and feature delivery dates, we should be discussing about results delivery dates and how we can get to these results by this date. Sometimes there’s a simpler product or feature to be built that will enable us to achieve that result faster. Sometimes there’s no need to build a product or feature, but a change in a process can yield the expected results.

Looking through the results delivery date perspective, there are two possible situations:

1) if there is any fixed date (Christmas, Black Friday, company event, regulatory date, etc.), the date is already given. And the expected result too. Christmas, Black Friday the expected result is more sales. Company event, normally the expected result is engagement, cross-sell and/or upsell. regulatory date, the expected result is compliance. With this information in hand, we should ask ourselves what can we deliver before the given date to achieve the expected result?

2) if it’s something new, with no specific date, again the conversation revolves around the expected result. What result is expected of this something new? Is there any expected date for us to obtain this expected result? Or the sooner the better? With the answers to these questions above in hand, we should ask ourselves what can we do to achieve this result in this period?

Summing up

  • Delivery date is another source of conflict between business people and the product development team. On one side, business people are constantly asking for a delivery date for a product or a feature and there are very good reasons to need a delivery date defined. On the other side, the product development is a very complex matter and the team has many reasons why setting a delivery date is so difficult.
  • To address this conflict, the first step is to understand that business people and product development team are parts of the same team and, as such, must have the same objectives, achieving the company goals while solving a problem for its users. For this reason, they should work together to achieve these objetctives.
  • The second step is to understand that behind every product or feature there’s a result expectation. So, when we discuss about a product or feature delivery date, we are actually thinking about when we will benefit from the expected results that this product or feature is set to generate.

Product development advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, and tech founders) 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.

What is and how to create the product vision and strategy?

At some point during the growth phase of your product, it may be helpful to create its vision and strategy. These tools will greatly help you in the decisions about what the future of your product will be. For this reason, I will explain in this chapter what is product vision and strategy and how to create them.

What is a product vision and why do we need it?

The same way your kids wants to be something (doctors, lawyers, engineers, etc.) when they grow up, the product vision is what you want your product to be when it grows up. Product vision is how you envision your product in the future. It is the reason why the product exists. It is what should guide all decisions regarding this product. It gives the context for the product development team to make decisions about what to prioritize in relation to the product.

As I mentioned earlier when defining product management as the function responsible for building the connection between the company’s strategic goals and the problems and needs of clients, a product must at the same time meet the strategic objectives that the product owner has for this product while it solves problems and needs of its users. There you have the two elements needed to make your product vision.

Creating the Product Vision

The vision of the product will be created by bringing together these two elements, understanding the objectives of the product owner and the problems and needs of the user of the product. So the first step in creating your product vision is to be clear about what the product owner’s goals are.

For example, a bank creating an internet banking system may have the objective to reduce the need for in-person, face-to-face interactions. A clinical lab that creates an app for users to view their clinical exam results may have as its objective to lower the operational costs of handling and sending results.

Then you need to understand the problems and needs that this product will solve for your users, in which context these problems and needs happen and what motivates these users have to see their problem or need to be solved.

A nice tool to understand the user is the empathy map.

Empathy map

This map helps to focus on the different perceptions that the user may have:

  • See? – What does your user see? How is the environment where it uses the product? What does the market offer?
  • Listen? – What does your user listen to? What do your friends tell you about your product? What does his boss say? What do the influencers say?
  • What do you say and do? – What does your user say and do in relation to your product? What does he talk about with friends and on social networks? What can he do with your product?
  • Think and Feel? – What does your user think and feel when using your product?
  • Pain? – What are the main pains, fears, frustrations, and obstacles that your user encounters?
  • Gain – What are the key winnings, desires, and needs that your user expects to have when using your product?

Another useful tool is the persona, which represents a group of users with similar patterns of behavior, attitudes, and motivations in terms of purchasing decisions, use of technologies or products, lifestyle, etc.
The personas are used to:

  • Know and understand customers and users of products and services;
  • Bring the user to the project focus;
    Make design decisions more human and less abstract.

The following figure shows how to build a persona:

What is needed to create a Persona

The first step is to define a name and some characteristics of that persona. This helps in conversations about the product. In the name, it’s nice to already give a hint of the main characteristic. For example, Maria, the cool girl, or Michelle, the busy one.

If you are making a product for Michelle, the busy, and want to insert a new feature, one question that comes to mind is: “Will Michelle, the busy one, be able to use this feature? Will she find it useful enough to find time to learn how to use it?”

Beyond the name and basic characteristics, it is also important to describe your behaviors and your problems. The following examples will make the concept of persona clearer.

Mary, the cool girl
Michelle, the busy one

Maria, the cool girl is one of the personas that we used at Locaweb. Given the different products that we have in our portfolio, we ended up building eight personas. However, for each product in our portfolio, we had no more than 4 personas, being one of them the primary persona for that product, i.e, for whom all decisions about the product were taken.

As part of understanding the problem or need that your user expects to be solved by your product, it is very important that you map out the alternatives that exist today for her to have that problem or need to be solved. In the case of commercial products, they are the competitors. In the case of products that are systems without clear revenue objectives, such as internet banking or the clinical lab system for result visualization, the alternatives are going in person to the bank or the lab, calling the bank by phone, and receiving results by mail, etc.

This alternative mapping is very important to understand how your user deals with her problem or need without your product. How these alternatives are better and in which ones they are worse than the product you manage.

Empathy map, persona, and alternative mapping can and should be created in conjunction with UX, engineering, and product marketing people.

Okay, you already have all the elements to create the vision of your product:

  • The objectives of the owner of the product you manage;
  • Who the users are and what problems and needs these users expect to solve with your product. Useful tools for this are empathy map, persona, and alternative map.

Remember that to get these elements, the product manager will have to use a lot of empathy to talk to the owner of the product she manages and understand their goals, and to talk to the product users and understand them.

With these elements in hand, you are ready to create your vision, which is nothing more than to make clear these elements. Simple, right? It would be something like this:

(name of software owner) has decided to have this software for (objectives of the software owner to have such software). This software is used by (description of the people who will use the software) that, when using this software, expects to solve (problem or need that the user expects to solve) in a better way than (existing alternatives).

(Include more information about the problem or need, including context and motivation to have it solved).

Please do not copy + paste this text! Create your own product vision, which does not have to be text. It can be a presentation or a video, remembering that the vision of the product is the reason why the product exists. It is what should guide all decisions in relation to it.

As you get your product vision clearer, it is important to circulate it within your company to get input, feedback, and questions. By doing this, you’ll have a chance to complete the product vision as well as get the alignment and buy-in from all stakeholders.

Product Vision examples

Internet banking

Here’s an example of a bank where the owner decided to create an internet banking app so they could decrease the cost of building, staffing, and maintaining physical bank branches:

XYZ Bank has decided to have an internet banking app to reduce the operating costs of bank branches.

This software is used by bank account holders who, when using this software, expect to solve their banking needs (see account balance and report, pay bills, make investments, etc.) in a better way than when they visit the bank’s agencies.

Locaweb’s Email product

During my time at Locaweb we put together the following product vision for Locaweb’s Email product:

Locaweb’s Email product will be the most complete and flexible email solution of the Brazilian market.

Conta Azul’s product vision

We built Conta Azul’s product vision as an image because with the image it was easier to explain all the elements of what we saw as the future of Conta Azul product.

Conta Azul product vision

Gympass Product Vision

Again, we preferred an image instead of words. The saying a picture is worth a thousand words has a reason to exist.

Gympass product vision

Product Strategy

Once you have defined the product vision, you’ll be probably thinking something along the lines of: “Hum, I think my product is still far from this vision.” Then comes the question “how do I get my product closer to this vision?”. This is where the product strategy comes in, i.e., what steps will be taken to bring the product closer to the vision.

A good tool to help build product strategy is the SWOT analysis, to help you and your team analyze Strengths, Weaknesses, Opportunities, and Threats to your product.

SWOT

Strengths and weaknesses are internal items (from your product development team, or your company) that you, your team, or your company have some control over, that help or hinder your product from reaching your vision.

Opportunities and threats are external elements to the organization over which the organization has no or minimum control, and which can influence positively or negatively the attainment of the vision of the product.

Filling the SWOT should also be a team effort. The product manager must have one or more sessions together with UX, engineering, and marketing people to build your product SWOT. It is likely that your organization has also done a SWOT analysis for the organization as a whole, which can be a great input for your product SWOT.

SWOT analysis can be tricky, especially in the weaknesses quadrant. It tends to be a big list of items your product doesn’t have yet. My suggestion is to limit all quadrants to 3 items. Having this discipline, you’ll be able to prioritize what are the 3 more important items in each quadrant. Since we have 4 quadrants, you will have a list of 12 items to take care of.

In order to build a more comprehensive SWOT analysis, it is very important to have a good market analysis available. This market analysis should include:

  • Competitors: a good view of your product competitors is very important to help you build your product SWOT. Don’t forget to think also about indirect competitors. For instance, an email product has the telephone as an indirect competitor.
  • Potential and addressable market: ultimately your product could have the total global population as users or the total number of companies worldwide in a B2B product. However, you most likely designed your product for a subset of these users – or companies. For instance, you designed a delivery product for people who sell things and since it is a delivery product, it is limited to a certain region. This is the potential market. The addressable market is the size of this market that you believe you can reach.
  • Market growth: as important as it is to know the size of the market is to know the growth of this market. For instance, the number of landline telephones is close to 1 billion, but this is a shrinking market since there’s a clear movement toward mobile telephones.
  • Disruptors: as important as it is to know your competitors is to know what can disrupt your product. For instance, at Locaweb we were seeing a decline in email usage, possibly due to the migration of a part of the communication, which was normally carried out through email, being made by other means such as WhatsApp and Slack. Anyone managing a riding or a delivery product such as Uber, Rappi, and others should be already discussing the impact of autonomous vehicles on their product and business.

Having the SWOT filled up, it’s time to draw the strategy of your product. Product strategy is nothing more than a short, medium, and long-term roadmap.

Long term?

You are certainly thinking that as you use agile methodologies in the product development team, it makes no sense to have a long-term roadmap, not even a medium-term roadmap makes that much sense. In fact, it does, but not in the classic sense of roadmap as a list of features, but instead using the roadmap as a priority list, a list of focus points that must be tackled in a specific order to make the product gets closer to the product vision.

With your product SWOT analysis completed, you should look at each of the items in each of the quadrants, along with the team (UX, engineering and product marketing), and evaluate what impact each item has on the product vision you have created. Are there strengths to be strengthened? If so, which ones should be strengthened first? Are there weaknesses to be tackled? If so, which ones should be tackled first? Are there opportunities to be taken advantage of? If so, which ones should be looked into first? Are there threats to be fought? If so, which ones should be tackled first?

This analysis will help you define the motivations and goals, i.e., the macro themes of your roadmap. Remembering that roadmap = motivation + metrics, which is being popularized with the acronym OKR (Objectives and Key Results). This analysis will help you define what to focus on now and what to leave for later, always aiming ultimately to get closer to your product vision. And that’s the product strategy, the path that you and the product development team will go through to get to the product vision.

Your product evolves, and your vision and strategy too!

An important point is that your product evolves as the team works on it. A lot is learned about the users of the product, their problems, and their needs. New alternatives may appear to help your user solve their problems and needs. The software owner can also revisit their strategic objectives and, consequently, revisit the defined goals for the digital product.

In addition, strengths and weaknesses may change over time, and opportunities and threats may appear or disappear. So, it’s important to understand that neither the vision nor the strategy of the product is written in stone. They can and should be revisited periodically.

My suggestion is that they be revisited annually, or when a relevant event happens, such as when there is a change in the strategic objectives of the company, or when there’s an alternative that solves the problem or need of the user in a different way from the one of its product.

Summing up

With this chapter, we are almost closing the theme of the growth phase of the software product lifecycle. In the next chapter, we will put it all together. Vision, strategy, roadmap, and OKRs.

Product leadership coaching

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, and tech founders) 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.

More on NPS

My latest article on NPS sparkled some interesting conversations on this metric that I believe are worth sharing:

NPS has or has not the % sign?

From a strictly mathematical point of view, we should use the percentage sign because when we subtract two percentage numbers, the result must be represented as a percentage or as a fraction number. For example, if we have 50% promoters and 30% detractors, the NPS calculation will be 50% – 30% = 0.5 – 0.3 = 0.2. That is, the NPS is 0.2 or 20%. From a mathematical point of view, saying that the NPS is 20 is not correct, because 0.5 – 0.3 is not equal to 20, is equal to 0.2, or 20%.

Source: https://xkcd.com/435/

However, a bit of caution is required. If your NPS is 20%, that doesn’t necessarily mean that 20% of the interviewed customers are promoters. It means that at least 20% are promoters. It can be:

  • 20% promoters + 0% detractors + 80% neutral
  • 23% promoters + 3% detractors + 74% neutral
  • 60% promoters + 40% detractors + 0% neutral
  • any other combination

The same goes for a negative NPS. A -16% NPS means that at least 16% of the interviewed customers are detractors. It can be:

  • 16% detractors + 0% promoters + 84% neutral
  • 19% detractors + 3% promoters + 78% neutral
  • 58% detractors + 42% promoters + 0% neutral
  • any other combination

In the article The One Number You Need to Grow by Fred Reichheld where the concept of net promoters and its correlation to business growth was first presented in December 2003, all charts show net promoters as percentages, not integers.

Most recently many NPS reports from Bain & Company, Satmetrix Systems, and even from Fred Reichheld, who conjointly own the NPS trademark, present the metric as integers and not as percentages.

So I believe we can safely say that it doesn’t matter if we use or don’t use a % sign when presenting the NPS number. However, regardless of whether or not we use the % symbol, what really matters the most is understanding why promoters, detractors, and neutrals gave us this rating.

How to manage NPS?

During my coaching sessions, one metric my coachees normally bring to discuss is NPS. How to measure? How to manage it? It is common to see targets and KRs set for NPS, like “we will have an NPS of 20 (or 20%) by the end of the quarter”. I advise against using NPS as a target because:

  • NPS is a lagging indicator: as I explained earlier, there are two types of metrics, lagging indicators, which are indicators that denote consequences (revenue, profit, churn, number of customers, NPS), and leading indicators, which are indicators that denote causes. A good example of a leading indicator is the customer’s engagement with a product, which is the cause of a lower churn and a higher NPS. So, instead of having a target for NPS or churn, we should aim for a customer engagement target.
  • NPS is an induced and subjective metric: in order to measure NPS, you need to disrupt your customer’s journey to ask her if she would refer you/your product to a friend. The simple fact that you are disrupting her journey already interferes with the measurement. To add to this, this is a very subjective question. I may refer to this friend, because I know he likes this kind of product, but not to this other friend because the product doesn’t make sense to her.

That doesn’t mean we should not measure NPS. We should because the act of measuring and discussing it provides many useful insights to help us improve our product.

Summing up

  • When presenting the NPS metric, it doesn’t matter if we use the % symbol or not. What really matters the most is understanding why promoters, detractors, and neutrals gave us this rating.
  • NPS is not a metric to be set as a target because it is a lagging indicator and it is an induced and subjective metric.
  • We should measure NPS because the act of measuring and discussing it provides many useful insights to help us improve our product.

Coaching on digital product leadership

I’ve been helping several product leaders and their 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: the loyalty metric

The financial outcome must always be used as one of the metrics that indicate that the company is being successful and that it is reaching its goal. However, it must not be considered in isolation, because there is good revenue and bad revenue.

Bad revenue is all revenue that comes at the expense of the relationship with the customer. For instance, a company that hinders their clients’ cancellation button when they want to cancel or when it sells something overpriced taking advantage of their needs, such as the price of a bottle of water in a hotel.

Good revenue is all revenue that comes from deals where we can make our customers happy, where they feel we’ve solved their problem. It’s revenue we can build on by getting even more businesses from loyal customers, who typically recommend our product or service to their friends.

The bad revenue may help the company in the short run; however, in the long run, clients will get tired of this behavior and will seek alternatives. That is, bad revenue can eventually kill your company in the long run.

It is not possible to differentiate the good from the bad revenue in a financial report, in which all you can see is revenue numbers without any information on the client’ satisfaction grade. Because of this, it is necessary to listen to your customers, measure their satisfaction, and correlate it with the financial results.

NPS – Net Promoter Score

There are many ways of measuring clients’ satisfaction. I really like one called NPS (short for Net Promoter Score). This metric has come up for the first time in 2003, in a Harvard Business Review article written by Fred Reichheld, consultant at Bain & Company, a renowned American company. In 2006, Reichheld wrote a book called The Ultimate Question [^nps] that had a second edition published in 2011, containing the lessons learned through the years.

[^nps]: The Ultimate Question 2.0 (Revised and Expanded Edition): How Net Promoter Companies Thrive in a Customer-Driven World by Fred Reichheld and Rob Markey, Harvard Business Review Press; Rev Exp edition (2011)

NPS is calculated based on a single question you should ask your client:

The NPS main question:

In a scale from 0 to 10, how likely would you tell a friend or colleague about us?

Zero means absolutely not, and 10 meaning absolutely yes. People who evaluated from zero to 6 must be classified as detractors; the ones who graded 7 or 8 must be classified as neutral, and the ones who graded 9 or 10 are promoters.

The NPS calculation is very simple, just subtract the detractors’ percentage from the promoters’ percentage. The result is a number varying from -100% to 100%. A negative number means that you have more detractors than promoters, and a positive number means the opposite, that is, you have more promoters than detractors.

NPS

Of course, it’s better to have more promoters than detractors, mainly if we think about the word-of-mouth marketing that comes from both detractors and promoters. Aside from talking about your company and services to their friends, the promoters buy more and are customers for longer. That is, they like your product or service, and will always give you ideas and suggestions that are important to your business.

Several companies use NPS to measure their clients’ satisfaction and loyalty. Some examples are Apple, Zappos, Rackspace, Microsoft, Intuit, and Facebook.

However, how often should you measure NPS? Once a year? Every semester? Every month? Every week? The book recommends measuring it every day, continuously. That can be done in the following way: every day you ask the NPS question to clients who are celebrating the X months or X years anniversary that day.

For instance, you can ask your clients when they complete 1 month since they have become your clients, then you can pick up some onboarding issues. You can also ask your 6-months clients and, from thereon, at each 1-year anniversary at the company. This way you can get NPS reports per time the client is your client, then you will know if you’re treating well both new and old clients. To check if your NPS is evolving, you take the moving average from the last 30 days.

Closing the loop: from information to action

The big problem here is that a number doesn’t solve much. We need to know where to improve, what to do so the promoters continue to promote our company and services, and what motivated the detractors to give us a low score. To get this information, Fred Reichheld recommends adding one more question to the survey:

The NPS second question:

What is the main reason you gave us that grade?

There you go. With these answers in your hands, you have what it takes to go from information to action. While reading the comments of the promoters, you will understand what motivated them to give you a high score and keep these actions. From the comments on the low scores, you have the first input to take action. It is very important to talk with the detractors to listen to more details on their dissatisfaction.

From the moment they see you care, their perception of your company will start to improve. To seek for understanding the detractors’ motivation and act to solve the problems that got them unsatisfied is the only safe way to increase the NPS and, consequently, the loyalty of your clients.

Maybe you are asking yourself when is the time for this feedback. The answer is quite simple and direct: the sooner, the better. In his book, Fred Reichheld advises getting in touch with the detractors in a maximum of 48 hours. Speed is important to show you read and care about your client’s feedback.

Tip: internal NPS

An interesting suggestion in the book is to measure the employees’ NPS, that is, on a scale from 0 to 10, how much this employee would recommend your company for a friend to work there. This questionnaire would have to be anonymous to make the employees comfortable while making comments on any problem they have within the company.

Following the path of NPS clients, you can run this NPS by seasons, that is, 1 month, 6 months, and each one-year anniversary at the company. This way you will be able to find out if employees had a good process for entering the company, and if they are still motivated after a few years.

So, we saw several types of metrics, began with the conversion funnel and talked about engagement, churn, global and individual financial metrics, revenue churn, and the “Holy Grail” of subscription products — the negative churn. Now, we will finish the topic by talking about the loyalty metrics — the NPS. In the next chapters, I’ll make my final considerations on the metrics theme.

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: 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?

Engagement

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.