Ambiguity is the job
Unclear requests aren't an obstacle to product work — they're the input. My value starts before anything is buildable.
How I work
Ambiguity → clarity → delivery → learning.
I apply the same working model to products built through Xpect and to embedded client engagements.
- 01
Discover
Understand the problem, users, business goals, constraints, and success criteria.
- Who has the problem, and what do they do today?
- What does the business need this to achieve?
- What constraints are non-negotiable?
- 02
Define
Turn ambiguity into product direction, priorities, requirements, and executable scope.
- A written definition engineers can build from
- Explicit scope boundaries and sequencing
- Trade-offs made visible rather than buried
- 03
Deliver
Work closely with engineering and stakeholders to take the product from plan to production.
- Backlog kept prioritised and unblocked
- QA and release readiness treated as part of the work
- Stakeholders informed before they have to ask
- 04
Improve
Measure, learn, iterate, and continuously improve the product.
- Real usage over assumptions
- Small corrections early instead of large rewrites later
- Decisions revisited when evidence changes
Principles
What stays constant across engagements.
Written beats verbal
Direction, scope and decisions get written down. Teams move faster when nobody has to reconstruct why something was chosen.
Close to the build
Product decisions are made next to the people implementing them, not handed over a wall and hoped for.
AI where it earns its place
AI is used where it measurably improves the product experience — not applied as a feature label.