Selected work, 2020 to 2026

Five years of requirements, delivery, and stakeholder work, written up the way I'd explain it in an interview.

Most of these are stories from my time at Arbor, a B2B SaaS platform built on supplier and emissions data. The earliest is from my year and a half building that same platform as a developer, and the last is from my time as a business analyst at Alberta Health Services. References are available on request.

4 case studies References available on request
Showing 4 of 4

The problem

One of Arbor's largest enterprise customers was chasing supplier data by hand. Supplier contacts would email back spreadsheets in whatever shape they felt like, and someone on the customer side had to open, clean, and re-type every one before the numbers were usable. It was slow, error-prone, and impossible to scale as the supplier network grew.

The approach

I owned the service that replaced the spreadsheet chase with an automated collection process. That meant bulk onboarding for supplier contacts, standardized templates so data arrived in a consistent shape, and a clear place for the customer's team to see what was in, what was late, and what needed a nudge. I ran the discovery sessions with the customer, wrote the requirements and acceptance criteria, and worked with development through refinement, delivery, and release sign-off.

The outcome

Supplier data arrived structured instead of landing in an inbox to be chased and re-typed. One of Arbor's largest clients adopted it, and the service became a core part of the platform offering rather than a one-off for a single account.

The problem

Arbor's sales-to-onboarding handoff was held together by spreadsheets and email threads, but nobody on the inside was calling it a problem. I noticed it watching deals stall after a verbal yes: contracts took an average of 50 days from agreement to signature, which delayed kickoff, delayed first value, and made forecasting genuinely difficult. Sales wanted to close faster. CS wanted a cleaner handoff. Neither team owned the contract step itself.

The approach

I collected and analyzed data across the pipeline to size the bottleneck, then made the case for building contract creation directly into the platform. Once the case was clear, I prioritized the work into the backlog, wrote the requirements, and managed the release. It meant coordinating between sales, operations, legal, and development, and translating each team's friction into a single workflow none of them owned individually.

The outcome

Average signing time dropped by weeks from the 50-day baseline. The sales team closed deals noticeably faster, and the handoff to CS got cleaner because the contract details were already structured data in the platform rather than a PDF in someone's inbox.

The problem

One of Arbor's largest enterprise clients had a recurring frustration: they wanted to make lower-carbon design choices earlier in the process, but every existing tool forced them to wait until a product was almost ready for production to model its footprint. The result was either late-stage compromises or carbon decisions getting deprioritized entirely.

The approach

I led the year-long co-development of the feature alongside the client, treating it as a partnership rather than a one-off request. The work meant running exploration sessions with the client's product team, translating what they needed into requirements the internal team could build against, and holding the line on scope so what we shipped generalized to the rest of the enterprise book instead of becoming bespoke.

Inside Arbor I worked closely with design, development, cloud infrastructure, operations, and executive leadership through the whole build, then owned the release and the post-launch conversations with the client.

The outcome

The feature launched to strong client feedback and led directly to an enterprise upsell. The client used it to shift tens of millions of dollars in production toward lower-carbon designs, and continues to use it today.

The problem

A demand and capacity initiative at Alberta Health Services needed structured process recommendations, but input from subject matter experts across a large public sector healthcare organization was conflicting and unstructured. Stakeholders wanted a single, shared view of what was being asked for and how those requests should be prioritized.

The approach

I facilitated the requirements workshops with subject matter experts, sitting in the middle of the conflicting answers and reconciling them into structured process recommendations. Alongside the workshops I built the Jira board stakeholders used to track incoming requests and prioritize them, so the same view of demand held between sessions.

The outcome

Stakeholders had a place to see their own demand and prioritize it together. Requirements were captured in a form the delivery team could act on, and the process recommendations gave the initiative a defensible starting point rather than a folder of meeting notes.

If any of that sounds like a problem you're trying to solve, let's talk.