The product manager’s true test begins when the storm hits and nobody’s steering the boat. That’s exactly where I found myself when I first took responsibility for the agent system of an ambitious Asian sportsbook project. What appeared from the outside as “Just another new market venture. We are almost there!” was, on the inside, an intricate web of teams separated by borders, cultural and professional discrepancies between the teams, incomplete requirements, and a stakeholders’ vision fogged by a lack of clarity, accountability, and visibility of the current state and the scope of work that has been left.
In this real-life story, you can read about the specific scenario and approach taken by a product manager: building a bridge between different roles, revising the workflow, rebasing a project, measuring velocity, and deciding whether the critical project for building a complex distributed solution should continue, or maybe not.
Table of Contents
The Challenge: A Project Without a Compass
Before I delve into the story in more detail, I needed to grasp the heartbeat of this project. The investors had recognized the massive potential of the Asia-focused Agent System, which was intended to emulate (or surpass) industry giants like IBC, SBO, Pinnacle, ISN, and Sing. My mandate was deceptively simple: identify the current state of the product development, for which the project was run for a while, learn what made these Asian agent systems tick, study the competition and their systems, understand contractors and clients, and take charge – every step from requirements to completion of the next generation of sportsbook agent management system.
Very quickly, I realized this wasn’t about adding features or ticking checklists. The project was fragmented. The development resources stretched across two counties, but there was almost no meaningful communication between the teams. No common goals. No shared language for progress. People were busy, sure, but nobody could answer the simplest question: “Where we stand, and how much work remains before we launch?” After I understood the primary business goals to be achieved, I started absorbing information around me, assessing the current state, as well as the way all involved parties work. I concluded that approximately $2 million had already been spent by the distributed team, who had worked for a year and a half, and with a story from the loudest speaker in the room (the hired software development service provider – Team 1), that the final delivery is around the corner.
My Approach: Diagnosing Before Prescribing
Some product managers are tempted to jump straight to solutions – draft a spruced-up roadmap, schedule some stand-up meetings, and fire up their favorite project-tracking tools. I knew better. This was deeper than process convenience; it was about cultural and structural resurrection.
So, I spent my first weeks as a detective. I was looking for answers to various vital questions. I was investigating the state of the crucial mechanisms for product development, which had been in place for over a year and a half. Some of the questions I needed answers to were:
- Which are the critical features for the system, and what’s the current state of their design and implementation?
- Is everybody aligned on what needs to be done and what needs to be achieved?
- How does the distributed team communicate (sync and async communication)?
- How are the responsible people tracking the project execution?
Learning About the Business Domain
I learned the concept behind the Asian Agent System for the sports betting industry, which is quite different than the one in Europe, for which I already had domain knowledge. Why certain users preferred one supplier’s approach over another, why East needs a concept called Agent System, why Europe doesn’t need it, and how each competitor (IBC, SBO, Pinnacle, ISN, Sing) solved problems we hadn’t yet considered. It was an intensive two-week period for me, and I was learning while assessing the various aspects of the current project.
Assessing the Scope of Work and What has Been Done Until that Moment
It was clear that the project’s requirements documentation was incomplete and very vague. The development team, which had to build the Agent Management System, relied on screenshots from the competitor’s system UI without creating a thorough decomposition of the system’s behavior behind the presentation layer (i.e., the user interface) and understanding all necessary details of the engine behind the web forms and colorful look and feel. Things were even more complicated because the idea was to learn from the systems of a few major players in the field and improve the critical features to outperform the top competitors. So, no pure reverse-engineering of one system, but assessing the core features from other competitors, learn, designing, and implementing new ones.
The heterogeneous team didn’t have a product manager previously, nor a business analyst with knowledge of an Asian sportsbook agent management system. The formally announced business analyst in Team 1 was the lead hostess at every iGaming fair the company behind Team 1 attended as an exhibitor. Not good!
Who is Doing What, How the Team Communicates, and Tracking the Execution
My client created a company behind this massive project with huge plans to build a successful multi-million-dollar business in the East. After speaking with the company’s CEO, the owner of the project to build the product, and participating in several bi-weekly status calls with the outsourced team, it became clear that the execution-tracking mechanism requires significant improvements.
The symptoms that manifested weaknesses were the following:
- The CEO was acting like a bad cop, trying to scare the outsourced team (Team 1), using this approach as the only mechanism to make things right.
- On the other hand, the CEO of the outsourced team was acting like a salesman, even though his company already had an active contract for a year and a half, with a monthly lump sum of tens of thousands of dollars, meaning the sales phase had ended a long time ago.
- The young, beautiful lady, who had worn a hat as a business analyst (requirements specialist), and the software architect were silent like fish, reflecting the internal organization of Team 1, which didn’t promise much.
- And the poor tester (independent freelancer) was left to create something between requirements and test cases that had to be Mizar for the development team.
I was learning about the team members, especially Team 1, by sniffing LinkedIn profiles and talking to all involved parties to collect relevant information and build my understanding of the situation, the people involved, their formal positions in the context, and their actual activities in the field.
Brief Conclusion After the Assessment Phase
It took me a few weeks, while I was learning and assessing, to clarify to myself that:
- The managment (a company that runs business in the iGambling industry with an in-house development team – Team 2) was getting frustrated, didn’t have visibility and control over the entire project, while…
- The contracted software development service provider (Team 1) focused more on sales than engineering – especially requirements engineering, lacking the capacity and relevant professionals to deliver more efficiently, for which they were paid a substantial monthly fee, and…
- The investor who hired me had a sense that things were not going well and felt he was getting lost. Looking at his spreadsheet of expenses and timelines for the past year and a half, and comparing them to the actual deliverables, didn’t look very optimistic to him.
Creating a Bridge: Combining Strategy and Process
Another weak point was communication between the in-house development team (Team 2) and the contracted company (Team 1). It was necessary to bridge the gap between the two teams, which required both strategic vision and precise identification of dependency points, as well as tweaks to the working processes. I need some time to create and introduce a requirements document and connection points for both teams to work on separate scopes.
I had to build trust in the investor that assessing the functional scope is very important. I succeeded by dedicating myself to learning about the Asian Sportsbook Agent Management System, delivering incremental results, maintaining complete transparency about what I do and why, being available to the investor whenever they need me, and creating written materials of my work so they can verify it whenever they need to. I put in extra effort in this segment because it was really key to the success of my work, which, at the end of the day, benefits the project and the investor.
The written materials were created in Atlassian Confluence, making them easily accessible and editable for all involved parties. The document itself was not enough, so I worked closely with both teams (Team 1 and Team 2) to get on the same page about what the connection points are, to decompose and clarify all the details, and reevaluate development pipeline priorities, which protected Team 2 from having empty work cycles because they needed Team 1’s deliverables.
I set up Jira and Confluence, not just to check boxes, but to give everyone visibility and accountability. I value transparency and partnering with my peers and team members. Now, the work that was being done by Team 2 was visible to the responsible persons from Team 1, the top management, and, of course, me. I created clear work breakdown structures comparing the local staging environment from which Team 1 was deployed, the competitor’s role model, and the specification I created with improved and even new features that the competitor’s role model didn’t have, and started tracking progress in measurable ways. We agreed with Team 1 to use 2-week sprints and story points for the user stories in Jira, and I started measuring velocity for the next 4-5 sprints. For the first time, my client felt he had visibility into the project and began to understand what was happening and what the process would be over the following weeks.
The Turning Point: When Clarity Drives Results
With rigorous tracking and open communication, the mood in both teams shifted. Engineers no longer worked in silos. Especially Team 2 had excellent visibility into what remained. The integral QA team of Team 2 could finally develop meaningful test cases and plans because requirements were clear, and defects were tracked in Jira, linked to user stories, which was confirmed once more as an outstanding collaboration tool between testers and developers, in the process of defect management. Stakeholders could see progress clearly.
I made it a point to present progress, blockers, and next steps during regular sprint reviews attended by Team 1, the top management, and the representative of the investor. This wasn’t about status updates only; it was more about building a shared narrative – one where every contributor could see the outcome of their work move us forward.
But the project had been in execution for a while, and the main question I still had to answer was “How much until we launch?”
I stayed silent until we completed 4-5 sprints so that I could gather enough information on the velocity of the critical team, Team 1. I was sure the delivery wasn’t around the corner, as the CEO of Team 1 was. Still, I wanted to confirm it with numbers (quantitative measurements) and have good arguments for the not-so-pleasant talk ahead with all relevant parties (read: investor, top management, and Team 1).
Measuring Velocity: The Sad Reality on The Field
This heading is about the harsh reality. At the end of the 4th sprint, the average velocity of Team 1 was telling a sad story that we will need more than 1.5 years to complete the project if we continue with the same working dynamics. I presented the news to all relevant parties, including the investor, top management, and Team 1, which was backed by a report with measurements. The CEO of Team 1 didn’t have any arguments against the projection that we will need more than a year to complete the project. That was a shock to everybody, except me.
Measuring Impact: The Real Value of Visibility
The investors underwent the most significant change because of the project modifications. The team developed smart decision-making skills through their quantity measurement activities and worked on expense disclosure for project completion. The project backers avoided a significant financial loss by gaining clear visibility into project requirements and team velocity, which showed they needed to invest more than twice their initial investment.
The CEO of the company created to govern this significant project lost his job, and Team 1, an outsourced software development service provider, lost a client. I’m not proud of that, but that was a direct result of the transparency and visibility system I established for the project, for which I’m more than proud because it saved the investor from much more money than they were obviously ready to invest; the investor who hired me to answer the ultimate question, “How much more it will take?”
Lessons Learned: What This Journey Taught Me
Looking back, I see this engagement as proof of just how much the right product management mindset can transform not only a team, but a company’s culture:
- Start by listening
I didn’t arrive with a solution; I started by understanding every voice – agents, developers, managers, and competitors. - Map reality honestly
A project’s status isn’t a set of optimistic estimates; it’s a living snapshot of risks, dependencies, and gaps. - Build bridges, not walls
Between geographically or culturally separated teams, real momentum only happens when everyone sees themselves as part of the same journey. - Transparency enables smart choices
Good news or bad, clarity about costs and benefits is what gave our investors the information they needed.
Looking Ahead
Today, when I reflect on my time as the product manager of the sportsbook Agent System, I remember more than the technical milestones, the hours spent in Jira, and the conversations with various internal and external stakeholders. I remember how avoiding setting baselines, KPIs, and tracking execution through quantitative measurement can lead a product development in an undesirable direction.
That is the narrative I carry forward, the reminder that, in product development, the best stories are those where transparency, discipline, and honesty lead not just to better products, but to better outcomes for everyone involved.
Client Feedback After the Project
“I am lot of years in the hi-tech industry, as an entrepreneur.
The need of a product manager is obvious, he should understand the project, ask the right questions to make sure all is clear, write is all in a proper way, and make sure it will be done by communicating the relevant departments – research, development, QA and more…
Vasil is very smart, ask the right question, and the methods and procedures of his work are amazing! He is very organized and will make sure the project will move in the right direction.
Vasil takes full responsibility and is a soul player, like every company wants.”
☕ If you find this story helpful, you can support my work with a coffee on Buy Me a Coffee. Or if you recognized yourself in the scenario, better contact VBU.