👋 Hey, I’m Lenny and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career.

Varun Parmar’s podcast appearance about Miro’s unique approach to product got so much love that I knew I needed to go deeper. In part four of an ongoing series on how the best product teams build product (don’t miss Figma, Coda, and Duolingo), Varun delves into Miro’s OKR process, planning systems, design reviews, product building philosophy, and, as always, shares tons of plug-and-play templates you can start using today. With over 50 million users, and a valuation of $17.5 billion (making it one of the 10 most valuable U.S. startups), there’s a lot we can learn from Miro’s journey.

What stood out to me most about Miro’s approach to product:

1. Their focus on speed—and how they operationalize it

2. Their systems for maintaining a high quality bar, including their “Mona Lisa principle” and their design review process

3. Their AMPED team structure

4. Their history with OKRs

5. Their product principles

6. The power of having a three-year “painted picture” vision

7. Their epic team rituals, including MiroFest:

Thank you, Varun, for taking the time to answer so many of my questions! Enjoy.

How Miro builds product

1. How is the Miro product org structured?

Over time, we’ve experimented with multiple organizational structures. The first structure divided the org between “Core Product” and “Growth,” which allowed each team to stay focused on one priority: delivering product features or driving growth. Then we evolved our structure to focus more on users, experimenting with use-case-focused teams to solve specific user needs and end-to-end experiences, e.g. Miro for workshops. 

Today the product organization is a cross-functional team composed of Analytics, (Product) Marketing, Product, Engineering, and Design—or AMPED for short. AMPED is organized into seven “product streams” aligned to the product component that each stream owns:

1. Core product experience

2. Enterprise

3. Growth

4. Core product foundation

5. Infrastructure

6. Platform

7. Data

Each stream focuses on a set of user personas or outcomes. For example, the Enterprise stream focuses on the enterprise admin and security persona, while the Platform stream is focused on developer persona, and the Growth stream is more horizontal, focusing on specific acquisition and activation outcomes.

Finally, we have common metrics across all of AMPED that are supported by multiple streams and teams. For example, improving first-time user experience is an outcome that is supported across multiple streams.

What we see is that the AMPED structure brings together all required functions into the team from the get-go; they bring diverse perspectives, as well as empathy for each other and the users, resulting in a much more effective product development process. Another great example here is that Product Marketing is part of our product development process from the start. So we’re not only thinking of what to build but how to position it, how to differentiate, and how to reach the users.

2. How far out do you plan in detail, and how has that evolved over the years?

At the company level, we have a “three-year painted picture,” which is a high-level picture that Miro’s Leadership Team co-develops and that defines the outcomes we want to achieve—both for our users and for Miro as a company. The painted picture is bold and ambitious, and establishes a general direction for the entire company. 

The painted picture informs our annual strategy, which sets the direction for the entire AMPED org for the next 12 months. We build the product strategy collaboratively in three steps, between November and January.

• First, the Product Leadership Team identifies priorities for the year (e.g. outcomes we need to achieve) and an initial list of initiatives we want to pursue. This is the stage where we also select initiatives from the past year that should continue or stop and add new initiatives. The leaders consult their teams and represent their views in discussions. 

• Next, the AMPED leaders come together to refine our priorities, discuss conflicts, and make tradeoff decisions. Typically, this group meets at an in-person offsite and dedicates four or five days to finalizing the product strategy. We also start thinking about staffing needs here to ensure that our most important initiatives are staffed appropriately across all functions.

  Our last offsite was in Barcelona in mid-December—we had a lot of deep discussions, ensured that leaders understood many areas of the product, not just their streams, and also managed to spend some time at the Joan Miró museum for inspiration! The in-person discussions also made alignment a lot easier.

• Finally, the full 700-plus AMPED org reviews the product strategy. The product strategy document is shared with everyone; I present the strategy at an all-hands meeting, and we hold Q&A sessions where AMPED leaders (not just product leaders) answer questions. This phase is about building broad awareness and providing teams with clarity on what we want to do. We got (and answered) more than 1,000 questions in the most recent iteration and refined the details based on the team’s input. 

Each stream takes the annual strategy as input and identifies which outcomes they will support and what initiatives they will drive. Teams also identify the estimated impact of their initiatives—this is helpful when we’re trading off between different opportunities they could pursue. The identified initiatives go into our product roadmap.

Our product roadmap operates on a rolling six-month cadence—we have 80% confidence in the current quarter and 50%-plus in the subsequent quarter. We used to plan just two weeks out, but this longer-term cadence allows us to be more strategic, while also being nimble and reacting to market changes. And we’ll revisit and update our product strategy mid-year based on the progress until then and the emerging market context.

For example, Miro AI is in beta as of March 9, a point the team reached in just eight weeks. When changes are happening in the market or inside the company, you should be agile and ready to adjust, not trapped by your own planning. Our flexible roadmap framework allowed us to embrace this watershed moment in AI capabilities; we prioritized initiatives and secured a team that rapidly ideated, built, and deployed the features. Other key factors that helped us act fast included: people who had passion around the topic (a motivated team can do a lot!); singular focus, as we deprioritized everything else for the core AI team; and fast, almost daily iterations and standups where we tweaked things, resolved blockers, and highlighted achievements.

3. Do you use OKRs in some form?

We do. And, like many other things, it is constantly evolving. We’ve improved a lot, but there’s also more work for us to do here.

We used to have OKRs at each level in the organization: Company → AMPED → Product Stream → Team, and followed a quarterly planning process. It was great in theory but had many challenges.

There were three big problems with this setup:

1. Overlapping initiatives: Having OKRs at every level meant each team had to define their objectives and initiatives. This often resulted in teams rephrasing the same initiative at different altitudes and adding it to many key results. It was hard to do traction (check execution against goals) and was not providing clarity or alignment for teams. So we’ve removed extra layers and now have Company-, AMPED-, and Product Stream-level OKRs, with each team just deciding which OKRs they will support. It has brought much-needed alignment and clarity to teams.

2. Too much time for the “process”: Quarterly planning needs a lot of time. In addition, the same DRIs had to present updates at multiple traction forums. It led to a lot of time being spent in following the process and was just not working. So we’ve moved to a semi-annual OKR frequency and fewer OKR tractions each month, reducing duplicate and process-related work by a lot. We also do quarterly check-ins for course correction, if needed. For example, if a KR metric is no longer relevant, or based on rolling forecasts, we need to adjust targets.

3. Too many priorities: We were seeing approximately three to five objectives with three to four KRs per objective. At each level, we created new sets of metrics, dashboards, and monthly traction reports, making it difficult to get a comprehensive overview of our common priorities. It was clear we weren’t driving focus. So we’ve started limiting the number of objectives and KRs (three to four objectives, two to three KRs) to start focusing from the top. This is still a work in progress, and we’ll continue to sharpen the pencil here.

Today we represent our OKRs as a ladder framework, where companywide OKRs are the most encompassing, followed by AMPED, and then the Stream, to avoid duplication. We also reduced the set of metrics that we track. The Product stream leaders present these to me as Chief Product Officer and to our CTO, Vadim Barshtak, for review and sign-off. We have an AMPED-wide monthly traction meeting where we discuss the most important topics and try to address the challenges that we see. 

4. How large is the product organization, and how many PMs do you have?

AMPED is about 700 people, including over 50 PMs (and we’re hiring!). Geographically, the Product organization is based in Europe, and the go-to-market team is global.

5. What would you say is unique or core to your product team’s philosophy for building products?

The Product team’s motto is “Deliver customer value faster with high quality.” The most important thing is that customers see value in what we build and deliver. It’s what we want the product teams to focus on. We spent a lot of time within the Product Leadership Team to define what we mean by each word, how we use it, and how we measure it. It’s been a good journey, but, in many ways, we are still in the early stages.

For example, product quality wasn’t always meeting our bar. We needed a way to help teams build a strong sense of what is good enough. One of the product leaders came up with the “Mona Lisa principle”—simply put, everything we ship should be like a Mona Lisa painting, something we’d be proud of putting our name on. When you look at a painting, you can easily say that something is a masterpiece and something is definitely not; the same is true with the product.

It was simple and super-easy to understand and use. But it still didn’t help the team get better. So we iterated, and the Design team built the monthly design reviews. Every month, they review everything that was shipped and say what is high-quality or not. You know how a picture is worth a thousand words—similarly, real examples of high quality are a lot more powerful, and simple at the same time. 

I think that’s what makes us unique: focusing on customers, building with empathy, and iterating for better outcomes. (By the way, these are also three of Miro’s core values.)