I have heard this phrase several times throughout my career. Software developers know that invariably comes a moment when this kind of discussion comes up, which usually has phrases like: “it’s getting harder and harder to deal with the code”; “if it were to do it from scratch, it would be much faster”; “if we do not rewrite, it will become increasingly slow and dangerous to deal with the code”.
At Locaweb, we had an Email Marketing product for sending and managing email marketing campaigns, which used MongoDB as a database, a nonrelational database known for its ability to store large databases. However, probably because of our limited experience in software development using this type of database and in managing non-relational databases, as the database grew, the system became slower and slower.
So, it was necessary to rewrite the product to use PostgreSQL. We designed this rewrite to be transparent to customers. That is, the client would not be migrated from one database to another, thus avoiding going through a period of unavailability or possible data loss. The rewrite was a success. The entire rewrite process, including putting all existing clients (over 15,000 at the time) into the new database, allowing the MongoDB database to be shut down, took six months, a reasonable time for such an initiative.
However, during these six months, the team delivered nothing new to the customer. No new features. To lessen our customers’ frustration, we decided to hire a third party to build iOS and Android apps on top of existing product APIs. This enabled us to deliver new functionality to our customers while the product team focused on rewriting. If this option did not exist, we would have to find other ways to deliver user value that did not depend on the engineering team.
If you are a software developer, rest assured that if you have not experienced this situation in your career, you surely will. The problem with rewriting software is that by rewriting it, the team stops doing new things for its user, as I showed in the example of Locaweb’s Email Marketing product. From a business standpoint, when software does not evolve, customers see no evolution, may lose interest in using the product and will start looking for better options in the market. Therefore, I would like to make some considerations on the subject.
1) New and better technologies will always appear. In the past, systems were developed with everything in the same code base. Then it was the MVC concept (model, view, controller) separating software code into layers according to their function. More recently, the concept of microservices was created, breaking the application into small, loosely coupled applications, preferably done via APIs and facilitating maintenance. If with every new technology that comes along we are going to rewrite the software, we will certainly do nothing but rewrite software.
2) Software rewriting must have a clear business motivation, ie it must somehow meet the strategic goals of the software owner company as it fulfills a user’s need or solves a customer problem. If there is no clear business motivation, the recommendation is not to rewrite.
3) If rewriting is unavoidable (are you sure?), it is important to think about this rewrite initiative from a business perspective, that is, what is the impact of this rewriting on customers and the software owner. Understanding this is the responsibility of the product manager. Some questions to help you reflect with your team on this impact:
What will this rewrite look like?
While rewriting is going on, will new features be delivered?
How will the new system coexist with the old system?
When new features are implemented, will they be implemented on the new system and the old system, or only on the new system?
When can new clients be installed on the new system?
When will existing customers be migrated to the new system?
If there is a proposal to make a synchronizer, so that customer data exists simultaneously on the old system and the new system, what is the cost of this proposal compared to not making this synchronizer?
If the difference between the old system and the new system can be perceived by customers, how will this difference be communicated?
There you go, some considerations about software rewriting, a very important topic for any product manager.
Digital Product Management Books
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.
How should the product manager relate to different areas of the company? Engineering, UX, product marketing, project management, operations, sales, legal, finance, customer service, human resources, and general management.
Recalling what I said in the article Main characteristics of a product manager, the most important feature every product manager needs to have is empathy, that is, the ability to put oneself in someone else’s shoes to understand their desires, motivations, needs, and problems. This feature should be used not only with the customer of the product but also with people from different areas of the company.
As said, the product manager must understand the impact his product has on legal work: have legal issues increased due to some new functionality in the product? And what about the sales, support, operations, finance, marketing staff, did the new product complicate their lives so much? And for the product team, the engineers and UX analysts who are part of the product core team, how do your product decisions impact their functions?
This is what we will see in this new series of articles!
Product engineering and product management
I will start by talking about the relationship between product engineering and product management.
Product engineering is responsible for developing the product and keeping it operating. With the business vision brought by the product manager, plus the solution design made by UX people – based on an understanding of the customer’s need or problem – product engineering “builds” the product.
To build it, they must not only do the programming but also define the technical architecture. That is, what infrastructure it will run on, which programming language is most appropriate, which database is most appropriate, how to ensure the non-functional requirements of this product (response speed, availability, scalability, etc.). It is also important to validate with the product manager whether the cost of this infrastructure fits his business model.
The fact that the product manager is responsible for defining the product to be made may give the impression that product engineering reports to product management. However, this view is incorrect, and if areas behave in this way, the chance of product failure increases because those who perceive themselves subordinate have less commitment to the outcome.
Product engineering, product management, and UX are one team, there is no subordination relationship between any of these groups. They should function as partners, each with their own expertise and responsibility, collaborating to produce the best product possible.
In the previous diagram, product engineering brings the available technology. As I explained in the article Innovation: what is it?, to innovate is not simply to know the latest technology. You need to know not only this, but all available technologies, and how to use them. This is the role of product engineering. The opportunity and potential for producing an innovation lie in knowing the technologies available and knowing how to use them to solve a problem or meet a need of a group of people.
Practical Advice for Product Managers
To make life easier with the product engineering team, here are some practical tips:
Don’t get into the technical solution unless you have earned the right to meddle. A product manager should have some technical knowledge of your product, but this is not your area of expertise. The experts are in the product engineering team. Therefore, avoid presenting technical solutions to the engineering team unless this team is open to receive your suggestions, and even so, the more time you spend thinking and discussing about the technical aspects of your product, the less time you will have to learn about your companies’ objectives and your clients’ problems and needs.
Take engineers into conversations with customers and users. As part of your daily life as a product manager, you should always talk to your customers and users to understand how your product solves their problems or meets their needs, and how you can make your product look even better. Engineers love to go to these conversations very much. It is a very cool experience for them to see real people using software they have developed. They will be even more engaged in the mission of making a better product.
Always make data-driven decisions. Whether it’s data from your product access and usage, or data from your customer and user conversations, use data to make your decisions and present it to the team. This will give more consistency to the items you will place on your product roadmap.
Learn to take out the excess. Always look for the minimum product or the minimum functionality, ie try to implement as little as possible to achieve your business objective.
Be present. It is critical to be with the product engineering team or at least as accessible as possible to the team. During product development, doubts will inevitably arise and if you are not present, either the team stops, or they will implement as they think it should be, which may differ from what you had planned.
Provide the team feedback about the product. You, as a product manager, know how your product is doing, how many users it has, what these users are thinking of it, how this product is helping the company achieve the goals. Tell this periodically to the product engineering team. As a result, you will be giving context and purpose to the team.
Negotiate the rewriting and maintenance stories. The engineering team, if it is a good team – attuned to good software engineering practices evolution and always following what’s new in the software development industry – will always find better ways to implement each piece of the product. If it is dependent only on the engineering team, the product backlog will only have stories about technical improvement. This is good, it shows that you are working with a great engineering team. However, you should use the previous item to provide the team with product context, ie to show that there are certain definite goals for the product that you as a team have to achieve, and therefore you should always release new features in it. There must be a balance between maintenance and rewriting stories, and new features. I’ve read in many places something like: “define X% of the time for maintenance and rewriting stories”. I don’t like to make this suggestion because I believe that every moment of the product requires a different balance, and it’s up to the product manager and his engineering team to talk and mutually agree on this appropriate balance at each stage. Remember the importance of finding a good balance, as this will avoid the famous technical debt that, as it grows, will slow down the product engineering team.
Oh, and there’s one more thing!
Some product engineers end up becoming great product managers. It’s important to be able to figure out when an engineer is looking for “something else to do” and give him that career choice.
At Locaweb, we have (and had) great product managers who were product engineers. In some cases, they became product managers of the product in which they were engineers. On the other hand, there are some product engineers who have tried product management and disliked it.
For those who are used to measuring their productivity by features delivered, it may be strange at first to lose that productivity benchmark. As we have seen, a product manager’s day to day life is made up of a lot of talk with the various people involved in it, and that lot of talk can “scare” the engineer who is used to working focused on feature development. So, you have to leave the door open so that she can be a product engineer again, without any harm to her career.
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? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.
Since 2011, there has been a lot of discussion about startups, with many books, lectures, discussion groups, events focused on the subject, which has a lot to do with digital product development and management. It has so much to do that some people treat both themes as one. However, there is a difference between them.
Everything about startups is focused on the first phase of a software product’s life cycle, the innovation phase. In some cases, one even talks a little about growth and how to cross the chasm, but the main focus is always on how to develop the software product.
As I mentioned in the article Innovation: next steps, there is a lot of good literature on the startup theme. Be sure to search!
Digital Product Management
Software product management involves much more than just the innovation phase. Software product management covers the entire product life cycle. Also, as we saw in the article What is software product management?, product management is a function of the core development team, which also has UX engineers and designers.
It is important to understand the roles and responsibilities of this role and how it relates to other areas of the company. It is also part of software product management knowledge to understand the difference between focus and product portfolio diversification and, if the company chooses diversification, how to manage that portfolio.
Therefore, as shown in the figure, software product management covers much more topics than when we talk about startups. For anyone who wants to read more books on software product management, I recommend:
Inspired: how to create products customers love by Marty Cagan, former VP of product management on eBay. It is the technology product management manual, where the author explains all the main concepts related to product management. For the people who come to work with me on my Locaweb product coordination team, this book is a must-read.
Agile product management with Scrum: Creating products that customers love, by Roman Pichler, Agile Methodology Implementation Consultant. In this book, he shows how *product owners* can create successful products using agile methodologies.
42 rules of product management (2nd edition): learn the rules of product management from leading experts around the world. This book is a collection of 42 great articles written by software product management experts.
We have reached the end of article series about the life cycle of a digital product. We now know what the phases of this life cycle are, what happens in each of them, and the role of the product manager in each one. In the articles that follow, we will understand how is the relationship of the product manager with other areas of the company.
Your software product may have arrived here coming from three different paths:
1. Your product growth has slowed, and you have done all the analysis and testing described in the previous article to make sure that it has indeed reached the stage of maturity.
2. Or, you have launched your product and are unable to bridge the chasm that lies at the end of the innovation phase, the first phase of the life cycle of your digital product.
3. Or, you have opted for a scheduled maturity by planning the end-of-life of the current version of your software product against a new one that has been developed and released.
Regardless of the path you take – unscheduled maturity, not crossing the chasm or programmed maturity – you have eventually reached what is known as the product’s end of life. Sometimes product managers use a more elegant term for this phase, the sunset of the product.
As with all previous phases, this phase also has to be managed. It is a mistake for a product manager to believe that when a product reaches the end of its life, the work of product management ends. On the contrary, this phase requires as much attention as the previous ones.
The first step is to recognize that you have reached the end of life, and a great indicator is to assess whether the cost of maintaining the product is greater than the return it gives. If this happens, there is a strong indication that it is entering this phase.
The decision to end a product’s life is not scientific. The numbers help a lot in this decision; however, as explained in the Thoughts on metrics article, in addition to metrics, you need to use other information such as experience, intuition, judgment, and qualitative information to make the end-of-life decision for the product.
Each of the three possible pathways your product may have taken to the end-of-life phase will bring with it specific facts and considerations for making your making decisions about your product. Typically, this is committee decision-making with product people and company executives.
If your product has indeed entered the end of life, the product manager will need to manage this phase. The decision and its management depend on the path it takes to reach it, and this is what we will see in the following sections.
End of life by unscheduled maturity
This is the worst case because besides being unplanned — as is the case with end-of-life after programmed maturity — this is a difficult situation to identify. Before you decree that it is the end of life of your digital product, you need to make sure that it is not only temporary. The most common in these cases is to numb the product for a while.
What does numb mean? It means not investing in its development and marketing, and watching how it behaves. Has it stopped growing? Or does it grow very slowly? Does it make sense to stop selling it? Or can the product be left in the market for a while? After some numb time, you should re-evaluate whether it is worth investing again in it.
This was the case with Locaweb’s Virtual PBX product, which we decided to lay dormant for about 3 years, without any marketing and development investment so that we could invest in other products. Even without any investment, the number of customers did not decrease. Even at times there was even a growth. This growth, when it happened, was quite small, but it was nonetheless a growth. For this reason, we decided to invest in the product again.
Another example, already commented in the previous chapter, was the case of Locaweb’s Web Hosting product which, because we focused too much on metrics and disregarded our empirical knowledge, ended up in a non-growth situation that, fortunately, could be corrected. It was not web hosting end-of-life. It was a growth deceleration we caused to the product.
By that, I mean again to be very careful not to make a hasty decision because the end of life by unscheduled maturity is extremely difficult to identify.
If you are really sure your product has reached the end of its life, you will need to manage this phase. The first decision you should make, along with the committee I mentioned — made up of people who work with the product and company executives — is whether you will discontinue the product or make it dormant. This decision will be based on the return it is giving to the company and the cost of maintaining it.
If the product still yields a considerable return, you are likely to decide to maintain it and make efforts to reduce the cost of maintenance. The product manager will be responsible for coordinating maintenance cost reduction efforts and assessing whether these costs are lower than the return that the product gives.
On the other hand, if the return on this product is small, or your operating costs are too large and not reducible, you are likely to discontinue it. In this case, the manager should coordinate all necessary steps to discontinue the product, including:
1. Set the sales end date and execute it;
2. Check for a replacement in the company’s product portfolio or in the marketplace;
3. If there is a substitute, define how a client can migrate to this one;
4. Prepare communication with customers by setting deadlines for the end of the product;
5. Test this communication with a small group of customers to assess the impact and make the necessary adjustments;
6. Perform communication with the entire customer base;
7. Follow up and act on time when necessary.
End of life by not crossing the chasm
If your product enters the end of life because it does not cross the chasm, although this is not a desired situation for the development team, it is an important situation that needs to be identified quickly, and the product manager plays a key role in detecting this.
This situation is easier to detect because the product does not grow. He wins a few clients, the *early adopters*, and then stops growing. At this point, you should assess with your marketing manager whether the product communication strategy is being effective and is reaching people who have the problem your product is intended to solve.
It is also important to understand with potential customers whether the product not only solves the problem but how they are willing to compensate you for that product. You can always make adjustments to the product and your marketing model to suit your customers.
However, if even after evaluating these issues and trying to make adjustments to the product and / or your marketing model, you are unable to make it grow, it is time to decree its end of life. The sooner you reach this decision, the better, so as not to waste time and investment on a product that will not work.
In this case, as the product has a small customer base, the options of keeping it dormant based on having a sizable revenue make no sense. Therefore, the only viable decision is to discontinue the product. As in the case of unplanned end-of-life, here too the product manager must coordinate all the steps necessary to discontinue it, which are the same as those described earlier in the *Unplanned End of Life* section.
End of life by scheduled maturity
This is the best of the three options for the software owner, but it will give the product manager a hard time. In the case of installed software, this happens when new versions are released. For online software, this occurs when the development team chooses to rewrite the product for some reason and decides to release a new version. This decision to rewrite an online product should be very thoughtful because the time spent rewriting your product is unused time in its evolution from the point of view of those who use it.
It may happen that your product was not properly planned from a technical point of view and now you are at a point where: either rewrite it, or the product can no longer evolve. However, falling into such a situation should be the exception rather than a normal part of a digital product’s life cycle.
In a nutshell
For installed software, end-of-life by scheduled maturity is intrinsic to the model, while for online software, end-of-life by scheduled maturity should always be the exception.
Because this kind of end-of-life can be programmed, the product manager must, in conjunction with UX and product engineering, design what this phase will look like, always aiming for minimal impact to customers. At Locaweb, in our email marketing product, we got to the point where we had to change the database. We used MongoDB which, due to design problems, was not being able to withstand product growth; that’s why we decided to change the database to PostgreSQL.
We designed this rewrite of the product in such a way that the customer would not be negatively impacted when the new version with PostgreSQL was implemented. Nothing has changed in the way customers use the product. The only impact they noticed was that the product was performing better, which was expected.
This is the most important point to think about at the end of life: what will happen to customers who are in the current version, which will become the “old” version when we launch the new one? This has to be carefully thought out, and the focus must always be on minimal impact to the customer.
Of course, when the new version has a different interface and interaction than the old version, the customer will be impacted. It is very important to test some of them to measure impact before forcing change for the entire customer base. In some situations, you may even decide to keep the old version for a while, given the difficulty of getting customers to the new version. But don’t forget, the focus is always to make your customers suffer as little as possible.
We saw in detail in previous chapters the entire life cycle of a software product, going through all its phases: innovation, growth, maturity — whether it can be programmed or not — and the end of life — that can come after maturity or when the product does not cross the chasm that separates the innovation phase from the growth phase.
To conclude this life cycle theme, let’s talk now about the difference between startup and digital product management. This difference has a lot to do with the life cycle of a software product.
After the innovation phase, assuming that your digital product was able to pass through the abyss, it has grown. Only there will come a time when your product will enter the stage of maturity – remember the product lifecycle?. This is inevitable, just review the technology adoption S curve in several practical cases:
Why does it happen?
There are three reasons for a product to reach the maturity stage of its life cycle:
This is the case of TV in the previous image. The TV market matured some 30 years after television was invented, that is, 100% of the addressable market, which could buy a TV, already had one. What solution did their manufacturers find to get out of maturity? In fact, they did not come out of maturity and eventually entered the last phase: the end of life. The solution they found was to create new TV products that could go through the entire life cycle again.
Today, television technology life cycles are much faster, and the next technology is already beginning its growth phase even before the previous technology came out of that phase. Today, TV makers no longer expect market exhaustion to create a new TV. They already use innovation as a way to force the current product to mature and to enjoy the growth phase of the new product.
It is an innovation that helps create a new market and a new perception of value, and that eventually completely changes an existing market and its perception of value (over a few decades, years or even months), making old technology obsolete[^wikipedia-innovation]. This is the basis of the book The Innovator’s Dilemma, a must-read for all people who work with technology, by Prof. Clayton Christensen, Harvard professor, and innovation consultant.
Disruptive innovation is what happened to film cameras, with the arrival of the digital camera; or with mobile phones that only made voice calls, with the arrival of smartphones; with traditional encyclopedias, with the creation of Wikipedia; and with CDs and DVDs with the launch of audio and video download and streaming services. Sometimes disruptive innovation can be created by the same industry as a strategy to defend against market maturation. This is the case with the TV industry launching SmartTVs, and the mobile phone industry with the launch of smartphones.
There is also a situation where the owner of the digital product, instead of waiting for maturity to happen, actively manages it. This is the case of TV manufacturers that barely launched plasma TVs, then launched LCD and then LED, not allowing the market to saturate and anticipate maturity with the new version. This also happens in software products, especially installed software such as Windows, MySQL, Nginx, Asterisk, and many others.
Anticipating the obsolescence of your product, its product manager is already planning the release of the new versions and the end-of-life process of the previous versions. This process is often quite slow and in some cases can be traumatic. This was the case with Windows Server 2003, which was released in April 2003. It went into a programmed state of maturity as soon as the next version of Windows Server, Windows Server 2008, was released in 2008. As of 2008, it lived in the phase. of maturity; in 2010, it was no longer sold; July 14th of 2015 was the date set by Microsoft to no longer support the product, meaning the product’s end of life. Windows 2003 was installed in many servers at Locaweb and we had to do the migration to newer versions of Windows server, but that migration was not easy to do and Microsoft took a long time to provide tools to help in this migration.
For online software products, the programmed maturity does not make much sense as the product is updated frequently and the user does not usually suffer from updates. Of course, there are exceptions even for online products. There are instances when the product development team chooses to rewrite the product for some reason and decides to release a new version. In this case, it is important to understand that you will be putting the current product into a programmed state of maturity and managing it as such. That is, you should plan the full maturity and end-of-life cycle of current release, including thinking about what to do with existing customers of the current release that is scheduled to mature and how to migrate them to the newer version of your product. This is something that should be discussed as one of the factors that can influence the product development team’s decision whether or not to develop a new version of their software product.
When does it happen?
It is not very difficult to see when one is reaching maturity. If it is a scheduled maturity, you will define when it will happen. If not programmed, just look at the growth of your product and notice that it is growing slower. Another point that happens is that growth; when there is, it will always be organic, meaning there is no use investing in advertising and marketing that you will not have new sales.
It is a little disturbing to enter the product maturity phase, especially if it is not a programmed maturity. In the maturity phase, it is not unusual to hear nostalgic phrases like “I remember that in the good times…” begin, but the important thing is not to get discouraged. First and foremost, you need to make sure that your product has really reached maturity, or if there is any other reason for slowing growth. To make sure your product has reached maturity, you should ask yourself a few questions:
Are we still focusing on the problem?
As we saw in the Innovation: Focus on the problem chapter, every product exists to solve a problem, and it is critical that the product manager never loses sight of it. When a product enters the growth phase, it is common for the focus to shift from the problem to be solved to how to accelerate that growth. When this happens, the main tool that can help accelerate growth, which is the focus on the problem, is lost. When the product manager and the product development team lose focus, the chances of product growth starting to slow are very strong, giving the impression that it has reached maturity.
For years, we have experienced strong growth in Locaweb’s Website Hosting product. As I told you in the previous chapter, in 2012 we brought in a pricing consulting firm that, after much research and analysis, suggested changes to our hosting plans to optimize and increase our revenue and profit. The changes were in the limits of the plans and the types of services included in each plan. Their suggestion was to reduce the number of sites per plan (there were already rare cases of customers hosting more than one site per plan) and, to compensate, to provide included services such as WebChat for chat service.
As I said, these changes did not affect revenue and profit at all, and we ended up wasting a lot of time and money on analysis to make these changes innocuous. But that was not the worst. With the changes made, our Website Hosting product has gone further to address our customers’ issue. They came to consider that the product had less of the core functionality and that we put in the additional services that made the product more expensive. Our customers have found better solutions in the market. This affected our product, which slowed considerably in 2013.
As a result, we have decided, more empirically, to do what we call Site Hosting product repackaging, changing the limits again based not only on data, but also on our knowledge about our customers and their issues, and our 15 years of web hosting product experience. With the change we made, which cost us much less time and money in its planning phase, it has grown back to its former pace. It is therefore important that the product manager and his development team never lose focus on the problem the digital product solves, and ensure that it is solving the problem as best as it can.
This example illustrates well what I mentioned in the previous chapter when I said that in addition to metrics, you need to use other information, such as experience, intuition, judgment, and qualitative information, to make product-related decisions. The consultancy made us look exclusively at data, making us disregard all our empirical knowledge with the product.
Is the whole market slowing down?
This is a second very important point to consider when looking at a slowdown in growth. How are your competitors, are they also slowing down? Is the market as a whole is slowing down? Are there any issues in the country’s economy that may be impacting your market? All of these issues should be evaluated as you begin to notice a slowdown in your product growth.
As you can see from .br domain registration curve, as of mid-2013, there seems to be a slowdown in the number of .br domains registered per year. In 2017 it was clear to see the deceleration of .br domain name registration. Now it seems clear that .br domain registration is in the maturity phase. Website hosting is also on the same path. In 2015/16 it was difficult to understand if the market was only pausing for a while, or if it was entering the maturity phase. Now it is quite clear. However, even as you evaluate the market and find that it is slowing down, you and the product development team can never lose focus on the problem it solves and ensure it is solving it as best it can. Even with a slowing market, it is possible to grow if your product is an excellent solution to the problem of a set of people.
Care must be taken not to confuse circumstantial deceleration with deceleration due to maturity. As you can see from the S-curve image in real life, some technologies such as the telephone, the automobile, and electricity experienced circumstantial decelerations before they reached maturity. Scenarios of economic crisis may impose a circumstantial slowdown.
Is there a disruptive substitute?
This is the third point to consider when a product begins to show signs of slowing growth. Is there a different product category on the market that replaces yours? In the case of the slowdown in Locaweb Website Hosting growth, there was also a product category with strong potential to replace ours; site builder apps like Weebly and Wix.
From the earliest website building services, we have always been aware of this potential, so we launched our website builder product to compete directly with Website Hosting as a solution to the problem of people who wanted a website, but didn’t have the required technical knowledge. There is also another problem that Website Hosting solves, which is the need to host and run database web applications. To address this, application hosting solutions such as Heroku and Google App Engine exists today. With that in mind, we also launched our application hosting solution called Jelastic Cloud.
Note that disruption does not exist only in the technology used by the product. A business model is also a form of disruption. Locaweb launched its first version of Cloud in 2008. We chose to maintain the same Business Model as Hosting Business with pricing based on disk space and transfer pricing and charging a monthly fee for the product. In 2009, AWS (Amazon Web Services) began to become well known for its Cloud Computing services, which were very similar to the technology Locaweb offered. The great innovation came in the form of the business model. Amazon has chosen to charge services per hour and to charge disk space and transfer separately. Although it was a more complex way to charge, it had the appeal of charging only for what was used. When we launched Locaweb’s Jelastic Cloud in 2013, we also opted for this business model.
Before accepting that your product has really reached maturity, it is very important to make sure of it. In my example of Locaweb, it is clear there was still room for growth if we focused on the customer problem.
Assuming it is not a scheduled maturity, that you have done the analysis describe above, and that even if you deepen the focus of the product manager and development team to the problem your product solves, you have not been able to resume growth: this is the time to accept the situation, and start decreasing your product development and marketing investment.
You may also decide to move your development and marketing efforts to another product in your portfolio. We’ll see more about product portfolio management and how to allocate investments in different portfolio products in future articles.
Another important point is the need to lower operating costs. You cannot have a mature software product that costs a lot to operate. Operating costs usually come in the form of human labor, ie cost to fix problems and customer service costs. Ideally, since the growth phase, your product has a very small operating costs, with low problem rates and service costs.
To make such a product, the product development team must take care of the quality of the product being put into production, both from the standpoint of technical quality and concern of the engineering team as well as from the point of view of ease of use and concern. from the UX team.
Once you make these divestments in development and marketing, probably by allocating them to another product in your portfolio and lowering operating costs, your product can still have a long life to maturity. It all depends on whether the software product still pays back to its owner while continuing to solve existing customer problems and / or addressing user needs.
This situation can be sustained for months or years. Even if there is no more investment in development, you need to keep a minimum on maintenance, which should make sense within the return analysis of your product. This minimum maintenance investment should be coordinated by the product manager. She should assess his situation and decide to invest effort only when bug fixes and updates are required.
Keep in mind that by keeping product maintenance this way, you will periodically shift focus from the development team, which is now focusing on another product. Therefore, this maintenance should be kept to a minimum. Maintenance needs are likely to increase over time due to the aging of the code that makes up the software, and over time this may cause the cost of maintaining this product to be greater than the return.
Being a head of product encompasses many different aspects and skills, and that’s the reason why I’m writing an entire book about this topic. However, since this is a question I get asked frequently, I’ll make a brief introduction to the topic that may be useful for people considering this step in their career as well as for people searching for a head of product for her company.
Whatever the road that got you into the possibility of filling a head of product position, either by you considering this your next career move or by you having the task to find someone to fill this position, it is important to have clear what is the mains responsibility of this role: expectation management. It will be something between 60 to 80% of the head of product time.
I’ve heard from some product managers that they want to become head of product because they view this position as a great opportunity to have a strong say about or even lead the building of the product vision and strategy, especially if you are in a company which is purely digital or at least a born-digital traditional company. This is true, but I have to say that this is no more than 10% of the head of product job. And even these 10%, it is not a solo endeavor. You’ll have to build it collaboratively with your product’s main stakeholders, especially the company founders who are the first product managers of any company.
The other 90% of the head of product responsibility is shared between helping product managers in their development – something between 10% to 40%, depending on the seniority of your product managers – and expectation management, which normally takes 50% to 80% of your time. By expectation management, I mean managing the expectation of all of your product stakeholders, internal and external.
It is important to have this time sharing clear before you decide to accept the head of product role so you understand what other areas and your team will expect from you decide to take the job.
I’ve normally seen people filling out a head of product position coming from three main backgrounds, either she is someone leading engineering, or someone leading product design or marketing, or a product manager that will start to manage other product managers.
CTO/Tech head filling the product head position
If you are a CTO or an engineering leader and were asked to step in as head product, chances are that you were asked to fill this position in addition to your existing responsibilities. I advice against this role superposition. Depending on team size, and your seniority, it’s better to have the product development team with 2 or more leaders, reporting either to the CEO or some other very senior position in the company. If you have up to 30 or 40 people in the product development team, it’s ok to have only one person leading the entire team. More than that, it’s good to split at least between a head of engineering and a head of product. In this product development leadership design, the UX function reports to the head of product. Depending on the size of the product development team and the relevance of design to your product strategy, the team can be lead by heads of engineering, design, and product. Depending on the scope and complexity of your product, you may have more than one head of product, one for each distinct context. For instance, here at Gympass we have Rodrigo Rodrigues as the CTO, Claudio Franco as the head of product for consumers and me as the head of product for companies and partners.
UX/Product design or marketing leader filling the product head position
UX and marketing are 2 areas who are very close to product management. While UX works together with product management in product discovery activities, marketing works together with product management in activities to tell the world about the product and its features and to increase its user base.
As I mentioned previously, UX can report to the head of product. It is a common team design. Both for a UX leader assuming the head of product as well for a marketing lead assuming this position, it is important that the product head understands not only the similarities but also the differences between the two functions and their role and responsibilities in the success of the product.
Product manager filling the product head position
This may be a natural career path for a product manager. As she gets more senior, she may become the go-to-person for other product managers in search for advice. So the 10% to 40% of helping other product managers part of the head of product position may come naturally to her. However, there’s still the 10% of vision building and 50% to 80% of expectation management to be considered.
The vision building should not also be something new to a senior product manager. She already does that for the product or part of the product she takes care of, so it shouldn’t be something new to her, only a bigger scope. Remember to work on building a high-level vision and let the details be worked on by the product managers. Building the details of a product vision is an important role of product managers.
The remaining 50% to 80% of time spent in expectation management shouldn’t also be extraneous to the product manager aspiring to become head of product. Actually, she already does that for her own product or part of product that she takes care of. From her team members, to people from other areas, to C-level all the way to the founder of the company. Here again we are talking about an increase of scope. And again we need to let product managers do stakeholder anxiety management as well, so they can develop these skill. But don’t forget that as head of product you’ll be the go-to-person for C-level people and the founders.
If you don’t want to manage other people, that’s fine. It’s always possible to have space in your team for a more senior product manager position. Some companies call it principal product manager. I’ll talk more about this role in a future article.
The first step for a product manager to become a head of product is when she continues to work with her own team (product engineers and designers) and oversees the work of a product manager in another team. One possible name for this new position is group product manager, since she is managing a group of product or parts of a product. As all goes well, the next step is to hire her replacement for the existing role she still plays as product manager. Freed from her daily job of managing a product, she will be able to manage 2 or more product managers.
Leading Product Development: the art and science of leading digital products
Even though I’m talking about digital product development, which is based software engineering, normally considered a science, I do believe there’s a part of art leading product development teams. Asking Google what is art, we get some interesting answers:
“the expression or application of human creative skill and imagination, typically in a visual form such as painting or sculpture, producing works to be appreciated primarily for their beauty or emotional power.” To develop a digital product we need creativity and imagination in order to build a product that will empower its users to do something. Empowerment is the process of becoming more cofident, which is an emotional power. And digital products have interfaces with humans, which can be admired. So it’s easy to see the process of building a digital product is a work of art.
“a skill at doing a specified thing, typically one acquired through practice.” Building good digital products requires practice, lots of practice.
On the other hand, when asking Google what is science, we also get interesting answers:
“the intellectual and practical activity encompassing the systematic study of the structure and behavior of the physical and natural world through observation and experiment.” Many product development teams have been building digital products, sharing their experiences and creating and improving the body of knowledge on how to build digital products.
“a systematically organized body of knowledge on a particular subject.” we are building this body of knowledge as we experience new processes and refine existing ones. Digital product development is a brand new science, and there’s a lot we don’t know yet, but we’ve been putting a lot of energy on building this body of knowledge so the next generations of digital product developers can always start one step ahead. This is how all sciences are built, one step at a time, one generation building on the steps of the previous generation.
The book is focused on the head of product role, but it will be useful to anyone within a digital product development team as well as for anyone who is not in this team but works in a company that has, or plans to have, a digital product development team.
The book will be divided into 3 mains sections:
Concepts: people who know me, know that I’m a big fan of starting any new endeavor with a ubiquitous language, a term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users – in my case, between author and readers. For this reason, I’ll start the book defining some concepts such as roles and responsibilities of a head of product, team structure, career ladder, and Y career for product managers.
Principles: every company has its own culture and within each company, every department has its own culture as well. Here I’ll talk about the culture I believe it’s mandatory to create successful digital products. And also, what are the 2 key values that every product development team must have.
Tools: here I’ll talk about the tools I’ve been using in my almost 30 years of product development leadership career and passing to other leaders so they can use with their teams. The tools I’ll talk about include vision, strategy, team structure, metrics, and ceremonies.
The first edition in Portuguese of this book is from 2015. I wrote an updated version of this book in 2017. So only two years passed since it latest version. However, learning is a continuous endeavor. I continue to learn from my daily experiences and I published what I learnt on Linkedin. Now I decided not only to translate my book into English with the help of Paulo Caroli but also to update 2017 content with my learnings.
In this changelog I’ll register what changed from 2017 edition so if you already read that book, you can go straight to the new content.
I’m using software, product, and digital product interchangeably. For the context of this book, these terms are equivalent.
I’ve updated statistics through the book, to keep data relevant, with comments about the data evolution.
Paulo Caroli was kind enough to write a preface to this third edition! (=
More examples, not only from Locaweb and ContaAzul, but also from Gympass, the 3-sided marketplace that connects fitness partners, to companies and their employees. At Gympass I’m leading a product development team, together with Rodrigo Rodrigues and Claudio Franco. We have the challenge to build a global product used by fitness partners, companies, and users from all over the world. Since we are the leaders in this category, we have the additional challenge to be the first ones to face certain problems, which is quite exciting.
In the “What is a digital product?” chapter I describe the difference between digital and traditional companies and present the concept of the born-digital traditional companies. It’s very important for a product manager to understand what type of company and product he is dealing with, to know how to better perform her job.
Also in the “What is a digital product?” chapter I describe a different way to categorize platforms. Besides all categorization I already presented in the 2nd edition, we can categorize platforms as either transaction platforms or innovation platforms.
In the “Leadership tips for product managers” chapter, I’ve added more info on why it’s so important to set a context and some examples of obstacles a product manager can remove for her team.
In the “Growth: what is a roadmap?” chapter I’ve added a whole section describing a tool, I’ve been successfully using at ContaAzul and Gympass, the 12-month rolling roadmap.
Also in the “Growth: what is a roadmap?” chapter, I’ve added an entire section on when to use OKRs and when to use roadmaps.
In the “Growth: how to prioritize the roadmap?” chapter I’ve added more information on how to deal with special requests, especially if you manage a B2B digital product with big customers.
I’ve added an example section in the “What is and how to create the product vision and strategy?” chapter to illustrate different types of digital product visions including. One hypothetical product vision for a digital product from a bank, and three real-life product visions, Locaweb Email product vision, ContaAzul’s product vision, and Gympass product vision.
In the SWOT section of the “What is and how to create the product vision and strategy?” chapter, I’ve added more techniques to help you fill out a more useful SWOT to support the design of your product strategy.
I’ve added a new chapter entitled “Growth: Putting it all together – vision, strategy, roadmap, and OKRs” where I explain how to use together the different tools that must be used during the growth phase a digital product lifecycle – vision, strategy, roadmap, and OKRs fit together
I’ve added a new section about the different options to expand a marketplace in “How to diversify your product portfolio?” chapter.
In the “Focus or diversification?” chapter I’ve added a section explaining when and how to use the 4 phases lifecycle to individual features of your product.
I’ve added two new sections to the “The IT problem” chapter. One about ThoughtWorks, a software development consulting firm well known for always being a step ahead of the software industry, suggesting that we apply product management to internal platforms. And the other about the “The fallacy of the internal customer” where I question the concept normally used in some organizations of internal customer or internal user when discussing work done between areas.
In the chapter about Where is software product management in a company? I’ve added a section explaining how a product manager can gain more autonomy.
In the “Conclusion” chapter I’ve added a section to explain how to make a career change to product management.
I’d like to thank Paulo Caroli for his interest in the subject to the point of motivating him to begin the translation of this book into English and for his kind words in the preface of this edition.
Cesar Carvalho, João Barbosa, Vinicius Ferriani, Claudio Franco, Livia Martini, and Benjamin Grol, from Gympass, thank you for inviting me to be part of this rocket ship, also an incredible source of continuous learning. And thank you Rodrigo Rodrigues and Claudio Franco, my partners in leading Gympass amazing and unique product development team.
When we hurry to launch an MVP, we are creating a solution for a problem. However, a very important step to create 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.
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 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, receives 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 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 member’s job to ask what is the problem and why we need this problem solved.
I wrote some time ago about the difference between a product and a platform. Platform business model is a very interesting topic, many businesses can benefit from understanding its dynamics and applying its principles into their own product or service. I participated in a panel last Friday at Endeavor’s Scale-Up Summit to discuss the platform revolution where we discussed different aspects of building and managing platforms. However, we didn’t have the chance to dive into a very important aspect of the platform business model, pricing. In a recent article, I discussed the pricing of digital products but platform pricing has its own intricacies.
When thinking about platform pricing, one question that probably will arise is: 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.
Whom 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 attorneys because they have high margins. On the other hand, suppose you are managing a platform that connects suppliers of equipment and chemicals – which have a small 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, on 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 cover charge bars, which decide whether to charge women cheaper or not charge 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, bars often have a “no cover 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:
There are always two sides: who advertises and who consumes the platform.
For advertisers, the more people consuming the platform, the better.
For those who consume the platform, ads or the content itself can be an intrusion if Facebook and Google can’t make them relevant.
For those who advertise, each new business initiated or closed through the platform represents a win.
For those who consume the platform, each business started or closed through the platform represents an investment with a possible outlay of money.
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:
There are also always two sides: advertisers and who has an interest in what is being advertised.
For advertisers, the more people consuming the platform, the better.
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.
For those who advertise, each business started or closed through the platform represents a win.
For those who are interested in what is being advertised, every business started or closed through the platform represents the possibility of getting what you were looking for.
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 to access 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, 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 use it and see benefits in its use. The cost of change to another platform is what explains the lock-in; The higher the cost to change to another platform, 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 lock-in and 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 more acquaintances with whom to exchange there. That’s why he 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 your 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 from 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 or no avalanches and resorts have low occupancy. The solution was to subsidize the installation of monitor equipment in the resorts and to charge annual instead of monthly, with the price varying by the depth of analysis.
When should we charge?
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 (eg 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 your 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 charge 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.
So here it is, the who, what, how much and when to price in a platform business.
Why do we need to make an MVP, a Minimal Viable Product? Why do we need to hurry to launch a half-baked product? Why not wait to have the product with more features to launch it? Herb Kelleher, co-founder and former CEO of Southwest Airlines has a famous phrase to motivate people to do things:
We have a ‘strategic plan.’ It’s called doing things.
This “strategic plan” can be translated into the #jfdi hashtag which means something in the lines of “just focus and do it” or “just freakin’ do it” (polite form).
But why the hurry? Why can’t we keep working on our product until we feel comfortable it has all the features we believe are needed to solve the user’s problem?
Well, I’ll give not only one but 3 main reasons:
Reason #1: The moment of truth!
The longer you take to put your product in front of real users, the longer you take to start getting feedback from real people to know if you’re on the right track. And what’s even worse, you’ll probably be giving too many steps in the wrong direction.
A digital product is supposed to solve a certain problem of its users. You will not know if you have built a good digital product until the product is used by real users and it actually solves one of their problems. The longer it takes for this to happen, the longer it will take for you to know if your product is or is not the solution for someone’s problem.
And if it is not, what should you do? Change, adapt and present it again to real users! The sooner you know that what you’re developing is not on track, the better because you’ll have spent less time, energy and money moving into the wrong direction.
Reason #2: Featuritis
There’s a limit to the number of features a user can understand. When we present a software full of features to a potential user, instead of providing her with a possible solution to one of her problems, we may end up creating a new problem for her. Kathy Sierra, well-known software development and user experience instructor, designed the Featuritis Curve that illustrates in a clear and fun way how user satisfaction diminishes as we increase the number of features of a product.
Reason #3: ROI
The longer you take to put your product in front of real users, the longer it will take for you get some revenue and the longer you’ll have to invest from your own money or investor’s money. Below is a typical return on investment chart. While you don’t launch your product and don’t have revenue, all you’ll have are costs, i.e., you’ll be in the investment phase of the curve below. This situation will only change when you get some revenue and this revenue pays your monthly costs. This is the monthly profitability phase in the chart. Only after a few months in the monthly profitability phase, you’ll be able to get to the return on investment phase. It’s a long way:
Now take a look at the chart below. If you decide to delay your launch in 3 months, this can delay your return on investment in 6 months! Are the features that you intend to implement in those 3 months you are delaying the product launch worth the 6 months delay to get to the return on investment phase?
On the other hand, if you are able to launch 3 months sooner than what’s described in the first chart, you’ll get into the return on investment phase 6 months sooner. Isn’t that worth figuring out how to launch your product faster?
If you’re not embarrassed…
There is a famous quote by Reid Hoffman, founder of LinkedIn, which really resonates with the MVP concept:
If you are not embarrassed by the first version of your product, you’ve launched too late.
To illustrate this quote, here are some print screens of early versions of well-known software products:
Facebook login screen, 2005:
So, what’s preventing you from putting your product in front of your users?