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 (http://uservoice.com), 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.

Innovation: next steps

Once you discovered a problem of a group of people, got to the bottom of it, its context, and the motivations that people have to solve this problem, you analyze the opportunity in detail. You evaluate if it is worth developing the digital product. You evaluate how to cover the costs of development and operation. And then you go for it.

There’s an enormous amount of books that talk about the subject and, if I would approach the subject in this book, it would probably double its size. That’s why I prefer recommending some book references that I find interesting on this matter. Moreover, software product development has been a much-explored topic in several articles, talks, and books about startups. In a way, startup and software product development can be considered synonyms.

Startup Guide

The first book I am going to point out is the Startup Guide: How startups and established companies can create profitable digital products, published in 2012 by Casa do Codigo, written by this author. In this book, I talk about a number of software product development techniques and illustrate them with practical examples based on my experience with ContaCal and Locaweb, and conversations I had with people who are developing software products from other companies.

In it, I talk about various issues related to software product development, such as:

  • Problem or need? What is the difference between problem and need? Should I focus on solving a problem or meeting a need?
  • Web, mobile or social product? People have been spending more and more time on mobile and social networks. Should I focus my software product on the web or mobile first? Or is it better to make a Facebook application right away?
  • What is MVP? What characterizes a product to be minimally viable? Viable for whom and for what?
  • Why do I need to launch soon? You may have heard that the faster you launch your software product, the better. The first explanation that comes to mind when we think about it is the cost of development, i.e. the faster we launch, the less it will cost us. However, in my view, this is not the main reason. There are more important ones.
  • How to make your web product fast? Once you understand why it is important to develop your software product quickly, the next concern is how to accelerate this development.
  • How to set the right price? Will you charge for your product? How much? When?
  • Is a free plan worth it? There are several software products that offer free plans. Is it worth it for any kind of software product? If not, what type of software product benefits from offering a free plan?
  • Launch Checklist. Okay, you are all set to launch your software product. Really? It’s always good to check that everything is in order before you “open the doors”.

More Reading Suggestions

Following are more reading tips on software product development, in order of importance:

  • The entrepreneur’s guide to customer development: a cheat sheet to The Four Steps to the Epiphany, by Brant Cooper and Patrick Vlaskovits. Steve Blank, a serial entrepreneur from Silicon Valley, wrote a book called The Four Steps to the Epiphany: successful strategies for products that win, that approaches generically the startup subject but creates a very important concept, of customer development. According to his experience, startups don’t die due to the difficulty of making a good product, but due to the difficulty in finding clients for it. Hence the idea of search and develop the client before search and develop the product. The problem is that Steve Blank’s book is very dense, so Brant and Patrick made an excellent summary of 104 pages in which they explain in details the concept of customer development.
  • Where good ideas come from: the natural history of innovation, by Steven Johnson, author of several interesting books about science and knowledge. In this book, he explains what are the main ingredients of innovation, especially the need of multi-disciplinary teams in order to make it possible to see the same problem from different perspectives.
  • The little black book of innovation: how it works, how to do it, by Scott D. Anthony, business partner of professor Clayton Christensen in an innovation consulting company called Innosight. In this book, he defines innovation as something different that has an impact. From this point on, he presents a step-by-step guide to find and test innovation opportunities.
  • Crossing the chasm: marketing and selling high-tech products to mainstream customers. Written in 1991 by Geoffrey Moore, who wrote the book in which he explains that between the early adopters and the early majority there is an abyss that many products are not able to cross, since the latter ones need good references to buy a new product and the first ones usually are not a good reference. In this book, Moore also proposes strategies based in war tactics.
  • Running lean: iterate from Plan A to a plan that works, by Ash Maurya. In 2010, Alexander Osterwalder and Yves Pigneur presented a new framework to analyze business models, the Business Model Canvas (BMC). I really appreciate this framework, but the BMC seems to me more focused on settled companies rather than startups. In 2012, Ash Maurya created a framework based on Business Model Canvas, but more relevant to new businesses for it approaches problem, solution and metrics.

Good reading, good product development and brace yourself for the next stage: growth (or the abyss…), our next subject.

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.

The 2 sides of Product Discovery

By the end of 2021, I had the opportunity to re-record the classes I gave at Cursos PM3 on the fundamentals of product management. It was a good opportunity to review and expand the content based on the new experience acquired in recent years. One topic that I decided to expand on was the role of product management, design (UX), and engineering in discovery/delivery.

Discovery and delivery

Discovery is normally led by product management and UX with some support from someone from engineering. It is when we focus on identifying and understanding the problem of users and test possible ways to solve this problem while checking if this possible solution will positively impact the business’s strategic objectives.

Delivery is normally led by product engineering with some support from the product manager and product designer. It is when we focus on delivering the solution we tested that showed the best indicators of its ability to solve our users’ problems while helping the company achieve its business strategic objectives.

These two tasks are not sequential, i.e., we should not wait until discovery is completed to a certain level in order to start delivery. Ideally, we should be constantly discovering and delivering and, in order to do that, we need to break down problems into their smaller sub-problems and test the most simple solution hypothesis to each of these smaller sub-problems.

The two sides of discovery

When we discuss discovery and delivery, we normally leave out of discussion or, at most, discuss very lightly the fact that discovery has two sides or two perspectives:

  • Problem discovery: this is when we are trying to understand the problem (or need) of our customer, how this problem is connected to our company business strategic objectives, the motivation the customer has to want this problem solved, when, where, how and why this problem occurs, if there are solutions to this problem and what our customer thinks about these solutions. It’s all about the problem and it’s mainly led by the product manager and product designer.
  • Solution discovery: when we start to gain some understanding of the problem to be solved, we need to discover possible solutions for this problem. This is when we generate and test solution ideas and hypotheses in the simplest way possible with prototypes, proof of concept, and other similar low-code or no-code techniques. This helps everyone in the product development team to understand better how to maximize the value to be delivered during the delivery while minimizing the risk and time of this delivery. For this reason, during solution discovery, the entire product development team (product managers, designers, and engineers) should get involved equally.
Problem discovery, solution discovery, and delivery

Simoultaneous tasks

As I mentioned earlier we should not wait until a task is completed to a certain level in order to start another task. They should be carried out simultaneously and the learnings and results from one task are a valuable input to the other task. During Problem Discovery, the product manager and designer are more involved. During solution Discovery, everyone should get involved. During Delivery, engineering is more involved. The image below tries to make these concepts more tangible:

Discovery and delivery flow

One interesting tool to help during both problem discovery and solution discovery is Teresa Torres’ Opportunity Tree (as far as I know we are not related (= ):

Opportunity Solution Tree (source: ProductTalk)

Using this tool we can make clear to everyone, especially to ourselves and our team:

  • what is the desired outcome, normally some objective aligned with the company’s strategic objectives?
  • what are the opportunities (problems or needs) that when tackled can help us get closer to the desired outcome?
  • what are the solution hypotheses that can help us tackle each opportunity?
  • what are the experiments, preferably the simplest and easiest ones, that will help us test the solution hypothesis?

From the description above it is easy to see that desired outcome and opportunities are problem discovery-related while solution hypothesis and experiments are solution discovery-related.

Opportunity Solution Tree clearly shows the problem discovery and solution discovery tasks.

So there you go, whenever you work on product discovery, remember its two sides, problem discovery, and solution discovery. It will make it easier for you and your team to understand what is the focus of each task.

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.

Innovation: How to get a return on the investment from building a digital product?

One of the most important questions of the opportunity assessment questionnaire we saw in the previous chapter is the question: “How are we going to measure success and make money from this product?”. It deals with two subjects: metrics and revenue. We’ll see about metrics in the Growth: Be a data geek chapter. Now let’s talk about revenue.

What are the costs of developing, distributing and operating software?

Every software development has a cost. When this software is a digital product – that is, a software that has users – the product has, in addition to the development cost, the operating cost, which is the cost of getting that software to users and depending on the type of product, the cost of storing data from these users.

Before the internet, software products were sold in boxes with manuals and floppy disks, or installation CDs. The revenue came from selling these boxes with the software. Some companies even charge an annual maintenance fee, which gives customers access to newer versions as they become available.

This digital product runs on the customer’s computers, meaning that all operating costs are his responsibility. The manufacturer recommends a minimum equipment configuration to run this software and the customer is concerned with owning, configuring, and maintaining this equipment.

In addition, administering this digital product is also his responsibility, as well as ensuring that it is running on equipment with sufficient disk space, sufficient memory, and that the generated data is secured and backed up. Revenue from the sale of this software product serves to pay for its development and distribution costs.

With the internet came the possibility of offering software to be used remotely, that is, it became possible to use software that is no longer running on the client’s equipment and does not need to be managed by it. This is what we are calling here a software product. In this new commercialization model, there is not only the sale of the software but also the sale of the service of its operation. Even smartphones apps, which run on users’ phones, have mostly some online component, that is, they search and store data on remote servers, which will also bring operating costs.

That is, every digital product has costs to develop a product plus costs to operate it. To cover these costs, you need to have some kind of return on investment to build the product.

Digital Product Revenue Types

Basically, there are 3 ways to monetize a web product:

User Paid Revenue

It is the model used in most business digital products, such as products offered by Locaweb, Google AdWords, MailChimp, and more. In this case, the revenue comes from the periodic payment (monthly, yearly, etc.) for the use of the digital product. Another very common option is pay-per-use (I’ll talk more about these forms of payment later).

Revenue paid by the user is also a form used by some end-user software products, but it is more difficult to charge this type of user. Netflix, Spotify, LinkedIn, and Dropbox are some examples. To understand how difficult it is to charge an end-user, imagine paying for a Google search. That is, even if the end-user perceives a lot of value in a product, it is hard to justify for this type of user that she must pay to use it.

Revenue paid by someone interested in your user

In this model, you usually do not charge the user of your product, but someone who is interested in your users. This model is widely used in end-user digital products. Typically, the business model is ad selling. One example is Google, which allows anyone to use search, and charges companies for placing ads along with search results.

Another similar example is Facebook, which also offers free access to users, and charges for ads from companies interested in advertising to their users. Another form of revenue is selling reports based on usage data. In addition to advertising and selling reports, another revenue option is to allow other companies to sell services to their customer base and share revenue. An example is the Brazilian personal free finance app Guia Bolso, which offers credit options to their clients, credit offered by financial institutions that share with the Guia Bolso part of the revenue generated with the loans.

An important point to note is that in order to be interesting to someone to the point that they want to pay to gain access to your user, you need to have a lot of users. Think in terms of hundreds of thousands who often return to use your product.

To attract hundreds of thousands of free users, you are likely to invest a lot of money, so you have to look for free ways to market your product. In addition, this should promote frequent user feedback, as this will give you an audience that will be of interest to anyone who wants to pay to talk to them.

To make your user base even more attractive to prospective advertisers, you should try to know a lot about your users, such as demographics, behavior, and preferences. This way you can offer more assertiveness and efficiency to advertisers.

Indirect Revenue

It is the revenue you earn as a result of users using the software but not paying to use it. There are basically two types of indirect revenues:

  • Revenue from sale or lease of physical or virtual items: This is the case with online stores that use online store software and services as a software product to sell or rent physical items. Amazon and Submarine are good examples. There are also stores that sell or rent virtual goods, such as Netflix’s streaming service or Amazon’s Kindle book sales. In the case of books, the sale is per item. In Netflix’s service, they charge a monthly fee to access streaming content. It is worth noting that the trading sites that broker the sale of physical items such as eBay and Etsy are not of this type. They are the type in which the revenue is paid by the user of the digital product, that is, by the person who places the physical item for sale, paying a commission for the sale. These sales brokerage sites are in the platform category.
  • Cost savings: This is the case of internet banking, high school or college intranet, system for access to laboratory test results, among other software products that do not market anything and do not charge for access. In this type of product, there is no revenue, but cost reduction. Internet banking reduces the costs of face-to-face customer service at branches; the intranet allows for a more streamlined communication flow between school and student or student parents, saving you on college and college visits and meetings; and access to results via the Internet reduces costs for other forms of exam delivery, such as printing and mailing.

Payment Types for Digital Product Use

When you pay for the use of a product, it can be done in two ways:

  • Recurring Payment: it is a lump sum payment to use the product, such as a cable TV subscription or a gym membership. If you fail to pay, you can no longer use the product and no longer have access to all information that may be stored on it. The most common periodicities are monthly and annual.
  • Pay Per Use: In this case, you pay for the use of the product. This usage should be very easy to measure and track. For example, in an email marketing product, which allows email messages to be triggered to an address book, you may be charged for the number of messages you send. Another good example is paying for ads, which can be paid per view, click, or ad conversion. The commission charged by intermediary sites selling physical items like eBay and Etsy is another example, as is Skype’s charge to make calls to landlines and mobiles.
    It is also possible to have a mixed model, with recurring payment plus pay per use. A good example is a product for internet telephony, where you can charge a monthly fee for access to the product, plus a charge for outgoing calls, such as Locaweb’s Virtual PBX. Another example is a product that offers the possibility for its user to have an online store. In this case, you may be charged a monthly fee plus a usage fee based on the number of sales your customer makes using this store.

Getting Return from a Platform

In the chapters What is a digital product? and What is digital product management? I talked about a different type of digital product, the platforms, systems that are valued the more people use it. I explained what differentiates them from a product, and the differences between managing a product and a platform.

Now that we’ve seen how to get revenue from a digital product, some questions that remain are: How to price a platform, especially when I’m interested in having as many people using it as possible to make it more valuable? And in some platform cases, I have people from different groups (buyers and sellers, app developers, and smartphone users). That is, the ideal on a platform would be to charge nobody, to ensure the largest number of users; however, if I do not charge anything, how will I cover the costs of its development and operation? There are four points to consider about platform pricing: who, what, how much, and when we should charge.

Who should we charge?

The first answer to this question is simple: who is least price sensitive. If you have a two-sided platform, identify which one is the least price-sensitive; This will be the side most willing to pay for a platform. The most sensitive side is the one we want to subsidize.

For example, if you are managing a platform that connects attorneys with potential clients, it is very likely that the least price-sensitive side is the attorneys one because they have high margins. On the other hand, suppose you are managing a platform that connects suppliers of equipment and chemicals – which have little margin on their prices – with potential buyers; it may make more sense to charge buyers because of the low margin from suppliers.

However, as I said earlier, this is only the first answer. There are other factors to consider:

  • Scale Sensitivity: If one side realizes that your platform is more valuable based on the number of users on the other side, this side will be scale sensitive and willing to pay for the platform. For example, in Google, the more people searching, the more interesting the platform gets for advertisers.
  • Competition Sensitivity: If one side realizes that the platform is more valuable the smaller its side is and, consequently, the smaller the existing competition, this side will be the competition sensitive side and more willing to pay. An off-line example is the entrance fee charged by bars, which decide whether to charge cheaper from women or not charge them at all, but charge men full entrance, who will be willing to pay because they understand there will be less competition. To attract more female customers, the bars often have a “free entrance for women” policy, sometimes on a ladies’ night. In some cases, these policies have been challenged in lawsuits as discriminatory, and are illegal in some jurisdictions in the United States, but is a good example of competition sensitivity if we frame these bars as a two-sided platform were men and women go to meet.

That is, there are several factors to consider. In some cases, both sides may be willing to pay; in others, only one. Cases like Google and Facebook are simpler to analyze:

  1. There are always two sides: who advertises and who consumes the platform.
  2. For advertisers, the more people consuming the platform, the better.
  3. For those who consume the platform, ads or the content itself can be an intrusion if Facebook and Google can’t make them relevant.
  4. For those who advertise, each business started or deal closed through the platform represents a gain.
  5. For those who consume the platform, each business started or deal closed through the platform represents an investment with a possible outlay of money.
  6. For these reasons, especially for the last two, it makes sense for advertisers to pay.

On the other hand, cases such as auction sites, employment, taxi search, and real estate for purchase or rent are more complex:

  1. There are also always two sides: who advertises and who has an interest in what is being advertised.
  2. For advertisers, the more people consuming the platform, the better.
  3. For those interested in what is being advertised, the more offers available, the better, as there are more chances of finding what you are looking for.
  4. For those who advertise, each business started or deal closed through the platform represents a gain.
  5. For those who are interested in what is being advertised, every business started or deal closed through the platform represents the possibility of getting what you were looking for.
  6. For these reasons, especially the last two, it may make sense for both sides to pay to use the platform. On the other hand, considering items 2 and 3, it also makes sense that both sides can use the platform at no cost. In this case, it may make sense to analyze who is least price sensitive and what the market practices are.

What should we charge?

Usually, people are willing to pay for something when they see the value and benefit it brings to them.

There are 3 benefits that can be charged on one platform:

  • Access: People may be charged for access to the platform. Something like a monthly fee, for example. This is the least common way to charge, as one of its main benefits is the number of people on different sides. This model can be found in platforms that work on exclusivity, where member quality is their main value proposition, and quantity is not relevant. Some platforms, after reaching a certain critical volume, may decide to charge for access to ensure quality and exclusivity. It is also possible to implement two levels of access, one free and one paid, with different functionalities and service levels, such as who is free is only supported via the Q&A site, and who pays is entitled to personalized support by telephone.
  • Usage: You can charge each time people use the platform. For example, on a job posting site, you may be charged for each job opening advertised. Another example is AdWords, where you are charged each time someone clicks on your ad, that is, each time your ad is used.
  • Rate / Percentage: In this model, the amount to be charged is a percentage or a variable rate of the benefit that one side of the platform has with each business conducted on it. Typically, auction and payment intermediation sites (PayPal, etc.) often use this billing model.

You can make combinations of these billing forms. For example, charge a monthly access fee plus a usage fee, or a percentage.

How much should we charge?

To answer this question, we need to think about lock-in, which means that a user of your platform is less likely to stop using it the more they see and see benefits in its use. The cost of exchange is what explains the lock-in; the higher the cost of exchange, the greater the lock-in. Another important point to keep in mind when we are defining how much to charge for the platform is the network effect, i.e., how much value we generate to the user by having more people using the platform. Typically, the amount to be charged by a platform, whether access, usage, and/or fee, reflects on the lock-in and the network effect.

These values ​​generally change over the life cycle of a platform. In the beginning, when there are few users, and the lock-in and network effect are still small, it is very likely that they will have to be subsidized.

Dropbox can be viewed as a single-sided platform, where the benefit of the network effect appears as more users use it for file exchange. The cost of switching increases as you put more files in Dropbox and you have better acquaintances with whom to exchange there. That’s why it charges for GB and encourages inviting friends to use it too. This incentive, giving free GBs to you and the friends you invite, is the form of subsidy Dropbox uses to increase the lock-in and network effect of its platform.

Another interesting example is an avalanche monitoring service, which launched a platform on which ski resorts would share weather data to predict avalanches more accurately. To be able to participate in this system, the resort would have to install a monitor, and this installation process was costly.

The platform also intended to charge a monthly fee for resorts to use it. The problem is that they were not comfortable paying the monthly fee and had already paid the cost of installing the monitoring equipment. In addition, they did not want to pay monthly in the summer, when there are few avalanches and resorts have low occupancy. The solution was to subsidize the installation of monitors in the resorts and to charge annually instead of monthly, with prices varying by the depth of analysis.

When should we charge?

For charging for platform access, you may be charged once or periodically. By periodicity, it may vary from monthly to multiple years. It is not uncommon to see cases where there are multiple period options (e.g. monthly and yearly), where discounts on longer period prices are offered.

In some cases, longer periods may be the only way to show the long-term benefit of its platform or to ward off concerns about its seasonal utility, such as the avalanche monitoring service.

When billing by use, the most common is to make this billing periodically, that is, each period the platform should evaluate how much was used and should be charged. The most common period is the monthly one.

Care should be taken with mixed charging models, with charge-for-access plus charge-for-use. If you charge for annual access, consider whether you can charge for annual use as well, or if it’s best to charge for monthly or quarterly usage.

When charging a fee or percentage, it is best to charge right after the transaction happens. If there is a high frequency of transaction events within a month, another option is to charge this fee monthly.


We just learned that every software product has development and operating costs, and we need to cover them in some way. We have seen different ways to get product revenue, and we learned the differences between product and platform when it comes to earning revenue.

Digital Product Management Books

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

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

Innovation: a lot of opportunities

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

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

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

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

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

Questions 1 to 4 will help to understand the opportunity.

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

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

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

How many opportunities to pursue at the same time?

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

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

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

New opportunities vs. existing product improvements

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

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

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

Warning: It’s not a bug team

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

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

Opportunities vs. improvements

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

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

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

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

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

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

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

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

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

Validating opportunities

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

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

Sample website on unbounce

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

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

Below is a partial result of this validation:

Partial result on unbounce

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

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

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

The total cost of this test was R$ 990.00:

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

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

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

Digital Product Management Books

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

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

Innovation: the job to be done

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

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

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

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

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

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

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

The “job to be done” market research

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

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

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

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

Understanding problems and their context

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

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

Digital Product Management Books

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

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

Innovation: Focus on the problem

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

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

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


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

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

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

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

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

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

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

Ford: And why is that?

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

Ford: Oh, I see your problem, and I have an even better solution for you — it’s called car.

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

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

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

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

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

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

Ford: What motivates you to wanting this problem solved?

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

Ford: Where does this problem usually happen?

Smith: At work.

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

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

Ford: Why was it difficult/complicated/bad?

Smith: Because it has taken me away from the kids.

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

Smith: I got off from work earlier.

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

Smith: The work piled up on the other days.

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

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


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

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

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

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

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

  1. Be brief. The shorter your survey, the bigger are the chances of getting a good number of answers and guaranteeing a high statistical relevance.
  2. Be clear. Especially in online surveys, when you are not interacting with the respondent, there are big chances of the person misinterpreting your question. One good way of testing your questionnaire is to test it live with some people. Check if they understand each question, or if they have some difficulties in comprehending some part of it.

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

  • Original question: How short was Napoleon?
  • Improved version: What was Napoleon’s height?
  • Original question: Should concerned parents use compulsory child seats in the car?
  • Improved version: Do you think the use of especial child seats in the car should be compulsory?
  • Original question: Where do you like to drink beer?
  • Improved version: Break into two questions: Do you like drinking beer? If yes, where?
  • Original question: In your current job, what is your satisfaction level regarding salary and benefits?
  • Improved version: Break into two questions: What is your satisfaction level with your salary in your current job? What is your satisfaction level with your benefits in your current job?
  • Original question: Do you always have breakfast? Possible answers: Yes / No.
  • Improved version: How many days a week do you have breakfast? Possible answers: Everyday / 5-6 days / 3-4 days / 1-2 days / I don’t have breakfast.


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

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

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

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

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

Problem mindset vs solution mindset

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

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

Here’s a great Albert Einstein quote:

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

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

Fischer Space Pen

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

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

Here are some examples from the companies I worked for.

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

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

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

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

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

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

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


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

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

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

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

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

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

Digital Product Management Books

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

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