CASE STUDIES · FIVE ENGAGEMENTS

Where the route changed, and why.

Five engagements, each run the same way: survey the ground honestly, chart a route that fits the real constraints, then build along it.

CASE 01 · TRANSACTION MONITORING · B2B
Fraud detection platform (confidential)

Standing up product management where none existed

A transaction-monitoring platform serving banks and payment processors brought me in with no product function in place. Product decisions had been running through a sales-led lens, and the company sold almost entirely through partners, meaning the people who actually understood customer pain sat one layer removed from the team building for them.

  • Survey

    I mapped what existed: no shared framework, no established path to customer input, and a partner layer that blocked the usual routes to the people using the product.

  • Route

    I introduced a structured product framework and adapted it to fit a partner-led business specifically, rather than importing a process built for direct-sales companies. That included building a case for direct customer access, grounded in what the framework actually required rather than a general appeal to best practice.

  • Build

    I delivered the operating scaffolding the company didn't have: a working task structure, a communication map that clarified who decided what, and competitive intelligence across the fraud-detection landscape that sharpened how the product was positioned against alternatives.

WHERE IT LANDED

A functioning product management process, running inside a business model that hadn't been built to support one.

CASE 02 · OWN PRODUCT · REVIEW & APPROVAL
Feedmark

Reading the market instead of defending the roadmap

Feedmark started as a review and approval tool built for solo freelancers sending work to clients for feedback. The first real adopter didn't use it that way.

  • Survey

    An early user named Athena started running Feedmark across two separate organizations at once, not as a single freelancer managing one client relationship, but as someone coordinating review across multiple accounts.

  • Route

    That usage pattern was more informative than the original pitch. It pointed toward a different, sharper audience: small agencies and product consultants managing feedback across several clients at once, not solo freelancers managing one. The positioning shifted from “a client feedback tool” to something closer to async review infrastructure.

  • Build

    The repositioning is shaping what gets built next, including a package-level review feature suited to the agency workflow the real usage data pointed to.

WHERE IT STANDS

Feedmark is in active development, built around what a real user actually did rather than what the original pitch assumed they'd do.

CASE 03 · CLIMATE HARDWARE · AGRICULTURE
Era Carbon

The buyer was the farmer, not the carbon market

Era Carbon's founder wanted to produce biochar and had oriented the entire business toward carbon markets. Carbon credits were the revenue story, and the roadmap followed from there.

  • Survey

    I worked through the problem space and the assumptions underneath it. The carbon market was the founder's interest. The person who would actually have to buy, install, and run the hardware was a farmer, and nothing in the plan reflected how farmers evaluate or purchase equipment.

  • Route

    I redrew the roadmap around that buyer. Making the hardware scalable meant understanding farm equipment purchasing behavior first, then designing backward from it.

  • Build

    The repositioned product gave the founder something fundable to present.

WHERE IT LANDED

The founder secured funding and relocated to Alberta to work on Era Carbon full time.

CASE 04 · B2B2C · SOCIAL IMPACT
Voto

Keeping users where the client wanted them

Voto ran campaigns that traded micro-donations for customer data. A company sponsors a cause, its users answer research questions, a charity gets paid. The model worked on paper. It broke on a single client objection: nobody wanted their users leaving their own website to complete a campaign.

  • Survey

    I ran user interviews to find out which causes people actually care about and what moves someone from interest to giving. The findings became personas and journey maps covering both sides of the model, the sponsoring business and the person answering questions.

  • Route

    The handoff was the failure point. Solving it meant bringing the campaign onto the client's site instead of routing traffic away from it.

  • Build

    I designed a widget that embeds in the client's page, asks users the research questions in place, and closes by showing exactly where the donation goes.

WHERE IT LANDED

A campaign format that satisfied the client's traffic concern and gave users a reason to finish.

CASE 05 · IDENTITY · DEEP TECH
Scramble Solutions

Finding the product inside the technology

Scramble Solutions had built something genuinely difficult: anonymized single sign-on that still satisfied KYC and AML requirements. The technology worked. The product it belonged inside was an open question.

  • Survey

    I built a research plan and a persona to test against, wrote the discovery questions, and ran forty customer discovery calls.

  • Route

    Forty conversations produce a clearer read on demand than any amount of internal debate. The calls surfaced which buyers felt the anonymity problem sharply enough to pay for a solution, and which treated it as a preference rather than a requirement.

  • Build

    Alongside the research, I ran design reviews with the engineering side to keep what was being built aligned with what the discovery work was turning up.

WHERE IT LANDED

A validated read on where the technology had a market, grounded in direct customer evidence.