Context
Cannabis is legal under a different set of rules in every US state that permits it, and those rules change often. Operators are required to track seed-to-sale movement, report to state systems, and survive audit. A compliance platform in this market isn't a workflow product with a rules engine bolted on — the regulation is the product.
I shaped product direction: translating regulation into roadmap, epics, and prioritised work, and running the discovery that told us where the real friction was.
The problem
Two failure modes sit on either side of this product, and both are fatal.
Model the regulation too literally and you ship a different product for every state, with a codebase that fragments and a roadmap that can never get ahead of the legislature. Abstract it too aggressively and you ship something that is technically configurable and practically unusable, where every operator needs a consultant to set it up.
Underneath that was a discovery problem. The people who feel compliance pain most acutely — the operations staff doing the daily reconciliation — are not the people who buy the software, and their problems don't surface in a sales conversation.
Constraints
- Regulation changes on someone else's schedule, with no notice and no negotiation, so the architecture had to absorb change as data rather than as code.
- Audit exposure, which meant "mostly right" was not a shippable state for anything touching reporting.
- Buyer and user were different people with different definitions of the product's value.
- Deep domain complexity that no one on the team had lived, so every assumption needed external validation.
What I did
Separated the stable spine from the variable surface. The parts every state shares — chain of custody, quantity reconciliation, reporting events — became the fixed model. The parts that differ — thresholds, forms, timings, categories — became configuration. Roadmap items were then classified by which side of that line they touched, which made the "is this a feature or a config change?" argument resolvable rather than perpetual.
Ran discovery with the operators, not the buyers. Customer interviews and usability testing with the staff doing daily reconciliation surfaced friction the buying conversation had never mentioned — the specific moments in the workflow where people abandoned the software and went back to a spreadsheet. Those became the highest-priority epics.
Used high-fidelity prototypes as the specification. In a domain this complex, a written requirement is interpreted three different ways by three different readers. Figma prototypes tested with real operators turned specification disputes into observation: we watched where people hesitated rather than debating where they might. Task completion improved measurably after the changes this surfaced, and — as valuable — the prototypes cut the volume of clarification questions engineering had to raise mid-sprint.
Made competitive analysis a standing input. In regulated markets, competitors are effectively running experiments on your behalf about which interpretation of a rule regulators accept. Reading their releases was a genuine source of roadmap signal, not a vanity exercise.
Outcome
Regulation became something the roadmap could absorb rather than something that repeatedly detonated it, and the discovery-and-prototype loop moved prioritisation off seniority and onto observed behaviour. Measurable adoption gains followed the epics that came out of operator research — which was the point: the users we'd been designing around weren't the ones struggling.
What I'd do differently
I let the prototype phase run longer than it needed to on the second major flow. Once the pattern was established, engineering could have started on the stable spine while I was still testing the variable surface. I was sequencing for tidiness rather than for throughput, and it cost us weeks.