How to choose a product partner
Milana Leidenius
Chief Product Officer at Alty
June 10, 2026
I've sat on both sides of this. I've hired partners to build products, and I've been the partner brought in to fix what a previous one left behind. The second situation is more common than anyone likes to admit, and it almost always traces back to a decision made months earlier — a partner chosen for the wrong reasons, or chosen well but assessed badly. McKinsey tracked digital banking transformations across banks globally. Only 30% said they got where they were trying to go.
Most of that is avoidable. The problems that sink a product engagement are visible before you sign, if you know where to look. Here's what I'd check.
Look for one team that owns the whole problem
The most common failure isn't weak talent. It's strategy, design, and engineering sitting in separate teams, handing work down a line. Strategy writes a deck. Design interprets the deck. Engineering builds whatever survived the interpretation. Every handoff loses something, and by the time the product ships, it bears only a passing resemblance to what was decided at the start.
So the first question I'd ask any partner is simple: who stays on this product from the first decision to the live release? If the answer is a different team at each stage, you're not buying a product. You're buying a series of translations, and you'll pay for the gaps between them.
What you want is continuity: the people who set the direction are still in the room when the hard build decisions get made. The teams that keep that continuity ship what they planned. The ones that don't spend the last month explaining why the product drifted.
McKinsey's research on banking transformations makes it measurable: when more than 70% of the people doing the build are outsourced, the project is significantly more likely to fail.
Ask for the unglamorous work, not just the screens
Anyone can show you a beautiful interface. Polished screens are the easiest thing in the world to put in a portfolio, and they tell you almost nothing about whether a partner can ship in a regulated environment.
Ask for the boring artefacts instead. How did they handle a migration without taking the system down? How did a build pass a security audit? What did they do when a backend wasn't ready and the timeline couldn't move? When we worked with a grocery delivery platform that had no mobile team and no backend APIs ready, the interesting part wasn't the app — it was agreeing the API contracts upfront so mobile and backend could be built in parallel, and embedding our specialists. Hence, the client owned the capability afterwards. None of that photographs well. All of it is what actually mattered. Read the full case study.
The unglamorous answers are the ones that separate a partner who can deliver from one who can only present.
Check they can defend decisions, not just deliver them
In fintech, every product decision eventually meets a board, a regulator, or a risk team. A partner worth keeping can explain why they made a call, not just what they built. That distinction matters more than it sounds.
When I'm on the other side of the table, I ask one thing: walk me through a decision you'd make differently now. Someone who can't name a single regret is either new to this or not being straight with me. Someone who talks honestly about a call that didn't land is someone I can hand the next one to.
You're not looking for people who are always right. You're looking for people who can reason in the open, because that's what you'll need when you're defending the work internally.
Match the proof to your situation
A case study only counts if it resembles your problem. A lot of buyers get impressed by a logo and never check whether the work behind it looks anything like what they need. The ones who don't make that mistake ask a narrower question: was this the same kind of problem as mine?
A design-only engagement doesn't prove a partner can engineer at scale. A greenfield build doesn't prove they can untangle a decade of legacy. If your situation is "we have a product that's lost momentum and we can't safely change it," then a portfolio full of clean new launches isn't reassuring. It's beside the point.
Ask specifically about work that matches where you actually are. If you're rethinking a product model under pressure, ask about a time they removed something rather than added to it. One of our sharpest engagements was for a power-bank rental service where the right move was to delete the app and the login entirely. Activation went from minutes to seconds. Read the full case study.
The proof you want is the proof shaped like your problem.
Watch for the red flags
Some signals are reliable. Promises of "end-to-end transformation" with no details underneath. Reluctance to name who'll actually do the work. Timelines offered with no ranges and no assumptions, as if delivery were a certainty rather than a forecast. A pitch that never once mentions what could go wrong.
Confidence is easy to perform. Honesty about risk is harder to fake, and it's a better predictor of how an engagement will go. The partner who tells you where the project might get difficult is usually the one who's thought about it.
The thing underneath all of this
Every question above is really the same question asked five ways: does this partner own the whole problem, or just their slice of it?
The slice-owners are easier to hire and cheaper to start with. The cost shows up later, in the gaps nobody was responsible for. I've been brought in to fix enough of those gaps to know what they cost.
I've been brought in to fix enough of those gaps to know what they cost.
These are also the questions I'd want asked of us. Our work is the answer.
Building a new product, or rethinking one that's stalled? Let's talk.
