Deliver early and often

Principles

In this part of the book, I will talk about digital product culture and I will present four fundamental principles that should guide the team behavior to increase the chances of success in implementing digital transformation strategies.

As I mentioned in the previous chapter, the principles behind the development of successful digital products that we will see on the next pages are:

• Deliver early and often;
• Focus on the problem;
• Deliver results;
• Ecosystem mindset.

Shall we proceed?

Deliver early and often

The first principle I will address is Deliver early and often, because, without it, everything else is much less effective. What’s the point of being focused on problems and delivering results, with an ecosystem mentality, if you only put software into production every 3 or 6 months?

Delivering early and often is what will enable you to have focus on solving more problems, generating more results quickly and ensuring that your entire ecosystem benefits from what you are doing.

A well-known phrase in the world of digital products is:

“If you are not embarrassed by the first version of your product you’ve launched too late.”

Reid Hoffman (2017), ounder of LinkedIn and venture capitalist.

To illustrate this phrase, I will show some early versions from some well-known websites, starting with this one:

Google website in 1998.

Once, when I presented this version of the Google website, I was informed that there was an even older version. I researched and found this one:

Google website in 1997.

You might be thinking that in 1998, the entire internet was made up of websites with poor design. Then I will show you a 2006 website:

Twitter website in 2006.

On the other hand, I believe that Reid Hoffman probably felt less embarrassed with his first version:

LinkedIn website in 2005.

Another good example from that time is Facebook, which in 2005 was called Thefacebook and had Mark Zuckerberg’s photo in the upper-left corner of all pages:

Facebook login page in 2005.

Facebook internal page in 2005.

Now let’s see some Brazilian examples of the companies I worked for:

Locaweb website in 1999.

Conta Azul website in 2011.

Gympass website in 2014.

Lopes website in 1998.

Dialdata website in 1995.

The last one is the website I built myself for my company called Dialdata, one of the first Internet Services Providers in Brazil. I’ve built it using animated gifs and CGI scripts. So here’s my moment of embarassment… (=

Why you need to be embarrassed

I will give four reasons that justify the need to launch your product or feature as soon and as frequently as possible.

Moment of truth

No matter how much research, interviews, and prototypes you create, the moment of truth, the moment when you will know if your product is indeed the solution to a problem for a group of people, is when it is in the hands of your customers, in the context where they need the product.

The longer you take to launch your product, the more time it will take to learn from real people whether you are on the right track. Worse still, the more product you build without validating it with customers, the higher the chances of taking steps in the wrong direction, drifting away from the goal of building a product that helps you achieve the company’s strategic objectives while addressing the problems and needs of your customers.

That’s why it’s so important to introduce something from your product to potential customers and users as soon as possible. It will help you know if you are heading in the right direction. And if you’re not, what do you do? Fix it, adjust it, change it! The earlier you find out that what you’re developing is not on the right path, the better, because you’ll waste less time, energy, and money going in the wrong direction.

Too many features

There is a limit to the number of features a user can understand. When we add too many features, instead of creating a solution for the customer’s problem, we end up creating a new problem for them.

Kathy Sierra, an American user experience consultant, created a feature graph that clearly and humorously illustrates how user satisfaction decreases as we increase the number of features in a product.

Featuritis curve. Adapted from: Kathy Sierra

Return on investment

The longer your product takes to attract users and, consequently, customers who will eventually pay for your product, the more you will have to invest from your own pocket.

Here is a typical return on investment (ROI) graph for a product. Until you launch it and start generating revenue, all you will have are costs. You will be in the investment part of the curve. This only changes when you begin to have revenue that exceeds monthly costs. Then, you enter the area described below as monthly profitability. Only after a few months in this area will you start to see a return on your investment. See how the path is long:

Return on investment.

This valley that spans from month 1 to month 11 is the total amount of money you will have to take out of your pocket to invest in your product. Now, look at the graph below to see how a delay of 3 months in generating revenue can set back the return on investment by 6 months — and as if those 6 months of delay weren’t reason enough, the valley doubles in size. This 50% increase in the delivery time of your product will cost more than double what was initially planned. Are these 3 months of delay in revenue worth it? Does what you plan to do in these 3 months truly compensate for a 6-month delay in the return on investment and double the investment?

Postponed return on investment.

On the other hand, just look at what you gain if you manage to accelerate the development of your product and launch it 3 months ahead of schedule: you gain 6 months of return on investment! And the explanation for this is not only because you advanced the revenue intake, but because you spent much less to be able to launch the product faster. See the graph below:

Return on advance investment.

Cone of uncertainty

“The Cone of Uncertainty” is a well-known concept in project management. It describes how the amount of uncertainty decreases over time as we progress and learn more about what has been done and what still needs to be done. In an image, we can represent it as follows:

Cone of uncertainty.

This image shows that the further we are from the end of a project, the higher the uncertainty. At the beginning of a project, uncertainty ranges from 0.25x to 4x. For example, if we are estimating the delivery time of a specific project to be 4 months, at the project’s outset, this estimate ranges from 1 month to 16 months. That’s a LOT of uncertainty!

However, this is the theory. When we examine real-life projects, most of them have their estimates lower than what the Cone of Uncertainty suggests. It is very rare to see projects being delivered before their original estimate. Thus, we can better represent the Cone of Uncertainty as follows:

Cone of uncertainty in real life.

This image shows that the probability of an estimate being 2x to 4x times the original estimate is higher than the probability of the estimate being correct or lower. This is why many people, when providing an estimate, tend to increase it to improve the chances of it being more accurate. “Padding” is the informal term commonly used for this overestimation of estimates.

A very effective solution to reduce uncertainties is to make rapid and frequent deliveries. By doing so, we reduce the initial uncer- tainty because we are closer to each delivery, and consequently, the overall uncertainty is decreased:

Iterative cone of uncertainty.

We’ve just seen the four reasons to deliver early and often:

• Product in the hands of the user = moment of truth;
• Avoids feature overload;
• Accelerates return on investment;
• Reduces uncertainty.

Gympass Wellness

In 2018, at Gympass, we were constantly discussing opportunities to expand our marketplace beyond gyms and studios. Personal trainers, sports equipment e-commerce, and wellness apps were some of the expansion opportunities we were considering. However, since we had a lot to improve in our core offering, we decided to postpone the exploration of these opportunities.

In October 2019, we reached a point where our product development team was well-structured and functioning properly to tackle our challenges in our core product. So, we decided to focus on expanding our marketplace. We chose to work on an idea called “Gympass End User Partnerships Hub.” The plan was to partner with wellness apps and provide them to our users. This new idea had two main hypotheses that we needed to test:

• App providers willingness to partner: App providers, similar to gyms, are accustomed to the recurring monthly revenue model. Would they accept being paid per day of use?
• Users willingness to pay: Are our users interested in paying a subscription to access these apps?

To test our first hypothesis, we built a proposal deck outlining the value proposition we planned to deliver to partners and talked to some potential partners. We presented the partnership opportunity to 8 potential partners, of which 6 showed interest, and 4 decided to join our proof of concept: NEOU, a physical activity training app; 8fit, a physical activity and nutrition training app; Tecnonutri, a nutrition app; and ZenApp, a meditation app.

Okay, our first hypothesis was validated; we needed to validate the second hypothesis, the willingness to pay. Is our user willing to pay to access these apps through Gympass? To test our second hypoth- esis, we created a simple form describing the product and asked for name, email, and company. After providing this information, the user would be directed to a Paypal subscription page, would needed to provide credit card details to sign up for the service. The user would receive an email with activation links for each app. There was no actual product; it was just a form to test interest and an email with links to the apps.

Initially, we named this service Gympass W, with W representing Wellness. We added a beta tag to make it clear that it wasn’t a finished product. Later, we renamed it Gympass Wellness, to make its value proposition clearer.

Our plan was to test this proof of concept with 5 corporate clients in the US and 5 in Brazil, providing us with a potential user base of 15 thousand employees. We expected to have about 200 subscribers. We launched internally — eat your own dog food — on March 9, 2020, and gained 66 sign-ups. Then came COVID-19.

We were able to adapt our Gympass Wellness pilot in record time to be offered to our entire user base, so they could not only stay active but also take care of their nutrition and minds during these challenging times. With Gympass Wellness, we were able to address the problems and needs of users and our corporate clients during the crisis. We grew from 4 to nearly 100 partner apps in less than 2 months because we needed a good variety of apps in various languages, and we went from zero to hundreds of thousands of users in a few months. I often describe this moment as the biggest blitzscaling in my career.

Digital transformation and product culture

This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:

• About the book
• Part 1: Concepts
• Chapter 1: The so-called digital transformation — Project and Product
• Chapter 2: Uncertainty and digital transformation
• Chapter 3: Types of company
• Chapter 4: Type of company vs digital maturity
• Chapter 5: Business models
• Chapter 6: Agile, digital and product culture

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing 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 books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products