Our 4-Week Discovery Process: From Idea to Build-Ready Brief

A healthcare startup came to us with a well-articulated idea: a platform to connect patients with specialist doctors across Egypt through video consultation and smart triage. They had a pitch deck, a market sizing slide, and a strong sense of the problem. When we started asking what the first version needed to do — and for whom specifically — the conversation shifted significantly. Did "triage" mean a questionnaire, an AI symptom checker, or a nurse on call? Were the doctors employed or independent? Were they salaried or paid per consultation? Who handled malpractice liability?

None of these questions had clear answers. And every answer changed the product substantially.

This is why discovery exists: not to slow things down, but to make sure the team is building the right thing before the meter is running on engineering time.

What discovery is not

Discovery is not a research report that sits in a folder. It is not a requirements document listing every feature someone mentioned in an interview. It is not a design sprint with a prototype.

Discovery is a four-week process that ends with a build-ready brief: a document the engineering team can open on Monday morning and begin working from with confidence. That means the scope is decided, the first release is defined, the risks are named, and the open questions are either resolved or explicitly deferred with a plan for resolution.

Week 1: Understand the business

The first week is not about features. It is about understanding what the product needs to change in the world — specifically, what success looks like in the first six months, who the paying customers are, and what the business constraints are.

Questions we ask in every discovery:

• What does the product replace or improve on? What do users do today without it?
• Who is the primary user versus the buyer? Are they the same person?
• What would make the first release valuable enough that early customers would pay for it?
• What are the hard constraints: regulatory, budget, timeline, team?
• What has already been tried or built? What failed and why?

This step often reveals that the scope should be narrower than the original idea — and that narrower is actually better for the first release. The healthcare startup above needed to pick one: the doctor side or the patient side. A platform that works well for one group and adequately for the other is stronger than one that works mediocrely for both.

Week 2: Map workflows and surface risks

The second week goes into the operational detail of how the product actually works for real people in real conditions.

We map user journeys across roles — in a clinic product, that means the receptionist, the doctor, the patient, the billing team. We look for:

• Edge cases in core flows: what happens when a doctor cancels last-minute? What if a patient books the wrong slot? What if a payment fails mid-flow?
• Third-party dependencies: payment providers, insurance systems, SMS/WhatsApp APIs, existing ERP or accounting software, lab systems.
• Compliance surfaces: what data is collected, how it is stored, and what local regulations apply (data residency, health record retention, invoice requirements).
• Manual processes that need to become digital: the spreadsheet the admin currently uses, the WhatsApp group where orders are confirmed, the paper form patients fill out at reception.

Each risk gets a status: resolved (we know how to handle it), mitigated (we have a plan that reduces the risk), or deferred (we are not building for this in V1, and here is what that means).

Week 3: Shape the first release

By week three, we have enough to make decisions. This is where we turn research into scope.

The principle is: the first release should be as small as possible while still being genuinely valuable. Not an MVP in the "minimum viable for investors to see" sense — an MVP in the "minimum valuable for the first real customers" sense.

We define:

• Must-have for V1: the features without which the product cannot be used by the target user to accomplish the core job.
• Nice-to-have / V2: features that improve the product but are not blockers for the first paying customers.
• Not now / out of scope: features that are good ideas but would double the build time with marginal benefit to V1 users.

The "not now" list is as important as the V1 list. A discovery that ends with a scope that has grown beyond the original idea has failed. A discovery that clearly names what is not being built — and why — has done its job.

We also estimate complexity honestly in this week. Not hours, not story points — rough T-shirt sizes that surface the features that will dominate the build. A feature that is "large" in complexity but "nice-to-have" in value gets deferred. A feature that is "large" but "must-have" gets broken down into smaller deliverable pieces.

Week 4: Write the brief and plan the build

The final week produces the deliverables: the build-ready brief and the delivery plan.

The brief includes:

• Product summary: what the product does and who it is for, in two paragraphs.
• V1 scope: features with acceptance criteria written in plain language, not technical specifications.
• Architecture decisions: technology choices, third-party services, deployment environment, any significant technical tradeoffs made during discovery.
• Open questions log: unresolved questions, who owns the resolution, and by when.
• Risk register: named risks with their status (resolved, mitigated, deferred).

The delivery plan sets the team structure, sprint cadence, milestone checkpoints, and launch criteria. It is not a Gantt chart. It is an agreement on how the team will work and what "done" means at each stage.

For the healthcare startup: discovery ended with a decision to build the doctor-side product first — onboarding, schedule management, consultation tooling — and make the patient-facing booking flow a V2 feature. The video consultation feature was deferred entirely until V2. The first release was smaller than anyone expected at the start of the four weeks, and it shipped on time.

Discovery works when it converts ambition into decisions: who the product serves, what the first release includes, which risks matter, and what is explicitly not being built. The four weeks are not overhead — they are the cheapest engineering time you will spend on the project.

For what happens after the build ships, see The Real Cost of Skipping Post-Launch Support.