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?
Thanks Eric. Our company has tripled in size since introducing this framework but so far, there hasn't been any issues in regards to the scalability of the framework which has been quite surprising to me as well. I think that's partially because our product teams already built a good intuition on what PADs worth bringing to the PAM and what is considered as a 'trivial' PAD to be reviewed within the product stream without coming to the main PAM. For larger scale organization, I think PAM should be organised within each product steam/vertical instead of having one for the whole product org.
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. 😊
Yes, if I were a Product Manager at Miro would I plan on bringing a PAD to a Product Alignment Meeting every 6 weeks? Quarterly? Semi-annually? Trying to get an idea of the size and complexity of a typical effort captured in a PAD and discussed at the alignment meeting.
There's no specific cadence. Teams present the outcome of their problem/opportunity discovery or solution discovery of their PAD whenever each stage is done and that differs per team and per scope of the PAD they are working on. In other words, teams only present when they have something to present. The goal here is not to create a specific cadence but rather create a panel where teams can bring their PADs to get feedback from peers and get approvals from leadership/sponsors.
I have a question on estimates in the solution framing. My guess is: in order to get the buy-in from the leadership and validate the investment to be made, the engineering team must come up with some sort of plan or rough estimate to produce the final solution, is that the case ? how does that play out in this document ? do team produce some sort of GANTT chart of the epics to be completed ?
I have a second question regarding broader product initiatives for larger, transversal projects. Imagine a team identified a project that will need the involvement of multiple other teams. I think they are represented in the PAD as dependencies. Should other teams need to do a PAD on their own if that's the case ?
Very interesting approach to Product Discovery and alignment across multiple stakeholders.
I have a few questions about some of the details of this process.
How long does a product team spend working on this phase of the discovery? Is the process the same regardless of the size of an initiative? How are lessons learnt shared/documented for initiatives not built? Is there any formal process prior to the Product Alignment starts? How do teams decide what to focus on next?
Are product teams accountable for the success/failure of their features, or leadership? Does this PAD meeting ritual incentivize focus on pleasing leadership or pleasing customers?
The team is ultimately accountable for the success and failure. The team is relying on their own strategy and research in picking a problem / opportunity and to find a solution to capture the opportunity or solve the problem and it's all extremely user-centric. The leadership is only there in the meeting to hear the story / pitch to provide helpful feedback and give the final go and nothing more.
Here are a few things I was wondering about while reading:
- Do you use this framework for all product work, or only for big projects?
- how do you keep alignment on iterations of a certain feature? Whether it's at the planning stage, the execution, launch, or post-launch: I'm sure things often change from what was presented at the PAM.
- are PADs only used for PM alignment or do you also share them with stakeholders within the company?
Thanks again for sharing your experience and thoughts :)
Great questions Yaara. At Miro we use the 6 week rule to identify what must go into the Product Alignment Meeting for the review. However, many teams are crafting PAD for smaller opportunities and problems as well, the only difference is:
- The PAD sections for smaller opportunities are quite lightweight + you don't need to fill in all sections (only the ones you need / relevant)
- You don't need to bring them to PAM for review
Actually earlier today I was writing a PAD for something which takes less than a week in terms of scope, but this helps myself and my team to orient ourselves around the opportunity better and it only took me and my team less than 40 minutes to craft it. The template is just there to structure your thoughts better.
The other two questions are going to be long to elaborate here so I'm going to write a separate blog for them but short answers:
- For minor changes, there's no need to bring back to PAM. For medium-size changes, PMs drop the changes on the PAM Slack channels and we align async. If things drastically changes, then it might worth to bring the PAD to PAM again.
- There are more stakeholders that benefit from PAD and we are currently expanding it for UI/UX design reviews, engineer design reviews, GTM alignments, and more.
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?
Thanks Eric. Our company has tripled in size since introducing this framework but so far, there hasn't been any issues in regards to the scalability of the framework which has been quite surprising to me as well. I think that's partially because our product teams already built a good intuition on what PADs worth bringing to the PAM and what is considered as a 'trivial' PAD to be reviewed within the product stream without coming to the main PAM. For larger scale organization, I think PAM should be organised within each product steam/vertical instead of having one for the whole product org.
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. 😊
Thanks Nits. Yes, I'm planning to elaborate on our product org in the upcoming posts.
Great post Farbod. What's a typical cadence/timebox for a team? 6 weeks? Quarterly?
Thanks Keith. May I ask which cadence are your referring to?
Yes, if I were a Product Manager at Miro would I plan on bringing a PAD to a Product Alignment Meeting every 6 weeks? Quarterly? Semi-annually? Trying to get an idea of the size and complexity of a typical effort captured in a PAD and discussed at the alignment meeting.
There's no specific cadence. Teams present the outcome of their problem/opportunity discovery or solution discovery of their PAD whenever each stage is done and that differs per team and per scope of the PAD they are working on. In other words, teams only present when they have something to present. The goal here is not to create a specific cadence but rather create a panel where teams can bring their PADs to get feedback from peers and get approvals from leadership/sponsors.
Hello!
Thanks so much for your insightful article.
I have a question on estimates in the solution framing. My guess is: in order to get the buy-in from the leadership and validate the investment to be made, the engineering team must come up with some sort of plan or rough estimate to produce the final solution, is that the case ? how does that play out in this document ? do team produce some sort of GANTT chart of the epics to be completed ?
I have a second question regarding broader product initiatives for larger, transversal projects. Imagine a team identified a project that will need the involvement of multiple other teams. I think they are represented in the PAD as dependencies. Should other teams need to do a PAD on their own if that's the case ?
Again, thank you for the article!
Very interesting approach to Product Discovery and alignment across multiple stakeholders.
I have a few questions about some of the details of this process.
How long does a product team spend working on this phase of the discovery? Is the process the same regardless of the size of an initiative? How are lessons learnt shared/documented for initiatives not built? Is there any formal process prior to the Product Alignment starts? How do teams decide what to focus on next?
Great article! Thanks for sharing.
Are product teams accountable for the success/failure of their features, or leadership? Does this PAD meeting ritual incentivize focus on pleasing leadership or pleasing customers?
The team is ultimately accountable for the success and failure. The team is relying on their own strategy and research in picking a problem / opportunity and to find a solution to capture the opportunity or solve the problem and it's all extremely user-centric. The leadership is only there in the meeting to hear the story / pitch to provide helpful feedback and give the final go and nothing more.
Great post, thanks for sharing!
Here are a few things I was wondering about while reading:
- Do you use this framework for all product work, or only for big projects?
- how do you keep alignment on iterations of a certain feature? Whether it's at the planning stage, the execution, launch, or post-launch: I'm sure things often change from what was presented at the PAM.
- are PADs only used for PM alignment or do you also share them with stakeholders within the company?
Thanks again for sharing your experience and thoughts :)
Great questions Yaara. At Miro we use the 6 week rule to identify what must go into the Product Alignment Meeting for the review. However, many teams are crafting PAD for smaller opportunities and problems as well, the only difference is:
- The PAD sections for smaller opportunities are quite lightweight + you don't need to fill in all sections (only the ones you need / relevant)
- You don't need to bring them to PAM for review
Actually earlier today I was writing a PAD for something which takes less than a week in terms of scope, but this helps myself and my team to orient ourselves around the opportunity better and it only took me and my team less than 40 minutes to craft it. The template is just there to structure your thoughts better.
The other two questions are going to be long to elaborate here so I'm going to write a separate blog for them but short answers:
- For minor changes, there's no need to bring back to PAM. For medium-size changes, PMs drop the changes on the PAM Slack channels and we align async. If things drastically changes, then it might worth to bring the PAD to PAM again.
- There are more stakeholders that benefit from PAD and we are currently expanding it for UI/UX design reviews, engineer design reviews, GTM alignments, and more.