Phase 01 / Landscape Research

Grounding ourselves in the broader financial landscape.

With a high-level goal of finding ways to monetize beyond tax filing, I conducted secondary research covering debt, savings, credit scores, and home ownership, drawing on StatCan, CMHC, and Canadian bank economics teams to ground us in the realities of Canadian financial health.

To make sense of such a wide range of topics, I ran the broader team through the Six Thinking Hats technique, adapting it to four hats to sort our findings:

This gave us a structured way to narrow a sprawling landscape into a shortlist of problem spaces worth investigating.

Narrowing in. Before running formal interviews, I pressure-tested the shortlist with colleagues and SMEs internally: of all the problem spaces we had surfaced, which could our tax data actually help solve for customers?

As a tax filing software, verified income was a data point we felt confident leveraging. Looking deeper into home ownership, verifying income for mortgage approvals stood out. Talking to colleagues with self-employment experience, a clear pattern emerged: working within tight timelines to verify income for mortgage approval was consistently stressful and painful. That pain point became our focus.

Phase 02 / Generative Interviews

Researching both sides of a broken transaction.

Rather than look at the self-employed applicant in isolation, we took a systems thinking approach and researched both sides of the relationship between the borrower and the broker.

With a lean budget, we optimized for depth over volume, enough to see the pattern from both sides.

Who we talked to

What we found was a process that was less than optimal for both parties, just in different ways.

For brokers, the frustration was repetition. Every new client meant sending out the same document checklist from scratch, then manually tracking what came back in. Both brokers we spoke to were still relying on spreadsheets to manage this, checking and updating them by hand in between calls, showings, and closings.

For self-employed applicants, the frustration was the burden. They weren't just handing over paperwork, they were hunting for it: calling accountants, tracking down old statements, contacting institutions they hadn't spoken to in years. More than one described it as an emotional experience, not because the math was hard, but because their financial credibility, something they'd worked years to build, was suddenly in question.

One problem became two.

These interviews revealed that self-employed applicants and mortgage brokers were stuck in the same broken transaction, just from opposite sides.

Two sides of the same broken transaction, both stuck waiting on the same missing piece: a faster, more trustworthy way to verify income.

Phase 03 / Concept Testing

We tested the value proposition from both sides of the transaction.

We wanted to design a solution that acted as the bridge between the self-employed individual and the lender, one that leveraged the financial data already gathered during tax filing. Our hypothesis was that if we removed the data-collecting friction for both parties, we could alleviate much of the pain.

Our concept, DocuGather, was simple: the broker would request a specific list of documents through the platform, removing the need to rebuild the same checklist for every new client. The self-employed user could then select from what was already available in their account and send it directly to the broker, with no need to search for anything, re-upload a single file, or track down old records.

Because documents like Notices of Assessment, T1 Generals, and HST account details already existed within our platform from prior tax filings, this exchange could happen in just a few clicks, easing the pressure applicants felt working within tight lender timelines. Both parties could also track progress in real time, giving each side visibility without manual check-ins or spreadsheets.

Concept testing showed strong resonance on both sides of the transaction. Users and brokers confirmed the friction was real, costly, and worth solving. But the economics did not support building DocuGather at that time, and leadership made the call not to proceed.

Phase 01 / Choosing the Right Instrument

Choosing a shared tool for cross-functional collaboration

When leadership announced a shift toward a focus on AI-first features, product teams paused to figure out how to best pivot, and research requests reached a standstill. My team lead and I saw an opening. Our research team had already been doing foundational work for the newly formed value stream, helping teams define personas and jobs to be done, and a shared journey map was the natural next step to connect the work into one visible system. I partnered with PM leadership to get the initiative running and to make sure PMs were an integral part of building with us.

Why a journey map?

Phase 02 / Creating an Effective Workshop Series for Remote Teams

Designing a workshop series around stakeholder adoption

The participants for this initiative were not research subjects; they were busy PMs spread across three continents, with no obligation to participate. Because of this, I framed this effort around what they would gain from it: a holistic, end-to-end view of the entire customer journey, and a clear picture of how NetSuite was helping customers achieve their business goals.

I designed the workshops around their schedules, doing some of the heavy lifting prior to the actual working sessions. Building on the persona and JTBD foundation our team had already established, I pre-mapped an initial customer journey in a collaborative FigJam board that included:

• The business phases of the value stream
• The jobs to be done at each phase
• The personas involved at each phase, and how they shift across small, mid-market, and enterprise businesses
• The current NetSuite capabilities supporting each job

Pre-mapping carried a risk of anchoring PMs to our assumptions, so their job in the sessions was explicit: review the draft, challenge it, and correct or add where necessary.

To respect everyone's time, sessions were capped at three per journey phase, with each PM assigned a specific phase to match their expertise and the product area they owned. I staggered sessions by geography and delegated workshops to four additional researchers, pairing each with a PM in their own region. Working in FigJam allowed people to review and contribute asynchronously, before and after live sessions. To mitigate the risk of producing four different maps, I met with the research team weekly to review our work, align on format, and keep us on schedule.

Phase 01 / Planning and Alignment

Aligning before a single question is written

Projects begin with a collaborative FigJam kickoff. Teams co-frame the problem using structured activities including weighted voting to prioritize open questions and align on success criteria.

Discussion guides are co-authored with PMs and designers during working sessions, not handed off as finished documents. I use AI to generate draft questions and frameworks in advance so sessions start with a concrete baseline rather than a blank page.

Phase 02 / Fieldwork

Designed for global participation

One week before interviews begin, I run a pilot session with a subject matter expert. The full team is invited to observe. Live observers are capped to protect the participant experience.

For team members with time zone conflicts, I include an async notes column so they can review recordings and contribute insights later. Nobody misses out because of where they are located.

Phase 03 / Synthesis

Making sense of it together

I facilitate collaborative synthesis sessions where teams review recordings and build themes collectively. When stakeholders participate in interpretation, they develop shared ownership of what comes next.

I use AI where it accelerates: drafting, organizing, pressure-testing. I rely on human judgment where it matters most: interpreting, facilitating, deciding what the findings actually mean.

Phase 04 / Delivery

Research that gets used

Findings are designed to be skimmed, shared, and acted on. Async video walkthroughs let stakeholders absorb research on their own schedule and arrive at discussions with sharper questions.

Delivery always connects insights to strategy. The goal is not to present findings, but to make the implications explicit for roadmap decisions and design direction.