How I Work
A synthesis of design thinking, lean, and agile — after 14+ years and 20+ shipped products. Now multiplied by AI.
I don’t run a heavy process. I run a sharp one. Design thinking gives me the lens for framing the problem. Lean Startup gives me the discipline to learn fast and not over-build. Agile gives me the cadence to stay in tight cycles with engineering. The combination is faster than any of them alone, and it’s what most of my best work has been built on.
I work distributed and async by default — doc-first, prototype-first, async-review-friendly, with sharp synchronous time reserved for the decisions that need it. And since early 2026, AI multiplies every step of the process about 10×: more variants, faster validation, working code prototypes, structured synthesis where I used to spend hours alone. The judgment doesn’t change. The bandwidth does.
Three traditions, one repeatable process
Those three traditions are the lineage. In practice, every project — whatever the surface area — runs through the same seven steps, from understanding the problem to measuring what actually shipped.
The steps, described
Understand
Research user and business needs, map the current landscape and its assumptions, and identify how people actually behave today.
Plan
Define the strategy, the scope and the time it needs, and the success criteria we'll measure against.
Ideate
Generate and co-design potential solutions, then evaluate them honestly before committing.
Design
Design the solution collaboratively and document the decisions behind it.
Review
Pressure-test the work with peers, stakeholders, and engineering for feasibility.
Implement
Work with devs to ship the design accurately, and with other teams to keep it aligned.
Test & Learn
Test against success metrics — A/B and usability — report on progress, and form hypotheses for the next round.
What I believe about design
Simplicity is making the right complexity understandable
Users aren't confused by 'too much.' They're confused when the product doesn't explain structure, priority, consequences, or next steps. Simplicity is sequencing the complexity, not hiding it.
Sometimes design should be visible
Good design isn't always invisible. At big decisions, to build trust, or to prevent a mistake — the right move is to show your work. Citations. Source grounding. Guardrails. Invisible AI is untrustworthy AI.
Prototype many versions to learn
Prototypes aren't deliverables. They're research instruments. I build several versions per major decision and keep the ones that earn trust — in Figma when that's enough, in working code when it isn't.
Stay in it through development
Production builds drift. Edge cases surface. Engineering hits constraints the Figma file couldn't see. I sit with engineering through build, review PRs against the design, and QA the real product. Design isn't done when the file is done.
AI multiplies every step ~10×
The judgment is still mine. The decisions are still mine. The taste is still mine. The bandwidth is 10×. AI sits inside every step — drafting variants, scanning competitors, synthesizing transcripts, generating prototypes I'd otherwise have to build by hand.
How I actually work day-to-day
Work mode
Out of Montreal, ET, with flexible overlap across ET–PT. Distributed and async by default. Responsive within the working day; not on call after hours unless we've agreed on something specific.
How decisions get made
Most decisions get made in writing — in working docs, Figma comment threads, or Loom walkthroughs. Sync time is reserved for the decisions that genuinely need it: usually one weekly review during build, plus an emergency channel for the rare blocker.
AI as a bandwidth multiplier
Since early 2026, AI sits inside every step of the process. Same judgment, more bandwidth — more variants to react to, faster validation, working code prototypes, structured synthesis where I used to spend hours alone.
Who I work with, and how
I’m at my best close to the craft on a collaborative team — not in a lone-designer seat. The work is shared.
Engineering
Async-first via PR comments, Figma comments, and Loom walkthroughs. I flag implementation concerns in the design phase, review PRs against the design, and stay through staging QA — not just file handoff.
Product
Founder-direct or PM-direct feedback in tight cycles. When someone with good judgment pushes back, the move is to adapt, not re-argue. The second version usually beats the first because you took the input.
Research
Real users when I can; transcripts, behavioral data, and product knowledge when I can't. Trust, in particular, is invisible until you watch someone hesitate before clicking.
Leadership / founders
Best work with founders, product leaders, and engineering leads who are close to the build — people who can decide, push back, and ship. No committees, no endless planning before a prototype to react to.
What I don’t take on
- Committee structures or design-as-service workflows
- Lone-designer seats where I'm the only one in the room
- Throw-it-over-the-wall handoffs to engineering
- Endless planning before there's a prototype to react to
- Invented metrics
What I work with
Design & prototyping
Figma (advanced) · FigJam for system mapping and workshops
Working docs
Notion (or your equivalent) · Loom for async walkthroughs
Engineering loop
GitHub · Linear (or your tracker) for PR review and ticket-level work
AI in the loop
Claude Code + AI tooling — a force multiplier through every phase
If you use different tools, I’ll match yours. The setup is the easy part.