I believe it because we will talk about one of the most prevalent issues when creating products: overengineering them. In my opinion, overengineering has killed more products than the absence of good development practices.

Before getting into detail, let me talk to you about my background. Before being a Product Manager, I was an Engineer. My formal training was in Computer Science. While during my career, I've always been closer to the business than to coding myself. I've created, scaled, and managed both engineering and product teams equally.

So it's not that I talk about over-engineering from the outside. I'm guilty of having caused and suffered it. Because of that, I know it's crucial to learn what it is, its costs, and how we can prevent it.

What is overengineering?

If we go to the strict definition of Wikipedia, over-engineering refers to the fact of designing a product in a more complex way than necessary:

Overengineering (or over-engineering,[1] or over-kill) is the act of designing a product or providing a solution to a problem in an overly complicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of the original design. [2] — Wikipedia

In the context of software, I like this definition from Paweł Głogowski:

Code or design that solves problems you don't have. 

Now you will think, who designs or codes to solve a problem that she does not have? It seems ridiculous, right? Hold on to the chair because, after two decades of career and having done it myself, I can assure you that over-engineering is not the exception; it is the norm.

Overengineering causes

Nobody does it with bad intentions. On many occasions, overengineering happens because we try to anticipate the future and be ready for the unknown.

When we code a feature, it is easy to think that we can make it future-proof by investing a little more time "just in case".

The reality is that nine times out of ten, that "just in case" never comes. But along the way, we have lost valuable time and increased the complexity of the project, something that we will carry throughout its whole life.

Another cause of overengineering is often a lack of experience. The more senior you are, the less prone you are to overengineer because you've already lived through quite a few situations where artificial complexity has exploded in your face.

The learning curve with respect to the experience of an engineer usually follows a pattern very similar to this:

1. You start by programming in a straightforward way. 

2. You discover a paradigm such as object-oriented programming and jump on the bandwagon. 

3. You read about design patterns and start looking for the opportunity to implement them in every situation.

4. After a few years of having suffered unnecessary complexity, you go back to writing straightforward code.

Loosely defined requirements add to this problem as well. If an engineer does not have a well-defined problem, he will tend to overengineer to protect himself from uncertainty.

Boredom can also lead to overengineering. If an engineer does not have exciting challenges to face, he may end up complicating any problem simply by trying something new.

Overengineering consequences

At the beginning of the article, I was not kidding when I said that overengineering kills startups. It has two particularly perverse effects on any system.

On the one hand, it increases our development costs. If our engineers do not choose the simplest solution to address a problem, our expenses in time and money increase, preventing us from iterating faster.

On the other, it also increases our maintenance costs. Simple code is much easier to program, test, and modify. When we complicate it, the complexity can grow exponentially, impacting our iteration speed. On the other hand, it also increases our maintenance costs.

So I reaffirm myself. Overengineering kills products. Much more than the absence of good engineering practices. It is this way because to benefit from good practices first you need to have product-market fit, while overengineering can prevent you from getting it in the first place.

Overengineering examples

The first that comes to mind is microservices-based architectures. They came like a wave a few years ago, and they should have taken down more projects than those they have consolidated. 

I put them as an example of overengineering because they are not necessary in 99% of cases, especially for a startup that has to find market-fit and will benefit significantly from using a more straightforward architectural pattern like a "majestic" monolith.

If you succeed in finding market-fit and it turns out that you need to switch to microservices due to scale problems, oh boy, that's a good problem to have.

Premature optimization is often another typical example of overengineering. A common situation is preparing a system to absorb a large amount of traffic with an overly complicated infrastructure setup when you still don't have users. In most cases, having a monolith running on a single server is all you will need to validate your business model.

One of the worst examples of premature optimization occurs when we spend a lot of time designing a system trying to prevent repeating ourselves in the future and having to throw away part of the work done. 

It doesn't matter how perfect your design or implementation is if you never see it working because you go broke before. The worst code on the planet that helps you validate a hypothesis is better than standing still for fear of not repeating yourself.

Related to the above, software rewrites are an obvious example of overengineering. Usually, engineers do not like to work on legacy codebases. Their natural tendency is to do everything from scratch. But as Joel Spolski wrote more than 20 years ago in Things you should never do, rewrites rarely serve their purpose and even can take your business away.

It's obvious to say it, but your client doesn't care how elegant your system is on the inside. Your client cares that you help him solve his problem. Every minute invested in not giving them value is a wasted minute.

How to prevent over-engineering?

The best way to prevent over-engineering from my point of view is to turn your engineers into true product engineers.

We can achieve it by involving them in the day-to-day business, explaining the why after each initiative, and linking it with the metrics that matter for the organization and its vision.

We need to bring them closer to our users, inviting them to interviews and discovery sessions with them. You want your team to empathize intimately with your user's problems, so they can quickly discard any engineering effort that won't solve them as efficiently as possible.

Don't expect your engineering team to be motivated to avoid complexity if you treat them as mere production chain resources whose sole task is to implement user stories from a backlog. They need to understand the why behind each decision.

Related to the above, define the problem well to reduce ambiguity. Your engineers need to know the why, but they also need to know what to expect. The more you can narrow down the problem, the less reason they will have to protect themselves overengineering a solution. An excellent way to define the expectations of a system is by using service objectives using SLIs and SLOs.

Engineers are one of the most creative profiles in any company. If your team trusts your criteria, day-to-day ideas or initiatives will likely arise on their part that may show that they are thinking about a future "what if" scenario. When you have the intuition this could be the case, ask: How does this help solve our current user's problems? What happens if we don't do it now? The answers will help you to discriminate if it is a possible case of overengineering or not.

Lastly, more oriented towards founders, prioritize hiring senior engineers who have already had a few experiences in product companies. Look for war scars during interviews. Ask about their most painful experiences and how they dealt with them. Stick with those who put the user and simplicity ahead of simply technology solutions.

Mental models to prevent overengineering

YAGNI

The problem of overengineering is so prevalent in the industry that the engineers themselves have a term to refer to adding code "just in case": YAGNI, an acronym for "You are not going to need it".

YAGNI tries to prevent you from adding anything that is not strictly necessary to solve the problem you have in front of you because the reality is that most likely, "you won't need it".

KISS

The term KISS, "Keep it simple stupid", refers to the fact that simple systems are easier to repair, evolve and maintain. Therefore, simplicity should be one of the goals of any design, avoiding any unnecessary complexity.

Worse is better

With Worse is better, we emphasize that there comes the point when having fewer options is preferable to having more. It's this way because it can simplify the use of our product, making it attractive to a broader segment of the market.

In other words, it encourages us to maintain the minimally essential functionalities of a product, avoiding adding fat that can add complexity to it.

Conclusion

Overengineering has the potential to destroy your startup: 

• Adding unnecessary complexity. 

• Increasing development and maintenance costs. 

• Reducing your iteration speed.

• Thus avoiding you from getting market-fit.

Unfortunately, overengineering is no exception; it is the norm. For this reason, it is vital to know what it consists of and try to prevent it mainly by involving and bringing your engineers closer to your customers' real problems.

Every minute we invest in development that doesn't solve an actual customer problem is a minute wasted. Avoid falling into the "just in case" trap.

The graveyard is filled with exquisitely designed startups and products to scale to millions of users who never got the slightest bit of traction. Don't become one of them.

The image is from Paul Tudor Jones, a billionaire American investor. One of his most remarkable achievements was anticipating the October 1987 Black Monday. But we are not here to analyze Jones' investments. What struck me was the photo phrase seen in the background "Losers average losers".

It caught my attention because it hooked on a topic that I'd wanted to write about for a long time — the peril of sunk costs and how to avoid falling prey to them while creating products.

The sunk cost trap

A sunk cost in economics is one that you have incurred and can no longer recover. From a rational point of view, that cost is lost and should not influence any future decision-making. However, time and time again, humans demonstrate that we are not particularly rational.

A practical example of sunk cost in our daily lives could be trying to finish a bad book for the simple fact that we have already started it. The rational decision would be to abandon it as soon as we stop enjoying it. The reality is that the simple fact of having invested some time can prevent us from doing so.

The result is terrible indeed. In the best case, we will spend more time doing something that will not give us anything back. At worst, we will postpone reading other books that we may enjoy.

Another example of sunk cost mismanagement in the real world is relationships. Rationally, the decision to end a relationship that is no longer going anywhere should not consider the years we have spent in it. There is nothing we can do to get them back. Despite this, we tend to remain tied to people who harm us simply by not accepting the loss.

Sunk costs are not limited to the personal sphere. Companies and governments around the globe are prone to falling for them. We have a curious example in the world of venture capital and funds that invest in startups. Rationally, if a fund invests in a company and doesn't go as expected, it should cut the loss and move on.

However, on many occasions, we observe how before accepting that cost, professional investors try by all means to recover the invested capital, even if that means burning even more money. A recent example was Softbank's failed investment in WeWork.

Being a professional does not save you from falling into the trap of sunk costs.

Only losers average losers

I go back to Paul Tudor Jones and his phrase "Losers average losers". In the investing world, there is a technique called averaging down. It consists of lowering the average price paid per share, buying more when it falls, looking for an earlier recovery. Let's look at an example.

Let's say we buy 100 shares of any company at $10 each, with such bad luck that it drops to $5 in the following weeks. At this point, we could assume that our bet has gone wrong, accept the loss by selling, and dedicate that money to more fruitful investments. However, many investors choose to average lower, trying to lessen the loss and accelerate the recovery.

They do it by buying 100 more shares at the new $5 price. In this way, they have 200 shares for which they have paid $1500, "lowering" the price paid per share to $7.5. In this way, the stock only has to go up 50% to recoup their investment.

Look at the absurdity. Nobody buys stocks because they think they are going to go down. We buy stocks that we think may go up. However, the market tells us very explicitly that we were wrong. Instead of accepting it, admitting defeat, and investing in more productive places, we end up spending more money, expecting to recover sooner.

Only losers average losers.

How to avoid falling into the sunk cost trap

If you've made it this far, you probably already have some examples in your head of situations in which you or your company has fallen into a sunk cost.

The by-the-book example is that product or functionality that took months to develop, which has not produced the expected results but continues to absorb resources simply because sunsetting it would be accepting our failure.

It's natural. The human mind is stubborn. Even knowing the sunk cost trap won't allow you to escape it easily. Being this the case, we must be especially cautious when developing a product to avoid falling head over heels for it.

Here are some techniques that could be useful to avoid it.

Develop small

If you have to invest months of work in launching an initiative, when you finally do it, you will be so sunk in it that it won't be easy to abandon. Officially you will have linked your future to that of the initiative. If it fails, you will fail, so you will tend to dedicate whatever resources are needed to refloat it even if it no longer makes sense.

The correct approach is to develop small. Imagine that your goal for the quarter is to increase the acquisition by 10%. You can invest two and a half months working on an initiative and risk playing it all or nothing 15 days before the end of the quarter. Or you can decide to do five smaller two weeks initiatives with the objective of increasing the acquisition by 2% with each one of them.

Size your bets small. It will make it easier to leave the hand.

Define success before you start

Before starting any initiative, you should have clearly defined what you intend to achieve with it. If you don't, once you launch it, it will be tough to assess whether you have to continue betting on or kill it.

I've seen organizations investing months of work on ideas without making an effort to define precisely what they expect from them. By the time they want to do it, they are already so caught up in the trap that turning back is very difficult.

We seek to facilitate our future decisions. Suppose we have defined success, but we only achieve 10% of what we anticipated. In that case, we will have a powerful tool to decide whether to divest and allocate its resources to other more profitable ones.

The real value of a Product Manager is in making these types of decisions.

Use time to your advantage

Another appealing technique for avoiding being a victim of the sunk cost trap is to use the time to our advantage by limiting the amount we will dedicate to a specific initiative.

In the markets, it is usual to use "Stop Losses", a tool that allows investors to sell a stock when its price goes below a specific price threshold. For example, we can buy a share at $10 and put a stop loss at $8. If the price falls to that level, our broker sells the shares automatically, limiting our loss.

In addition to this technique, Paul Tudor Jones also used the concept of "Time Stop". If an investment did not follow the direction he expected in a specific time, he would sell his position and get out of it.

In the world of product development, Basecamp does something similar. Their development cycles are limited to six weeks. If a team does not get to ship anything significant in those six weeks, they close the initiative and move on to something else. This way, they limit the maximum loss they can suffer from a specific effort to those six weeks.

Do the same by setting the maximum time you will dedicate to an initiative before starting it.

Conclusion

As we've discussed, it's improbable that you can escape the sunk cost trap. The best advice I can give you is to lean on techniques like the ones we have mentioned to avoid falling prey to it.

It is essential to do so because resources are limited. If we are not quick to recover them when we don't get the return that we expect, it will threaten our ability to deliver real value and even our survival as a company.

It is almost a matter of life and death. Your goal is to stay in the game. To do this, we need to be radical by cutting our losses to maximize our number of tries.

Avoid gambling everything on just one hand.

Sir Basil Liddle Hart is one of the most famous military historians in the West. In his book, Strategy: The Classic Book on Military Strategy, he devotes the first part to making a strategic review of the most important battles between the 5th century BC and the 20th century.

More than 2,500 years of history go a long way. If we count three generations of soldiers for each century, we could say that modern military science draws on the knowledge of up to 75 previous ones. By contrast, those of us dedicated to Internet product development go for the second generation.

“Fools learn from experience. I prefer to learn from the experience of others. “ — Otto von Bismark

This post intends to present a leadership and management model for product teams that I’ve named Mission-Driven Product Management. It tries to condense hundreds of years of military experience into a simple set of guidelines that we can use in our day-to-day work.

March to the sound of guns

Few people doubt that Napoleon was one of the best generals in history, and it was precisely due to his Strategic and Leadership skills.

During his time, the prevailing military doctrine implied strictly following and complying with the orders set from the High Command. One of the keys to the French general's success was to change this doctrine by giving his commanders clear guidelines for action and independence to carry them out.

One of these guidelines was “march to the sound of the guns”. Napoleon incited his commanders to act without waiting for orders on their initiative if they heard the sound of the battle. Meanwhile, rival armies often stood still for days while waiting to hear from their superiors.

By the time the orders arrived, they had become obsolete in the face of the advance of the Grande Armée, rendering them useless. This speed of action and flexibility was one of Napoleon's primary keys to conquering much of Europe.

“Strategy is the art of making use of time and space. I am less concerned about the latter than the former. Space we can recover, lost time never.” — Napoleon Bonaparte

Auftragstactics

In Mission Command: An introduction Gavin Egerton, an Irish military man, tells how after the defeats at Jena and Auerstedt at the hands of Napoleon, the leaders of the Prussian army had to re-evaluate their doctrine.

Carl von Clausewitz, one of the most significant military theorists in history, was in charge of analyzing both defeats. He concluded that Napoleon’s willingness to foster initiative among his subordinates and his flexible approach to battle had been key to his success.

This reflection led Prussia to create a new military doctrine called Auftragstaktiks. Under it, the High Command was responsible for clearly defining the objectives of a mission. But, there were the subordinates on the battlefield, those closest to the action, to decide how to achieve them.

A central part of German military ideology ever since, a U.S. study in 1939 highlighted the German army's emphasis on developing its officers' leadership and initiative as one of the fundamental aspects of Poland's invasion success.

“The emphasis which the Germans placed on the development of leadership and initiative in commanders during years of preparatory training brought its rewards in the Polish campaign. With confidence that these principles had been properly inculcated, all commanders, from the highest to the lowest echelons, felt free to carry out their missions or meet changes in situations with a minimum of interference by higher commanders.” They recognized that “initiative, flexibility and mobility” were the essential aspects of German tactics. — Wikipedia

Commander’s Intent

Like Prussia at the time, almost all modern armies have their version of the Napoleonic doctrine of defining an objective and empowering their units to achieve it.

In the Anglo-Saxon world, it is usually known as Mission Command. And it is known as Commander’s Intent to clearly express what is expected of a mission without going into the details of how to achieve it, which is delegated to the teams involved.

Thus, military science recognizes how in high uncertainty environments, plans devised from the highs can become obsolete as soon as they come into actual contact with the enemy.

“No battle plan ever survives contact with the enemy.” — Helmuth von Moltke

Mission-Driven Product Management

For Mission-Driven Product Management, I define a doctrine of product development that draws on the same Napoleonic roots as AugsfrasTaktics or Mission Command that we can use while in high uncertain domains.

Under this doctrine, the Product Manager assumes the role defined by the Commander’s Intent. His primary duty is to clearly express the mission's objectives so that the team does not doubt what is being pursued. In terms of problem and solution, the Product Manager would define the problem.

The team, for its part, assumes responsibility for achieving the mission objectives on its own. They would be in charge of providing the solution.

To clearly express the problem, the Product Manager relies on a Mission Document, no longer than a page, containing at least the following keys:

• What is the problem we want to solve?

• Why is it important to solve it?

• How will we know that we have been successful?

Reading this document should help the team to understand what is expected of them. Additionally, it has the advantage that any other company member can read it and understand what is being done, which helps to promote internal alignment.

Companies like Intercom or Xing have experimented with their versions of mission documents. You can find a couple of examples here:

• Auftragsklärung (Xing)

• Intermission Document (Intercom)

Accompanying this document, there may be another one that would be the typical specification document. The Product Manager can use it to give more details about the business requirements, in the form of acceptance criteria, that the team's solution must satisfy.

He can also describe the use cases that we want to solve, provide additional context about the environment (competition, trends), and/or define the solution's scope by setting non-goals.

Therefore, the Product Manager's role is to give context to the team to design the best possible solution to the given problem. But it is not about working on isolation. Once the problem is defined, the Product Manager can collaborate as one more member on the ​​solution side. Still, it is vital that the team, based on their low-level knowledge about the system, participate and even lead this part.

Mission-Driven Product Management Pros

In my opinion, this approach to product development brings several advantages.

First, making use of the knowledge of the entire team leads to better solutions. For example, engineers are among the most creative profiles out there. Having them limited to implementing solutions that come from above without participating is a complete waste.

In the same way, it is much more motivating. In which team would you prefer to work? In one where your room for maneuver is limited to merely coding the user stories that someone has devised from above, or in one where you contribute to creating the best possible solution to a problem? It is a fact that the best profiles demand to participate and not be left out. Adopting a model where you empower them will improve their satisfaction, and therefore, also your retention.

Lastly, I also believe that it is much more efficient because it allows the Product Manager to focus on adding the most value: the problem's domain. It is materially impossible to think that a Product Manager can define the problem and propose the solution simultaneously. In situations where this happens, either the Product Manager becomes a bottleneck for the entire team, or neither the problem nor the solution is the best it can be.

No one size fits all

Although I firmly believe in this model, it must be borne in mind that, as with almost everything in life, it is not all blacks and whites.

Returning to the military experience, armies do not really only to a specific operation mode but adapt it to the situation and the moment's circumstances.

They reserve Mission Command for high uncertain environments. It is usually used by elite troops specially trained in these situations, such as the Marine Corps.

As it happens, the uncertain environment is usually one of the most common characteristics in the Startup universe, so if you work in this field, it is really possible that you can benefit from applying this model.

But if by any chance you find yourself in environments that are not complex, where most of the uncertainty is resolved, other ones where a more centralized model of control is exercised are also possible. The classic military model representing them would be Command and Control.

Always keep also in mind that the profiles required for one scenario and another are also different. The elite soldier is not going to endure being in a rigid environment and vice versa. A few months ago, I wrote precisely about this in Three phases and attitudes of Product Development in case you want to go deeper.

So far, these were my thoughts today about Product seasoned with a touch of military history. If you have any comments, questions or feedback, don’t hesitate to contact me via Twitter at @simonvlc. It will be a pleasure to continue the conversation there 😀.

Thx for your time, Simón.

The year 2016 is when Kent Beck, founding father of the Extreme Programming and the Agile Manifesto movements, published a changing paradigms article: The Product Development Triathlon.

Beck begins the article with this first paragraph:

25 March 2016. Because I keep careful notes these days, I can identify the precise moment when I asked the question I should have asked twenty years ago: what if those waterfall folks are not wrong? What if they are solving a different problem than I am solving? What problem is that?

This epiphany does not come to him by chance. Beck was then working for Facebook, where he found successful teams working with the most diverse methodologies, including the classical Waterfall development model.

The question then arises. What if there is no model (Agile, Waterfall, etc.) that works for all product development phases? What if, in each stage, some models behave better than others?

From there, Beck introduces a Sigmoid-type curve and describes three stages that each product goes through during its evolution: Exploration, Expansion, and Extraction.

In his own words:

Product development proceeds in three phases:

1. Explore–the risky search for a viable return on a viable investment. Successful Exploration is unpredictable, so the highest expected value strategy is to reduce the cost of experimentation and put a little investment into many, uncorrelated experiments. If you are lucky, one of these experiments turns out to be unexpectedly successful, which leads to:

2. Expand–now things are going nuts (think Pokemon Go or Facebook Live Video). Unanticipated bottlenecks appear. All you have time for is to eliminate the next bottleneck just before it derails you. Once growth becomes routine, it is time to:

3. Extract–now the shape of the problem and solution spaces are clear. One euro in equals three euros out. Playbooks emerge: here is how you roll out the service in a new city. Economies of scale matter: delivering the service at lower cost is more profitable.

For Beck, each of these phases presents different problems and, therefore, requires particular approaches. We can’t expect to operate the same way during Exploration as when we are in Extraction.

If we assume this postulate, the classic Waterfall so vilified by the Agile Manifesto followers can work. But it works in a particular phase, Extraction, in which you have eliminated all the uncertainty and your future is predictable. This stage is characterized by 1+1 equals 2, allowing you to correctly estimate and lay down plans with a high degree of confidence.

By contrast, in Exploration, where most Startups live, 1+1 can be equal to 0; Or 17; Or any other number. In this phase, the uncertainty is maximum, and your only objective is to optimize the number of experiments to find those growth levers that allow you to reach the next one. Most experiments will fail (1+1=0), but the ones that succeed may be exponential (1+1=17).

In other words, there are no right or wrong models. A model will be more or less successful depending on the phase in which our product is. And this is important because it also affects the profiles, the people, who will stand out (or suffer) in each phase.

Wardley's Pioneers, Settlers, and Town-Planners

Therefore we arrive at Simon Wardley, currently a researcher in technology with experience managing development teams. In 2015, Wardley wrote a post on his blog in which he stated that not only aptitude but also attitude is key when building a team.

Wardley raises three types of profiles according to their mindsets: Pioneers, Settlers, Town-Planners.

Pioneers are those who are better suited to deal with uncertainty. They are adventurers not afraid of entering uncharted territories. They enjoy exploring, paving the way for the next to come, and have the ability to correct course quickly, even if it means retracing their steps back.

Settlers are those profiles that pick the paths pioneers have successfully opened. They improve, expand, and make them useful to be traveled on (or commercialized).

Town-Planners, pick what the Settlers have enhanced and the market validated, and then industrialize it. Their specialty is optimizing costs by taking advantage of economies of scale. There is little to no uncertainty; each euro earned from the margin is one euro more of profit. Their way of thinking is structured and long-term.

Merging 3X and PST to improve the productivity of your teams

We have seen two mental models, Beck’s 3x and Wardley’s PST. It is easy to see how the phases of one and the other’s profiles overlap almost entirely.

The consequences are not trivial, and it is that, depending on the stage in which your company or product is, some people will fit better than others. Similarly, we must pay special attention to phase changes because the profiles and models you used in one won’t probably adapt well to the next.

For example, if your company is in Exploration, you’ll need Pioneer-type profiles comfortable with uncertainty and can withstand or even excel in chaos. However, if those same Pioneers reach the Extraction stage, they will find themselves lost.

Likewise, if you try to explore with Town-Planners-type profiles, you will make them terribly unhappy. Their mental models are not prepared to open new paths; they need certainties and precise plans. And since this is their natural tendency, if you do not identify the problem soon, you may end up building in excess to do any experiment, which in the initial phase of any product can kill you.

I have just introduced an essential concept that of happiness. It is no surprise that your employees’ satisfaction is key to productivity, and this is closely related to having each profile at the right place.

Suppose Pioneers have to act as Town-Planners, or Town-Planners do the job of Pioneers. In that case, unhappiness will grow, productivity and motivation will suffer, not to mention the costs derived from staff turnover, etc.

Use the 3X curve as an alignment tool

Not everything is lost. Fortunately, human beings are smart enough to adapt to different contexts, but it is essential to understand where we are and how it affects what is expected from us.

For example, as a recently graduated engineer, my profile was that of a Town-Planner. I had little adaptability and was easily disturbed by uncertainty. However, over the years, and after having gone through different and varied professional experiences, I learned to embrace change as part of my daily life.

It is that experience that I try to transmit to my teams every day, clearly explaining the phase in which we find ourselves and what the company expects from us. I do it out of self-interest because I need a motivated team, which is impossible to get if we disagree with the game we play.

For this purpose, the Kent Beck 3X curve is an ideal tool. A good team exercise would explain the different phases, draw the curve on a board, and then have each team member point where they think the product is.

The more the team agrees on the stage, the more alignment you will have, and the easier it will be to achieve your goals. If you find yourself at opposite ends, you will need to dig deeper and understand why you think differently until you get to the root of the discrepancy and fix it.

You can do the same exercise at the company level. Misalignment does not only occur between teams but also between departments. Believe me, there is nothing sadder than seeing two areas pulling the company in opposite directions, both believing they are doing the right thing.

A company can have products in several phases

An important note is that while generally, a company is in a single phase at a specific point in time, its products can be in different stages. A good example is Facebook, which we could probably position in Extraction, but having products in various maturity grades.

And this is relevant because it means that all profiles can fill a gap. If an employee has a Pioneer profile, take them to a front-line team where everything is yet to be discovered. On the other hand, if you have a Town-Planner, transfer him/her to those teams that work more long-term and need more structured thinking. Both will be happier, but above all, also more productive.

Conclusions

• Not everything is binary. Agile can coexist with Waterfall development. There are no right or wrong models; there are merely different problems to solve. If Kent Beck can recognize it, so can we.

• Different phases in product development require different profiles and mindsets. Do not take a Town-Planner to explore; do not build a long-term project with a Pioneer.

• Pay attention to phase changes. The Pioneers who paved the first trails may not be the best to maintain and optimize them.

• Use the 3X curve to align your team with the phase and mindsets necessary at all times. If necessary, do it at the company level as well.
  Within the same company, different products can coexist in different phases. Take advantage of it moving the profiles to where they suit best.

The ‘Disagree and Commit’ principle has a two-pronged objective:

• To encourage the team to disagree when making an important decision

• To unite the team in committing to the decision once it has been made

Disagreeing: Encouraging conflict

Why would we want to encourage disagreement when making a decision? In order to make the decision more effective.

To illustrate the importance of disagreement in decision-making, Peter Drucker, who is widely considered the godfather of management, tells a story about Alfred Sloan, the man who, in the 1930s, turned General Motors into the biggest company in the world.

The story, as told by Drucker, begins in a meeting with the advisory board of General Motors in which an important decision had to be made. Upon speaking to everyone in attendance and realizing that they all agreed with the original proposal, Sloan said:

“I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.” — Alfred Sloan.

The Consensus Trap

By doing this, Sloan was trying to avoid the Consensus Trap. The Consensus Trap goes as follows: although in theory, it seems as though everyone in the meeting is in agreement, in reality:

• The majority disagrees, but simply keep quiet

• The decision is so important that nobody wants to assume full responsibility

• Everyone wants to get the meeting over and done with as soon as possible

We can encourage disagreement and avoid the consensus trap with one easy technique: interpret silence as a negative and ask every person in the meeting clearly if they agree with the decision.

Silence during a meeting should never be taken to mean that those in attendance accept the results of the meeting. We must make sure that everyone present agrees by asking them clearly to say their point of view out loud.

But the fact remains that sometimes people will say whatever they need to say in order to end the meeting. That’s where the second part of the technique comes in: committing.

Committing: Executing the decision

Committing means that whatever final decision is made, the team must do whatever they can to implement it. ‘Disagreeing and Committing’ achieves this by making everyone at the meeting responsible for ensuring the work gets done.

But why would people implement a decision they didn’t agree with? Firstly, because everyone at the meeting has had the opportunity to express their opinion and has been listened to. Even though their point of view may be at odds with the final decision, it is easier for them to accept it knowing that they have at least had their voice heard, and even, perhaps, that their initial ideas were wrong.

That’s not all. If we actively disagree with the decision, the last thing we want is for it to fail because it was badly implemented. By this token, the more we oppose an idea, the harder we work to bring it to fruition. Andy Grover himself said:

“If you disagree with an idea, you should work especially hard to implement it well because that way when it fails you’ll know it was a bad idea. Not bad execution.” — Andy Grove.

The great thing about the ‘Disagree and Commit’ principle is that, when done correctly, it assures the best possible result for the business:

• Even if we were wrong, we have still in some way contributed to the best possible decision being made.

• If we were right, then we know the weaker ideas have been discarded in the shortest time possible

Thus, we avoid the worst possible scenario, in which a small minority feels they have contributed to making a decision but the rest of the team aren’t compelled to implement the decision because they don’t support it.

‘Disagree and Commit’ speeds up decision making

Another interesting result of this technique is that it also avoids that we invest a lot of time discussing a decision favoring the decision-making process.

By the same token, Jeff Bezos introduced the term in one of his annual letters to the investors at Amazon:

Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” — Jeff Bezos.

In fact, this principle has become one of the principles of leadership at Amazon:

13. Have backbone, disagree and commit

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

If you want to know more

Here are a few links to articles and books on the topic of ‘Disagree and Commit’ which helped me in the writing of this article:

• Product Management in Practice: A Real-World Guide to the Key Connective Role of the 21st Century, by Matt LeMay

• The Advantage, Enhanced Edition: Why Organizational Health Trumps Everything Else In Business, by Patrick M. Lencioni

• Disagree and Commit, a blog post by Tom Tunguz

• Hackernews thread in which the use of Disagree & Commit is debated

The Inversion Principle is the perfect example to introduce you to the concept of mental models, and how they can help us in our daily lives, so I’ve decided to write this post to organize my ideas and share them with you.

What is a mental model?

A mental model is quite simply a way of thinking that helps us to process the world around us in a more effective way. In more technical terms we could call them hacks or routines that our brain uses to simplify the outside world.

Nowadays, almost everything we read on the Internet about mental models we owe to Charlie Munger, the legendary investor and Warren Buffet’s right-hand man, who in 1994 gave a speech in the USC Business School (video/ transcription) in which he described how he used them:

What is elementary, worldly wisdom? Well, the first rule is that you can’t really know anything if you just remember isolated facts and try and bang ’em back. If the facts don’t hang together on a latticework of theory, you don’t have them in a usable form. You’ve got to have models in your head. And you’ve got to array your experience — both vicarious and direct — on this latticework of models. You may have noticed students who just try to remember and pound back what is remembered. Well, they fail in school and in life. You’ve got to hang experience on a latticework of models in your head.

What are the models? Well, the first rule is that you’ve got to have multiple models — because if you just have one or two that you’re using, the nature of human psychology is such that you’ll torture reality so that it fits your models, or at least you’ll think it does. You become the equivalent of a chiropractor who, of course, is the great boob in medicine. It’s like the old saying, “To the man with only a hammer, every problem looks like a nail.” And of course, that’s the way the chiropractor goes about practicing medicine. But that’s a perfectly disastrous way to think and a perfectly disastrous way to operate in the world. So you’ve got to have multiple models. And the models have to come from multiple disciplines — because all the wisdom of the world is not to be found in one little academic department. That’s why poetry professors, by and large, are so unwise in a worldly sense. They don’t have enough models in their heads. So you’ve got to have models across a fair array of disciplines.

As we can see, Munger uses mental models to process all the information he absorbs, both from what he reads and his own experiences. These models then form a catalog, from which we can extract the one we need according to the situation, and apply it in the real world.

The Inversion Principle

One of the mental models that Munger has discussed on several occasions is the Inversion Principle, which is based on a maxim by the German mathematician Carl Gustav Jacobi: “Invert, always invert” .

Jacobi made important contributions to the mathematics of his day, and one of the ways he dealt with the most difficult conundrums was to invert them.

Munger explains the concept using India as an example:

“Think forwards and backwards — invert, always invert.” “Many hard problems are best solved when they are addressed backward.” “The way complex adaptive systems work and the way mental constructs work is that problems frequently get easier, I’d even say usually are easier to solve, if you turn them around in reverse. In other words, if you want to help India, the question you should ask is not “how can I help India,” it’s “what is doing the worst damage in India? What will automatically do the worst damage and how do I avoid it?”

Naturally, we have to confront problems head-on, starting from the beginning. However, Munger highlights the importance of first approaching the issue from the opposite angle, to ensure that we have considered everything that would ultimately prevent us from achieving our objective.

Applying the Inversion Principle to developing better products

The process of using the Inversion Principle is very simple:

1. Define the problem: What is the problem you are trying to solve?

2. Invert it. What would you have to do to guarantee the failure of your objective?

3. Consider the solutions. What would you have to do to avoid the failure that you identified in the previous step?

Let’s apply this logic to a real-life example. Imagine we are Product Managers of an e-commerce, and we want to increase the conversion rate.

Instead of thinking about what we could do to increase it, let’s invert the question. What would guarantee that our conversion rate does not increase?

Here are a few examples that come to mind:

• Not giving visitors the confidence to become customers

• Complicating the buying process by making the customer create an account

• Having an unreliable or unresponsive application

• Not offering all possible payment methods

• Not offering a compatible version for all possible devices

• Including unnecessary information on the product pages

Once we have a list of things that will guarantee our failure, we can start to look for solutions. Let’s take a closer look at the first three points on the list:

Not giving visitors the confidence to become customers

We know unequivocally that one way of ensuring our conversion rate does not increase is if the clients do not trust our product. What could we do to build trust?

• Make sure the app is well designed and looks professional

• Include high-quality images of the products

• Highlight our contact details, including phone number, so the customer knows that if they have a problem of any kind, a member of our team will be available to offer support

• Display accessible, clear information about the buying process: orders, refunds, delivery, etc.

• Explain who we are and why the client should trust us

Complicating the buying process by making the customer register an account

Introducing a registration process can take a lot of customers to abandon their shopping carts. What could we do to minimize the chances of this happening?

• Firstly, consider this: is it really necessary for the user to have to create an account to buy a product? Could we avoid it altogether?

• If not, how can we simplify the process? For example, does the user really have to think of a username and a password? Their username could be their email address, and instead of choosing a password, we could email them an activation link to validate their account.

Having an unreliable or unresponsive website/app

Few things are more frustrating than clicking “proceed to checkout”, only to find a slow server or an error message that prevents us from completing the purchase. To resolve this issue, we could implement performance constraints on our app which the technical team would be responsible for ensuring. For example:

• The total size of each request between our app and the customers' device cannot exceed 1MB

• The system must have a 99,99% availability rate

• The system must be able to withstand a load of 1,000 users per second for intervals of 15 minutes

• Less than 0,5% rate of errors in our error-tracking service

Simple, right? The great thing about the Inversion Principle is that it forces us to focus on the things that are most critical to our goal, and, as Munger himself says, long-term it’s much more effective to consistently avoid errors than to always try to make progress.

“It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.” Charlie Munger.

Other examples of the Inversion Principle

Let’s look at other ways we can apply the Inversion Principle outside the field of Product Management.

Applying the Inversion Principle to achieving personal goals

A few months ago, I had a small crisis at the sheer volume of unread books that were accumulating around my house, so I began to look for a solution using the Inversion Principle.

What could I do to ensure that I could never read all the unread books in my house?

• Waste time on social media

• Read too much online news

• Watch too much Netflix and other streaming services

Once I worked out how to guarantee failure, I took the following measures:

• I uninstalled all social media apps

• I blocked the URLs for the main digital news outlets on my devices

• I watched a maximum of one TV episode per day

The results were almost immediate, and in due course, my pile of unread books started to go down.

Applying the Inversion Principle to your relationship

Can the Inversion Principle be applied to relationships? Let’s test it out. Firstly, what would guarantee the failure of a relationship?

• Not communicating regularly

• Not being empathetic, or putting yourself in the other person’s shoes

• Not being a trustworthy person

Applying the Inversion Principle to being a good leader

This is especially useful for people who are in charge of a team. Firstly, what would make a bad leader?

• Not having a clear strategy and constantly changing your mind

• Micromanaging your team and telling them ‘how’ instead of explaining ‘why’

• Not doing regular, individual meetings with the members of your team to help them with their professional development

• Not being transparent, and withholding information you receive from other parts of the company

Applying the Inversion Principle to improving your life

Let’s get philosophical for a moment. What will guarantee you have a miserable life in the future?

• Not making the most of every moment with your family

• Not taking care of your mind and body

• Spending beyond your means

Conclusion

As you can see, there are endless ways in which we can apply the Inversion Principle, because, at the end of the day, it’s nothing more than a tool that forces us to consider problems from a different perspective.

I am particularly drawn to hacks that force me outside of my comfort zone, because, in my own experience, it’s not enough to always stick to what we know without considering other ways of doing things.

For those who didn’t previously know about mental models, I hope you found this post interesting! I also hope to continue writing about this, and other subjects, in the future. It’s been a pleasure to share this with you, and I leave you with a few links so you have some great reading material for the coming weeks. Enjoy!

Other mental models

There are hundreds of mental models which we can apply in our daily life. Here is a list of the most useful links I have found:

• Farnam Street, a website that I cannot recommend highly enough, it has a list of up to 109 mental models all briefly explained.

• Gabriel Weinberg, co-founder of DuckDuckGo has his own personal compilation of Mental Models on Medium

• For Product Managers, another essential figure is Brandon Chu, General Manager and Product Director of Shopify, who published this article on Medium: Product Management Mental Models for Everyone

References

Articles about the Inversion Principle which helped me write this post:

• Inversion and the power of avoiding stupidity

• Inversion: How Smart People Consistently Avoid Looking Dumb

• Inversion: The Crucial Thinking Skill Nobody Ever Taught You

• 5 Critical Mental Models to Add to Your Cognitive Repertoire

• A Dozen Things I’ve Learned from Charlie Munger about Inversion (including the Importance of being Consistently Not Stupid)