Measure Impact, Not Effort

The article argues that technology companies should measure the real impact on the customer, not just internal metrics such as the number of deployments or infrastructure modernization. It introduces a three-layer measurement system (customer metrics, DORA metrics, capacity allocation), prioritization methods such as Cost of Delay and WSJF, and organizational principles such as stream-aligned teams that connect technology work with the delivery of real value.

A team at a bank deploys a new version of its internal middleware. The deployment goes smoothly, the monitoring is all green, zero incidents. A success?

It depends on what you're measuring. If it's the number of flawless deployments — yes. If it's whether the client got their mortgage in five days instead of fourteen — you don't know the answer yet.

And this is exactly where it's decided whether a company grows or slowly dies.

A technology company that isn't delivering customer value faster than it did last year isn't growing — even if its infrastructure is more modern, its pipeline cleaner, and its documentation more thorough. The market doesn't wait. The competition doesn't fall asleep. And the customer doesn't know — and doesn't need to know — which orchestrator is running in the background.

Growth is not the number of systems deployed. Growth is what the customer will get tomorrow and wasn't getting yesterday.

But how do you tell whether a company is delivering value or just running in place?

The most effective filter for any technology decision is seven words long: How will the person using us notice?

This question doesn't disqualify internal projects or infrastructure work — on the contrary, it helps justify them properly. Optimizing a scoring model that shortens mortgage approval from fourteen days to five has a clear customer impact. Migrating an orchestrator that makes life easier for three engineers has an indirect impact — and deserves a different priority.

Companies that ask this question systematically don't do less work. They do different work. But the question alone isn't enough — you have to be able to measure the answer.

Product-mature companies typically measure across three layers, each of which answers a different question.

This is the main metric. Everything else is supporting. At a bank it might be loan approval time, the number of clicks to open an account, the share of applications completed digitally, or the Net Promoter Score after an interaction with an advisor.

The key is that every team can connect its work to the movement of one of these metrics. Not always directly, not always immediately — but there has to be an articulated path from what the team does to what the client experiences.

This principle is captured by the concept of the North Star Metric — a single metric the entire organization orients itself around. Booking.com measures the number of completed reservations after subtracting cancellations. Airbnb tracks the number of nights booked. A bank can measure the time from application submission to disbursement of funds. They all have one thing in common: the metric directly correlates with whether the customer is getting value.

Even the best idea won't help if it takes months to reach the user. The DORA metrics — deployment frequency, lead time for changes, change failure rate, time to restore service — have become an industry standard precisely because they measure the speed at which a good idea turns into a customer experience.

The Accelerate research program, which developed these metrics, analyzed data from tens of thousands of technology professionals and showed a strong correlation between performance on the DORA metrics and a company's business results. The best teams (which DORA labels "elite performers") deployed code more than two hundred times more often than the weakest teams — with a seven times lower failure rate.

What matters is what the DORA metrics don't measure: they don't measure the number of components deployed or the technical sophistication of the solution. They measure the flow of value from idea to user.

The third layer is the simplest, and yet most companies don't track it: what percentage of engineering capacity goes into features with a direct customer impact, and how much into internal infrastructure?

There is no universally correct ratio. A bank under pressure from regulators needs a different mix than a fintech startup. But tracking this ratio over time is essential — if it shifts over the long term toward internal projects with no clear link to the product, the company is dealing with itself instead of its clients.

Marty Cagan, author of the book Inspired, distinguishes between "discovery" (what to build) and "delivery" (how to deliver it). Most companies invest almost exclusively in delivery and neglect discovery. The result is that they build efficiently — but not always the right thing.

But measurement alone isn't enough. One question remains: in what order to do things?

Most companies prioritize their backlog by urgency or by how loud the requester is. There is a better way: calculate how much every week of delayed delivery costs.

Don Reinertsen, author of The Principles of Product Development Flow, introduced the concept of Cost of Delay — the financial expression of the value that slips away for every unit of time a feature is not in production. A new online mortgage application that would bring in 200 new clients a month has a Cost of Delay estimable in the tens of millions of korun per year. Migrating an internal logging framework has a Cost of Delay close to zero.

This principle underlies the WSJF method — Weighted Shortest Job First: priority is determined by the ratio of Cost of Delay to task size. A small change with a high impact goes first. A large project with an unclear benefit waits. It's not a perfect model — it requires estimates that tend to be inaccurate. But even a rough estimate of Cost of Delay is infinitely better than none.

To keep estimates from being pure speculation, it helps to formulate every change as a testable hypothesis: "We believe that simplifying the form by three fields will increase the share of completed applications by 15%. We'll verify this with an A/B test in two weeks." The main benefit of hypothesis-driven development is not the accuracy of the prediction, but that it forces the team to explicitly name the expected impact before the first line of code. A feature without a formulated hypothesis is an expense without an expected return.

One question remains: how to arrive at the hypotheses. Impact mapping, a method by Gojko Adzic, offers a simple visual structure: the goal (increase conversion by 20%) → who influences it (clients, advisors, back-office operators) → through what change in behavior (fewer branch visits, faster decisions) → what enables that change (online repayment simulation, pre-approval notifications). Every feature must have a path back to a business goal. If it doesn't, it's not a feature — it's a wish.

Teresa Torres, in her book Continuous Discovery Habits, develops this approach into Opportunity Solution Trees — a tree structure whose root is a customer outcome, whose branches are opportunities to achieve it, and whose leaves are specific solutions. The team first maps opportunities and only then selects solutions — the exact opposite of when someone shows up with a finished proposal, "let's deploy X," and only then looks for a justification.

But measurement and prioritization hit a ceiling if the organizational structure doesn't support the flow of value to the customer.

Matthew Skelton and Manuel Pais, in the book Team Topologies, describe four types of teams, the key one being the stream-aligned team — a team organized around a single stream of customer value rather than around a technology layer. In a banking environment, that means a "mortgages" team with competencies spanning from the frontend through the backend to the data model, instead of separate "frontend," "middleware," and "database" teams between which every request travels for weeks.

A stream-aligned team owns the entire chain from customer need to production deployment. It has no alibi of "we're waiting on another team." It has no excuse of "we delivered our part." It has a single metric: did the customer get value, or not?

For such a team to work, it needs to handle two things in parallel: figuring out what to build, and building it. Cagan talks about continuous discovery and continuous delivery, Torres about continuous discovery habits — in both cases the point is that both streams run at the same time. While part of the team delivers a validated feature, the other part validates further hypotheses through prototypes, customer interviews, and data analysis. The team never builds blindly — and never stands still.

Combining stream-aligned teams with this approach and with measuring Cost of Delay creates a system where everyone knows what to build, why to build it, and how much it costs when it's delayed. That is the infrastructure for growth — not an orchestrator, but a way of thinking.

Even the best measurement system is useless if the information doesn't lead to decisions. The most powerful mechanism for connecting metrics with action is a direct link between financial results and compensation.

Profit shares, performance bonuses tied to customer metrics, transparent sharing of business results — these tools turn abstract dashboards into personal interest. An engineer who sees a direct connection between what they delivered and the number on their paycheck doesn't need anyone to explain prioritization to them.

Without this link, the rational strategy is to minimize personal risk and maximize the visibility of one's own work. A new internal framework is easy to present at a review. Shortening mortgage approval time by two days is hard to attribute to a single person — and yet it has a many times greater impact on the business result.

Transforming an entire organization is a long-term process. But any team can start — tomorrow.

Step one: Add a "customer impact" field to every backlog item. It doesn't have to be quantified — a verbal description of how the change will show up in the client experience is enough. Filling in this field alone changes the way people think about their work.

Step two: At the start of every planning session, ask the question: "If this sprint we could do only one thing that would have the greatest impact on the client, what would it be?" And do that one thing first.

Step three: At the end of every cycle, evaluate not just what was delivered, but what changed. Not "we deployed a new middleware," but "the application processing time dropped from fourteen to nine days, and the conversion rate rose by four percentage points."

Companies that measure impact instead of effort don't deliver more. They deliver what matters. And that's why they grow — while others just run.

This text is a general analysis of product metrics and approaches to measuring impact in technology companies. It does not describe any specific organization.

Methodological note

The concept, structure, and editorial line of the article are the work of the author, who developed the content sketch, established the key theses, and directed the entire creative process. Generative AI (Claude, Anthropic) was used as a technical tool for research, fact-checking, and fleshing out the author's outline.

The author continuously edited the outputs, verified the key findings, and approved the final version. No part of the text was published without human review. All factual data were verified against the publicly available sources cited in the text.

This procedure complies with the requirements of Article 50 of EU Regulation 2024/1689 (AI Act) on the transparency of AI-generated content. #poweredByAI