From Product Owner to Product Manager - what I learned crossing over
On frameworks, empowerment, and finally doing real product work
Where it all started
I started my product career at Swedbank as a business analyst in a team working with a few popular internet banking products across the Baltics. I was motivated - in the way only someone early in their career can be -convinced I was about to build things that would genuinely matter to people.
The excitement dissolves fast. In regulated business you’ll surely find yourself juggling among a range of wild requirements: starting from impossible deadlines from regulatory authorities, to some top-down decisions - which engineering teams do not quite buy in.
You are a smashing success if you manage to scope down the massive deliverables to reasonable requirements, and manage the skyhigh expectations of stakeholders across multiple business domains and layers of hierarchy. But, then!
You’ll most likely be hit with a few waves of framework updates (think of one battle after another), followed by consequential small reorg which brings some degree of disruption, resistance and anxiety within the teams. When it comes to people - a cultural change - you’ll obviously have an expensive consultant brought in to implement something complex that's supposed to magically fix everything. Disruption, resistance, anxiety. Repeat.
None of this is unique to Swedbank. It's simply what large organisations do.
I gained valuable experience as a Product Owner there. It's a fail-safe environment to start a product career - structured, guided, and low-risk by design. Extensive processes absorb mistakes before they happen. Maintaining a beloved brand for millions naturally makes the status quo the priority.
The cost of safety
Stability comes with a price. Risk appetite is low, and changes pass through layer after layer of approvals before they ever land with the product owner and engineers — who are handed only the execution. Discovery, the problem space, real customer insight — none of it exists in that setup. Decision-makers can become surprisingly disconnected from what’s actually happening on the ground.
At some point, I’d read enough Marty Cagan to know: sooner or later, I’d move somewhere the work I cared about was actually possible.
The other side
Looking back, having worked as a Product Manager at a fintech company for almost 2 years, it amazes me that I learned so much more about the real world!
Now I don’t have a polished framework or a process workflow that makes decisions for me, but I do have to make bets under uncertainty. I have the privilege of talking to customers about their problems, watching them be remarkably polite and friendly even while describing how much they struggled with a feature we haven't gotten around to fixing yet. Uncomfortable - but deeply insightful.
Product discovery and navigating the problem/opportunity space is the most valuable thing a PM can do. If we know what the biggest problems are, we already have half the solution. We can cut through the noisy backlog and identify the 20% of ideas that actually move the needle. That's the mission.
Product teams, together with customer support, are best positioned to understand customer problems in the most nuanced and intimate way. Customer interviews build real context. We have a good understanding where the customers struggle most, what moves the needle for many customers and therefore for our business. Knowing problems takes you to experimentation. We might know what the problems are, We won't build anything until we've validated the problem and experimented on possible solutions.
Why fintechs win
Most of what I've described is simply unthinkable at a traditional bank. Decisions about what to build or fix rarely sit with the people closest to the product. Empowered teams, experimentation, real discovery work - these are hard to achieve inside structures designed to protect stability above all else.
That's why fintechs and neobanks will continue to disrupt traditional banking - and with AI-assisted development accelerating the pace of shipping, that gap will only widen. But the disruption won't come from technology alone. It'll come from organizational philosophy. The engine of that disruption is empowered teams - people with real ownership, real responsibility, and genuine closeness to the customer. Not process-driven feature factories.
The verdict
Here's what that looks like in practice. A product engineer noticed something that wasn't right for customers. They raised it at the team's retrospective. The team made a decision the same day. By the next afternoon, the fix was live. Zero approvals.
In a bank, the risk of moving that fast feels enormous. In an empowered team of domain experts, the upside is bigger.
Fair warning - I leaned into the drama deliberately. I want my writing to entertain as much as it informs, and I hope you had as much fun reading this as I had writing it.
So, for anyone who’s comparing the two - both are valuable stages of a product journey. A Product Owner role is a solid starting point - but it's a ceiling for anyone ready to do real product work and get close to actual customer problems. For that, you need a seat at the table where the real decisions happen.
