Product Discovery That Settles What You're Actually Building
The work that happens before journeys or screens: sitting with owners and staff, watching the real process, and writing down what the software must do and for whom. GullySystem runs discovery for new ideas and for software already in use.
What Product Discovery Covers
Discovery is the stage where a business problem becomes a written set of requirements someone can design against. It happens before a journey is mapped, before a wireframe exists, and before anyone agrees on a screen count.
- Suited to founders with an idea still on paper, and to businesses about to commit a development budget
- Covers stakeholder interviews, watching the current process, and collecting the documents people actually use
- Ends in a written requirement set, a role list and an agreed scope, not yet a drawn screen
- Works for a first product and for software already running that needs a rebuild justified properly
Why Projects Go Wrong Before a Screen Is Ever Drawn
Most expensive requirement mistakes are made in the first conversation, long before design or development starts.
The Brief Names a Solution, Not a Problem
Someone asks for a dashboard without saying what decision it should support. We get a screen built around a word instead of a job, and it satisfies nobody once it exists.
Two Departments Want Different Things From the Same Screen
Sales wants the order entered in seconds, accounts wants every field checked before it moves on. Nobody has resolved which wins, so the requirement arrives already contradicting itself.
The Exceptions Never Make It Into the Brief
The normal sale is described in detail. The partial return, the credit note, the emergency override written up after the fact are not — and those are exactly where finished software usually breaks.
Nobody Has Agreed What Success Looks Like
The project is scoped as a list of features rather than an outcome, so six months later nobody can say with confidence whether it actually worked.
The Person Approving the Brief Has Never Done the Job
A requirement is written by a manager who has not stood at the counter or driven the delivery route in years, and the software inherits their idea of the job rather than the real one.
How We Run a Discovery Engagement
Discovery is conversation and observation before it is documentation.
Stakeholder Interviews
Separate conversations with the owner, the managers and the people doing the work, so disagreements surface with us instead of in a review meeting later.
Watching the Work, Not Just Hearing About It
Time spent beside the people doing the job, because the workaround they mention in passing is usually more important than the process they describe formally.
Collecting What's Actually in Use
The spreadsheet kept on the side, the register, the sample invoice, the WhatsApp group used for approvals — the documents that reveal what the official process leaves out.
Writing the Requirement in Plain Language
No feature jargon, no assumptions about how it will be built — a description any stakeholder can read and correct without a translator.
Mapping Roles and Permissions
Who does what, who approves what, and who should never see what, settled early so the design work that follows is not rebuilt around a missed role.
Scope Sign-Off
A written scope you approve before design begins, so the requirement set is a fixed reference rather than something that keeps quietly expanding.
What Discovery Produces
Discovery ends with documents, not designs.
- A written requirement set in business language, reviewed and corrected by the people who will use the software
- A role and permission list covering every person who will touch the system
- A prioritised list of what matters most, separated from what can wait
- An open-questions register naming what still needs a decision before design starts
- An agreed scope document that becomes the reference for the journey mapping and design work that follows
What Shapes a Discovery Engagement
Two discovery projects with the same page count can take very different amounts of time.
- How many departments or roles have to be interviewed and reconciled
- Whether any requirements already exist in writing, or everything is currently spoken knowledge
- How many branches, sites or teams need to be visited to see the real variation in how work is done
- Whether stakeholders broadly agree on what's needed, or discovery has to help them reach agreement first
- Whether this is a new idea or a rebuild of software already running, which brings existing data and habits into scope
What Discovery Leads To
Discovery is the first stage of a longer design process. Once the requirement set is approved, the next step is mapping how each role actually moves through the work.
Frequently asked questions
We already have a detailed written spec. Do we still need discovery?
Often, a shorter version of it. A spec written by one person, however detailed, usually contains assumptions nobody has tested against the people who will use the software. We review what you have, interview a handful of real users to check it against reality, and tell you honestly where it holds up and where it does not, rather than repeating the whole exercise from nothing.
What if our own stakeholders disagree about what to build?
That is common, and discovery is a reasonable place to settle it. We interview each side separately, write down where they actually disagree rather than where they think they disagree, and bring a specific, worded question back to the group instead of an open argument. Most disagreements turn out narrower than they felt in the room.
Do you design screens during discovery?
No. Discovery produces a written requirement set, a role list and an agreed scope — no wireframes or visuals yet. Screens are drawn in the next stage, once the requirement is settled, so design decisions are made against something agreed rather than something still being argued about.
What drives the cost of a discovery engagement?
Mainly the number of roles and departments involved and how much of the current process is undocumented. A single-role process with a written spec already in hand is quick to confirm. A multi-department process running on institutional memory across several branches takes considerably longer to capture correctly.
How long does discovery usually take?
It depends on how many people we need time with and how available they are, more than on the size of the eventual product. Getting an hour with a busy warehouse supervisor across three branches is often the longest part. We agree an interview and observation schedule up front so you know what's needed of your team and when.
Can discovery happen before we've chosen a developer?
Yes, and it is often better that way. A requirement set and scope document written independently of any one vendor gives you something neutral to quote development against, whether that's an in-house team, an existing vendor or GullySystem.
What do you need from us to start discovery?
A decision-maker who can settle open questions, access to two or three people who actually do the work, any existing documents even if informal, and permission to observe the real process rather than only be told about it. A messy spreadsheet used as a workaround tells us more than a polished process diagram.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private