Early product work is about evidence, workflows, and risk. Technology matters, but it should support the product decision rather than become the starting point.
01 · Start with evidence
Make the problem concrete
Write down who has the problem, what they do today, what is frustrating about it, and what would need to be true for them to change behavior.
What should you know first?
02 · Make it visible
Prototype before making it expensive
A flow, prototype, landing page, concierge process, or small internal test can often validate the direction before full development.
Test the riskiest assumption first
03 · Build to learn
Know what version one must prove
Version one should answer a small set of important questions about usefulness, adoption, willingness to pay, workflow, or feasibility.
Every build should answer something
A practical next step
Bring the problem, not the technical plan.
You can start with notes, sketches, a workflow, or a rough idea. Product and technical direction can be figured out together.
