A question list
The open questions that matter, ranked by how much damage a wrong answer would do. Each has a suggested way to answer it: an interview, a look at existing data, or a quick prototype test.
Product discovery · mobile · web · London
Good products start with better questions.
Insyta investigates before it builds. We help you separate what you know from what you assume, then design and develop mobile apps and web applications that answer real needs and use data with purpose.
Move the lens over the brief, or
“Our customers want an app so they can book appointments faster. Everyone uses their phone for this now. We need it live before the summer and it should have all the features of our website.”
Every brief is a bundle of guesses
That is not a criticism. A brief has to be written before anyone knows everything. The trouble starts when guesses are treated as facts and built straight into screens, databases and launch dates.
On day one we annotate your brief like this fictional one, marking which phrases are evidence, which are constraints and which are hopes. It usually takes an hour and changes the shape of the project.
The questions we help with
Illustration created for this site
We read the small print of your problem before we write a line of code.
What a discovery actually produces
Discovery has a reputation for vague workshops and long reports. Ours ends with a handful of short, concrete things you can act on whether or not you continue with us.
Interview notes in people's own words
Short summaries of conversations with users or staff, quoting their language. Interfaces built from real vocabulary need fewer help pages.
A tested prototype
A clickable model of the riskiest journey, tried by a few real people. We record where they hesitated and what we changed.
A first-version scope
One page saying what the first release does, what it leaves out on purpose and what data it needs, ready to estimate and build.
Sort your assumptions
Type the beliefs your product depends on, then decide how sure you really are. It is the first exercise we run in every discovery, and it is useful on its own. Anything left in “Guessed” is a candidate for research before it becomes a feature.
Known we have evidence
Believed some signals
Guessed untested
Evidence, or opinion?
Five sentences we often hear in briefs. Decide what each one is, then read why. There are no trick questions, only useful arguments.
“Our customers hate phoning us.”
“Last quarter, most bookings arrived through the website form.”
“People will want every feature the website has.”
“In testing, five people paused at the payment step.”
“Younger users will only ever use an app.”
Choose an answer for each sentence.
What we will not do
We will not show you invented charts, made-up percentages or results from projects we cannot name. Evidence in our work comes from your users, your data and tests we run together, and we say clearly where the evidence stops and judgement begins.
That honesty applies after launch too. Our support work runs Monday to Friday, 09:00 to 18:00 UK time, and every report receives a written diagnosis before any change is made.
Read our standardsThree habits from our field guide
Ask about the last time, not the usual time
“Tell me about the last booking you made” gets a real story. “How do you usually book?” gets a tidy, imagined average.
Count before you build
Before adding a feature for a group of users, check how many of them appear in your own records. Small groups still matter, but they deserve a different plan.
Write the question on the prototype
Every test prototype should carry the question it is meant to answer. If nobody can say what it is, the test is not ready.
Short answers to common questions
- We already know what we want built. Do we still need discovery?
- Not always. If your evidence is solid, we will say so and move straight to design and build. A short review of the brief is usually enough to tell.
- How long is a discovery?
- It depends on how many open questions there are. We agree a fixed scope and a list of outputs before starting, so you know what you will hold at the end.
- Can you build what discovery recommends?
- Yes. We design and develop iOS, Android and web applications and help publish them, but the discovery outputs are yours to use with any team.
- Do you need access to our data?
- Only where it answers a specific question, and only in the minimum form needed. We agree what we will look at, and how, before we look.
What is the question you keep coming back to?
Ask it here