You now understand how a mobile app screen gets built.
But before you present that wireframe to leadership, there’s one question you must answer:
Can it actually be built?
Here’s what happens if you skip this step.
You present the wireframe. Leadership loves it. They approve it. You get the green light.
Then you take it to engineering.
And that’s when you discover call routing will take a year to build.
Or the data you need doesn’t exist.
Or three teams have conflicting dependencies.
Now you’re explaining to leadership why something that was approved suddenly can’t launch on time.
This is why you validate the wireframe with technology stakeholders first.
The goal of this call is simple: identify constraints and dependencies.
Let’s look at how to run this meeting.
Who should be on this call?
It’s the same group of technology stakeholders who attended the Product Blueprint Review meeting.
So, you’ll have managers from:
- Mobile app engineering (iOS and Android)
- Software architecture
- Database engineering
- Data engineering
- Backend engineering (microservices)
- The call center technical team (IVR), since call routing is involved
If anyone wasn’t at the previous meeting, give them enough context separately on a one-on-one call so they’re aligned before attending this session.
You might wonder why managers are involved, and not your core team that will actually build it.
Because your job as a product manager is to protect your core team’s time and help them work more efficiently.
Individual contributors should be building. Managers can represent their teams, surface constraints early, and prevent rework later.
You’ll work closely with your core developers, engineers, and designers after this validation step. We’ll talk more about team structure in an upcoming post.
How to structure the call
Start by setting expectations.
Tell everyone exactly what you’re trying to accomplish:
“We’re going to walk through the low-fi wireframe and identify constraints and dependencies. That’s the goal of this call.”
Simple. Clear.
Now you’re ready to walk through the wireframe.
Let the designer lead the walkthrough
Don’t walk through the wireframe yourself. Ask your designer to do it.
Why?
Because they’re closer to the design. They understand the interactions. They can explain why elements are placed where they are.
In our case, the designer also walks through both call-routing options.
1) Option A: RM call forwarding (best experience)
Calls go directly to the RM when they’re available. When they’re not, calls are routed to an internal support queue. From the client’s point of view, nothing really changes. It’s still one number. One simple flow.
2) Option B: Call-to-message fallback (simpler)
If the RM doesn’t answer, voicemail directs the client to email the RM through the app. That email is automatically copied to an internal support team that can respond if needed.
You step in only when context is missing.
For example, if they forget to mention that this feature is only for the one million high-net-worth clients (not all ten million banking customers), you clarify that.
Once the walkthrough is complete, open the floor for questions.
Questions fall into two buckets: design questions and business questions.
Design questions sound like this:
“What happens when the user clicks the call button? Where does it take them?”
The designer answers:
“It opens the phone’s native dialer. Same for email. It opens the default email app, and the backup team is automatically copied.”
Business questions sound like this:
“What happens if a relationship manager’s photo isn’t in the database?”
You answer:
“In an ideal world, every RM has a photo. But if one doesn’t exist, we show a default icon instead.” The designer can show that fallback icon.
Answer the questions. Then move forward.
Identifying constraints
You’ve explained the wireframe. You’ve answered questions.
Now it’s time to hear from engineering.
You ask:
“What constraints do we have? What would prevent us from building this?”
And then you listen.
Here’s what might happen.
The mobile app engineering manager asks:
“Do we have a way to identify high-net-worth clients?”
The architect responds:
“We have a ‘net_worth’ flag in the client database to identify these clients in the database. We’re not sending it to the mobile app today, but that’s not a big effort. We can expose it.”
Mobile team says:
“That works.”
Good. No constraint there.
Then the call routing team speaks up:
“Option A isn’t possible right now. It would take us about a year to build that capability. We can add it to the roadmap, but it’s long-term.”
You ask:
“What about Option B?”
They respond:
“Option B is possible. Private banker calls already go through our system. We just update the voicemail message. That’s a configuration change.”
There’s your constraint.
Option A = long-term investment.
Option B = feasible now.
Once you’ve identified constraints, move to dependencies.
Ask each team:
“What do you need from other teams before you can start building?”
Yes, everyone depends on the architecture diagram. That’s assumed.
But what else?
- Backend engineers and mobile app developers depend on the API contract. Without it, development can’t begin.
- Mobile app developers might depend on IVR routing codes.
- Backend engineers might depend on data engineers exposing specific fields.
Ask each team to call out their dependencies explicitly. This way, there are no surprises later in the development process.
Once constraints and dependencies are clear, explain the next step.
Tell your stakeholders:
“We’ll now schedule a meeting with leadership to get approval on the low-fi wireframe. I’ll be adding all of you to that call.”
In our case, we identified a blocker. Option A would take a year.
So we present both options:
- Option A: Best experience, long timeline, high investment
- Option B: Feasible, faster, lower effort
Leadership decides which direction to take.
In the next post, we’ll walk through how to run that leadership meeting.