Moving from a product domain to a platform role sounds like a straightforward expansion. More surface area, similar job. That's roughly how I thought about it before I made the switch in March.

It turned out to be a different kind of work entirely.

I used to work with product teams in Savings and Investments (S&I) domain at SEB, designing solutions in both web and mobile apps. I was specializing in that domain, getting to know the customers, their behaviors and pain points specifically for this area. And now, my focus shifted from this domain to the mobile app, but in its entirety.

The scope did double, in the sense that I'm now responsible for the full mobile banking app experience across the Baltics rather than a single product area. I am there to design mobile specific solutions and align the products designed in the app for better customer experience. But the bigger change wasn't the surface area. It was what the role actually requires from me organizationally.

When you're embedded in a product team, the question is rarely who owns what. You're there, the work is there, and you move together. Platform is different. The channel is yours, but teams around you don't always experience it that way. They see a designer who works with the mobile app, they have a need, and they reach for whoever is available. That's not bad intent. It's just how organizations work when roles aren't fully defined yet.

So I've been saying no more often than I expected to or wanted to.

Not to work in general. To work that belongs someone else. Specifically, teams trying to pull me into product-level tasks that should wait for their domain specialist designer rather than get a quick fix from whoever is closest. Saying yes would feel helpful in the short term. It would also mean failing the platform, because my attention is on overall experience we deliver and the channel suffers when I'm working across product-specific requests.

What I didn't anticipate is what the no actually does. Last quarter I spent several meetings with a team explaining my position and pushing back on taking on their project. It wasn't a comfortable process. But it brought in the domain specialist, triggered resourcing conversations, and eventually landed at CPO level, setting priorities and clarifying how work should flow. And who owns what. One refusal surfaced questions the organization hadn't fully answered yet.

That's the pattern I keep seeing. Every time I hold the boundary, something underneath it becomes visible. A missing way of working. A conflicting priority. Misalignments. A gap in how design is understood and allocated. The no isn't a resolution. It's a diagnostic.

I'm still in the middle of this. The transition isn't done, the boundaries aren't fully established, and the organizational questions keeps surfacing aren't all answered. What I'm learning is that owning a platform means owning that discomfort too. It's part of the job, not a sign that something has gone wrong.

All this being said, I have probably made some people unhappy along the way. I will have to face that during my performance review. Saying no slows things down in the short term but it opens up the right conversations, and those conversations are what actually move things forward.

Photo by Frantisek Duris on Unsplash