Often I see this problem in the context of solution design:
- We discuss options.
- We consider several potential candidates.
- We determine how much profit each option will bring.
- Usually, the one that provides the most and the fastest wins.
No one should be surprised by this order of things. After all, it is obvious that we prefer to engage in actions whose results we will see quickly.
However, this is precisely the trap that many teams fall into.
Problems that come with one-dimensional gain
Let’s start with a life analogy. How many times have you bought sweets to satisfy a momentary craving? More than once, right? The colorful packaging, the promise of a sweet taste, and the tricks of store marketers have probably caught everyone. And a quick rush of endorphins makes life instantly better. 😃
We encounter the same temptations in the process of creating software. Here, we take shortcuts, there we make a quick fix, and it can immediately go into production. The PM and the team are satisfied, and we can move on to the next task.
Such a solution seems profitable in the short term. But looking more long-term:
- Eating sweets makes you gain weight terribly.
- All the “cut corners” significantly lower the quality of the product.
We end up with obesity and a system that cannot be maintained.
How to counteract this?
Profit Matrix
The solution I recommend to the teams I work with is to analyze profits (and losses) in two dimensions:
- Short-term
- Long-term
On such a matrix, we place potential proposals. We then analyze how a given change will affect the product.
Based on this, we can analyze the introduced change in terms of whether it will generate more problems than solutions.
Example
Let’s take a fairly typical problem “Where to store the service keys in our product?"
The simplest and fastest option is:
Let’s keep it in the code. Developers can change them immediately there.
Does it work? It works. 😃 At least at the beginning. In the long run, it will look like this:
Looking ahead, we see the following problems:
- Employees with access to the code repository have access to all keys. - It is difficult to manage which key belongs to which environment (DEV, TEST, PROD).
- Versioning of keys is challenging.
We can consider other, possibly better options:
- Keys in the database.
- Keys in CI/CD.
- No keys – using IAM.
Our matrix will then change as follows:
- Keys in the database – Not only do we now have to create an additional structure, but it is also difficult to manage in the long run.
- Keys in CI/CD – We can use ready-made options from the provider, and it scales nicely per product. But there is an initial learning cost.
- No IAM keys – This option allows us not to insert keys at all, so if this option is available, why not use it? 🤔
We see the broader impact of each option on the product and can choose the one that we will be satisfied with both now and a year from now.
Potential Use
In the discussed scenario, we use the matrix to improve the quality of the technical discussion within the team. However, it is not its only use:
- Internal team meetings — discussions between Dev / Test / PM about the impact of features on the product.
- Stakeholder meetings — convincing how a “quick” change will affect the quality of the product.
- Quarterly OKR meetings — choosing the best feature to achieve set goals.
In any situation where you want to take a broader look at the impact of a given change on the solution, it is worth pulling out the profit matrix and analyzing the consequences in a broader perspective.
