When I took responsibility for Payoneer’s Bank Transfers team, much of the expected machinery was already there. There was a backlog, work was organized into sprints, and stakeholders were bringing requests.
It was also clear that the area wasn’t working particularly well. Use cases could continue from sprint to sprint, new demands kept arriving, priorities were difficult to hold together, and frustration had built up both inside the team and among the people depending on it.
What was much less clear was why those patterns had developed, which parts were symptoms rather than causes, and what would actually help.
Before changing the team, understand the system
I had plenty of ideas about what needed to change. What I didn’t yet have was enough context to know which of those ideas would actually help.
So for the first sprint or two, I held back from changing very much. I went through previous work and the backlog, watched how requests entered the team and moved through it, and spent time with Engineering, QA and stakeholders who had been working together long before I arrived.
That history mattered. A backlog can show what somebody asked for. It rarely tells you why a team stopped trusting a certain kind of commitment, why the same disagreement keeps returning, or why an awkward practice became normal in the first place. The people already in the system had lived through those decisions, and their perspective changed some of my assumptions about what needed attention first.
Once I understood more of the history, the need for change did not disappear. The team still needed a more reliable way to turn demand into work it could understand, commit to and complete.
The issue was not simply whether we were running sprints correctly. It was whether the team had a working system for deciding what it would take on, preparing it well enough to start, and aligning the people who depended on the result.
For a period I ended up filling part of the agile-coaching gap alongside the product role. We went back to fairly basic practices: shaping work before it entered a sprint, breaking large requests into pieces the team could actually finish, making priorities clearer, and aligning Product, Engineering and stakeholders before development was already underway.
None of those practices was especially sophisticated. The harder judgment was deciding when the team was ready for each of them.
The destination could be clear before the path was
I could see where I wanted the team to get to, but that did not make every part of the target state the right next step.
Some practices only became useful after more basic habits were stable. Sometimes I needed to push; sometimes I needed to explain the destination more clearly; and sometimes a sensible change had to wait because another capability needed to develop first. A change that made perfect sense on paper could still create more friction if the surrounding system was not ready to support it.
Resistance was useful information too. A habit that looked inefficient to me might be protecting something another person valued, or solving for a history I had not lived through. Understanding that did not mean keeping the habit. It meant dealing with the reason behind the resistance rather than treating resistance itself as the problem.
Over time, I found myself asking a different question. Instead of only asking what the team should be doing differently, I was asking what the team needed to become capable of next.
The destination could be clear long before the path was.
Knowing when someone else can take it further
For quite a while I continued filling the coaching gap because the gap was real and someone needed to fill it. I learned a great deal by doing that, but I also became clearer about where my own expertise ended.
By the time we were able to bring in a dedicated agile coach, the team was ready for deeper specialist support. Continuing to occupy that role myself would not necessarily have helped the team progress further.
Handing that work over felt like the right next stage. I had been useful in the gap; someone with deeper expertise could now take that capability further.
The same problem appeared at a larger scale
About a year later, I encountered a related problem at a larger scale.
Payoneer’s Product organization was growing quickly. More product managers were joining, and some newcomers were struggling to establish themselves. It was easy to describe this broadly as an onboarding problem.
Once we looked more closely, that label started to break down.
Some of the people entering Product were successful Payoneer professionals moving internally. They already understood the company, its domain and many of its stakeholders, but product management itself was relatively new to them. They needed more support building product craft and experience.
Experienced PMs arriving from outside often had almost the inverse problem. They already knew how to manage products, but they did not yet understand Payoneer: its architecture, organization, stakeholder landscape and the informal operating practices that made it possible to get things done.
They could hold essentially the same role and need help with almost opposite things.
Once we separated those patterns, a single onboarding curriculum stopped making much sense.
That became the starting point for a Product mentorship initiative I proposed and then developed with colleagues in Product. We began separating two dimensions that had been easy to blur together: learning the organization and domain, and developing as a product professional.
We mapped those needs across different stages of the PM journey, from onboarding and taking responsibility for a team or domain through roadmap work, discovery and solution design.
Different gaps needed different kinds of support
Identifying what somebody needed to learn was only part of the design. We also had to decide what kind of support fit the need.
Some development needs were individual and benefited from sustained one-to-one mentoring. Some were shared by several PMs, where a small group could learn from both an experienced PM and one another. Others were narrow and situational enough that an ongoing mentoring relationship would have been unnecessary; a focused clinic or short session with the right expert made more sense.
The proposed model also kept mentoring separate from direct management. Mentors were not intended to sit in the mentee’s reporting hierarchy or grade their performance. The relationship was meant to support development rather than create another evaluation channel.
We also treated mentoring itself as a capability worth developing among senior PMs, rather than assuming that experience automatically made someone a good mentor.
We surveyed people across Product rather than assuming we already knew where the gaps were. The responses did not point to one universal weakness. Different needs appeared around roadmap planning, stakeholder cooperation, discovery, architecture, product methodology and other parts of the PM journey.
That made the design problem more concrete. Some gaps called for sustained individual support. Some could benefit from peers. Others were better suited to focused teaching or access to an expert.
Over the following months, parts of the approach were actively put into practice. We ran a series of lectures and clinic sessions while continuing to develop the broader mentorship approach.
Payoneer later introduced a company-wide mentorship initiative, which changed how much of the Product-specific work continued. The exact model did not carry forward as originally conceived, but the diagnosis behind it stayed useful: people entering the same role could have very different capability gaps, and the right support depended on understanding those differences.
The same diagnosis could lead to very different decisions
The Bank Transfers team and the mentorship initiative were very different situations, but both began with labels that were too broad to guide action very well.
“Poor process” concealed history, habits, expectations and readiness.
“New PM onboarding” concealed different starting points and different capability gaps.
Understanding those differences was necessary, but it was not sufficient. The leadership decisions came afterward: what to change first, what not to force yet, where coaching would help, where a repeatable mechanism was more useful, and when someone else was better placed to take the next stage further.
I still think listening matters. What changed for me was what I expected listening to produce.
The aim was not simply a better diagnosis. It was stronger capability: a team that could operate more effectively, people receiving the kind of support they actually needed, and fewer situations where progress depended on me remaining the person in the middle.