Insurance Broker Platform



This Canadian Insurance Brokerage is attempting to innovate within the insurance industry and emerge as an InsurTech in the process. They developed an in-house software platform to power their brokerage which gained traction within the industry, eventually creating an opportunity to white-label their solution as a SaaS product. I was brought in as a Product Owner to help the organization manage their constantly growing list of requirements, but found myself in a hybrid Scrum Master/Product Owner role - owning both the development process and the product roadmaps. Over my time at this organization, I implemented an end-to-end scalable Agile process built on Scrum, and helped to establish clear and concise roadmaps as well as detailed backlogs for each of the 8 interconnected product modules. 


2019 - 2020


Scrum Master / Product Owner


Agile - Scrum / Agile - Kanban


Still in its inception, This firm was developed initially as a platform to power a single brokerage. Interest from the industry provided the opportunity to pivot the digital strategy and develop the platform as a Software as a Service (SaaS) platform. This relatively new strategy meant that most of the modules were comprised of functionality which was either heavily integrated into other parts of the application, or still merely a concept yet to be developed. This resulted in a convoluted backlog comprised of nearly 3000 user stories and requirements which needed to be organized, cleaned out, and-in many cases-completely redone.

The most detrimental challenge for our team was the disproportionate ratio of pending work to developers. When I joined the team in 2019, the product backlog was the equivalent of nearly two years at their current capacity. Without expanding their dev team, a majority of the product backlog would be obsolete before they would have the opportunity to complete their planned work. In a similar way, the vast list of priorities often created conflicts between the eight modules, and with a limited number of development teams it is difficult to ensure that each module progresses at a similar pace.

This resulted in a convoluted backlog comprised of nearly 3000 user stories and requirements which needed to be organized, cleaned out, and-in many cases-completely redone


The broker platform has several primary milestones between its inception and its entrance into the market:

First, the launch of the initial SaaS platform offering, followed by the integration of third-party underwriting referral decisioning.

Second, implementing the ability for brokers to capture manually created or custom products, and enabling organizations the ability to manage their users' security access and permissions within the application.

Finally, the Automated balancing and reconciliation of brokerage transactions and accounting, as well as multi-carrier quoting, and CSIO API Synchronization to enable direct-to-consumer billing



My experience with this project was my first major foray into leadership beyond merely product or project management. My first course of action once joining the company was to establish a formal development process using the Scrum methodology. Due to the long-term, but rapidly evolving project ahead of them, the company had unsuccessfully attempted to institute a form of Scrum, but did not internally have the expertise to implement it effectively. As a certified Scrum Master, I began by implementing the prescribed Scrum ceremonies including Sprint Planning, Retrospectives, and Reviews; as well as structured Daily Scrums and Backlog Refinements.

Once the Scrum ceremonies had been firmly established, I turned my attention to the product backlog and backlog refinements. I spent time reviewing the extensive list of user stories, and removed items that were out-dated, already completed, no longer relative, or simply inconclusive in their scope. Cleaning up the backlog allowed myself as Product Owner to identify and outline prospective work and features for the modules, and begin to identify a high-level backlog hierarchy of Epics, Features, and the underlying user stories. Additionally, cleaning up the structure of the user stories enabled the development team to increase the efficiency and accuracy of their backlog refinement ceremonies.

With the high-level backlog hierarchy in place, I was able to build out a product roadmap of features for each of the eight modules. These roadmaps were constructed using a prioritized list of features and enhancements, consisting of both the pre-existing user stories from the backlog as well as new requirements which were identified or conceptualized as the roadmaps began to take shape. These newly implemented roadmaps and a clearly prioritized backlog helped to clearly outline how conflicting priorities or similarly ranked requirements should be planned out and brought into a development cycle. This alleviated difficulties associated with spreading the development team's efforts across initiatives, and allowed us to create a singular focus or Sprint Goal for each respective team's iterations.

As a final step in the restructuring of the software development process, I established a number of key KPI's to evaluate the success of the process I had implemented, and tracked their ongoing performance against their past performance. This performance tracking was initially based on their pre-Scrum performance, but quickly became an ongoing set of metrics to which the leadership and executive teams could monitor the development process.