In the article "The Method," I mentioned that every product must have a 10x differential that changes the way the user interacts with your platform. I really like this reference because it makes us think about how to design a product that truly makes a difference in our user's life.

I came across this video of Steve Jobs recently where he draws a rather intriguing connection to the potential of a tool:

Quotation here:

I remember reading an article when I was about 12 years old, I think it might have been Scientific American, where they measured the efficiency of locomotion for all these species on planet Earth, how many kilocalories did they expend to get from point A to point B. And the Condor 1 came in at the top of the list, surpassed everything else, and humans came in about a third of the way down the list, which was not such a great showing for the crown of creation. But somebody there had the imagination to test the efficiency of a human riding a bicycle. A human riding a bicycle blew away the Condor, all the way off the top of the list. And it made a really big impression on me that we humans are tool builders, and that we can fashion tools that amplify these inherent abilities that we have to spectacular magnitudes. And so for me, a computer has always been a bicycle of the mind, something that takes us far beyond our inherent abilities. And I think we're just at the early stages of this tool, very early stages, and we've come only a very short distance, and it's still in its formation, but already we've seen enormous changes. I think that's nothing compared to what's coming in the next hundred years.

I repeat the quote here - "for me, a computer has always been a bicycle of the mind, something that takes us far beyond our inherent abilities." This is coherent and a significant part of what we have been experiencing for years, but now greatly amplified by the entire revolution surrounding artificial intelligence.

So, I ask again - what are you doing in your software to make it the bicycle of the mind for your user? A tool that will make them so productive and powerful that they won't be able to distance themselves from it anymore!

But beyond thinking about how to develop the software and which differentiators you should address in the product's construction, I would like to address in this article the "game" we need to play to increase the chances of our product's success.

The Game

Infinite Game

The first concept is that of the "Infinite Game." Many times, we think of competition as a zero-sum, finite game where we have to defeat an opponent.

However, the market doesn't behave that way. The game to be played is infinite in the sense that you should focus much more on how to play better today than yesterday in your business, rather than on how to destroy your adversary.

This infinite game only ends when you leave the competition, so you should prioritize long-term victory and staying in the arena over simply obliterating the opponent.

The goal is to keep the game being played! A game that doesn't have known players (your competitors can change at any time), the rules can change at any moment, and at the end of the day, your greater objective is continuity.

An interesting reference to this concept is the book by Simon Sinek, titled "The Infinite Game" (https://amzn.to/44oeTQS), but while browsing the internet, I came across the young Steve laying out this concept for us:

One of the things I don't see is, I don't see it myself, I don't see it in enough of the rest of us, is I don't see that start-up hustle. In other words, if we zoom out at the big picture, it would be a shame to have lost the war because we've won a few battles.

And I sort of feel like I and some of the rest of us are concentrating too much on the smaller battles.

And we're not keeping the war in perspective. And the war is called survival.

The war is called not running out of money until we get our product on the market.

What a sensational quote! "We're not keeping the war in perspective." You need to look at your war in perspective, and a significant part of the strategy is survival. Surviving and getting better every day.

What are you doing today in your company/product to play this infinite war?

Market Size

What's the size of the market you can address? Sometimes your solution is magnificent, has a great competitive advantage, but you're selling it to just a handful of clients.

You won't move the needle if you don't have a large market. Which brings us to our third point...

Distribution Model

Developing the software, believe me, is just the tip of the iceberg. If you don't have a clear distribution model, in other words, a strategy for accessing the market, you might have the best product in the world, but it will fail.

Microsoft is a great example of this - at various points, it didn't even have the best product on the market, but it had such a strong and well-defined distribution model, and knew how to play the "infinite game," which gave it time to evolve the product, capture markets, and succeed.

If you're founding a startup with three developer partners who believe that writing the code will bring them all the success in the world, rethink your strategy now.

Output vs Outcome

When developing a product, it's quite easy to confuse output with outcome. Measuring development success solely by outcomes is a risk. You might be delivering a lot of things that hold no value for your end-users.

This raises the question - how to measure both. I like to think of output based on some metrics mentioned in "Accelerate: The Science of Lean Software and DevOps" (https://amzn.to/3P4IcU5):

• Deployment frequency - How often the company releases successfully to production.
• Lead time for changes - How long it takes to put a change into production.
• Mean time to recovery (MTTR) - How long it takes to recover from a production failure.
• Change failure rate - The percentage of deployments causing failures in production.

These metrics provide a balanced measure of the speed at which you're delivering and the amount of problems that speed might be causing in production.

I usually add a fifth metric:

• Code Coverage and QA strategy

Which points to how you're developing an automated testing strategy. Without these five well-crafted metrics, you run the risk of delivering your software slowly, which goes against the principle of the infinite game + improve every day.

Speaking of the product, the outcome is certainly one of the most important metrics! What you're delivering, is it bringing value to the end-user?

I like to think of outcome in three major groups:

• Traction
• Product
• Business

Traction is often the easiest metric to measure - how your product is gaining traction. Are users using a set of features? Or have you developed something super-specific that only serves a very limited set of users? Sometimes this metric indicates failures in other processes - training, feature promotion, etc. But it definitely should be measured. Even your most junior PM can install a tool (Google Analytics, Mixpanel, Pendo, etc.) and start measuring traction easily.

Product means measuring how the product brings business value to the user. For example - my user became X% more productive in task Z after the implementation. Vehicles started saving K% fuel after using the feature. Difficult to measure, but certainly what will make a difference for your user in the end.

Business outcomes are certainly complex to measure and align with the company's strategy. User retention (reducing churn by X%), entering a new market segment are examples of business outcomes.

The cover image is a photo taken by the author, in San Francisco, looking at the Golden Gate Bridge.