Akur8 ReservingOne

Building the conditions for good design in a complex actuarial SaaS

Role: Senior Product Designer  |  Period: Nov. 2024 – present  |  Context: B2B SaaS · Actuarial loss reserving · Hybrid, Montreal-based

In 18 months, I helped ship 3 major feature epics and around 30 Reserving items, co-led a strategic initiative that redefined the product's direction, and built a research practice for Reserving from the ground up. The role was a starting point. What the product needed took it further.

Akur8 builds machine learning-powered software for insurance professionals. ReservingOne is their actuarial reserving platform, used by actuaries to estimate future insurance liabilities, a domain where a wrong number has real financial consequences.

When I joined, the product was in its early stages: the architecture was in place and a handful of basic features had been built, but most of the product still had to be designed and delivered. The initial target was existing users of a legacy actuarial reserving tool with over 1,500 users and a strong foothold among Tier 1 and Tier 2 carriers in North America.

Six months in, leadership shifted the go-to-market strategy: the scope expanded to cover an end-to-end reserving process, machine learning needed to become a core part of the product rather than a feature, and the target audience broadened to include European insurers alongside the existing North American base. Everything had to be rethought.

When leadership announced the shift, I paused the ongoing research programme and re-oriented around the new direction. Together with the PM leading the initiative, I defined what needed to happen in two weeks: updated personas, a reworked high-level workflow, and reprioritised Jobs to Be Done (JTBDs).

I re-worked all seven Reserving personas using everything available in Dovetail, our user research repository, then reshaped the JTBDs based on prior subject matter expert (SME) and user sessions. To avoid biasing the next phase, I created a clean FigJam file (our collaborative whiteboarding tool), separate from all existing material, and built an async workshop canvas for internal SMEs: JTBD mapping, prioritisation by impact and attractiveness, and an assumption matrix.

I planned and ran five individual SME sessions, co-led two external user research interviews focused on workflow discovery and machine learning opportunities, then aggregated all results and brought them into a series of cross-functional prioritisation sessions with product managers, designers, and senior stakeholders.

One of the PMs co-leading the initiative with me was openly sceptical of the method and timeline. Rather than bypassing him, I flagged the tension to my manager, adapted the approach to address his concerns directly, running five individual SME sessions with async preparation rather than a single broad workshop, so the voices he felt weren't being heard enough had proper space. His input shaped the final output, and he went on to co-own the Gross Reserves Analysis workstream with me through the Montreal gathering and beyond.

The prioritisation output fed directly into three in-person workshops during an internal Reserving team gathering in Montreal, co-facilitated with 10 to 14 participants each, covering Cash Flows, Data Management, and the Reserving analysis workspace, with machine learning embedded as a transversal principle across all three.

What came out of it:

• 7 updated personas and reworked JTBDs anchored in the new direction
• A validated assumption matrix and design estimation framework
• A high-level retro-planning for ReservingOne V1.0 (H2 2025)
• A prioritisation framework and retro-planning template that spread across the Reserving product team

The strategic work didn't stop there. As the implications of the shift continued to surface through the rest of 2025, the framework held. We built on it rather than starting over.

Akur8 had recently put a research framework in place, but it needed to be adapted to the Reserving context and put into practice in a way that worked for the squad. This work was shared with my fellow Senior Product Designer, who contributed significantly throughout. Some areas were mine to lead, some were joint, some were hers.

Working alongside my fellow Senior Product Designer, I established a recurring research cadence with internal actuarial data scientists, bi-weekly sessions alternating between discovery and feedback, and continued co-leading external research with users across 11 client companies, including on-site sessions.

To make findings usable across the squad, we structured how Reserving used Dovetail: setting up the workspace, importing NPS results, and building AI-assisted synthesis workflows. I created a custom Claude skill to surface secondary themes in transcripts that Dovetail's native tools missed, and wrote a Confluence guide so others could replicate the setup independently.

For each design partner, we set up a dedicated Dovetail project with standardised structure, and created a shared external Drive with a per-partner feedback log, the foundation of a light diary study approach that let us collect signals between formal sessions.

The value of that infrastructure showed up in the field as much as in Dovetail. In October 2025, I designed and co-facilitated an on-site contextual-inquiry session with a design partner's actuarial team, three parallel tracks across three hours with a Principal and three consultants, covering workflow shadowing, prototype testing, and a demo environment review. I designed two research plans, ran the prep call, and led the analysis and synthesis afterwards. The findings directly shaped our Information Architecture, Grid-Search, and Reserving analysis workspace work for the months that followed. The client became an NPS promoter in the next quarterly campaign.

AI became a genuine part of how I worked, not a side experiment. I used ChatGPT to query around 50 session recordings and update all seven personas in around two days. I built and maintained Dust agents for the design team, including an onboarding tracker and a designer random pairing tool. I synthesised workshop outputs into FigJam using AI, contributed to the team's shared Claude custom styles library, and documented experiments in Confluence to make them reusable across the team.

Building on a cross-product design-engineering framework co-developed with the wider design team, my fellow Senior Product Designer and I led two Reserving-specific workshop initiatives to tackle the harder collaboration questions: design-to-dev handoff with frontend engineers, and product-to-dev collaboration with backend. The output was a new Jira Kanban board giving squads shared visibility into design progress, new pre-sprint statuses, and the start of a shared framework for story-readiness.

I also started practising async-first refinement: recording design walkthroughs in advance and sending them to engineers with a structured prompt, come ready with questions, technical concerns, feasibility feedback, and alternative approaches, so that meeting time was spent on decisions, not exposition. The initiative was marked completed in the design team tracker.

When the H1 2026 roadmap had grown to roughly twice the available design capacity, I designed a re-prioritisation method, ran the sessions with the PMs alongside my fellow Senior Product Designer, and reduced scope to 25 weeks, still 6 to 7 weeks over capacity when accounting for the buffer design needs before dev completion.

I made that gap public, named it precisely, and held the boundary on what needed to follow: either redistribute work across squads, or hire a contractor. I was also explicit about what was mine to own and what wasn't. Validating priorities against user feedback and managing design dependencies was my job; gathering dev estimates and building the implementation timeline was the PM and tech lead's. Design resources need to follow resourcing decisions.

This wasn't a one-off exercise. The estimation framework I had built for H1 2025 became the template across all subsequent planning rounds, refined each time with new parameters and a consistent two-question filter: can we delay this? Can we ship a smaller version? The re-prioritisation became a recurring, formal, cross-functional rhythm, one my manager described publicly as something I orchestrated.

By August 2025, deep into the Reserving analysis workspace setup, I spent a week reviewing past prototypes, research findings, and Figma comments before designing anything new. I questioned the Object taxonomy that had been assumed as a given.

What I found: the plan to let users build customised Objects was the wrong priority. The more valuable problem was automating the process and clarifying how those Objects would be visualised. I raised this with the PM. The conversation was, in my words at the time, "surprisingly easy", which tells you something about the value of doing the investigative work before the meeting.

The epics for custom Object creation were deferred. The team moved faster on what actually mattered.

• GTM initiative: SME workshop canvas, assumption matrix, JTBD prioritisation output
• All 7 personas before and after the strategic pivot
• Retro-planning framework and design estimation matrix (FigJam)
• Dovetail synthesis structure and Claude custom skill documentation
• Dust agents overview
• New Jira board after the DT Board initiative
• Reserving analysis Figma flows and Figma Make prototypes
• Additional research artefacts (Dovetail): session guides, insights, design partner feedback logs

Screens shown in anonymised or low-detail form where required.