This is Viktor Martynov, Founder & CEO at Aviamarket, speaking to you.
In this post, I’ll explain how business metrics support developers in improving their understanding of a product.
Metrics serve as a coordinated language of communication between the business and the development team. Product managers and analysts rely on metrics to gain insights into the product’s trajectory, pinpoint its strengths and weaknesses, and determine which aspects require prioritization at different times. Metrics also play a role in evaluating process efficiency and overall productivity.
Every business, at a particular stage of development, collects various metrics. Startups focus on different metrics than large corporations, but ultimately, they all boil down to one universal metric — profitability.
There are various tools available for measuring these metrics. Take Google Analytics, for example. In the case of larger companies, they might even develop their own solutions. These solutions involve a system in which data is divided among various platforms like Google Analytics, Power BI, MetaBase, and others. Meanwhile, internal data scientists analyze another portion of the data.
Fortunately, there are readily available solutions for the most popular libraries and frameworks. Consider a library for Vue, Angular, or React, for instance. In these libraries, you can send specific events and specify details, such as the type of click, category, and value. The number of fields can be extensive, and you can determine where to extract each value based on input from analysts.
Let’s explore some challenges that developers might face, which can be effectively addressed with metrics.
Sometimes, it’s unclear why a manager assigns seemingly trivial tasks, like rearranging blocks, tweaking button colors, or adjusting font size and color. These tasks appear to be time-wasting in comparison to other, more substantial responsibilities.
As developers, we write code and observe its functionality — buttons get pressed, code gets sent to the backend, and everything seems to be working as expected. However, we struggle to perceive the tangible value that our work brings to the end user, the very people we’re creating the product for.
This is a direct result of the previous point. Our job becomes boring because we lack a sense of connection to the overall business.
Our potential remains unrecognized, and we don’t get opportunities for career advancement. Product managers tend to view us merely as task performers who excel at coding and don’t seek input or ask questions.
Why are we hired in the first place? Of course, because of our skills — but primarily, to ensure that the code we write brings money to the business.
During the work, the product manager or analyst requests changes like block swaps or button color adjustments, which might not sit well with us. However, there’s a hypothesis behind these requests: even seemingly minor alterations can potentially enhance the company’s business metrics.
Previously, we had the old dark blue “Request an offer” button. Now, it’s the new blue “Enquire now” button. At first glance, it might not seem like a big change, so you may wonder why we spent time on this seemingly mundane task. After all, the developer could have been working on a user’s personal page on the website.
But let’s not forget that we’re talking about metrics here! This means we need to understand the impact of this change and how it relates to metrics. So, we go to the product manager, Oliver, and ask, “A month ago, we updated the button’s color and name instead of finalizing new features. What’s the difference?” It turns out that this button color change had an impact on the “get_consult” metric that analysts track, and, more broadly, it led to an increase in the total number of applications.
Meanwhile, the business tracks every step of the user journey, from visiting the site to buying an aircraft, by measuring metrics for each action by buyers.
Let's imagine that for a month, the total transaction value on the platform was EUR 30,000,000. After a minor update, the transaction value increased to EUR 55,000,000. Now, we can clearly see that changing the button’s color led to more user clicks. This makes the seemingly trivial task suddenly meaningful.
However, it can also be the opposite. For instance, a product manager has a hypothesis that leads to what appears to be a silly problem. The team addresses it, but two weeks later, it turns out the hypothesis was incorrect, and the solution fails. The manager then requests the code rollback, which can be frustrating. But it’s essential to understand that failing hypotheses is not a negative outcome. Even if one in ten hypotheses fail, they provide valuable insights for further development.
In the previous section, we discussed how to ask a product manager about the purpose behind tasks. But what if we regularly check our updates to see how they benefit the business? This would help us look beyond the code and understand the bigger picture, the impact on the whole company. We start to see the connection between our work and financial outcomes. For instance, five small releases contribute to a turnover of EUR 55 million.
Here’s a glimpse of what this might entail.
When we understand how to measure our impact and the inner workings of our product, it makes development more exciting. We now know the “why” behind each task and how it benefits users. This fundamentally changes how we approach product development. We’re no longer just coding; we’re thinking about the whole product.
Will an employee who understands the product and contributes to development solutions get overlooked? The answer seems quite clear. Your ideas add value to the business. While it’s not the sole basis for promotion, it’s one of the many aspects in the promotion hierarchy, alongside engagement, initiative, technical and interpersonal skills, and more.
Let’s talk a bit about refactoring. Developers always see its value, but managers may not always share the same perspective.
Refactoring is designed to eliminate code deficiencies, enhance the developer experience, and boost platform or website performance. Notably, through refactoring, we can also impact business metrics, as Amazon has effectively demonstrated.
In 2006, Amazon discovered that a mere 100-millisecond delay in website loading caused a 1% drop in revenue. According to Google, Amazon made $26.9 billion in 2021. If developers hadn’t improved the platform over the course of a year, the company would have missed out on an additional $27 billion. That’s an astonishing amount to overlook.
What’s intriguing is that the hypothesis regarding the 100-millisecond delay wasn’t proposed by a manager but by a developer. It was a regular engineer who thought, ‘What might happen if our site slowed down? How could this impact us?’
So, we discovered metrics and found out that they help:
Horizontal progress. The developer is building analytical skills, which could lead to a future role as a team lead or manager if desired.
Also, a product-oriented mindset. This allows the developer to better understand their work, propose new features, and enhance their prospects for career growth (while reducing the risk of burnout).