Miro's Product Alignment Approach
An intro to how we do product at Miro
When I first joined Miro, less than a year ago, we had 3 million users and around 300 employees. A lot has changed since then. We have since grown Miro to around 12 million users and 600 employees, making Miro one of the fastest-growing B2B startups in history.
With such hyper-growth, there’s been an ever-growing need to scale the way we do product. In this article, I’m going through the approach that I introduced at Miro a while ago and is currently at the heart of how we center ourselves around the product strategy.
The goal of the product alignment approach is to guide structural opportunity discovery, solution discovery, ensure product collaboration and knowledge sharing in the product org as the company rapidly grows. This approach can be used at companies of all sizes. In fact, the earlier a company adopts this approach, the easier it will be to overcome product collaboration and alignment issues arising from the company’s growth.
Product Alignment Approach:
The Product Alignment approach consists of a single document called PAD (short for Product Alignment Document) as well as ceremonies that go along with this document as it evolves and goes through different stages.
Product Alignment Document (PAD):
Product Alignment Document (PAD for short) is the artifact where we document the result of the product discovery and impact. PAD consists of 3 main pillars listed below. Each part is associated with the stages that the document goes through.
Opportunity/Problem Framing: Every product development starts with finding a new opportunity to capture, or an existing problem to solve. In this stage, the team explores the opportunity/problem, listing the what, the why (the importance of the opportunity/problem), the target audience, success metrics and competitive landscape. Within this stage, the team also explores a few potential high-level directions for solving the problem. It’s very important to avoid selecting a specific solution at this stage and stay open-minded to a variety of solutions. The key here is to stay high-level and avoid getting into the solution design and implementation details.
Solution Framing: During solution framing, the team decides which direction to pursue. In this stage, the team works on the solution discovery, designers design the key flows, engineers craft engineering design docs, go-to-market teams prepare the go-to-market plan and the product manager facilitates the collaboration among the team and guides them toward the right direction. It’s also important to list any potential risks or dependencies involved in launching the proposed solution.
Post-launch Recap: Once the solution is implemented and launched, the team assesses whether they achieved success and reflect on any learnings that they can take to improve further.
PAD templates are added at the end of this blog post.
Product Alignment Meeting:
PAD content is not something new. All great product teams perform detailed product discovery in one way or another. What is equally important to crafting a PAD is to have a relevant audience who reviews your PAD to challenge you and provide feedback.
At Miro, we hold weekly product alignment meetings where teams present their problem framing, solution framing or post-launch recap stages of PADs to be challenged, receive feedback, exchange knowledge and ensure buy-in from the leadership team.
Depending on the size of your company, you can either go as wide as inviting the whole product guild and even the leadership team or as narrow as inviting the product people in your product stream. If it’s well-organized, you can easily have up to 20+ people in this meeting and still stay productive.
Product alignment meetings have multiple advantages:
Teams do not waste time on detailed solution discovery for problems or opportunities that are not considered strategic by the leadership. They validate the opportunity against both the user need and the business need before investing heavily in it.
Teams get feedback on the problem/opportunity they are aiming to solve and the approach they are taking in tackling them. This feedback is coming from leadership and product peers which are working on other areas of product and have an outside/new perspective than those on the team.
Everyone stays informed and up to date on the most important product decisions and the why behind them.
Teams feel more accountable for doing proper problem/opportunity/solution discoveries before jumping into solving the most attractive problem with the most obvious solution.
Teams improve their presentation and storytelling skills.
The whole product org strengthens their product management muscles as they get exposed to the many product challenges other teams are facing and the approaches they are taking in solving them.
How we run Product Alignment Meetings at Miro:
This meeting takes place weekly at Miro and each team who has something to present will add their topic to the agenda and specify whether they need a problem framing or solution framing review. Each team summarizes their PAD in a couple of slides (in Miro) to present and each presentation normally takes less than 30 minutes including Q&A.
Every product alignment meeting at Miro includes 10+ PMs, product leadership team and the CEO — Yes, our CEO attends every single product alignment session and this is the best thing I’ve seen the CEO do, as it helps him to stay on top of where the product is moving. The required and optional attendees are specified in the calendar invite.
There are four classes of possible outcomes coming from the leadership / relevant sponsors for each team who present:
Looks great, please proceed
Approved, please account for recommended course corrections
Directionally OK, but please follow up offline before proceeding
Not approved, additional work required
At the end of every quarter, we have a big post-launch recap session where teams share the outcome on whether they achieved success for the PADs that were launched in this quarter. They also share any learnings which might be insightful for the whole product guild.
OWNER: TEAM: STATUS:
What problem are we trying to solve? What is the opportunity that we’re addressing?
For whom are we solving this problem?
How do we know this is the right problem to solve? Why this opportunity and not others?
Does this relate to current OKRs and if yes which one? Or is this a proposal for a future OKRs (based on business strategy)?
Is this leading to a competitive neutralizer, differentiator or delighter?
Any links to customer research, conversations or observation from data.
How do we know if we solved this problem?
Competitive Research: (if competitive neutralizer)
How did others capture this opportunity / solve this problem?
Potential Solution Directions:
What are some high-level solution directions we explore for capturing this opportunity / solving this problem? Describe potential solutions through short descriptions or high-level sketches / low-fi prototypes (no implementation details at this stage). Compare the high-level solution directions through impact vs complexity (e.g. using high-level t-shirt sizing estimation).
What is the scope of the proposed solution?
What are the key features? Provide job stories, main flows or mock-ups.
How complex is it to realize the solution?
Rejected Solutions and Why:
Provide some context on why this solution was picked and the rest of the proposed high-level solution directions were not pursued. Any links to user research, customer data, etc.
Out of Scope:
What is not in the scope of the proposed solution?
Dependencies, Risks and Mitigations:
What are the dependencies?
What are the risks associated with the solution (e.g. compliance, legal, privacy, security, strategic risk, operational, infrastructure stability/scaling risk, etc.) and potential mitigations?
What is the release plan? List the key milestones e.g. dev complete, alpha, beta, general accessibility.
What are the marketing and operational supports needed for this launch?
What’s the pricing and packaging strategy?
How successful we were in achieving our goals according to success metrics and the actual results?
What are the learnings that we can take to improve further?
You can copy the ready-to-use templates below:
Full guide and template on Coda
Thanks to Thor Mitchell, Olga Stepanova and Andrey Khusid for providing their input on the approach, Boris Kirov, Thor Mitchell and Adrian McPhee for reviewing drafts of this, Kristin Leitch for improving the Miro template and all Mironeers for adopting and evolving the approach.
If you’re finding this helpful, feel free to share it with peers, or subscribe to get these stories to your inbox for free.
I really like the weekly frequency PAM. It allows teams to tackle emergent problems or address feedback without waiting for the next quarter.
Also, the Post-Launch Recap serves as a really nice accountability mechanism. It's very easy to identify success metrics and not follow through on them, or to de-prioritize data gathering to evaluate those success metrics in favor of a few more features.
Q: With such rapid scaling of the company (and of your Product organization), what pain points have begun to show up?
Great post Farbod. Would love to know how are you guys structured with the PM org, and how it overlaps/ aligns with growth functions, if any. May be ideas for future posts. 😊