It was a reasonable question. The canvas was the product people recognized. It was where teams collaborated and experienced Miro's value. Administration happened somewhere behind that experience. The assumption was that admins could handle complexity, and that improving their experience would contribute less to growth than improving the canvas.
I had been hired to build Miro's enterprise foundation and led design across Growth and Enterprise. From that position, I could see how much depended on the people working behind the canvas. They managed access, supported adoption, protected content, and helped their organizations decide whether Miro could be used more broadly.
We had underestimated both the difficulty of their work and its influence on our business.
Testing the assumption behind the roadmap
Customer feedback made the usability problems visible. But usability complaints alone did not answer the investment question.
Rebuilding the enterprise experience would require significant engineering capacity. It would compete with other priorities. It would also introduce migration risk for customers already relying on the product. Leadership needed to understand why taking on that cost and disruption would help the company grow.
I worked with business development and customer support to examine where customers were struggling and where we were losing them. Those conversations connected what we heard in research to consequences beyond the interface.
We had assumed customers could work around a difficult administrative experience. In practice, they were less technical than we expected, and the complexity was not something they could simply absorb.
That changed the argument I needed to make. Describing a better experience was insufficient. I needed to explain what the existing experience was preventing customers from doing—and why that mattered commercially.
Alongside customer research and reports from business development and support, I worked with a data scientist to assess potential growth and ARR. The projections were a way to evaluate the opportunity, not a guarantee of the return. Together, these sources gave us a stronger basis for deciding where to invest.
From usability problems to an investment decision
The enterprise experience had developed through individual features, with legacy structures underneath. Improving isolated screens would leave much of that fragmentation intact.
I argued for changing the information architecture around how customers understood and managed their organizations. That meant treating administration, permissions, security, and governance as parts of a connected experience.
It also required a team able to work on that experience over time.
I made the case to our CEO for a dedicated team of 30 engineers focused on customer experience, building missing capabilities and moving away from legacy products. I expanded the design team to 20, with authority over design hiring and budgets, and worked with my Product counterpart to determine priorities.
The difficult commitment was sustained capacity. Each individual feature could have a justification, but the foundations between them also needed ownership and investment.
Our roadmap therefore had to account for both the capabilities customers were asking for and the structural work required to make those capabilities fit together.
Funding the transition as well as the destination
Approval did not remove the risk.
Existing enterprise customers had integrations with ServiceNow and other third-party systems. Those connections supported real work. A cleaner information architecture would be little comfort if the transition broke something their organization depended on.
We shipped the information architecture first because it provided the foundation for subsequent work. We also replaced custom interface code with the design system we had created.
For migration, we rolled out gradually by region and enterprise size. We handled the largest and most complex accounts individually, and I funded a team to provide hands-on support.
That support was part of the investment decision. If we wanted customers to move to a new experience, we had to resource the transition as well as the product itself.
The business case could not end at "this will be better when it is finished." It had to account for how existing customers would get there.
Two different paths to growth
Our early enterprise priorities included security capabilities customers needed before they could sign contracts.
I proposed security and data-protection capabilities on the canvas, including work that became paid offerings. Enterprise Guard, compliance, content security, and AI security helped address requirements that mattered in large enterprise purchasing decisions.
This was one connection between the enterprise foundation and growth: giving organizations what they needed to commit.
The next was helping them adopt more broadly after that commitment.
We increasingly treated admins as people who could champion Miro within their organizations. Giving them visibility into usage and tools to support adoption made their experience part of how the product expanded.
These were related but distinct objectives. Meeting a purchasing requirement did not automatically produce sustained usage. We looked at signed deals, ARR, and monthly active usage because each answered a different question about whether the work was contributing to the business.
It would also be inaccurate to attribute an entire enterprise contract to one feature or to design alone. Security capabilities helped meet requirements within a broader purchasing decision. Being precise about that contribution makes the commercial argument more credible.
What this changed about how I lead
The most useful question in this work was not "How do we convince leadership that admins deserve better UX?"
It was "What assumption is causing us to underestimate this customer?"
Once we examined the assumption that admins could tolerate complexity, we could connect research to customer loss, purchasing requirements, organizational investment, and delivery risk.
That connection required work across functions. Customer research described the experience. Support revealed the burden of living with it. Business development showed where it affected customer relationships and deals. Commercial analysis helped us assess the opportunity. None of those perspectives was sufficient alone.
For me, this is a central responsibility of design leadership: bringing those perspectives together well enough to support a consequential decision.
The canvas remained essential. But its value depended on an enterprise being able to adopt, govern, and support it. The people responsible for those conditions were customers whose needs deserved a place in our growth strategy.
When a product is loved by its users but struggles to grow inside an organization, I now look closely at the people responsible for making that growth possible. Their work may be less visible. Its consequences rarely are.