Make the problem specific
Define the user, the situation, what they do now and the smallest outcome that would make the product worth returning to.
Technology and product consulting / Australia
Build the useful thing. Keep ownership.
AI has made it much easier to produce a convincing first screen. It has not made product decisions, ownership or real users optional. I help teams and non-technical founders turn a useful problem into something small enough to test and solid enough to learn from.
GREG WOULFE / NEWCASTLE, AUStart here
This may be the problem if…
- You have a strong idea but cannot yet explain the smallest useful product.
- A prototype looks impressive while the workflow behind it remains vague.
- The tool choice is driving the product instead of the customer problem.
- An internal process belongs in something better than another spreadsheet or form.
- You need enough technical understanding to make decisions without pretending to be an engineer.
My point of view
The build starts before the code
The expensive mistake is rarely choosing the second-best AI builder. It is building a large answer to a problem nobody has made specific enough to test.
I start by narrowing the person, the repeated problem and the one complete path that would be genuinely useful. Then we can choose a sensible way to build it, put it in front of real people and learn where the idea is right or wrong.
Ownership matters from the beginning. Where does the data go? Can the product move? What happens when usage grows? Who can maintain it? AI can help with the work, but somebody still needs to stay responsible for the decisions.
How I approach it
From idea to evidence
The point is not to build the most. It is to reach useful evidence without creating a product you cannot understand or change.
Choose the narrow path
Turn the idea into one complete workflow. Remove the features that do not help test the important assumption.
Build with ownership
Choose the stack or builder against the product's likely future, then create something testable with sensible data and change control.
Learn from real use
Watch where people hesitate, what they value and whether they return. Use that evidence to keep, change, stop or invest further.
Useful outputs
What the work can produce
Sometimes the right result is a brief and a decision. Sometimes it is a working product. We decide that from the problem.
- 01
A clear product problem, customer and testable value proposition
- 02
A deliberately narrow product scope and decision log
- 03
A working prototype, internal tool or first product version
- 04
User tests and evidence for the next investment decision
- 05
A practical ownership, handover and iteration plan
Why me
Advice tested against running products
I am a non-developer who has built and operates two software products with real customers and commercial consequences. That experience has made me enthusiastic about what AI enables and much less impressed by demos that hide the ownership questions.
I work comfortably between the business problem, the person using the product and the technology making it possible. When deeper engineering is needed, I would rather name that early than bluff through it.
See the experience behind itStart with a conversation
Bring me the problem behind the app idea.
If you have a workflow, product idea or useful frustration, we can work out the smallest honest way to test it.
Talk it through