Focus on value

I ask myself the same question every day: Does my work add value? Or am I moving rocks uphill just to let them fall and start all over again? Am I like Sisyphus?. Not even 20th century philosophers can stop my desire of creating products that actually add value and also make me grow at a personal and professional level.

Good Product Software Engineers have a high sense of ownership and are involved in all the phases of building a product. From problem identification, solution research and business assessment to iterative implementation, continuous deployment and value measurement. They focus on increasing value over anything else. And it's not easy because it involves understanding the user, the business, the product, the brand, the team, the company and its politics, etc.

Inexperienced Product Software Engineers focus on technology. They find solutions to problems but they don't question if it is a problem worth solving. They don't know the value they are adding so they don't find the most adequate solution either.

What is value?

The Cambridge Dictionary defines it as:

1. the amount of money that can be received for something.
2. the importance or worth of something for someone.
3. how useful or important something is.
4. a number or symbol that represents an amount.

I personally prefer how Ron Jeffries defines it in The Nature of Software development :

In Agile software development —as in many other realms— we talk about the notion of value. We make decisions about what to do, or what not to do, based on value. We do things sooner if they are of higher value, and we do things later if their value is lower. What do we mean by value? Value is, simply, "what you want".

Good and experienced Product Engineering teams are able to forecast the value they will add with a decent accuracy. They take decisions based on the certainty they have on that forecast and ideally they can quantify it. They can put a number on it because statistics and data analysis are part of the culture. But inexperienced ones struggle to do that. Most of the time is because, in their teams, value is not explicit nor visualised.

If value is what we want, it can be for anyone and it can take any form. Value can be for the user when we implement a new feature. It can be for the Product Engineering team when we improve our CI/CD pipeline. It can be for the Business Developer when we automate a weekly report.

Start with the language

Atomic Habits by James Clear has taught me how small but key changes can have an big impact. James states that, if you're life is too chaotic and you want to regain control, start making your bed in the morning.

Language matters and it shapes the way we think so the first step is to focus our language on value. Most of us work with user stories, so let's take them as a example. User stories are typically written in the form of:

As a type of user, I want some goal so that some reason.

The value is placed at the end of the sentence. We are supposed to make decisions based on how much value we forecast to add but we treat it like the least important thing. An example helps:

As a Business Developer, I want to have the weekly report automated so I can save time.

We do focus on the Business Developer but we don't necessarly focus on their problem. Solving this is simple, just place the value first:

Value added for someone, somehow.

Again, an example helps:

To save time to the Business Developer, automate the weekly report.

Focusing on the added value makes the team start to ask questions otherwise they wouldn't ask. How much time? In this case the value is quantifiable. Maybe 2 hours for writing that weekly report. We can even question the solution. Could we do something to save even more time to the Business Developer?. Sometimes what the user wants is not what the user needs.

Continue with the data

A young Product Engineering team won't be able to forecast the added value with great accuracy but starting to measure is the way towards focusing on value.

Most of the time, before deploying something to production we are in a superposition. We can't be sure that what we built adds value, until the user, the Engineering Team or the Business Developer interacts with what we built. And the only way to collapse that wavefunction is to measure. Sometimes the measurement will be quantitative and other times it will be qualitative. Either way, measuring the added value leads to an organization based on data.

Taking measurements is only another step forward. But without visualizing value, it is all the same. That's why it is important to:

• Make your data available to everyone. Every member of the Product Engineering team should be able to ask any question to the data and receive instant answers. Use some tool like Metabase.
• Make it visible. A young Product Engineering team doesn't have the habit to dig into the data. Create dashboards that everyone can see at any moment.
• Make it accessible. Teach the members of your team how to use the necessary tools to ask the right questions. Give an SQL 101 course.

Without visualizing value, it is difficult to start asking questions. It is even difficult to feel that our work is worth something.

Have patience though. Growing a Product Engineering team from childhood to maturity takes time. Because it's not about changing processes but about changing people and evolving culture.