Approach
A founder’s perspective on products, teams, and AI
My work connects three questions:
- 01What should we build?
- 02What organization and systems will let us build it?
- 03What evidence will tell us it works?
Start with real demand
The PULL framework
The best solution to a problem that isn’t urgent won’t sell.
That’s the biggest lesson I’ve learned about product-market fit. You can build something wonderful that saves people money and pain, and it still won’t sell, or at least not easily and at scale, if the problem isn’t urgent and important to them right now.
The products people pull out of your hands remove a block on a project that’s already on their to-do list, one they’re actively stuck on. Rob Snyder’s PULL framework is how I test for that before a team writes code. A customer is ready to buy when all four of these are true:
- ProjectThe customer already has a project on their to-do list.
- UnavoidableIt can’t be put off. It has to get done, and soon.
- LookingThey’re actively looking for a way to get unblocked.
- LackingThe options they’ve found fall short in a way that matters to them.
Get that right up front, then compound it with your other advantages. That’s where products succeed.
Framework by Rob Snyder. Read his explanation of PULL →
Principles
How I work
01
Understand the customer and the business
I start by understanding the problem, who experiences it, and why solving it matters. That context guides product direction and helps a team make tradeoffs as the work develops.
Founding and running companies has taught me to consider customer needs, technical possibilities, and business constraints together.
02
Make intent concrete
People and agents need a shared understanding of the intended result. Specifications, prototypes, and architectural constraints make that understanding explicit.
They also give reviewers a reference for evaluating the implementation: an oracle that isn’t the code itself.
03
Build the team around the work
A capable team needs clear ownership, useful context, and room to develop its methods. My role includes assembling that team, shaping direction, and establishing the conditions in which it can execute.
The people closest to implementation contribute many of the refinements that make the system effective.
04
Treat verification as engineering
Verification needs its own design: independent references, appropriate tests, meaningful coverage, and clear release decisions.
Teams need to understand what their checks establish and where uncertainty remains. A green suite is not the same as a correct product.
05
Make the development system observable
I want to understand how work moves through the system, including waiting, retries, failures, and human interventions.
That visibility helps distinguish a model limitation from a problem in instructions, tooling, or the surrounding workflow, and it makes improvement a more informed process.
06
Turn lessons into lasting changes
A useful retrospective changes what happens next. That might mean a clearer specification, a better skill, a new check, or a different way to divide work.
Over time, those changes become part of how the organization operates.
07
Keep leadership close to the work
I enjoy moving between company-level decisions and technical detail.
Understanding the work helps me make better decisions about product direction, team structure, resources, and execution.
In practice
From intent to delivered software
The software factory our team built at Provar puts these principles into one loop. Quality isn’t a phase after the build; it runs during the build and feeds the next one.
- 01IntentProduct intent, tracker context, the codebase, and prototypes.
- 02PlanWaves of tickets, each with a detailed build spec and its dependencies.
- 03BuildAutonomous loops dispatch builder agents into isolated worktrees.
- 04VerifyFast checks, end-to-end coverage, and blind audits against the reference.
- 05LandA deliberate milestone merge under the full suite, reviewed by people.
↻ Observe · Distill · Inherit
Telemetry, retrospectives, and debug reports become gate rules, skills, and preflight checks that the next build inherits.
People, throughout
People set intent, review at milestone boundaries, and make the judgment calls agents shouldn’t make alone.
Working through one of these questions?
I help founders and leaders with product direction, agent strategy, engineering organizations, and software factories.