In the previous chapters we saw my personal leadership principles:

• People: priority # 1, always
• Leading is like being a doctor
• Leading under pressure
• Mentoring is a two-way street
• How and when to delegate

We also saw what corporate culture is, a set of ways to solve problems and react to the situation shared by a group of people working together. And we saw the 5 values ​​needed to create successful digital products:

• Don’t waste time looking for culprits, focus on learning
• Don’t compare work situations with war, nobody wants to kill anyone
• Profit and revenue are consequences, they should not be the main focus
• Transparency, the foundation of a high-performance team
• Diversity, the basis of the best products

Product culture

It turns out that these values are necessary, but not sufficient. There is a set of four values ​​that are in fact the core of the entire digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results. The four values, which will be the subject of this and the following chapters, are:

• Release early and often
• Focus on the problem
• Result delivery
• Ecosystem mindset

Let’s start with the first one: Release early and often.

The sooner we present the product to our users, the better, as we can receive feedback from real users who will be able to use the product in their own context. There are 3 reasons that justify this need to launch your product or functionality as soon as possible and frequently.

Moment of truth

It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

The longer it takes you to get your product out on the street, the longer it will take to learn from real people if you are on the right track. And if that’s not enough, the more steps you will be taking in the wrong direction.

You will only know if the product you made really solves some people’s problems if they use it. The longer it takes for this to happen, the longer it will take to know whether or not it is the solution to the problem.

And if not, what do you do? Fix, adjust, change! The sooner you know that what you are developing is not on the right track, the better because the less time, energy, and money you will waste going the wrong direction.

Too many features

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

Kathy Sierra, recognized programming and user experience instructor, has created a feature chart that illustrates in a clear and fun way how user satisfaction decreases as we increase the amount of functionality in a product.

Return on investment

The longer your product takes to have users and, consequently, customers who will at some point pay for your product, the more you will have to invest out of your own pocket. Below is a typical graph of a product’s return on investment (ROI).

During the period that you are building the product and don’t release it to users, all you will have is cost. That is, you will be in the investment part of the curve. This only changes when you start earning revenue and it is greater than your monthly costs. Then you enter the area described below as monthly profitability. Only after a few months in this area will you have a return on your investment. See how long the road is.

Now take a look in the graph below, how a 3-month delay in obtaining revenue can delay the return on investment by 6 months. Are these 3 months of delay in earning revenue worth it? What will you do in those 3 months really make up for 6 months of delayed return on investment?

On the other hand, see what you get if you can accelerate the development of your product and launch it 3 months ahead of schedule. You get 6 months of return on investment! And the explanation for this is not just because you get to the revenue early, it’s because you spent less to be able to launch the product faster. See the chart below.

If you are not ashamed of your first version, you took too long to launch

LinkedIn founder Reid Hoffman once said that:

“If you are not ashamed of the first version of your product, you took too long to launch”.

To illustrate this phrase, which in a way summarizes the value of release early and often, I decided to take screenshots of the first version of some well-known services.

MMF – Minimal Marketable Feature

Minimal Marketable Feature or MMF comes from a 2003 book called Software by Numbers, by Mark Denne and Dr. Jane Cleland-Huang. In this book, they introduce the concept of:

Incremental Funding Methodology (IFM), an ROI-based approach (Return on Investment) for software development in which the software is developed and delivered in carefully prioritized blocks of functionality valued by the customer. These blocks are known as Minimum Marketable Features – MMFs.

It is a concept prior to that of MVP, which has the advantage of this mentality of implementing the minimum necessary for each feature of the product. The basic difference between MVP and MMF is that, while MVP talks about a minimum viable product, that is, it needs a complete product, even if minimal, in order to be presented to possible users, MMF brings the minimal concept down to the level of each feature.

To illustrate MMF, they used a very simple example: imagine that you have to build an internet banking system on the web. There are many features and it can take many months or even years for this product to be delivered with all “mandatory” minimal set of features. When thinking in terms of MMF, we should look at those “mandatory” features and find out if we can launch them independently, that is, if a particular feature, if launched independently, would bring some value to the customer. In an internet banking system, we could choose to release it only with an account statement and no other resources. This would be a very simple internet banking system, but if launched as soon as it is ready, and not after some other features are also ready, it will bring value to the customer sooner. And whenever you deliver value to the customer, you also deliver value to your company. In addition to the satisfied customer, in this example you have probably reduced the cost that your company has in serving these customers, because if users do not obtain their account statements over the internet, they will certainly use another way of obtaining this information and probably this other way is not as economical as internet access, like going to an agency or an ATM.

Minimum marketable functionality (MMF) is minimal, because if it were smaller it would not be marketable. And an MMF is marketable because, when launched as part of a product, people use (or buy) the functionality.

The next time you are planning a new product or feature set for an existing product, try to think in terms of MMF. It can bring a lot of value to you, your customers and your company.

Summing up

• There is a set of four values ​​that are in fact the core of every digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results.
• The three reasons for you to launch your product soon are that (i) this is the moment of truth, (ii) so you avoid the excess of features and (iii) accelerate the return of the investment.
• If you are not ashamed of your first version, it took too long to launch.
• Minimal Marketable Feature or MMF is a concept prior to that of MVP, which has the advantage of bringing this mentality of implementing the minimum necessary for each product functionality.

In the next chapter we will see the importance of focusing on understanding the problem to be solved before thinking about solutions.

Update

There’s a fourth reason to release early and often. It’s the Cone of 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? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of leading digital products