App Discovery & Product Development Workshop
App Discovery & Product Development Workshop
Chapter 01
Chapter 01
The
Workshop.
The
Workshop.
Discovery and Product Definition, facilitated as one engagement. We map the problem you’ve lived, surface the assumptions underneath it, and decide what a first release must prove — and what it doesn’t need yet.
Discovery and Product Definition, facilitated as one engagement. We map the problem you’ve lived, surface the assumptions underneath it, and decide what a first release must prove — and what it doesn’t need yet.
Starts with a Founder Working Session — applications reviewed personally.
Starts with a Founder Working Session — applications reviewed personally.
Building software
doesn’t make an
idea clearer.
Building software
doesn’t make an
idea clearer.
Good Discovery does. Good Definition earns the build.
Before we invest in screens, architecture or production code, we make the problem, assumptions and first-release scope explicit — in a single, structured engagement.
Two Disciplines, One Room
Discovery and
Definition happen
together.
Discovery and
Definition happen
together.
Two Disciplines, One Room
Discovery and
Definition happen
together.
Discovery and
Definition happen
together.
Discovery
Understanding the problem, the people who live it, and the assumptions being made.
Many strong software ideas begin because a founder has personally experienced a process that is slow, expensive, frustrating or simply handled badly. That lived experience is the starting material. But before it becomes a product roadmap, we separate the observed problem from the proposed solution — examining workflow, users, current alternatives and the circumstances in which the problem actually occurs.
Definition
Deciding what the product is and, just as deliberately, what it is not.
Every feature on a first release has to justify its place. Definition is only as good as the Discovery that feeds it — which is why we don’t treat them as sequential projects. The same engagement that surfaces the assumptions shapes the scope. The people who understand why the problem matters are the ones deciding what deserves to be built.
Discovery
Understanding the problem, the people who live it, and the assumptions being made.
Many strong software ideas begin because a founder has personally experienced a process that is slow, expensive, frustrating or simply handled badly. That lived experience is the starting material. But before it becomes a product roadmap, we separate the observed problem from the proposed solution — examining workflow, users, current alternatives and the circumstances in which the problem actually occurs.
Definition
Deciding what the product is and, just as deliberately, what it is not.
Every feature on a first release has to justify its place. Definition is only as good as the Discovery that feeds it — which is why we don’t treat them as sequential projects. The same engagement that surfaces the assumptions shapes the scope. The people who understand why the problem matters are the ones deciding what deserves to be built.
If we don’t know,
we don’t pretend
we do.
If we don’t know,
we don’t pretend
we do.
Before Features, Find the Questions
Before features,
find the questions.
Before features,
find the questions.
Before Features, Find the Questions
Before features,
find the questions.
Before features,
find the questions.
01
Define the Problem
What is actually happening today? Who experiences it? How often does it occur, and what does it cost in time, money, effort or frustration?
The objective is to move from “I have an app idea.” to “A specific group of people appears to have a meaningful problem.”
01
Define the Problem
What is actually happening today? Who experiences it? How often does it occur, and what does it cost in time, money, effort or frustration?
The objective is to move from “I have an app idea.” to “A specific group of people appears to have a meaningful problem.”
02
Expose the Assumptions
Every product idea contains beliefs about users, behaviour, demand, pricing, workflows and willingness to change. The Workshop makes those assumptions visible before they quietly become expensive features.
02
Expose the Assumptions
Every product idea contains beliefs about users, behaviour, demand, pricing, workflows and willingness to change. The Workshop makes those assumptions visible before they quietly become expensive features.
03
Identify What Must Be True
What needs to be true for this opportunity to become a useful product and a viable business? Those are the questions the market validation stage has to investigate.
03
Identify What Must Be True
What needs to be true for this opportunity to become a useful product and a viable business? Those are the questions the market validation stage has to investigate.
01
Define the Problem
What is actually happening today? Who experiences it? How often does it occur, and what does it cost in time, money, effort or frustration?
The objective is to move from “I have an app idea.” to “A specific group of people appears to have a meaningful problem.”
02
Expose the Assumptions
Every product idea contains beliefs about users, behaviour, demand, pricing, workflows and willingness to change. The Workshop makes those assumptions visible before they quietly become expensive features.
03
Identify What Must Be True
What needs to be true for this opportunity to become a useful product and a viable business? Those are the questions the market validation stage has to investigate.
Your experience
found the problem.
The Workshop gives it
structure.
Your experience
found the problem.
The Workshop gives it
structure.
Many strong software ideas begin because a founder has personally experienced a process that is slow, expensive, frustrating or simply handled badly.
That lived experience is valuable. But before it becomes a product roadmap, we need to separate the observed problem from the proposed solution.
We examine the workflow, users, stakeholders, current alternatives and the circumstances in which the problem actually occurs.
The goal is to understand the problem well enough that we can ask better questions about the opportunity.
Your experience
found the problem.
The Workshop gives it
structure.
Your experience
found the problem.
The Workshop gives it
structure.
Many strong software ideas begin because a founder has personally experienced a process that is slow, expensive, frustrating or simply handled badly.
That lived experience is valuable. But before it becomes a product roadmap, we need to separate the observed problem from the proposed solution.
We examine the workflow, users, stakeholders, current alternatives and the circumstances in which the problem actually occurs.
The goal is to understand the problem well enough that we can ask better questions about the opportunity.
What has to be true
for this to work?
What has to be true
for this to work?
A technically possible product is not automatically a viable business.
The Workshop identifies the assumptions that could materially change the opportunity: who the user is, who pays, how frequently the problem occurs, what people do today, what would cause them to change behaviour and what an acceptable commercial outcome would need to look like.
Find the assumptions
that could kill the idea
before they become
features.
Find the assumptions
that could kill the idea
before they become
features.
What has to be true
for this to work?
What has to be true
for this to work?
A technically possible product is not automatically a viable business.
The Workshop identifies the assumptions that could materially change the opportunity: who the user is, who pays, how frequently the problem occurs, what people do today, what would cause them to change behaviour and what an acceptable commercial outcome would need to look like.
Find the assumptions
that could kill the idea
before they become
features.
Find the assumptions
that could kill the idea
before they become
features.
Scope With Purpose
Scope With Purpose
Every feature
has to justify
its place.
Every feature
has to justify
its place.
What is the product fundamentally helping the user accomplish? Strip away everything that does not contribute to solving the validated problem.
The goal is to move from “What features should the app have?” toward “What outcome does the user need?” That clarity produces a first-release scope the founder can actually execute without funding the entire enterprise vision on day one.
The proof of concept should test
the risks we still care about.
Not everything we might build one day.
The proof of concept should test
the risks we still care about.
Not everything we might build one day.
In the first release
The critical workflow that proves the core job. The features users need to get value on day one.
Deliberately not yet
Enhancements, edge cases, and the full roadmap vision. Deferred because deferral is a decision, not an oversight.
What is the product fundamentally helping the user accomplish? Strip away everything that does not contribute to solving the validated problem.
The goal is to move from “What features should the app have?” toward “What outcome does the user need?” That clarity produces a first-release scope the founder can actually execute without funding the entire enterprise vision on day one.
The proof of concept should test
the risks we still care about.
Not everything we might build one day.
The proof of concept should test
the risks we still care about.
Not everything we might build one day.
In the first release
The critical workflow that proves the core job. The features users need to get value on day one.
Deliberately not yet
Enhancements, edge cases, and the full roadmap vision. Deferred because deferral is a decision, not an oversight.
Proof of Concept
Proof of Concept
It looks real.
It feels real.
But its job
is to help us learn.
It looks real.
It feels real.
But its job
is to help us learn.
interactive
visual
navigable
representative of the proposed experience
realistic enough to put in front of real people
intentionally faster and cheaper to create than production software
interactive
visual
navigable
representative of the proposed experience
realistic enough to put in front of real people
intentionally faster and cheaper to create than production software
This is not
Release 1.
This is not
Release 1.
No Production Backend Required
The PoC only needs the functionality required to test the experience.
No Production Architecture Promise
It is not designed to prove long-term infrastructure or scalability.
No Guarantee the Code Carries Forward
The PoC may be intentionally discarded when Release 1 begins.
No Reason to Over-Engineer It
Its job is learning, not longevity.
Throwing away the PoC code
does not mean
throwing away the value.
The value sits in what we learned, the workflows we defined, the product decisions we made and the evidence the founder can now take forward.
Throwing away the PoC code
does not mean
throwing away the value.
The value sits in what we learned, the workflows we defined, the product decisions we made and the evidence the founder can now take forward.
A Pilot Light Principle
The first version
of your idea
should be cheap
to be wrong about.
The first version
of your idea
should be cheap
to be wrong about.
Learn cheap.
Build expensive
only when it’s earned.
Learn cheap.
Build expensive
only when it’s earned.
The closer we get to production development, the more expensive change becomes. The Workshop gives us a controlled environment to find the weak points while they are still inexpensive to fix.
A Pilot Light Principle
The first version
of your idea
should be cheap
to be wrong about.
The first version
of your idea
should be cheap
to be wrong about.
Learn cheap.
Build expensive
only when it’s earned.
Learn cheap.
Build expensive
only when it’s earned.
The closer we get to production development, the more expensive change becomes. The Workshop gives us a controlled environment to find the weak points while they are still inexpensive to fix.
Workshop Outputs
Workshop Outputs
What you
leave with.
What you
leave with.
01
A clear problem map and the assumptions that matter
Separated from the solution. You leave knowing what you actually know versus what you were assuming.
01
A clear problem map and the assumptions that matter
Separated from the solution. You leave knowing what you actually know versus what you were assuming.
02
A prioritised first-release scope — what’s in, what’s deliberately not, and why
Not a wishlist. A disciplined first-release definition where every element has earned its place.
02
A prioritised first-release scope — what’s in, what’s deliberately not, and why
Not a wishlist. A disciplined first-release definition where every element has earned its place.
03
A working proof of concept you can put in front of real people
Interactive, realistic and intentionally faster to build than production software. Its job is to generate evidence, not ship features.
03
A working proof of concept you can put in front of real people
Interactive, realistic and intentionally faster to build than production software. Its job is to generate evidence, not ship features.
04
A validation kit: who to speak to, what to ask before showing anything, and what counts as signal versus compliment
So the legwork between the Workshop and the evidence session is structured, not improvised.
04
A validation kit: who to speak to, what to ask before showing anything, and what counts as signal versus compliment
So the legwork between the Workshop and the evidence session is structured, not improvised.
05
The evidence session — when your validation legwork is done, we sit down together and read what you found against the gate. Included in the workshop fee, whenever you’re ready for it.
The evidence session is a structured read-out — not a sales conversation. We look at what was heard, what it means and whether the gate has been earned.
05
The evidence session — when your validation legwork is done, we sit down together and read what you found against the gate. Included in the workshop fee, whenever you’re ready for it.
The evidence session is a structured read-out — not a sales conversation. We look at what was heard, what it means and whether the gate has been earned.
01
A clear problem map and the assumptions that matter
Separated from the solution. You leave knowing what you actually know versus what you were assuming.
02
A prioritised first-release scope — what’s in, what’s deliberately not, and why
Not a wishlist. A disciplined first-release definition where every element has earned its place.
03
A working proof of concept you can put in front of real people
Interactive, realistic and intentionally faster to build than production software. Its job is to generate evidence, not ship features.
04
A validation kit: who to speak to, what to ask before showing anything, and what counts as signal versus compliment
So the legwork between the Workshop and the evidence session is structured, not improvised.
05
The evidence session — when your validation legwork is done, we sit down together and read what you found against the gate. Included in the workshop fee, whenever you’re ready for it.
The evidence session is a structured read-out — not a sales conversation. We look at what was heard, what it means and whether the gate has been earned.
The Workshop is a fixed $10K commitment — the first of exactly two on the way to Release 1. See how the investment is structured.
The Workshop is a fixed $10K commitment — the first of exactly two on the way to Release 1. See how the investment is structured.
The context
starts here.
The context
starts here.
The Workshop is not a document that gets handed off. It becomes shared context that follows the idea into every decision that comes next.
The problem, assumptions and product decisions uncovered during the Workshop become the foundation we carry into Market Validation, Release 1 and whatever the opportunity earns next.
Not sure whether you’re ready for the Workshop?
We’ll help you work out where you are, what still needs to be proven and what should happen next.
Not sure whether you’re ready for the Workshop?
We’ll help you work out where you are, what still needs to be proven and what should happen next.
Next Chapter
The Workshop ends.
The market
begins.
The Workshop ends.
The market
begins.
The Workshop produces the questions and puts a proof of concept in your hands. Market Research & Validation takes those into the real world — where real users, real behaviour and real market signals either confirm the opportunity or challenge it.
This stage is founder-led. You do the legwork. We equip it and read the evidence with you.
Chapter 02
Market Research & Validation
You take the proof of concept to the people who live the problem. We equip the legwork, then read the evidence with you.
Real user conversations
Market demand signals
Behavioural evidence
Evidence session with Pilot Light
Next Chapter
The Workshop ends.
The market
begins.
The Workshop ends.
The market
begins.
The Workshop produces the questions and puts a proof of concept in your hands. Market Research & Validation takes those into the real world — where real users, real behaviour and real market signals either confirm the opportunity or challenge it.
This stage is founder-led. You do the legwork. We equip it and read the evidence with you.
Chapter 02
Market Research & Validation
You take the proof of concept to the people who live the problem. We equip the legwork, then read the evidence with you.
Real user conversations
Market demand signals
Behavioural evidence
Evidence session with Pilot Light
Common Questions
Workshop
questions.
Workshop
questions.
What is The Workshop?
How long does the Workshop take?
Do I need to have my idea fully formed before the Workshop?
Is the Proof of Concept a real app?
What happens after the Workshop?
What if the Workshop reveals the idea needs more work?
Common Questions
Workshop
questions.
Workshop
questions.
What is The Workshop?
How long does the Workshop take?
Do I need to have my idea fully formed before the Workshop?
Is the Proof of Concept a real app?
What happens after the Workshop?
What if the Workshop reveals the idea needs more work?
The Primary Offer
Not sure whether
you’re ready
for the Workshop?
Not sure whether
you’re ready
for the Workshop?
The Founder Working Session
That’s exactly the kind of question the Founder Working Session is designed to answer.
We’ll work through where you are today, what you’ve already done and what still needs to be proven. Afterwards, I’ll personally turn that discussion into a practical 30, 60 and 90 day action plan based on where you are today and what needs to happen before the idea is genuinely ready for Release 1.
I put some skin in the game too.
You leave with a tailored action plan I’ve prepared for your idea, not a recycled playbook.
If I think you’re too early to spend money with Pilot Light, I’ll tell you.
If you’ve already done enough to move into the Workshop, Validation or Release 1, I’ll tell you that too.
Founder capacity is deliberately limited. Applications are reviewed personally.
The Primary Offer
Not sure whether
you’re ready
for the Workshop?
Not sure whether
you’re ready
for the Workshop?
The Founder Working Session
That’s exactly the kind of question the Founder Working Session is designed to answer.
We’ll work through where you are today, what you’ve already done and what still needs to be proven. Afterwards, I’ll personally turn that discussion into a practical 30, 60 and 90 day action plan based on where you are today and what needs to happen before the idea is genuinely ready for Release 1.
I put some skin in the game too.
You leave with a tailored action plan I’ve prepared for your idea, not a recycled playbook.
If I think you’re too early to spend money with Pilot Light, I’ll tell you.
If you’ve already done enough to move into the Workshop, Validation or Release 1, I’ll tell you that too.
Founder capacity is deliberately limited. Applications are reviewed personally.
The Decision Gate
What the Workshop has to earn: a first release worth proving — and a proof of concept worth testing.
Progress
The evidence has earned the next stage.
Progress
The evidence has earned the next stage.
Refine
The direction is close but the assumptions need adjusting.
Refine
The direction is close but the assumptions need adjusting.
Learn More
The decision needs evidence we don’t yet have.
Learn More
The decision needs evidence we don’t yet have.
Stop
And that can be the most valuable outcome of all.
Stop
And that can be the most valuable outcome of all.
The outcome determines what happens next — not momentum.
The Decision Gate
What the Workshop has to earn: a first release worth proving — and a proof of concept worth testing.
Progress
The evidence has earned the next stage.
Refine
The direction is close but the assumptions need adjusting.
Learn More
The decision needs evidence we don’t yet have.
Stop
And that can be the most valuable outcome of all.
The outcome determines what happens next — not momentum.