That is a substantial number. It also requires a careful explanation.
It does not mean design generated €300 million in revenue. It does not mean customers spent that amount on security add-ons. And signed contract value is not the same measure as annual recurring revenue.
It means these capabilities helped give enterprise customers what they needed to sign contracts whose combined value exceeded €300 million.
The distinction matters because the way we describe results reveals something about our judgment. A large number can establish the scale of a business outcome. It cannot, by itself, establish our contribution to it.
Start with the purchasing decision
I led design across Growth and Enterprise and owned Miro's admin and enterprise experience. Part of that responsibility was understanding what prevented organizations from adopting and expanding the product.
The canvas was where people experienced Miro's value. Enterprise purchasing introduced additional questions: could the organization protect its content, meet its compliance requirements, and control how AI interacted with its information?
Those questions shaped whether a customer could move forward.
Working with business development, customer support, and my Product counterpart, I connected the experience roadmap to requirements emerging from customer conversations. I proposed security and data-protection capabilities on the canvas, including capabilities that became paid offerings.
The commercial logic was specific. Customers needed certain controls before they could commit. Addressing those requirements helped make a purchasing decision possible.
That is a stronger explanation than saying that better design drove growth. It identifies how the work contributed.
A contract contains more than our contribution
An enterprise contract reflects the value of the whole product and the work of many people.
Customers were purchasing Miro for collaboration. Product and engineering teams built and maintained the capabilities. Sales teams developed the opportunity and negotiated the agreement. Security, legal, procurement, and customer stakeholders all participated in the decision.
Our enterprise work addressed requirements within that larger process.
A capability can be necessary to a deal without accounting for the entire value of the deal. If a customer needs a particular security control before signing, delivering that control can have significant commercial importance. It does not follow that all the contract's value belongs to that control—or to the team that designed it.
This is why I describe the result as signed contract value supported by the capabilities, rather than revenue generated by design.
That wording is deliberate. It preserves the scale of the outcome while respecting the limits of attribution.
Define the number before using it
"€300 million" sounds precise. Without a definition, it leaves several questions unanswered.
Was it pipeline or signed business? Annual revenue or total contract value? Revenue from an add-on or the broader contracts in which that add-on played a role?
In this case, the figure refers to signed enterprise contract value. It is not a pipeline estimate, and it is not an ARR figure. It includes the broader contracts supported by Enterprise Guard, compliance, content-security, and AI-security capabilities.
These distinctions should sit close to the metric. Readers should not have to discover them later.
I would rather present a qualified result that survives scrutiny than a stronger-sounding claim that becomes smaller with every follow-up question.
For design leaders, that is especially important. We often ask to participate in investment and commercial decisions. We need to handle business evidence with the same care we expect others to apply to customer research.
Explain what you actually decided
Even an accurately defined business outcome does not explain leadership.
A portfolio could display €300 million in supported contracts and still leave the reader unsure what I did. Did I design a screen? Lead a team? Identify the opportunity? Allocate resources? Influence the roadmap?
My contribution needs its own account.
I led the enterprise experience, controlled design hiring and budgets, and worked with my Product counterpart on prioritization. I used customer evidence and input from business development and support to argue for investment in the enterprise foundation. I also made the case for dedicated engineering capacity and proposed security capabilities that addressed customer requirements.
Those are decisions and responsibilities I can describe directly.
The contract figure provides commercial context for that work. It does not replace the explanation of it.
The same standard applies when assessing other leaders. I want to understand what they recognized, what they chose, what authority they held, and what changed because of their involvement. The number becomes useful when it is connected to those details.
Keep forecasts separate from results
Before securing investment, I worked with a data scientist to assess potential growth and ARR. That analysis helped us evaluate the opportunity and make the case for resources.
It was forward-looking. The signed contract value was a subsequent commercial result.
Those forms of evidence serve different purposes. A forecast supports a decision under uncertainty. A result helps us evaluate what happened afterward. Combining them into one success statement hides the uncertainty that existed when the decision was made.
An honest leadership account should preserve that uncertainty.
We did not have the eventual contracts in hand when arguing for the investment. We had customer evidence, commercial requirements, and an assessment of the opportunity. Leadership still had to decide whether the potential return justified the cost, competing priorities, and migration risk.
That judgment is part of the story. Retrospective certainty makes it disappear.
Winning the contract was one milestone
Security and compliance capabilities helped meet purchasing requirements. After commitment, customers still needed to adopt the product successfully and sustain its use.
Our focus expanded to equipping admins to champion Miro within their organizations: understanding usage, introducing capabilities, and supporting broader adoption.
We judged progress through signed deals, ARR, and monthly active usage. Each addressed a different aspect of the business.
Signed contracts showed commercial commitment. ARR provided a recurring-revenue measure. Monthly active usage helped us examine whether people were using the product. None could fully substitute for the others.
A strong sales result did not mean the experience was finished. It created a reason to keep examining what happened after the sale.
What the number is useful for
The €300 million figure helps communicate the scale of the business supported by enterprise capabilities. It makes clear that administration, governance, and security were consequential parts of the product.
It cannot isolate design's causal contribution, establish the value of an individual feature, or prove that every investment decision was correct.
That does not diminish the work. It places the claim where the evidence supports it.
When I describe design's impact, I want to be able to explain the customer requirement, the decision we made, the capability we delivered, and the business outcome it supported. I also want to be clear about what I cannot attribute.
The metric earns its place when I can answer the next question: what, exactly, did our work make possible?