From "Build Us an App" to a Confirmed Result

"We need an app for booking consultations." That sentence may describe a real need precisely, or it may simply be the first solution that came to the client's mind. Before counting screens and estimating development, it is worth finding out what happens before a booking is made, who keeps the schedule, why people fail to turn up, and what exactly the business wants to achieve.

What you will be able to do

After this unit you will be able to tell a problem apart from a proposed solution, a user from a buyer, and evidence from assumptions; assess the main product risks; choose the cheapest appropriate test; decide whether development should start at all; and hand your team both the conclusions and a list of what is still unknown, ready to be turned into requirements.

Other units cover the context around this one: the map of modern software development and the anatomy of a code project explain the product and its code, the terminal and local environment explains how a program runs, Git explains the history of changes, and GitHub explains review. Jira and the studio operating system shows how agreed work is recorded and handed over. This unit asks an earlier question: has the problem itself been defined correctly, and what should happen next? In product requirements and UX foundations the findings of discovery become requirements and scenarios, and the economics of an AI studio looks at the business side of the studio.

Discovery is not the meeting before coding starts

Discovery is the work that helps you decide which problem is worth solving, for whom, and in what way. Delivery is designing, building, testing, releasing and supporting the chosen solution. The two kinds of work alternate: discovery is not finished once and for all before delivery begins. New data from real use of the product can show that the problem is different, that an assumption did not hold, or that a better alternative has appeared.

Teresa Torres describes continuous discovery as small, regular research activities that a team carries out together with customers in pursuit of a desired outcome. This is her methodological guideline, not a universal rule such as "every studio must interview someone every Friday". What matters is that research results keep influencing the team's decisions. That way the team relies on fresh data rather than on memories of a pre-project workshop held long ago. Torres explains how research connects to the decision about what to build.

John Waterworth's account of a government services programme also describes strategies for involving researchers and studying users regularly throughout the life of a service. It is an example of how one government team worked, not a universal calendar for a private studio (Waterworth, "8 strategies that worked for us").

Discovery covers three closely related but distinct questions:

1. Need: what is the person trying to achieve, and what gets in the way?
2. Solution: what approach might remove the obstacle, and how can we check that it works?
3. Feasibility: can the team build and maintain that approach safely with the time, skills, data, contracts and systems it has?

Researching needs is not the same thing as technical investigation. An engineer might, for example, check whether the existing service allows available hours to be read. That produces data about the feasibility of one particular approach, but it does not prove that clients need a new app. Implementation planning helps break down work that has already been chosen, but it does not prove that the problem matters either.

Discovery reduces uncertainty to a level that is good enough for the next decision; it does not promise complete certainty. A piece of research can end with a decision to go ahead, to limit the first version, to test one more assumption, or to stop. In the UK government's official service manual, the end of discovery is tied to a decision about whether it makes sense to move forward given the value and cost of a possible service; stopping after research is a perfectly normal outcome if it saves wasted work. The guide to the discovery phase describes public digital services, so its examples need adapting for a private studio.

A problem is not the name of a feature

"Build a calendar and a profile page" describes a possible interface. To understand the problem, you need to find out:

• who exactly is trying to get something done, and in what situation;
• what the person does today;
• where delay, errors, uncertainty or unnecessary costs appear;
• how people work around the obstacle;
• what happens if nothing changes;
• who else the problem creates work or risk for;
• what change in behaviour or outcome the organisation needs.

A useful problem statement can be built like this:

When [situation], [specific role] is trying to [achieve an outcome]. Today this person [current method or workaround], but [specific friction] leads to [consequence for the user or the organisation]. We do not yet know [important assumption].

This is not a form to fill in mechanically. Its purpose is to stop the name of a solution from being substituted for a description of real experience. GOV.UK advises teams to question a solution handed to them in advance and to restate it as a problem; doing so can open up alternatives, such as different information, a different process or a different service. The manual also stresses recording what is outside the problem.

For example, "we need an interactive map" is a choice of tool. Behind it there may be a need to quickly find the nearest location where appointments are held. But you still have to establish whether people look for it on a map, phone a member of staff, get lost because of a confusing timetable, and whether searching for the address actually matters. If it turns out that addresses are already easy to find and the real problem is that people cannot reschedule a booking, a new map will not help.

Jobs To Be Done: the progress a person is seeking

Jobs To Be Done (JTBD) is an approach that explains people's choices through their circumstances and the progress they want to make, rather than only through age, profession or a list of features. A person "hires" a product or service when it helps them take a step they need in a particular situation. That progress can be functional, emotional and social. The Christensen Institute explains JTBD through circumstances, the forces of change and the types of progress.

For booking a consultation, functional progress might sound like "find a time that does not clash with work". Emotional progress: "be confident that the booking really is confirmed". Social progress: "not look unreliable in front of the colleagues I invited". These are not ready-made facts about every client; they are possible lines of inquiry.

JTBD is useful because it lets you see alternatives that look nothing like your product. Someone who wants to reschedule a consultation might phone, send an email, ask a colleague to pass on a message, simply skip it, or wait for a reply. The competition for the desired outcome is not just between two apps; it includes every habitual way of coping, plus the option of changing nothing.

Do not turn JTBD into a magic sentence that supposedly unlocks a hidden truth. It is a lens for asking questions, not evidence. The context has to be checked against people's stories, observation, existing data and small experiments.

Who uses, who pays, who decides

In a small project one person often plays all of these roles. In a more complex one they differ. The word "client" on its own does not tell you whose experience needs improving or who can approve the spending.

• Segment: a group of people or organisations with a similar situation or problem. "All clinics" is too broad if types of consultation, booking rules and responsible roles differ.
• User: the person who does the work through the service, for example a visitor booking a time.
• Buyer or customer: the party that chooses the solution and agrees to purchase it; this might be the clinic's manager.
• Payer: the person or organisation whose money pays for the system or service. In an organisation this is often the accounts department or the budget holder.
• Administrator: the person who configures schedules, rules or access and handles exceptions.
• Stakeholder: a person or group that the decision will affect: reception, specialists, management, support, the legal or technical team.

Do not assume that the buyer automatically represents the user. The manager may care about a full calendar, the consultant about time to prepare for the meeting, the client about easy rescheduling, the administrator about less manual coordination. All of these interests can be legitimate without being the same.

A user journey is the sequence of actions, contacts and decisions a person goes through in the context of a whole task. For booking it might be: hear about the consultation → check the terms → find a time → confirm → receive a reminder → attend or reschedule → receive follow-up information. Each step might involve a web page, a call, an email, a personal message or the work of a member of staff. A journey is not a list of screens: a screen shows only part of the interaction.

The GOV.UK manual recommends researching the user's entire experience, including support, offline steps and the staff who deliver the service. It specifically reminds teams about the needs of disabled people and about differing levels of digital confidence and internet access. Its description of user research in discovery presents observation, conversations, analytics and support logs as different sources of learning.

Hypothesis, assumption and evidence

An assumption is a belief that influences a decision but is not yet backed by sufficient data. A hypothesis is a specific statement about what should happen under certain conditions and what result we will see if it is true. Evidence is material that supports or weakens a statement: a direct observation, a person's testimony, or a record. A conclusion explains how the team interprets that material; in the product requirements document observations, testimony, conclusions, assumptions and decisions are marked separately.

To keep conclusions checkable, sort your notes into five categories:

• Observation: what the team directly saw, measured or checked; record the source, who collected the data and when, and the context.
• Testimony: what a specific person said about their own experience; record who said it, when and under what circumstances. A retelling of an interview is testimony, not directly observed behaviour.
• Conclusion: how the team currently interprets the observations, testimony and records.
• Assumption: a belief that influences the decision but still needs checking.
• Open question: what we do not yet know and what could change the decision.

"People want reminders" is, for now, an assumption. "In a sample covering a defined period, the logs show a certain number of same-day cancellations" is an observation, provided the period, source and counting method are known. "Reminders will reduce no-shows" is a hypothesis. After reminders are introduced you may need to compare comparable groups and check whether the change was caused by the reminders themselves rather than by seasonality, a different mix of visitors, or a process change made at the same time.

For every entry, keep a path back to the primary material: notes, the analytics time window, the interface version, the support ticket or the test summary. Do not turn the words of one participant into the needs of a whole market. Repeating the same assumption in three reports does not create three independent pieces of evidence.

What different methods can show

Interviews help you understand circumstances, the person's own language, their goals, their current methods and the reasons behind their choices. Ask about a specific past event, not about whether the person would use a product that does not exist yet: intention does not prove future behaviour or willingness to pay. For example: "Tell me about the last time you rescheduled a consultation. What did you do first?"

Observation reveals the real steps, workarounds, interruptions and objects a person uses. A member of staff may describe the process as "two clicks", while in practice they are cross-checking a paper diary, email and a spreadsheet at the same time. A single observation, however, does not show how widespread a problem is. The researcher's presence can also change behaviour, so the context must be recorded.

Behavioural data is the record of what people do in a product or service: starting and completing a booking, cancellations, errors, time to confirmation. It can show the frequency and sequence of events, but usually does not explain the cause. If many people abandon the form at the step where they choose a time, the reason could be empty slots, confusing text, a technical fault, needing to ask an employer, or something else entirely. Do not collect unnecessary personal data; use only the measures the decision needs, and make sure counting is done the same way before and after a change.

Support requests and internal work records show where people ask for help, what has to be fixed, and how much manual work a process creates. But not everyone who is unhappy gets in touch: silence does not prove there is no problem. Request categories can also be incomplete or out of date.

Surveys can collect answers from many people, but the wording influences the answers, and self-selection among participants can skew the sample. A survey about intentions does not prove a future action. Surveys are more useful for a specific question that needs many responses than as a substitute for observing experience.

A prototype is a simplified representation of a future service, anything from paper screens to an interactive demo. Watching a person carry out a specific task on a prototype can reveal confusing text, a mistaken expectation or an awkward sequence. It does not prove that people will buy the product, that an integration works, that the system is secure, or that it can be maintained. Choose a prototype that answers exactly the question you are asking. The official guide to qualitative usability testing warns that a controlled task may not reflect real use, and describes the limits of the sample and context.

Steve Krug advises watching people perform a specific task rather than just asking for their impressions of an idea. Ask a person to find a free slot and reschedule a meeting. If they hesitate between "Change time" and "Cancel booking", clarify the label or the consequence of the action and repeat the same task. Clarity of choice is covered in more detail in product requirements and UX foundations; see also Krug on the difference between a usability test and a focus group and the book excerpt on clarity of choice.

In the fourth chapter of Don't Make Me Think, Revisited, Krug explains that what matters is not the number of clicks as such, but the mental effort and uncertainty that accompany each choice. In a booking prototype, a person should understand, without guessing, the difference between "Change time" and "Cancel booking" and what pressing each will do. If participants hesitate, simplify the wording or show the consequence before confirmation, then repeat the same test task. This is an example of a refinement that comes from observing behaviour, not from a vote on which label people like.

Define the question first, then the method. "Do people understand what this button means?" can be checked with a short prototype test. "Why do people cancel consultations?" needs interviews, data and possibly observation. "Should we support this feature?" also requires checking the business and technical conditions.

During research, explain to people what is happening, ask for consent to record, restrict access to notes, and remove personal data if it is not needed. When someone tests a prototype, it is the product and the scenario being assessed, not the person's cleverness. The GOV.UK guide to moderated usability testing recommends giving neutral tasks, listening more than talking, and storing personal data securely.

What the team shipped and what changed

An output is what the team created or released: for example, a time-selection screen. An outcome is the change for the user or the organisation that the team wanted to achieve: for example, more people attending the consultations they booked, or staff spending less time rescheduling bookings.

An output can be counted once the work is done. An outcome has to be checked through behaviour or results in the real context. Releasing ten features does not mean anyone's life became easier. Success should not be defined solely by the number of screens, closed tickets or lines of code written.

Cagan's four risks

Marty Cagan names four product risks. For each one, frame a question, gather the appropriate evidence, and involve the specialist who is able to assess it. In Cagan's view, the product manager is responsible for value and business viability, the designer for usability, and the lead engineer for technical feasibility. In the early stages they work together. In a small studio one person may combine roles, but all the necessary aspects still have to be assessed. Cagan's article explains this division and the definitions of the risks.

Risk	Question	What can support a conclusion	Typical false substitute	Whose expertise is needed
Value	Does this problem matter, and will people choose the proposed approach?	Recent experience, how often the problem occurs, workarounds already in use, behavioural data; a test of real willingness to act, where appropriate	"People liked the mock-up" or "I'd use it myself"	Product manager together with a researcher and the team
Usability	Will a person understand how to complete an important task?	Observing target users completing a specific task on their own; visible errors, hesitation and completion	"The screen looks modern" or "the button is there"	Product designer and researcher
Technical feasibility	Can the team build and maintain this with the available technology, skills and time?	Checking critical technical assumptions, access to data and external services, dependencies, maintenance cost and risks	"A similar product exists" or "an agent can write the code"	Lead engineer with the team
Business viability	Does the solution work alongside sales, costs, contracts, law, support and trust?	Agreement with the payer and budget holder; checking the cost and revenue model, acquisition channels, operational work and constraints	"If users like it, the business automatically wins"	Product manager together with the people responsible for the business and operations

Evidence must fit the question. An interview can support a conclusion about the context of a problem, but it does not replace a technical check of an integration. A prototype can reveal usability difficulties, but it does not confirm that the payer will approve the budget. A technical prototype that works does not prove market demand.

Teams often test only usability, because it is easy to observe. Cagan warns that reactions to a finished design do not prove value and do not remove business viability risk. There is no universal test, and no fixed number of conversations, that automatically eliminates risk. Ask what has to be true for this solution to work, and what available evidence would change your next step.

The SEEK case shows a change in process, not a universal recipe. In her own account of a team she coached, Teresa Torres describes a move from irregular discovery and roughly five or six interviews a quarter to weekly interviews and an explicit list of risky assumptions to test. This is a self-report by the participants in the case, not an independent measurement of effectiveness: it shows how a way of working can change, but does not prove a causal business effect (Torres, the SEEK case study).

Worked example 1: "We need a booking app"

Situation. The owner of a consultancy clinic asks for a mobile app with a profile, calendar, reminders, payment and ratings. Her team often searches through email threads to confirm appointment times, and consultants report missed meetings. At this stage, the reason for the no-shows and the scale of the losses are unknown.

This entire example is an illustrative scenario with invented data, not a report about a real clinic or a piece of research that was actually carried out.

The problem before research. The first statement of the problem is "we need an app". The team starts by clarifying who books the time, who confirms it, who can change a booking, who is responsible for the calendar, and which situations create the most work. It asks to see not personal data but the current process, from the first enquiry to a completed consultation.

In this scenario it turns out that:

• the visitor wants to find an acceptable time and be confident that it is booked;
• the administrator keeps two schedules and reconciles them by hand;
• the consultant loses preparation time when someone does not turn up;
• the owner makes the decisions about spending;
• the team does not yet know why people miss appointments, or whether they want to book online themselves.

A possible problem statement: "When someone arranges a consultation, they need to know that the time is confirmed and have a clear way to reschedule. At the moment confirmation goes through several channels, and staff reconcile changes by hand. We do not yet know whether this confusion is what increases the number of no-shows." This describes the work and an open hypothesis, not a promise that an app will reduce no-shows.

Action. The team separates observations from explanations and collects the available summaries of cancellations and no-shows for an agreed period. With the clinic's permission it observes the manual booking process without looking at personal data, talks separately to visitors, administrators and consultants, and reviews the existing calendar service. The period and the definition of a "no-show" must be written down, because the baseline depends on them.

In parallel, the team frames the outcome: "reduce the proportion of booked consultations that end in a no-show, without increasing manual time per booking". First it measures the baseline and agrees how to calculate it. Inventing a starting figure or an arbitrary target before you have access to the data is not acceptable.

Checking the four risks.

Risk	What exactly the clinic checks
Value	Match up cases of no-shows, calls and reschedules to find the cause and how much it matters to visitors and to the clinic. The owner's approval on its own does not prove demand.
Usability	Observe how visitors find a time, understand the confirmation and reschedule a meeting on a prototype; the team's own judgement is not enough.
Technical feasibility	Check access to the calendar, the provider's rules and synchronisation without double bookings. An integration in another project does not guarantee access here.
Business viability	Confirm the budget holder, the full cost, how exceptions are handled, how the benefit will be measured, and whether consent is needed for notifications. A high rating for the interface does not settle these questions.

Here the product manager cannot confirm every aspect alone. A researcher helps reveal behaviour and context; a designer uncovers difficulties in the interaction; an engineer assesses access, synchronisation and maintenance; the clinic's manager confirms the business and operational conditions. An agent can help with code, but it does not replace these checks and does not turn an assumption into a fact.

Alternatives. Before building a custom app, you can compare:

• configuring an existing online booking service;
• adding a simple page of available hours to the current website;
• connecting the clinic's calendar to an off-the-shelf booking system;
• running a limited manual pilot of confirmations and reschedules;
• changing the administrator's instructions or the email template, if the main friction is not the interface;
• leaving the system as it is, if the problem is rare or the cost of fixing it exceeds the expected benefit.

Custom development makes sense when research reveals a specific need, off-the-shelf alternatives do not cover an important part of the context, the payer accepts the cost, and the team is able to maintain the result. Do not build a product simply because it can be generated quickly.

Result and next step. In the invented research, the team sees that no-shows often follow a change in the schedule, and that messages do not always reach the right person. That is not enough to justify a separate mobile app. The first step should be to test, with a limited group, messages that ask for explicit confirmation together with a simple way to reschedule, and to find out whether the existing service supports this. After the pilot, compare the agreed measures with the baseline and record the differences between groups and periods.

Why, and when, this decision may not fit. It reduces the risk of spending money on an unnecessary mobile product and tests the problem closer to the real process. But if users work without internet access, have differing accessibility needs, or the existing service cannot synchronise bookings safely, a web page or messages may not solve the task. A short test will not prove that users will stay with the product a year from now, or that the changes are explained solely by the new way of booking.

The client conversation: diagnosis before prescription

Blair Enns's list of twelve principles includes diagnosis before recommendation, choosing your clients, and talking about money early. For a studio this is a guideline for selling expert work with integrity, not an excuse to hide the price, pressure the client, or turn away everyone who does not have a budget ready. The author's page for The Win Without Pitching Manifesto.

Diagnosis before prescription means the studio first understands the situation, the available data, the risks and the limits, and only then proposes a scope and a solution. It is not free strategic design work in the first conversation. A short introductory call can establish whether there is a mutual fit, but a full audit, research, requirements and design are separate work, for which payment and deliverables need to be defined.

Examples of appropriate questions:

• "Tell me about the last time a client didn't turn up or rescheduled a consultation. What happened from the first message until the situation was resolved?"
• "What have you already tried changing? What happened after that?"
• "How do you currently count missed meetings and the time spent on manual coordination?"
• "Who books appointments, and who changes the schedule? Who handles exceptions?"
• "Who will use the system, who approves the decision, who signs off the spending, and who will pay for ongoing support?"
• "What deadlines or external dependencies are already fixed?"
• "What budget range could be considered, and who confirms it? If there is no range yet, what do you need to know before making that decision?"
• "What criteria would give you grounds to proceed, and under what circumstances should we stop or take a different path?"

Explain the purpose of the budget question: to understand the available options, the full cost and who has authority to decide, not to pressure the client or tailor the estimate to a hidden limit. Record who makes the decision and what data is still needed; do not treat the absence of a ready budget as proof that the problem is unimportant.

Do not ask the client to disclose other people's medical or payment information; for an initial diagnosis, a description of the process, anonymised summaries and permitted samples are enough. Do not push the client towards a particular budget or an unsuitable service. Explain why you are asking, and give them the option not to answer.

Paid diagnostic work can be bounded in subject and duration: for example, analysing the existing booking journey, holding agreed conversations, testing the key hypotheses, and preparing a decision with alternatives and open questions. This gives the client a useful result even if their next decision is not to commission development from this studio.

Qualification is checking the fit between the problem, the studio's experience, access to the necessary participants, budget, timelines and risks. It is not a judgement of the client's worth. You can say honestly: "From your description we don't yet know whether you need development at all. We suggest a short paid diagnostic; afterwards you'll receive a conclusion with options. If it turns out that an off-the-shelf service fits the need better, we'll say so too." You can decline if the client asks for a complete solution for free, will not allow access to users for research, or expects a result the team cannot responsibly guarantee.

A separate paid stage is not needed for the sake of ritual. If the need has already been validated, the scope is small and the decision can safely be reversed, it may be appropriate to estimate the implementation straight away. A diagnostic is justified when the cost of a mistake or the level of uncertainty is high enough that separate work gives the client a useful result regardless of whom they hire for the next step.

Positioning around a problem, not just a technology

David C. Baker links expertise to repeated experience and to positioning for clients who need exactly that competence and have few substitutes. This is the author's own thesis, not an independent comparative study. The description of The Business of Expertise on the author's site.

It is useful to build positioning around a combination of:

1. Whom the studio helps: for example, small clinics, service organisations or internal operations teams.
2. Which recurring problem it understands: booking, handling exceptions, coordinating between several systems, access management.
3. What proven experience gives it an advantage: examples of completed work, an understanding of the regulatory or operational environment, tested diagnostic methods.
4. What the client can check before buying: a clear way of working, understandable limits, examples of relevant results, and an honest discussion of risks.

"We work with React" names a tool. It does not explain whom the team is useful to or what kind of complexity it knows how to reduce. "We help clinics with two or more locations reduce manual coordination of bookings" names a type of client and a problem, but it is still not proof of competence. A position has to be tested on real projects, backed by experience gained, and narrowed or changed if demand and the ability to help are not confirmed.

Specialisation carries its own risk. A position that is too broad makes a studio look like many others, while one that is too narrow may leave too few suitable clients or limit new opportunities. Do not invent "niche expertise" out of an attractive slogan; name the real recurring problems and the evidence your recommendation rests on. Here Baker's ideas about patterns and positioning are applied to product diagnosis; this is an adaptation, not a summary of the book.

Worked example 2: two studios, one brief

What follows is an illustrative dialogue, not a real client email or a piece of research. Both studios received the same request: "We need a mobile booking app. We'd like to see a mock-up of five screens and a cost estimate by Friday."

Studio A: haggling over the rate and free screens

Client: "We need a mobile booking app. Can you send a mock-up quickly?"

Studio A: "Sure. Send us your logo. We'll do five screens for free and charge for development by the hour. What budget do you have in mind?"

Client: "I don't know yet. We'd like the app to reduce the number of no-shows."

Studio A: "Then we'll add reminders and a consultant rating. That will help persuade people to turn up."

What happened. The studio agreed to a solution before understanding why people miss appointments. Without evidence, it credited reminders with the desired effect and proposed a rating feature the client never mentioned. Five screens may look convincing, but they will not answer questions about users, calendars, payment, rescheduling rules, the cost of support, or how the result will be measured.

Asking about the budget is reasonable in itself; the problem is that it turned into haggling over price without any understanding of the work. A free mock-up can also push the client towards a premature decision and leave the studio with unpaid work. This does not mean every free conversation is wrong. The risk arises when complete expert work, the very thing the client came to hire specialists for, is done without payment.

Studio B: diagnosis, fit and limits

Client: "We need a mobile booking app. Can you send a mock-up quickly?"

Studio B: "We can work out what needs to be known before a mock-up. You mentioned the number of no-shows: tell me about the most recent time a consultation was missed. What happened before the meeting?"

Client: "The administrator phones people in the evening but doesn't always manage to. Some people change the time by email. We don't know who has already confirmed."

Studio B: "At an introductory meeting, could we see an anonymised example of the current process and discuss it with the administrator? Do you have totals for booked, cancelled and actually attended consultations over the same period?"

Client: "Yes, we can bring in the administrator. The data would need to be summarised."

Studio B: "Who will make bookings, who will change the schedule, and who approves spending? What budget range is already possible, even if there's no final figure yet?"

Client: "I'm the owner and I approve the budget. I don't have an agreed range until I understand whether a new app is needed."

Studio B: "Understood. In that case we won't propose full development right now. We can separately agree a short paid diagnostic: analyse the process, check the data and the alternatives, set out the risks and the decision. At the end you'll have a document you can use to move forward with us or to approach another supplier. We won't prepare full mock-ups or a specification as part of it."

Client: "I need to consult the administrators and understand the price."

Studio B: "Fine. Let's agree a short follow-up call after this conversation. If we lack access to the data or the people, we'll tell you exactly what we won't be able to establish; we won't present assumptions as an audit."

Decision. Studio B did not force the diagnostic on the client: it explained its result, price, timeframe, and the questions it will not resolve. The studio checked the fit between its experience and the request, the payer's role, access to people, and the unknown budget. A diagnostic should be useful in its own right and leave the client free to choose who does the next piece of work.

Result in the scenario. The client agrees to pay for a limited diagnostic after receiving its scope, cost, timeframe and list of deliverables. If it turns out that an off-the-shelf calendar covers the need, the recommendation may be to configure it rather than build something custom. If the client only wants free screens, the studio can politely decline; this protects the team's time and is not a punishment of the client.

Why, and when, this approach does not fit. If the client has already validated the scenario, has firm requirements, a known budget and a clear scope, a direct estimate may be appropriate. A separate stage is also unnecessary if it costs more than the risk of a small, reversible decision. The principle is not to add a paid diagnostic as a ritual, but to avoid taking responsibility for a complete solution without the necessary context and the client's agreement.

Connection to positioning. If the studio has repeatedly helped clinics coordinate bookings across locations and sees recurring causes of no-shows, that experience can become a genuine specialisation. It will be able to ask sharper questions and tell a scheduling problem from a messaging problem more quickly. But it should not claim that experience before it has earned it: the market's response has to show whether this distinction is truly valuable to buyers.

Next step: test the risk before spending

Discovery is not meant to produce a list of every possible feature. Its result is a well-founded choice about where to invest time and money next. Start with the hypotheses whose falsity would change the decision most:

1. Consequence of being wrong: if the assumption is false, how serious will the mistake be?
2. Uncertainty: how little do we know about it right now?
3. Cost of testing: how cheaply and safely can we gather information that would change the decision?

This is a qualitative judgement, not a formula for producing falsely precise scores. Test first the assumptions that could make the entire development unnecessary or dangerous. If people already get through booking well and the cause of no-shows is unclear, six months of building a calendar is not the first test. If two schedules frequently contradict each other, check access and synchronisation before choosing an architecture.

The options might be:

• Build: when the product difference matters, no purchase or integration can deliver it, and the team can maintain the result.
• Buy: when the need is standard and the cost, rules, confidentiality, supplier terms and ability to leave the service are acceptable.
• Integrate an existing service: when a new interaction between systems is needed and can be implemented safely without duplicating the whole product.
• Change the process: when a manual message, a new confirmation rule or clearer instructions will test the need faster and more cheaply than software.
• Don't build: when the problem is too rare, the benefit does not justify the cost, another team has already solved it, or the necessary conditions are not available.

Compare the full cost, not just the first invoice: licences, configuration, migration, support, training, contracts, supplier risk, data maintenance and future changes. Custom development gives more control but creates an obligation to maintain it. An off-the-shelf system speeds up the start but may come with limitations. A manual process is cheaper for a small test but may not withstand a large, sustained volume.

The MVP and the limits of the first version

A minimum viable product (MVP) is the smallest complete solution that helps a person do an important job and makes it possible to observe the result. It is not a set of cut-down screens, and it is not permission to launch an unreliable service. For booking, the first version must reliably show the confirmed time, avoid double bookings and explain how to reschedule.

Scope is the agreed extent of the first piece of work; non-goals are what will not be included or tested for now. Explicit limits stop a list of ideas from quietly becoming a promise for the first release.

An example scope for the booking scenario might include one type of consultation, one calendar, booking confirmation, rescheduling, and measuring the proportion of meetings attended. Out of scope might be a multi-location system, consultant ratings, a loyalty programme, a personal medical record and automated invoicing. This is not a universal template, nor a recommendation for a real medical service; every limit must be justified by context, law, risk and data.

An MVP is different from a prototype. A prototype can be disposable and unfit for real work; it tests an idea or usability. An MVP works with a real process, so requirements for quality, security, accessibility, support and data apply to it. At the same time, "minimum" means a limited scope, not minimal care for the person using it.

A real worked example: from an assumption to a different segment

thoughtbot describes its work with founder Paul Young on Tremor, an idea for product teams. The first hypothesis was that teams lack context, so they build features instead of solutions for the market. After segmentation, conversations and prototype testing, the first round disproved some of the assumptions and revealed a promising group that had not been chosen at the outset. The studio reports more than 30 interviews, a refined problem and a change of segment; its summary describes the idea as better positioned for attracting co-founders and investment. The thoughtbot case study.

The sequence of work. The first hypothesis linked the problem to a lack of context in product teams. The studio segmented potential customers, wrote down its assumptions about their needs, and researched how people already pass on context and requirements and where their usual tools fall short. Then it formulated the problem and a hypothesis, recruited participants, built a prototype and a test script. The first round disproved some of the assumptions and opened up a promising segment that had not been chosen initially; subsequent conversations focused on qualitative research without a new prototype. In the end, the studio reports more than 30 conversations with specialists, potential customers and people close to the problem, a changed problem statement, and a position described as "ready to look for co-founders and investment".

This is a report by the firm that did the work, not an independent evaluation: the full notes, the make-up of the sample and the financial data have not been published. It supports the claim that the hypothesis and the next step changed, but it does not prove that investment was raised, that Tremor became commercially successful, or that the method will produce the same result in another context. The example is useful precisely because the team revisited its initial segment instead of trying to confirm it at any cost.

AI in research: a helper for evidence, not its source

Artificial intelligence (AI) is the name for a group of computational methods that can generate text, classify material, find repetitions or answer questions. AI can help organise notes that have already been collected, find contradictions and suggest questions for the next conversation. The uses below are possible working hypotheses to test in the service you have chosen, not guaranteed features of every model or confirmed research results:

• grouping support requests, if you have permission to process them and the context is preserved;
• separating quotations from editorial paraphrase, provided every result is checked against the source;
• turning notes you have already collected into a list of themes for further comparison;
• finding contradictions between two summaries you provide;
• suggesting future questions that would help test assumptions.

You can ask a tool to summarise a document, compare two versions of it, or find passages on a topic, but the result has to be checked against the original. A quotation without a verified location in the record does not become testimony, and a convenient list of themes does not show how often they occur across the whole audience.

Before trusting such a process, try it on a small anonymised set: for each theme, ask for the exact passage and source file, ask it to flag contradictions, and to write explicitly "not found in the material" when there is no support. Check every passage against the primary note, and look at whether opposing cases and the voices of particular groups have disappeared. Based on the result, decide whether the tool reduces manual searching without losing context. Even a Research feature with web citations helps you find a source, but it does not transfer responsibility for the conclusion to the model.

OpenAI and Anthropic describe working with files and research features in specific products. Access depends on the plan and settings, and the documentation does not guarantee accuracy: a model that was not present at the interview can invent a fact, a quotation or a link. Check every generalisation against the original: OpenAI on uploading files and ChatGPT's accuracy; Anthropic on uploading files, Research and incorrect responses.

Give the model only material you are permitted to process in the chosen service. Do not paste names, contact details, medical, payment or other confidential data without permission. Keep the original notes, and distinguish the participant's words, the researcher's conclusion and the model's text. A person checks the generalisations and makes the decisions; the procedure for working with an AI-drafted product requirements document is set out in product requirements and UX foundations.

Worked example 3: ten invented testimonials

This entire example is illustrative. It does not describe real interviews or reviews.

Situation. The team has not yet spoken to any users. The client asks an AI to "generate ten convincing user testimonials" to show that consultations simply must be bookable online. The model produces ten plausible stories: people could not get through on the phone, missed a meeting, wanted to reschedule, or did not receive a reminder.

The mistake. If the team labels these passages "interview findings", it is inventing a method, participants and facts. The testimonials do not become evidence even when they read like true stories. They cannot be presented in a pitch, a specification or a demand estimate as the voice of the customer.

The honest course of action. The team removes all ten "testimonials" from the draft and labels them as synthetic scenarios generated by a model. They can be turned into untested questions: "What happens when you can't get through?", "When did you last reschedule a meeting, and how?" and "How did you find out that the booking was confirmed?" Then the team plans real conversations and observation, checks the available data, records consent and the source of every claim, and updates its conclusion.

A summary for the client, written by a person:

"The previous ten texts were generated by a model. They did not come from users and are not evidence of demand. We have removed them from the evidence section. At present, the need for online booking is not confirmed. The next step is to review recent booking cases with administrators and visitors and compare them with the available data. After that we will be able to propose what to test next."

This wording preserves trust, does not hide the mistake, and states precisely what is not yet known. If the invented testimonials have already been passed to the client or used in a budget decision, the correction must reach the same people and the same documents.

Handing over without losing uncertainty

The findings of discovery flow into a product requirements document (PRD). Its detailed structure is covered in product requirements and UX foundations; the document brings together decisions, expected behaviour and constraints so that the team can plan implementation, and it must not turn untested assumptions into statements of fact. In the handover after discovery it is worth preserving:

1. The decision and its reason: build, buy, integrate, change the process, research further, or stop; what data the decision rested on.
2. The desired outcome: who should be better off, which measure will change, what the baseline is, and how the change will be measured.
3. Users and roles: who uses, who pays, who administers, who approves, and whose interests also affect the system.
4. The problem and the journey: context, current methods, difficulties, consequences, exceptions and accessibility needs.
5. Evidence: links to sources, time frames, samples and observations; no invented quotations or figures.
6. Assumptions and unknowns: what still needs testing, why it matters, and which conclusion might change.
7. The four risks: value, usability, feasibility and viability; for each, the evidence available, the remaining question, the responsible expertise and the next test.
8. Limits: the first target group, scenarios in scope, exclusions, contracts, data, accessibility, security, external dependencies and budget limits.
9. The next step: its owner, the required result, the review date, and the condition for stopping or changing the plan.

For example: "Do not build a custom app for now. For one type of consultation, test the existing calendar and manual confirmation. We know that multiple channels make reconciliation harder, but we don't know whether this causes no-shows. Match the available data for an agreed period and observe how bookings are rescheduled. If the existing service confirms bookings without extra manual work and does not create a critical privacy risk, compare its cost with custom development; if the cause of no-shows is something else, revisit the hypothesis."

Discovery continues after release too: a change of supplier, of the clinic's processes or of the user base can change the risks and the original hypothesis.

In brief

Start from people's experience and the consequences, not from the name of a feature. Separate observations, participants' words, conclusions and assumptions; test each risk with the appropriate method and specialist. Agree the budget and limits of the diagnostic, then compare an off-the-shelf product, an integration, a process change and doing nothing with custom development. Hand the team the decision, the evidence, the unknowns and the conditions for review. A model's text is not a client's testimony.

Sources and further reading

Links were checked on 23 September 2026. Web pages and product features may change; each entry below states which claims it supports and where the limits of the conclusion lie.

• GOV.UK Service Manual: How the discovery phase works, published 4 August 2016, updated 21 June 2021; User research in discovery, published 18 November 2016; Using moderated usability testing, published 21 February 2017, updated 3 October 2017; also Usability testing: qualitative studies, published 30 January 2020. Accessed 23 September 2026. Used for restating a predetermined solution as a problem, research methods, the full user journey, neutral tasks and the limits of controlled testing. The guides were written for public digital services; their examples need adapting for a private studio.
• John Waterworth, "User research for government services: 8 strategies that worked for us", 21 January 2015; accessed 23 September 2026. A first-hand summary from a government services programme about involving researchers and the team throughout the life cycle. Not used as a universal rule about frequency for a private studio.
• Marty Cagan, The Four Big Risks, article dated 4 December 2017; accessed 23 September 2026. The author's explanation of the risks of value, usability, feasibility and business viability, and of the associated roles. The article refers to Inspired; the full text of the book was not read for this unit.
• Teresa Torres, Everyone Can Do Continuous Discovery—Even You! Here's How, the author's material on Continuous Discovery Habits, 2 August 2023; accessed 23 September 2026. Her definition of small, regular team activities in pursuit of an outcome is used as a methodological guideline, not a universal rule about frequency.
• Teresa Torres, Taking Continuous Discovery to the Next Level at SEEK, Product Talk, 10 April 2019; accessed 23 September 2026. The author describes a team she coached and its move from irregular discovery and roughly five or six interviews a quarter to weekly interviews and explicit testing of assumptions. This is a self-report by the consultant and the team, not a controlled study or evidence of a causal business effect.
• Christensen Institute, Jobs to Be Done Theory, the institute's current page; accessed 23 September 2026. Used to explain progress, circumstances, and the functional, social and emotional dimensions. In this unit JTBD is a lens for framing questions, not standalone evidence of a need.
• Blair Enns, The Win Without Pitching Manifesto, the book's official page, no publication date; accessed 23 September 2026. The published list of principles is used for diagnosis before recommendation, choosing clients, talking about money early, and the limits of free problem-solving. The full text of the book was not read; the scenario in this unit is an application with its own caveats, not a quotation.
• David C. Baker, The Business of Expertise, the author's description of the book, undated on the page; accessed 23 September 2026. Supports the author's thesis about repeated experience, pattern recognition and positioning. This is the author's own page, not an independent comparative study; the full text of the book was not read.
• Steve Krug, Don't Make Me Think, Revisited: A Common Sense Approach to Web (and Mobile) Usability, 3rd edition, New Riders, 2014, 212 pages; excerpt: the fourth chapter, accessed 23 September 2026. The chapter supports the explanation of ambiguous choices and unnecessary mental effort, but it is not the whole book. Also "You say 'potato,' I say 'focus group'", 22 March 2022, which distinguishes observing real use from discussing opinions or reactions to ideas.
• thoughtbot, Validating a market opportunity with product teams: Paul Young, no publication date shown on the page; accessed 23 September 2026. A first-hand account by the studio of segmentation, the change of hypothesis and segment, and more than 30 conversations. The company that did the work describes the result itself; the full notes, sample make-up and financial data are not given, so the case does not confirm investment or commercial success.
• OpenAI Help Center: Uploading files and audio to ChatGPT and Does ChatGPT tell the truth?, accessed 23 September 2026 and rechecked 10 October 2026; the files page redirects from an old URL to the current one. The files article gives examples of summarising, comparing documents and finding quotations that can be tried on permitted material; it also asks users to check important data against the original record. Availability depends on the product, plan, workspace and settings; example prompts do not guarantee an accurate result.
• Anthropic Help Center: Upload files to Claude, published 23 July 2026; Use research on Claude, published 2 June 2026; incorrect or misleading responses, published 16 March 2026; accessed 23 September 2026 and rechecked 10 October 2026. Used for the types of supported files and the limits of their analysis, Research with internal context and the web when search is enabled, and the warning to check important claims. A citation in an answer does not guarantee that the source supports the conclusion; the pages also do not guarantee that an analysis is complete or correct.