At this stage, you’ve documented your Product Blueprint.
You’ve clarified the target audience and the problem. You’ve seen that retired business owners account for 70% of the churn. You’ve prioritized the key issues faced by this audience.
The hard part comes next.
Most product work doesn’t fail because the problem is wrong. It fails because leadership never fully aligns on the problem.
That gap shows up later as new objections to the problem or requests to move in a different direction. When that happens, weeks of design and development work get thrown away.
This erodes trust. Designers and developers lose confidence when their work gets scrapped because of late-stage misalignment.
So how do you avoid that?
By getting leadership aligned on the problems you’re trying to solve before you move on to design.
That alignment happens in the Product Blueprint review meeting.
What’s a Product Blueprint review?
It’s a meeting where leadership reviews your Product Blueprint.
All you’re trying to do is get a green light on the prioritized problems. Once you have that, you can confidently move to the design phase.
By getting a green light early, you prevent misalignment later.
But here’s the thing.
Without structure, these meetings drift.
Discussions drift into solutions before validating the problem. Leaders question assumptions you thought were settled. Engineering jumps into technical debates too early.
So you need to set expectations upfront and run a focused meeting.
Before that, let’s start with who should be in the room.
Who should be in the Product Blueprint review?
In fintech and financial services companies, I’ve seen the same team set up show up again and again. Especially in domains like wealth, payments, and lending.
Three groups need to be in the room: Business, Product, and Dependency teams.
- Business brings domain knowledge. They also fund the entire project.
- Product brings the product management lens. They lead everything from discovery to design to development. The group includes product, engineering, and design leadership.
- Dependency teams like marketing and compliance need context early. Without it, they often deprioritize projects.
Let’s break down each one.
Business leadership
This group represents the business line where the problem lives.
In a high-net-worth context, this might include the VP of Wealth or the VP of HNW Banking. Along with leaders who represent relationship managers.
These leaders understand how clients generate value for the business. They’re accountable for revenue and retention and decide whether a problem is worth solving.
Their role in the meeting is to validate whether the problem is real, significant, and aligned with business priorities.
Product leadership
This group applies a product management approach to solve the business problem in a structured way.
Their responsibility isn’t just to build products. It’s to turn business problems into clear products that drive results.
Leaders from product, design, and engineering should be represented here. Typical roles include AVP of Product, AVP of Design, and AVP of Engineering.
Engineering managers and the architect are also invited to listen in. They’re informed in advance that this isn’t a technical discussion and that the goal is to provide context. A separate session will be scheduled later to discuss technical implementation.
Dependency teams
Dependency teams vary by organization. Marketing and compliance are common examples, but the exact mix depends on how your company operates.
In our case (a B2C bank), we included marketing and compliance. In a B2B setup, you might also involve sales and customer support.
The key is to identify the teams that support product delivery.
Here’s what happens when you don’t bring them in early.
These teams often deprioritize initiatives when they don’t understand the value being created. From their perspective, multiple initiatives compete for their limited capacity. And projects that affect fewer users are easy to push aside.
This is where context changes everything.
Let’s say your bank has 10 million retail customers. A feature for 1 million high-net-worth clients may sound small in comparison but the revenue impact is significantly higher.
When dependency teams understand that context early, they prioritize your feature.
Marketing needs this context to plan promotion across digital channels and physical branches. Compliance needs it to engage early and assess regulatory risk with a clear view of business impact.
Bringing these teams in early builds shared understanding and reduces the risk of late-stage pushback or deprioritization.
Now that you know who should be in the room, let’s talk about how to structure the meeting.
How to structure the meeting
Without a clear structure, this meeting will quickly drift away from your goal and slide into long hypothetical discussions that don’t lead to decisions.
You need to keep the audience engaged and encourage interaction, while preventing the conversation from getting derailed. That starts with setting expectations upfront.
Start with objectives and rules of engagement
Share an agenda of what you will cover and set expectations of what you need from them.
Meeting Objectives
- Walk through the Product Blueprint (target audience and problem)
- Get a green light on the prioritized problems
- Answer questions from leadership
Rules of Engagement
- Respect the order of the material and avoid jumping ahead
- There will be time for questions and feedback at the end of the presentation
- Leaders should focus feedback on their areas of expertise to keep the discussion productive
- For engineering stakeholders, this meeting provides context only. A separate session will be scheduled for technical discussions
- When giving feedback, clarify whether it is a blocker, a comment, or a suggestion
I usually set expectations with engineering stakeholders before the meeting to avoid drifting into technical discussions.
This structure keeps the conversation moving, directs feedback to where it’s most useful, and still leaves room for leadership to raise important concerns.
Deep dive into the Product Blueprint
The next step is to deep dive into the Product Blueprint, get buy-in, and align on next steps.
We covered how to build this document in the previous post. In this meeting, you walk through it section by section.
The business problem
Start with the high-level context. Call out the 10% quarter-over-quarter churn and the 100,000 clients leaving.
The Target Audience
Explain who is churning, how you segmented clients and why retired business owners account for 70% of the churn.
The Customer Problem
Walk through Dave’s journey. Show how retired business owners became snowbirds, how their banking behavior changed, and how they struggled to reach their relationship managers.
This is where you should spend the most time. That’s because leadership is often far removed from customers’ day-to-day realities and your job is to bridge that gap.
The prioritized problems
Present the three key issues you identified:
- Unable to reach the relationship manager when they’re away
- No visible or empowered backup ownership
- Clients not identified as high-net-worth when calling from US numbers
Next steps after the Product Blueprint meeting
Once you’ve walked through the blueprint and answered questions, there are two possible outcomes.
If leadership is aligned and you receive a green light, you can move forward with confidence. The next steps are to wireframe solutions using low-fidelity mockups and then present those wireframes to the same group in a follow-up meeting.
If there are open questions or action items, take them away and follow up with the relevant stakeholders. Once those are resolved, you can proceed.
With a clear approval in place, the next two steps are:
- Create low-fidelity mockups
Simple wireframes that explore solutions to the problems you’ve identified. - Technical feasibility review
After the mockups are ready, set up a session with engineering managers and architects to identify technical constraints before presenting them to leadership.
The Product Blueprint review meeting is where clarity turns into alignment.
By the end of the meeting, everyone understands who the product is for, which problems matter most, and why they deserve attention now.
With a green light in place, the path forward is clear.
You can begin designing low-fidelity mockups to explore solutions and then work with engineering to understand the technical constraints involved.
In the next post, I’ll walk through how to create low-fidelity mockups that bring your solution to life.