Process
How I work
Most products fail not because they weren't built well — but because the wrong thing was built. My process is designed to prevent that.
Start with demand, not solutions
Most product failures aren't engineering failures — they're demand failures. Teams build something nobody was actually trying to hire. The product works, but it doesn't fit the job people needed done.
Jobs to Be Done is a framework for understanding demand at its root: what progress is someone trying to make? What's the struggling moment that causes them to look for a new solution? What are they really hiring a product to do?
Deeply influenced by Bob Moesta's work on demand-side thinking, I bring this lens to every product engagement — before wireframes, before pitches, before code. It's the difference between building what people ask for and building what they actually need.
The struggling moment
What causes someone to look for a new solution? Understanding this is worth more than any user survey.
The job to be done
People don't want features — they want to make progress. Defining the job clarifies what to build and what to leave out.
Demand before supply
Only once the demand is understood does it make sense to shape a solution — not the other way around.
I work in Shape Up cycles
Shape Up is the product development methodology developed by Basecamp. Instead of maintaining endless backlogs or running two-week sprints that never quite deliver, teams work in focused six-week cycles on carefully shaped problems.
The key insight is that the shaping — defining what to build and more importantly what not to build — happens before the cycle begins. This prevents scope creep, builds team autonomy, and ensures that what ships actually matters.
I've been practicing Shape Up for four years and have introduced it to client teams — framing problems, writing pitches, and guiding the transition from Scrum-as-usual to intentional product cycles.
Shape
Define the problem and the rough solution — with enough detail to build from, enough room for the team to figure things out.
Bet
Decide what to work on this cycle — and what to say no to. A deliberate choice, not a backlog shuffle.
Build
The team owns the work end-to-end. No daily standups, no micromanagement — just meaningful progress toward something shippable.
The outcome is what matters
Features ship. Outcomes are rarer. I care about whether the thing we built actually helped someone make progress — not just whether it was delivered on time.
This shapes how I approach every decision: what to include, what to cut, what to validate before investing further. User outcomes and business outcomes aren't in tension — when you get the first right, the second follows.
I've invested seriously in understanding users — including a UX certification from Nielsen Norman Group — but I apply that as a thinking tool, not a process to follow.
From demand to shipped
One of the most expensive gaps in product teams is between the people who define the work and the people who build it. I can close that gap — translating understood demand into a shaped problem, then engineering it into a working product.
This works especially well for smaller teams and early-stage products where every cycle needs to count and handoff costs are high.
What this means in practice
If you have a fuzzy idea
I can help shape it — turning vague intent into a clear, scoped problem worth solving.
If you have a team that ships slowly
I can introduce Shape Up principles and help the team build a healthier product cadence.
If you need something built
I can take a shaped concept through to a working product — designing and building end to end.
If your product feels off
I can look at it through a user outcome lens — where is the friction? What job isn't getting done? What's worth fixing first?