DEV Community: Oleksandr Tytarenko

How Long Does a Discovery Phase Take? Typical Timelines

Oleksandr Tytarenko — Mon, 02 Nov 2026 08:14:47 +0000

A software discovery phase usually takes 1-3 weeks for a small MVP, 3-6 weeks for a typical product with a few integrations, and 6 weeks or more for integration-heavy or regulated systems. The size of the product matters less than you might think. What usually decides the length is how quickly stakeholders are available, how much is unknown about the existing systems, and how many people have to agree. Here is how to read those ranges, what stretches them and a week-by-week plan for a four-week discovery.

Typical durations by project size

Published guides agree on the broad shape, though each one defines discovery slightly differently. The UK government's service manual says there is no set length, but that around 4 to 8 weeks is typical for its public-service discoveries, which include a lot of user research. Agency guides for commercial software quote shorter ranges: one describes discovery as typically three to six weeks, compressing to a couple of weeks for a simple product with a clear owner; another gives about three weeks for small projects and up to two months or more for large ones.

Put together, a reasonable planning range looks like this. Treat it as a rule of thumb, not a quote:

Project type	Typical duration	Assumptions
Small MVP, one user type, no or simple integrations	1-3 weeks	One decision maker, available weekly; existing material to start from
Typical product: several user types, 2-4 integrations	3-6 weeks	A handful of stakeholders; integrations documented
Complex or regulated: many integrations, legacy systems, compliance	6-12 weeks	Many stakeholders; systems need investigation; legal or security review
Public service with heavy user research	4-8 weeks or more	Research with real users is the main work

The ranges overlap because the deliverables differ. A discovery that produces requirements and a rough estimate is shorter than one that also produces wireframes, an architecture and a prototype. When you compare two offers, compare their lists of deliverables before you compare their week counts.

What stretches a discovery

The same product can take three weeks with one client and six with another. The usual reasons:

Stakeholder availability. If the decision maker can meet once every two weeks, every decision takes two weeks. This is the most common reason a discovery runs long.
Disagreement. Two departments that want different things will not settle it in a workshop. Discovery brings the disagreement to the surface; settling it takes as long as the organisation needs.
Unknown systems. A legacy system with no documentation, an API nobody has tried, data whose quality nobody knows. Someone has to look, and access alone can take a week to arrange.
Approvals outside the team. Security reviews, legal checks on data, procurement questions.
Starting from nothing. Teams that start with decks, notes, past research and call recordings move faster than teams that start from a one-line idea.
Scope that keeps growing. If every workshop adds a new module, the discovery is turning into product design. Agree on the boundary in week one.

Most of these are calendar problems, not effort problems. A discovery that needs 15 days of work can easily take six calendar weeks if the people needed are hard to reach.

What can run in parallel

You can shorten the calendar by not running everything in sequence:

Access requests and system investigation can start on day one, before the workshops. Request repository, environment and API access in the kick-off email.
Stakeholder interviews can run alongside reading the existing material.
Architecture exploration can start as soon as the main flows are known; it does not need final requirements.
Drafting the documents can start in week one. Write the background and problem statement from what you already have, and correct them as you learn.

What cannot run in parallel: settling priorities before the requirements exist, and estimating before the architecture and main integrations are understood. Those two set the minimum length of any discovery.

A week-by-week outline for a 4-week discovery

This plan fits a typical product with a few integrations and a client who can meet twice a week. It follows the ten sections of the discovery phase template.

Week	Focus	Outputs by the end of the week
1	Context and people	Stakeholder list with who decides; background; first draft of the problem statement; access requested; open-questions log started
2	Goals and users	Goals with metrics; users, main journeys and key flows; first list of requirements
3	Requirements and architecture	Requirements with priorities and acceptance criteria for the Musts; context diagram; integrations checked; key decisions recorded
4	Plan and sign-off	Milestones with low-high estimates and assumptions; risks and open questions with owners; executive summary; review with the decision maker

Keep a short review at the end of each week with the decision maker. It catches wrong turns early and stops week four from becoming a week of rewrites.

To compress this to two weeks for a small MVP, merge weeks 1 and 2 and weeks 3 and 4, and drop anything the first release does not need. To stretch it for a complex system, the extra time usually goes into week 3: integrations, data and decisions.

Tools can shorten the writing, though not the meetings. Discovery Phase AI drafts the background, problem statement, goals, users and requirements from the files you upload (decks, documents, call transcripts, images) and gives each stage an AI quality score with suggestions. That cuts the time spent turning notes into documents. It does not replace the conversations in which stakeholders agree.

Signs you are done

A discovery is done when its outputs can support a decision, not when the calendar runs out. The GOV.UK manual frames it the same way: you have finished when you can decide whether to move on, and stopping is not a failure if the research shows that is the right call.

Practical signs:

The decision maker has read the executive summary and agrees with it.
The scope of the first release is agreed in writing, including what is out.
Every Must requirement has acceptance criteria and traces to a goal.
The estimate is a range with its assumptions written down.
Open questions and risks each have an owner and a date.
The next step is clear: build, run a smaller pilot, or stop.

These match the sign-off section of the discovery phase checklist:

If the calendar is up and these are not true, you have two honest options. Extend the discovery for a stated reason and a stated number of days, or close it with the gaps written down as open questions and risks that the first phase of the build will have to resolve. For the bigger picture of what discovery is for, see the discovery phase in software development.

Disclosure and a sample

I build Discovery Phase AI, a tool aimed at the writing-and-assembling side of discovery: it drafts the early stages from the decks, documents and call transcripts you already have, and exports one report. Your team still runs the interviews, reviews every draft and makes the decisions.

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Fixed Price vs Time and Materials for Software Projects

Oleksandr Tytarenko — Sun, 01 Nov 2026 08:08:34 +0000

Fixed price suits work whose scope is clear enough to write down and test: the vendor carries the risk of overrunning and charges for it. Time and materials (T&M) suits work whose scope will change as you learn: the client pays for the hours actually spent and keeps the right to steer. Since most software projects begin unclear and get clearer, a common approach is to fix the price of a discovery and a well-defined first phase, then move to T&M once the product is live and changing.

This article is practical guidance, not legal advice. Have a lawyer review any contract you sign.

The two models in one table

	Fixed price	Time and materials
What is agreed	A scope, a price and usually a date	Rates, a team and a way of working, often with a budget cap
Who carries the overrun risk	Mainly the vendor, up to the agreed scope	Mainly the client
How change is handled	Change requests, each priced and approved	Re-prioritise the backlog; the cost follows the hours
What the client must provide	A clear scope up front and quick sign-off	Ongoing time from a product owner who makes decisions
Price includes	The work plus a risk margin	The work as it happens
Works best when	Scope is defined and testable	Scope is uncertain or expected to change
Typical failure	Disputes over what was "in scope"	Budget drift without visible progress

The table hides one important point: a fixed price does not remove risk, it prices it. A vendor quoting a fixed price on a vague scope will either add a large margin or lose money and try to make it back through change requests. Both are worse for the client than an honest range.

When fixed price works

Fixed price works when someone could hand the scope to a different team and get roughly the same thing built. In practice that means:

Requirements are written and testable, with acceptance criteria for every Must.
The integrations are known: the APIs exist, are documented, and someone has checked them.
The assumptions are listed, so both sides know what the price relies on.
The client can review and accept work quickly. A fixed price with slow sign-off becomes a delay dispute instead of a scope dispute.

US federal acquisition rules offer a useful reference point here, even outside government work. They steer firm-fixed-price contracts toward work that can be bought on "reasonably definite functional or detailed specifications", and they allow time-and-materials only when the extent or duration of the work cannot be estimated with reasonable confidence at the start (FAR Part 16). Commercial software contracts are not bound by these rules. The logic still carries over: price firmly what you can specify, and pay for time where you cannot.

Good fixed-price candidates: a discovery phase itself (time-boxed, with defined deliverables), a clickable prototype, a migration with a known source and target, or a first release whose scope came out of a proper discovery.

When time and materials works

T&M works when the job is to find the right product as much as to build it:

The product is new, and user feedback will change the backlog.
Integration or data quality is unknown until someone looks inside the systems.
The work is ongoing: improvements, maintenance, a product team after launch.
The client has a product owner who can prioritise every week.

The risk with T&M is not price. It is drift. Without a goal per sprint or milestone, a cap and visible output, hours pile up and nobody can say what they bought. Typical safeguards:

A not-to-exceed budget per phase or per month, with a warning at 75-80% of it.
Milestones with low-high estimates, so the client can see whether spend matches progress.
Regular demos of working software, not status reports.
A right to stop at the end of each phase, with the work done so far handed over.

The federal rules make the same point: T&M orders there need a ceiling price, and contracting officers are told to avoid protracted use of T&M once experience gives a basis for firmer pricing (FAR Part 16). In other words, T&M is meant to be a phase, not a permanent state.

The hybrid after a discovery phase

The discovery phase is what makes a fixed price possible. Before it, scope is a wish list. After it, you have requirements with priorities, an architecture, a roadmap with estimated milestones and a list of assumptions. That is enough to fix the price of a first phase, but rarely enough to fix everything.

A common structure:

Phase	Model	Why
Discovery	Fixed price, time-boxed	Deliverables are known in advance; the client gets a plan whether or not they go ahead
Phase 1 (first release)	Fixed price, or T&M with a cap	Scope comes straight from discovery; assumptions are written into the contract
Later phases	T&M with a monthly budget	The product is live, feedback changes priorities, and fixing the scope would mean pricing guesses

Two details decide whether the hybrid holds:

The assumptions travel into the contract. If phase 1 is priced on "the client's API returns stock levels in real time", say so, and say what happens if it does not.
The estimate is a range, and the fixed price sits inside it on purpose. Discovery gives you a low-high range per milestone. Where the price sits in that range, and why, should be visible to both sides.

Here is what that input looks like in the Discovery Phase AI example report, made for an invented project called Fieldwise: four milestones, each with a person-week range, a 16-22 person-week total, and the assumptions that range depends on.

Risks for each side

Risk	Fixed price	Time and materials
For the client	Paying a risk margin; arguing over what "in scope" meant; a vendor cutting corners to protect margin	Open-ended cost; paying for the vendor's learning; slow progress if the product owner is unavailable
For the vendor	Absorbing overruns; scope creep through vague requirements; slow client sign-off eating into margin	Being cut off at short notice; budget caps used as fixed prices in disguise; disputes over productivity
Shared	A bad scope document makes both models fail, just differently

A cap on a T&M contract is often treated as a fixed price in all but name, while the vendor still carries no obligation to finish. Be clear which one you mean. A cap is a stop-and-review point, not a promise of delivery.

How to choose

Ask four questions, in order:

Could you write acceptance criteria for every Must today? If not, the scope is not ready for a fixed price. Run or finish a discovery first.
Are the integrations and data known? If a key system has not been looked at, either fix the price of everything except that part or treat it as T&M until it is understood.
Who will make decisions every week? T&M without an available product owner is the most expensive option on this list.
Is the product expected to change after launch? If yes, plan for T&M after the first release whatever you choose for it.

As a rule of thumb, not a formula: if you answered "yes, yes, someone named, no" you can fix the price. Two or more "no" or "not sure" answers point to T&M with a cap, or to a fixed-price discovery that turns those answers into "yes".

A discovery that produces requirements with acceptance criteria, an estimated roadmap and a written list of assumptions is what makes either model safe. The discovery phase checklist lists what to have before you sign, and the discovery phase in software development explains what that phase produces.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Non-Functional Requirements Examples for Software Projects

Oleksandr Tytarenko — Sat, 31 Oct 2026 08:08:34 +0000

A non-functional requirement (NFR) says how well a system must do its job: how fast, how available, how secure, how accessible, how long it keeps data. A good one has a number and a way to test it, such as "search results appear within 1 second for 95% of requests". Below are measurable examples by category, the question that gets each one out of a client, and how NFRs change the estimate.

Why NFRs get missed

Functional requirements are easy to collect because people describe what they do: "I need to approve an invoice." Nobody walks into a workshop and says "I need the approval page to respond within 800 milliseconds at the 95th percentile." Quality expectations stay unspoken until they are broken.

Three patterns cause most of the misses:

They are assumed. The client thinks "obviously it is secure and always up". The team thinks "normal hosting, normal security". Both are right in their own heads and wrong about each other.
They are vague. "Fast", "scalable" and "user-friendly" are written down, but nobody can test them, so they do not shape the design or the price.
Nobody owns them. A feature has a user who asks for it. Availability or data retention belongs to operations, legal or IT, who are often not in the discovery sessions.

The ISO/IEC 25010 quality model (2023 edition) splits product quality into nine characteristics, including performance efficiency, compatibility, reliability and security. You do not need the full model, but it is a useful list to check against so that a whole category is not skipped.

Categories and measurable examples

Each example below has a number, a condition and something a tester can measure. Treat the figures as illustrations; the right values come from the client's needs and budget.

Category	Measurable example	How it is tested
Performance (response time)	The order search returns results within 1 s for 95% of requests, with 200 users active at once	Load test at the stated concurrency
Performance (web pages)	Public pages reach a Largest Contentful Paint of 2.5 s or less for 75% of visits	Field data from real users
Capacity	The system handles 50,000 orders a month and 3 years of history without the search target above being missed	Load test on a seeded database
Availability	The customer portal is available 99.9% of each calendar month, excluding announced maintenance	Uptime monitoring
Recovery	After an outage, service is restored within 4 hours (RTO) with no more than 15 minutes of data lost (RPO)	Restore drill from backups
Security (access)	Every page except sign-in requires an authenticated session; staff accounts use multi-factor sign-in	Access test per role
Security (verification)	The application meets the OWASP ASVS Level 2 requirements before go-live	Security review against the checklist
Accessibility	Public and customer pages meet WCAG 2.2 Level AA	Audit with assistive technology
Data retention	Support messages are deleted 24 months after the last reply; audit logs are kept 7 years	Scheduled job and a test record
Privacy (location)	Personal data is stored and processed only in the EU	Hosting and vendor review
Compatibility	The staff app works on the latest two versions of the main desktop browsers	Browser test matrix
Maintainability	A new team member can run the system locally from the written setup guide in under one day	Onboarding trial

A few sources for the numbers:

The 2.5-second LCP figure is Google's "good" threshold for Core Web Vitals, measured at the 75th percentile of page loads.
OWASP ASVS is a free, public checklist of security requirements in three levels; naming a level turns "secure" into something testable.
WCAG 2.2 is the W3C accessibility standard; Level AA is the level most commonly asked for.
Availability percentages translate into allowed downtime. Over a 30-day month, 99.9% allows about 43 minutes of downtime, 99.95% about 22 minutes and 99.99% about 4 minutes.

Retention periods are the client's decision, often driven by law or a contract. Under the GDPR, personal data should be kept no longer than necessary (Article 5(1)(e)), so a retention NFR usually needs a specific period per type of data, not "forever".

Questions to ask the client

Clients rarely answer "what is your availability target?" with a number. Ask about consequences instead, and turn the answer into a figure yourself:

Performance: "Which screen do people use most, and what happens if it takes five seconds?" "How many people use it at the busiest hour of the busiest day?"
Availability: "If the system were down for an hour on a Tuesday morning, what would it cost you? And at 2 a.m. on a Sunday?"
Recovery: "If we lost the last hour of data, could you re-enter it? The last day?"
Security: "Who must never see this data? Has anyone asked you for a security questionnaire or penetration test?"
Accessibility: "Is this used by the public or by employees? Are you bound by an accessibility law or a buyer's policy?"
Data retention: "How long do you have to keep records, and is there anything you must delete after a while?"
Location and vendors: "Do your contracts or regulators say where data may be stored?"
Growth: "How many users or records do you expect in a year? In three?"

When the answer is "I don't know", write the NFR with a proposed value and mark it for confirmation. A proposed number that someone corrects is far more useful than a blank.

Where NFRs go in the document

Put NFRs in the same requirements list as functional ones, not in an appendix at the back. Give each one:

An ID and a short title, like any other requirement
The type non-functional, so it can be filtered
A priority (Must, Should, Could, Won't)
One or more acceptance criteria with the number and the test
The goal or constraint it serves, where there is one

In the example report for Fieldwise, an invented field-service project, "Work without coverage" is a non-functional Must sitting in the same list as the functional requirements, and "Data stays in the EU" is a constraint:

Keep constraints separate from NFRs. A constraint is a limit the team cannot change: a mandated cloud provider, a regulation, a fixed budget or deadline. An NFR is a quality target the team designs for. Mixing the two hides which items are negotiable.

The discovery phase template uses exactly this split (functional, non-functional, constraint), and the discovery phase checklist asks whether performance, security, availability, accessibility and compliance needs are named:

In Discovery Phase AI, a requirement carries one of these three types, and its AI score rates whether it is clear and testable, which tends to flag an NFR that has no number.

How NFRs change the estimate

NFRs often move the estimate more than an extra feature does, because they apply to everything. Rules of thumb, not measured figures:

Each extra "nine" of availability costs more than the last. Going from 99.9% to 99.99% usually means redundant infrastructure across zones, automated failover and someone on call, which changes both build and running costs.
Tight recovery targets need tested backups and drills, not just a backup setting.
A named security level adds work everywhere: input validation, logging, session handling, reviews. Asking for ASVS Level 2 late in a project means rework.
Accessibility is cheap when designed in and expensive when retrofitted. Agree the level before screens are designed.
Data volume and retention shape the database design, archiving and search. Three years of history is a different system from three months.
Location rules limit vendor choice, which can rule out a service the estimate assumed.

That is why NFRs belong in discovery and not in the first sprint. List them with numbers, mark the ones still to confirm, and state in the estimate which NFR values it assumes. If a client later raises a target, the change and its cost are then visible instead of being an argument.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

How to Define MVP Scope: Cut Down to What You Can Prove

Oleksandr Tytarenko — Fri, 30 Oct 2026 08:08:48 +0000

To define MVP scope, start from the one business question the first release must answer, then keep only the features without which you cannot answer it. Everything else goes on an "out" or "later" list, written down and agreed. The result is a short set of requirements you can estimate and build in weeks, not a smaller copy of the full product.

What an MVP is for

Eric Ries, who made the term popular, defined the minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The key word is learning. An MVP is an experiment with a product attached.

That changes how you scope it. A feature belongs in the MVP if the experiment fails without it. A feature that would make the product nicer, more complete or easier to sell belongs later, however good the idea is.

Two common misreadings to avoid:

"Minimum" does not mean low quality. The parts you build should work properly. Users who hit bugs teach you about the bugs, not about the product.
"Viable" does not mean complete. It means a real user can get real value from it, in a narrow case, without your team stepping in.

Start from the question, not the feature list

Most MVP scoping goes wrong because it starts with the full feature list and tries to shrink it. Start instead with one sentence:

We believe [user] will [do something] because [reason]. We will know we are right when [measurable signal] within [time].

Examples:

"We believe field technicians will close visits on a phone instead of paper, because it saves them the evening paperwork. We will know when 70% of visits in the pilot regions are closed in the app within six weeks."
"We believe small clinics will book a paid onboarding call after a free trial, because setup is the main hurdle. We will know when 1 in 10 trial sign-ups books one within a month."

The numbers in these examples are illustrations. Pick your own threshold before launch, so the result cannot be argued afterwards.

This sentence comes straight out of discovery: the problem statement says who is affected and why, and the goals give you the metric. If you cannot write it, the MVP is not ready to scope. You still need the discovery work, which the discovery phase in software development covers.

Cut-down questions for every feature

Take each candidate feature and ask these questions in order. Stop at the first one that removes it from the MVP.

Does the business question fail without it? If the experiment still works, it is not MVP scope.
Can a person do it by hand for now? Manual onboarding, a spreadsheet report, an admin who approves accounts by email. If a human can cover it for the first hundred users, do not build it yet.
Can an existing tool do it? Payments, email, sign-in and analytics rarely need to be built for an MVP.
Can it be narrower? One user type instead of three, one region, one language, one payment method, one platform.
Is it a constraint you cannot negotiate? Legal, security and data-location requirements stay in, however small the MVP. "Data stays in the EU" is not optional just because it is a first release.
What does it cost compared with what it teaches? A feature that takes a third of the budget and tests a side question should wait.

Question 5 is the one most often skipped. A non-functional requirement such as working offline, or a constraint such as where data is stored, can be the most expensive line in the MVP and still be required.

In, out and later

Write the result as three lists and get them agreed. The "out" and "later" lists matter as much as the "in" list, because they are what stop scope from creeping back.

List	Meaning	Example (field-service app)
In	Needed to answer the business question	Day list of visits; close a visit with notes and photos; works without coverage; data stored in the EU
Later	Valuable, planned after the MVP result	Decline a visit with a reason; dispatcher alerts; third region
Out	Not planned, with the reason	Customer-facing app (no evidence customers want it); built-in invoicing (the existing system does it)

If you use MoSCoW priorities, "in" is roughly your Musts, "later" your Shoulds and Coulds, and "out" your Won'ts for this release. DSDM guidance, where MoSCoW comes from, is often summarised as keeping Musts to no more than about 60% of the effort, so there is room to drop Shoulds and Coulds if the schedule slips. In an MVP the Musts are usually closer to the whole release, which is exactly why the list has to be short.

This is what that looks like in the requirements of the Discovery Phase AI example report, made for an invented field-service project called Fieldwise. Most rows are Musts, one is a Should, and the EU data rule appears as a Constraint rather than a feature:

Turning the MVP into requirements and an estimate

The three lists are a decision. To build from them, turn each "in" item into a requirement a developer can test:

A short title and one sentence: "A technician records work done, parts used, photos and a customer confirmation, then closes the visit."
Type: functional, non-functional or constraint.
Priority: Must for everything on the "in" list. If something on it feels like a Should, it probably belongs on "later".
Acceptance criteria: how you will know it works. "A visit closed offline appears on the dispatcher's board within one minute of coverage returning."
The goal it serves: every requirement should trace to the business question. One that does not is a sign that scope crept back in.

Then estimate in ranges, not single numbers, with the assumptions written next to them: team size, which integrations exist, what you are handling manually. If the range is larger than the budget, go back to the cut-down questions, not to the estimate. Squeezing the estimate is the slow way to cut scope; cutting a feature is the fast one.

Finally, write the date or signal at which the MVP will be judged and what happens next for each outcome: build the "later" list, change direction, or stop. That decision is what the MVP is for.

The discovery phase template has the requirements and roadmap sections in a form you can copy. The discovery phase checklist has the questions to check them against before the build starts.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

MoSCoW Prioritization: A Practical Guide With Examples

Oleksandr Tytarenko — Thu, 29 Oct 2026 08:14:13 +0000

MoSCoW sorts every requirement into one of four buckets: Must have, Should have, Could have and Won't have (this time). It works when the buckets mean something: Musts are few enough to deliver with confidence, each Must has a test, and the Won't list is written down. This guide covers the definitions, two rules that keep the method honest, a worked example and the usual mistakes.

The four buckets

MoSCoW comes from DSDM, an agile delivery framework now maintained by the Agile Business Consortium. The lower-case o's are only there to make the word pronounceable. The consortium's guidance defines the buckets roughly like this:

Bucket	Meaning	The test
Must have	Without it the release fails: unsafe, illegal, unusable or pointless	"If this is missing, do we cancel the launch?" If yes, it is a Must
Should have	Important, but there is a workaround, even a painful one	"Can we go live with a manual fix or a delay?"
Could have	Valuable, nice to have, first to drop when time runs short	"Would anyone notice at launch if it were missing?"
Won't have (this time)	Agreed to be out of this release or timeframe	"Have we said out loud that we are not doing this now?"

Two details matter more than they look:

The buckets apply to a timeframe, usually a release or an MVP. A Won't today can be a Must in the next release.
Should is not "Must, but softer". A Should has a workaround the business can live with for a while. If nobody can name the workaround, it is a Must.

Rules that keep Must have defensible

Left alone, almost everything drifts into Must. Two rules stop that.

Rule 1: cap the Musts

The Agile Business Consortium recommends that Must haves take no more than about 60% of the total effort, with Could haves around 20% as contingency. The cap is on effort, not on the number of items: ten small Musts can cost less than one large Should.

The reason is arithmetic. Estimates are wrong in both directions, and if 90% of the planned work is Must, there is nothing to drop when something takes longer. With 60% Must and 20% Could, the team can lose all the Coulds and still ship every Must on time.

If the Musts add up to more than the cap, you have three honest options: move some to Should, cut the scope of a Must (a simpler first version), or extend the timeframe. Pretending the cap does not apply is not one of them.

Rule 2: every Must has acceptance criteria

A Must without acceptance criteria cannot be finished, because nobody can say when it is done. Write one or more checks a tester can pass or fail:

Weak: "Users can book appointments."
Strong: "A patient can book a free slot for a chosen therapist in at most three steps; the slot disappears for other patients within 5 seconds; the patient receives a confirmation email."

If the room cannot agree on criteria for a Must, it is not understood well enough to be a Must yet. Record it as an open question with an owner.

A worked example

An invented project: a small physiotherapy clinic wants an online booking MVP within three months. Phone calls take up the receptionist's mornings, and missed appointments cost revenue. The table shows how the requirements might be sorted.

Requirement	Bucket	Why	Rough effort (person-days)
Patient books a free slot with a chosen therapist	Must	The whole point of the MVP	8
Clinic staff block and unblock time in the calendar	Must	Without it, slots are wrong from day one	4
Confirmation email after booking	Must	Patients need proof; the clinic needs fewer calls	2
Patient data stored in line with health-data rules	Must	Legal requirement, not a choice	5
Reminder email 24 hours before	Should	Cuts no-shows; the receptionist can call for now	2
Patient cancels or moves a booking online	Should	Workaround: phone the clinic	4
Waiting list for fully booked days	Could	Useful, but rare at current volume	4
Patient uploads a referral letter	Could	Can be brought in on paper	3
Online payment at booking	Won't (this time)	Needs a payment provider decision first	—
Mobile app	Won't (this time)	A responsive website covers the need	—

Total planned effort is 32 person-days, of which the Musts are 19, about 59%. The Coulds are 7, about 22%. That fits the guideline. If the referral upload turned out to be legally required, it would move up to Must, and something else would have to move down or the deadline would move.

The same structure works in a real discovery document. The example report, built for an invented field-service project called Fieldwise, shows each requirement with its type, MoSCoW priority and review status:

The second page holds the Should and Could items, such as equipment history and photo attachments:

How Won't have prevents scope creep

Most scope creep is not a new idea. It is an old idea nobody formally ruled out, coming back as "I thought that was included". A written Won't list closes that door:

It records a decision, not an omission. "Online payment: Won't (this time), pending a payment provider decision" shows the topic was discussed and parked.
It gives a polite answer. When a stakeholder asks for it mid-build, the reply is "It is on the agreed Won't list for this release; shall we raise a change request?", not a debate.
It feeds the next release. The Won't list is the first draft of the next backlog.
It protects the estimate. An estimate is only valid for a scope. Listing what is out shows exactly what the number does not cover.

Put the Won't items in the same list as everything else, with the same IDs, rather than in a separate document. In the Fieldwise example above, routing suggestions are marked Could with the note "deferred to a later release after the pilot". Marking it Won't would say the same thing more clearly, which is a typical small fix a review catches.

Common mistakes

Everything is a Must. If more than about 60% of the effort is Must, the bucket has stopped meaning anything. Apply the cancel-the-launch test to each one.
Prioritising without estimates. The cap is about effort. Sorting before you have even a rough size per item means the 60% check cannot be done.
No Won't list. An empty Won't bucket usually means the conversation about what is out has not happened.
Should used as a parking lot. Items nobody wants to argue about pile up in Should. Each Should needs a named workaround.
One person sorts alone. MoSCoW is a negotiation between the people who pay, use and build. Sort with the decision maker in the room.
Buckets set once and never revisited. Re-sort at each release, and whenever a Must turns out larger than estimated.
Constraints treated as priorities. A regulation or a mandated platform is not a choice the team can trade off. List it as a constraint (it is effectively always in scope) and spend the MoSCoW discussion on what can actually move.

A final check before sign-off: the discovery phase checklist asks whether every Must has acceptance criteria, whether each requirement links to a goal, and whether priorities stay under about 60% Musts. If you can answer yes to all three, your MoSCoW list is ready to estimate against.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

PRD vs BRD vs SRS: Which Requirements Document Do You Need?

Oleksandr Tytarenko — Wed, 28 Oct 2026 08:09:53 +0000

A BRD (business requirements document) explains why a project exists and what the business needs from it. A PRD (product requirements document) describes what the product does for its users. An SRS (software requirements specification) states, precisely enough to build and test against, how the system must behave. Most small projects need the content of all three but not three separate files.

The three documents in one table

The names are used loosely, and two companies can mean slightly different things by "PRD". The table shows the most common reading of each.

	BRD	PRD	SRS
Question it answers	Why are we doing this, and what must the business get?	What will the product do, for whom?	Exactly how must the system behave?
Main readers	Sponsor, budget holder, steering group	Product, design, engineering leads	Developers, testers, integrators, sometimes auditors
Usually written by	Business analyst or sponsor	Product manager	Business or systems analyst, tech lead
Typical content	Problem, goals, success metrics, scope, constraints, stakeholders	Users, journeys, features, priorities, release scope	Functional and non-functional requirements, interfaces, data, acceptance criteria
Typical length (rule of thumb)	3-10 pages	5-20 pages	15-60+ pages
Changes how often	Rarely, once approved	Every release or so	With every change request
When a small team can skip it	When the sponsor and the product owner are the same person	When the SRS is short and user-centred	When the PRD already has testable requirements

The lengths are a rule of thumb from typical projects, not a standard. A regulated system can need a far longer SRS; a two-month internal tool might fit all three into twelve pages.

Of the three, only the SRS has a formal standard behind it. ISO/IEC/IEEE 29148 (current edition 2018, which replaced IEEE 830) describes the content of a software requirements specification, and also of a business requirements specification (BRS) and a stakeholder requirements specification. The PRD comes from product-management practice and has no single agreed format.

BRD: why the project exists

The BRD is the document a budget holder reads before saying yes. It should be readable by someone who will never open the code, and it should hold up if the project is challenged six months later.

What goes in it:

The problem, in business terms: who is affected, what goes wrong, what it costs.
Goals with numbers: a metric, today's value, a target and a date. "Cut manual order entry from 6 hours to 1 hour a day by Q3" works; "improve efficiency" does not.
Scope: what is in, and just as important, what is out.
Stakeholders: who approves, who is consulted, who can block.
Constraints: budget, deadline, regulation, systems that must stay.

What stays out: screens, feature lists and technology choices. If the BRD names a database, it has drifted into the SRS.

Here is what the goals part can look like in practice, taken from the example report for Fieldwise, an invented field-service project: each goal has its success metrics and a target date, and the KPIs show today's value, the trend and the target.

PRD: what the product does

The PRD turns the business case into a product. Its reader is the team that will design and plan the build, so it is organised around users rather than around the business.

A useful PRD covers:

The users and actors, with what each is trying to achieve.
The journeys they take and where they get stuck today.
The features or user stories, each with a priority (MoSCoW is common: Must, Should, Could, Won't).
The release scope: what ships first and what waits.
Open questions and the person who answers each.

A PRD is a living document. It is fine for it to change between releases, as long as the change is visible and the BRD's goals still hold.

SRS: how the system must behave

The SRS is the contract between "what we want" and "what we test". Each line in it should be something a tester can pass or fail. The 29148 standard lists quality criteria for a requirement such as being necessary, unambiguous, feasible and verifiable.

A typical SRS holds:

Functional requirements: what the system does in response to input ("When an order total is over the customer's credit limit, the system blocks submission and shows the limit").
Non-functional requirements: performance, security, availability, accessibility, data retention, each with a number.
Constraints: limits the team cannot change, such as a mandated platform, a regulation or a hosting region.
Interfaces and data: integrations, formats, who owns which data.
Acceptance criteria for each requirement.

The SRS gets long because precision is wordy. That is acceptable; vagueness is not.

In the same Fieldwise example, the requirements list keeps the three types side by side, each with an ID, a priority and a review status (the acceptance criteria open under each row):

Which one to write first

Write them in the order the decisions are made: business case, then product, then system.

BRD first. Without agreed goals and scope, every later argument about a feature has no referee.
PRD second. Once the goals are fixed, decide who the product serves and what it must let them do.
SRS last, and often in slices: detail the requirements for the first release, and leave later ones at PRD level until they are next.

In practice the three overlap. Interviews for the BRD surface features; writing acceptance criteria reveals a missing goal. Expect to go back and edit, but keep the direction: an SRS line that serves no goal in the BRD is either missing a goal or should not be there.

In a client project, all three usually come out of the discovery phase, the paid stretch before the build where the team settles what to build and what it will take.

What a small team can merge

For a team of two to ten people, three separate documents with three owners is usually overhead. A single requirements document with clearly marked parts carries the same information:

Part 1, business (the BRD content): problem, goals with metrics, scope in and out, stakeholders, constraints. Two or three pages.
Part 2, users and scope (the PRD content): users, journeys, prioritised features, first release.
Part 3, requirements (the SRS content): numbered requirements, each with a type (functional, non-functional, constraint), a priority, acceptance criteria and the goal it serves.

The discovery phase template follows roughly this shape, from stakeholders and problem statement through requirements and roadmap. Discovery Phase AI keeps the same structure as separate project stages: each requirement carries a type, a MoSCoW priority, acceptance criteria and an optional link to a goal, and the whole set exports as one report (you can see one for an invented project on the example report).

What you should not merge away:

The "why" section. Teams that skip the BRD content end up debating features with nothing to judge them against.
Acceptance criteria. Without them the requirements part is a wish list, and the estimate built on it is a guess.
The out-of-scope list. It costs a paragraph and prevents weeks of argument later.

Keep separate documents when the audiences really are separate: an outside sponsor who must approve the business case, a regulator who will audit the SRS, or a vendor contract that refers to a specification by name. Otherwise, one well-structured document read by everyone beats three documents that half the team never opens.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Open Questions and Assumptions Log: Keep Unknowns Visible

Oleksandr Tytarenko — Tue, 27 Oct 2026 08:06:34 +0000

An open-questions log lists what you do not know yet, with a named owner and a due date for each item. An assumptions list records what the plan treats as true without proof, and which part of the estimate depends on it. Keep both from the first discovery call, review them every week, and close or carry forward every item before sign-off. Most scope arguments later in a project start with an unknown that nobody wrote down.

Why unknowns cause disputes

During discovery everyone hears the same unknowns: "We think the legacy system has an export." "Legal still has to confirm whether we can store this data." "Marketing may want a second language." People say these things on calls, everyone nods, and the conversation moves on.

Three months later the build team finds the legacy system has no export. The client remembers the plan as covering the integration. The vendor remembers it as resting on an assumption. Neither can show a written record, so the gap turns into a debate about the contract rather than a planned change.

Writing unknowns down does not make them go away. It changes who is surprised. A logged assumption that turns out false is a known risk with an agreed next step. An unlogged one is a dispute.

Project management practice treats this as a standard document: an assumptions log started at project initiation, with each entry's date, impact and owner, kept up to date as the project runs (a short guide to project assumptions). You do not need a heavy process for it. You need a list that people actually read.

The open-questions log

Keep it to three required columns, plus a few optional ones:

Question	Owner	Due	Blocks
Does the payment provider support partial refunds?	Client finance lead	14 Nov	Refund flow (REQ-12)
Who approves copy changes on the checkout page?	Client marketing	7 Nov	Nothing yet
Can we use the existing customer database for log-in?	Client IT	10 Nov	Architecture decision on sign-in

Rules that keep it useful:

One question per row, phrased so it can be answered with a fact or a decision. "What about payments?" is not a question; "Which payment provider do we integrate with?" is.
The owner is a person, not a team. "Client IT" is fine as a label as long as one person there has agreed to answer.
A due date, even a rough one. A question with no date stays open forever.
"Blocks" says what waits for the answer. This is what lets you rank the list.
The answer is written into the row. Then the row is closed. Do not delete it, because the record of what was decided and when is the point.

Review the log at the end of every discovery workshop and in a short weekly check. New questions come up all the time; what matters is that they land in the log the same day.

The assumptions list and how it ties to the estimate

An assumption is different from a question. A question is something you will get an answer to. An assumption is something you decide to treat as true so the plan can go on, usually because checking it would take longer than discovery has.

Each assumption should say three things: what you assume, what in the plan depends on it, and what changes if it is wrong.

"The client's product API returns stock levels in real time. Depends: milestone M2 (catalogue). If wrong: add a nightly sync job, roughly 3-5 person-weeks."
"Two backend and one frontend developer from week 1. Depends: every milestone date. If wrong: dates move proportionally."
"No content migration from the old site. Depends: M4 (launch). If wrong: migration becomes its own milestone, to be estimated."
"No holiday freeze in December. Depends: the release date."

The "if wrong" part is what makes an estimate honest. A range of 30-40 person-weeks is only a range under those assumptions. When an estimate goes to a client or into a contract, the assumptions list should go with it. If you price the work as fixed, the assumptions mark where the price stops.

Some assumptions are really constraints: limits the team cannot change, such as a regulation, a fixed platform or a budget cap. Keep them in the same list but label them, because a constraint is not something you test. It is something you design around.

In Discovery Phase AI, the roadmap stage keeps assumptions as one-line entries beside the milestones and their low-high person-week estimates, so they appear in the same place as the numbers they qualify. A spreadsheet tab beside the estimate does the same job if you keep it current.

Blockers: the unknowns that stop work

Some open questions are urgent. They stop a milestone or a decision from going ahead. Track them as a separate type so they cannot hide in a long list:

Type	What it means	Example	How fast it needs attention
Open question	Something not yet known	Who approves checkout copy?	By its due date
Risk	Something that may go wrong	The vendor's API may be rate-limited	Watch, plan a response
Blocker	Something that stops work now	No test account for the payment provider	Escalate this week

A blocker needs an owner with the power to remove it, which is often someone more senior than the person who raised it. If a blocker sits for more than a week, the delivery plan is already wrong, and the people who own the plan should hear it from you first.

Discovery Phase AI keeps blockers, risks and open questions as one typed list per project. Each item is either Active or Resolved and can point at the stage it came from. You can also create an item by selecting a sentence in a stage, such as a requirement that depends on an unconfirmed fact. Here is that list in the example report, made for an invented project called Fieldwise:

Closing items before sign-off

Before the client signs off on discovery, go through both lists item by item. Every entry ends in one of three states:

Answered or confirmed. The answer is written in, and anything it changed (a requirement, an estimate, a decision) has been updated.
Accepted as a known unknown. The client and the team agree it stays open into the build. It needs an owner, a date and a note in the scope or estimate saying what happens if the answer goes the wrong way.
Dropped. It no longer matters because scope changed. Say so in the row.

Nothing stays open just because nobody looked at it. Discovery Phase AI enforces this at the project level: a project cannot be marked done while any blocker, risk or open question is still active. Even without a tool, a simple rule works: sign-off happens only when every row has a state.

The discovery phase checklist asks about both lists in its estimates section:

For where these lists fit among the other discovery outputs, see the discovery phase in software development.

Hand both lists to the build team with the rest of the discovery document. To them, the open items are the most useful part: they show where the plan is still soft.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Discovery Handoff: What the Build Team Needs on Day One

Oleksandr Tytarenko — Mon, 26 Oct 2026 08:01:12 +0000

A good discovery handoff gives the build team five things: the agreed scope and priorities, the decisions with the reasons behind them, the open questions and assumptions, the access they need, and one named person who owns changes. Put it all in one document and walk through it in a single meeting. Do not count on the team piecing it together from slides, call recordings and chat threads. Below is the checklist, a 60-minute meeting plan and the rules for what happens after.

Why handoffs lose information

The people who ran the discovery know far more than they wrote down. They remember why a feature was cut, which stakeholder pushed back, and which number in the estimate was a guess. The build team gets the document, not the memory. Information usually goes missing in four places:

The reasons. A requirement or architecture choice arrives without the reason for it, so the team either follows it blindly or quietly changes it.
The unknowns. Open questions were discussed on calls but never logged, so nobody knows they are still open.
The estimate. The number travels and its assumptions do not. A range of 30-40 person-weeks that assumed an existing API turns into a promise once that API proves not to exist.
The people. The developers do not know who on the client side can answer a question, or who has the final say.

Often the same company runs discovery and delivery, just with different people. The handoff problem is the same, because the people who carry the context are not the ones who build.

What the build team must receive

Use this as the checklist for the handoff package. If an item is missing, write down that it is missing. Do not let it look complete.

Item	What "done" looks like	Usual owner
Scope and priorities	Every requirement has a priority (for example Must, Should, Could, Won't) and the first release is agreed in writing	Product owner or PM
Requirements	Each Must is testable and has acceptance criteria	Business analyst
Users and flows	Main journeys and key processes drawn and reviewed	Designer or analyst
Architecture	A context diagram, the integrations, and decision records	Solution architect
Estimate and roadmap	Milestones with low-high ranges and the assumptions behind them	Delivery lead
Open questions and risks	Each with an owner and a due date	PM
Access	Repositories, environments, test accounts, API keys requested through the proper channel, design files	Client IT and PM
People	Who answers which kind of question, who approves changes, how fast	PM

The discovery phase checklist has the questions to ask before you call each of these finished. If you need a refresher on what discovery is meant to produce, see the discovery phase in software development.

Two of these items deserve their own section, because they are the ones most often missing.

Decisions and the reasons behind them

Every significant choice made during discovery should arrive as a short record: the question, the options considered, what was chosen, and what that choice means for the work. This is the architecture decision record (ADR) format Michael Nygard described in 2011. His argument still holds: someone who joins later and does not know why a decision was made can only accept it blindly or reverse it blindly, and both are expensive.

For a handoff, a decision record needs:

Title and number, so it can be cited ("ADR-4: Use the client's existing identity provider").
Context: the constraint or pressure behind the choice (a contract, a deadline, a team skill, a cost).
Options compared, including the ones rejected and why.
Decision in one or two sentences.
Consequences: what it makes easier, what it makes harder, what it rules out.
Status: proposed or accepted. A decision still at "proposed" is really an open question and belongs on the next list too.

Here is how that looks in the Discovery Phase AI example report, built for an invented field-service project called Fieldwise. Each decision has a number, a status and the number of options compared, and links to the requirements it covers. ADR-003 is still proposed, so it goes to the build team as an open item.

Do not limit this to technical decisions. Scope decisions matter just as much: "Offline mode is out of release one because the client's field staff always have coverage" will save an argument three months later.

Open questions and assumptions

No discovery closes every question. What matters is that the open ones are visible, owned and dated. Give the build team two lists:

Open questions: what is not known yet, who will answer, by when, and what work is blocked until then. "Does the payment provider support partial refunds? Owner: client finance lead. Due: sprint 2. Blocks: refund flow."
Assumptions: what the plan treats as true without proof. Tie each one to the estimate or milestone it affects. "The client's product API returns stock levels in real time. If not, add 3-5 person-weeks for a sync job."

Mark the blockers separately: questions that stop a milestone from starting. The team should see them on the first day, not on the day the blocked work begins.

In the Fieldwise example, the assumptions sit right under the milestones and their person-week ranges. The first one, that IT will expose two missing API endpoints, is exactly the kind of assumption a build team needs to check in week one.

Discovery Phase AI keeps risks, blockers and open questions as one list on each project, and the project cannot be marked done while any of them is still active. That is one way to make sure nothing is closed quietly. Whatever tool you use, the rule is the same: an unknown that is not written down will be treated as a known.

The handover meeting

One meeting, 60 minutes, with the people who ran discovery, the build team leads and the client's product owner. Send the package two days before and ask everyone to read it. Use the meeting for questions, not for reading slides aloud.

Minutes	Topic	Who leads
0-5	The goal of the project and the business question release one must answer	Product owner
5-15	Scope: what is in release one, what is out, what is later	PM
15-30	Architecture and key decisions, including the rejected options	Architect
30-40	Estimate, milestones and the assumptions they depend on	Delivery lead
40-50	Open questions, blockers and risks: confirm each owner and date	PM
50-55	Access and environments: what is ready, what is still requested	PM and client IT
55-60	How changes will be raised and approved from now on	Product owner

Record two outputs. The first is a list of new questions the build team raised, added to the open-questions log with owners. The second is a short note confirming that the build team accepts the package as the starting point, or naming what it does not accept yet. That note is the real end of discovery.

After the handoff: who owns changes

The discovery document becomes the baseline. From then on it should change only on purpose:

One owner for scope and priorities, usually the client's product owner. The build team can propose changes; that owner approves them.
Changes are recorded, not overwritten. When a decision is reversed, add a new decision record that supersedes the old one. When an assumption proves false, update the estimate it was tied to and say so.
Open questions close with an answer, written into the item itself, not into a chat thread.
The discovery team stays reachable for a set period (the first two or three sprints is common practice) to answer "why" questions.

If you produce the discovery in Discovery Phase AI, the report exports as PDF, Word, PowerPoint or Markdown (Markdown only on the Free plan), so the build team can take the baseline into their own tools. The whole Fieldwise report is in the example report.

A handoff is finished when the build team can start without calling the discovery team on the first day. They will still call later, and those calls should be about details, not about what was decided.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

How to Estimate a Software Project: Give a Range

Oleksandr Tytarenko — Sun, 25 Oct 2026 08:01:02 +0000

To estimate a software project, split the work into milestones, give each one a low, a likely and a high figure in person-weeks, write down the assumptions those figures rest on, and add a contingency with a stated rule for using it. The client gets a range they can budget against and a list of what would move it. This article walks through each step with an example table you can copy.

Why one number misleads

A single figure such as "26 weeks" sounds precise, but it hides how much is still unknown. Two people can agree on it while one hears "at most" and the other hears "about". When the project lands at 31 weeks, the conversation is about broken promises rather than about which assumption changed.

Estimation research explains why a range is more honest. Steve McConnell's "cone of uncertainty", based on Barry Boehm's work, describes estimates made at the initial-concept stage as being off by up to 4x in either direction, narrowing as requirements, design and decisions are settled (Construx). McConnell presents those bounds as close to the best case a skilled estimator can reach at each point, not the worst. A finished discovery phase puts you further along the cone than a first sales call, but not at the end of it.

So the job is not to make the uncertainty disappear. It is to show it, explain where it comes from, and say how it will shrink.

Break the work into milestones

Estimate milestones, not the project as a whole. A milestone is a result someone can see ("Technicians can complete a visit offline"), linked to the requirements it delivers. Splitting the work this way:

Exposes the hard parts. An integration estimated on its own gets a wide range; buried in a project total, it disappears.
Lets ranges differ. The first milestone, which the team understands best, can have a tight range while later ones stay wider.
Makes trade-offs concrete. If the client wants a lower total, they can see which milestone or requirement to cut.

A rule of thumb: milestones of two to six weeks of effort are easy to estimate and to track. One milestone holding half the project is a sign it needs splitting. Every Must-have requirement should be linked to some milestone; anything unlinked is either out of scope or missing from the estimate.

The screenshot above is from our example report, built for an invented project called Fieldwise: each milestone carries a low–high estimate, the total is shown as a range, and the assumptions sit right below the table.

Low, likely and high per milestone

For each milestone, ask the people who will do the work for three figures in person-weeks:

Low: if the assumptions hold and nothing surprising turns up.
Likely: what they would bet on.
High: if the known risks happen, but not a catastrophe.

If you want one planning figure per milestone, the PERT formula weights the likely case: (low + 4 × likely + high) / 6 (three-point estimation). Use it for planning, but show the client the range.

An example for an invented field-service app, three developers and a designer:

Milestone	Low (pw)	Likely (pw)	High (pw)	PERT (pw)	Main uncertainty
M1 Foundation and sign-in	4	5	6	5.0	Low: well-known work
M2 Offline technician app	7	8	11	8.3	Sync conflicts on poor connections
M3 Dispatch system integration	4	6	10	6.3	Partner API not yet documented
M4 Supervisor dashboard	3	3.5	5	3.7	Report formats not agreed
M5 Pilot and fixes	2	3	5	3.2	Number of pilot defects
Total	20	25.5	37	26.5

Report the total as "20 to 37 person-weeks, most likely around 26". Sum the lows and the highs separately; do not average the range away. Note that the whole project is unlikely to hit every high at once, so the true spread is somewhat narrower than the simple sum; for a client-facing estimate the simple sum is easier to explain and errs on the safe side.

Person-weeks are effort, not calendar time. Turning them into dates needs the team size, how much of their time is on this project, holidays, and how much of the work can run in parallel.

Write the assumptions and exclusions

The range is only as good as the list of things it assumes. Write them as short, checkable sentences next to the estimate:

Team: "Three developers and one designer, full time from 3 November."
Third parties: "The dispatch API exposes the two missing endpoints by the end of month one."
Client input: "Feedback on each milestone demo within three working days."
Scope limits: "Two regions in the first release; the third later."
Technical: "Photos up to 5 MB, at most six per visit."

Then list the exclusions: things a reader might expect but that are not in the figures, such as data migration from the old system, translations, app store submission, or ongoing hosting. An exclusion written down is a scope decision; one left unsaid is a future dispute.

Each assumption is also a trigger. If it turns out false, the estimate is reopened, and both sides already agreed that it would be.

The discovery phase checklist uses the same test for this part of discovery: estimates as ranges, with the assumptions behind them, and each risk with an owner.

Add a contingency and say how it is used

Even a good range does not cover everything. A contingency is a separate, named amount for the unknowns nobody listed. Three things make it work:

Keep it separate. Do not hide it inside the milestone figures, or nobody can tell estimate from buffer.
Size it to the risk. There is no universal percentage. A common rule of thumb is to size it from the risk list: the wider the ranges on the riskiest milestones and the more external dependencies, the larger the reserve. Say what you based it on.
Agree the rule for spending it. For example: the delivery lead may draw on it for work inside the agreed scope, reports each use at the next review, and any new feature is a change request, not contingency.

A contingency the client can see and track builds trust. One they discover later looks like padding.

Revisit the estimate at set points

An estimate made once and defended forever stops being true. Agree in advance when it will be revised:

After the first milestone. The team's real pace is now known. Compare actual effort with the estimate and adjust the later ranges.
When an assumption breaks. The partner API is late, the team changes, the scope grows.
At each change request. Every addition gets its own low–high figure before it is accepted.

At each revision, the ranges for the remaining milestones should narrow. If they widen, that is information too: something important was unknown and is now visible.

For the wider picture of how estimates fit into discovery outputs, the overview of the discovery phase in software development lists the other deliverables. In Discovery Phase AI, the roadmap stage stores each milestone's estimate as a low and a high number of person-weeks, adds them up into a total range, and keeps the assumptions in a list next to the milestones.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Software Project Roadmap Template: Milestones and Estimates

Oleksandr Tytarenko — Sat, 24 Oct 2026 08:01:01 +0000

A software project roadmap at the end of discovery is a table of milestones, each with a start date, a target date, an effort range, the milestone it depends on and the requirements it delivers, plus a short list of the assumptions behind it. It answers "what gets built in what order, and roughly how long will it take". Below is the table to copy, how to find the critical path, and a filled-in example with a month-scale timeline.

Discovery roadmap vs product roadmap

The word "roadmap" covers two different documents, and mixing them up causes trouble.

	Discovery (delivery) roadmap	Product roadmap
Question it answers	How and when do we build this agreed scope?	Where is the product heading over the next year or more?
Unit	Milestones with dates and effort	Themes, outcomes, bets
Time horizon	Weeks to a few months	Quarters to years
Tied to	Specific requirements	Goals and strategy
Audience	Sponsor, delivery team, budget holder	Leadership, customers, the wider company
Changes when	Scope, team or a dependency changes	Strategy or the market changes

A discovery roadmap is concrete on purpose. Each milestone should be traceable to requirements, so that when someone asks "why is this taking ten weeks?" the answer is a list of things, not a feeling. It is closer to a delivery plan than to a vision deck. If the project later becomes a long-lived product, a product roadmap can sit above it; the discovery roadmap covers the first release or two.

The milestone table

Use one row per milestone. Seven columns are enough:

Column	What goes in it	Rule of thumb
ID	M1, M2, M3…	Never reuse an ID, even if a milestone is removed
Name	What exists when it is done ("Offline inspection forms")	A result, not an activity ("Development")
Start	Calendar date	Real dates, not "week 3", so holidays show up
Target	Calendar date	Not before the start
Estimate	Low–high in person-weeks	A range; see below
Depends on	The milestone that must finish first	One is usually enough; more means the split is wrong
Requirements	IDs of the requirements it delivers	Every Must requirement appears somewhere

Add a status column (Not started, On track, At risk, Done) once the build starts, and keep a separate list of assumptions next to the table: team size, the date a vendor delivers an API key, a holiday freeze, who tests. Assumptions are what the dates rest on, so they belong on the same page.

Two checks catch most gaps in a draft:

Coverage. Count the requirements linked to at least one milestone against all requirements. Anything unlinked is either out of scope (say so) or missing from the plan.
Size. If one milestone holds most of the effort, split it. Milestones in the range of two to six weeks are easier to track than one of five months; that is a rule of thumb, not a standard.

The roadmap section of our discovery phase template sums up the same contents in four lines:

Dependencies and the critical path

A dependency says one milestone cannot start until another is done. The chain of dependent milestones with the longest total duration is the critical path: any delay on it delays the release, while a delay elsewhere may not. The idea comes from the critical path method, used in project scheduling since the 1950s.

To find it on a small roadmap:

Write each milestone's dependency.
Follow each chain from the first milestone to the release.
Add up the durations along each chain. The longest is the critical path.

Watch for two warning signs. A milestone that starts before the one it depends on ends is either a mistake or a sign the dependency is partial and should be split. A cycle (M3 depends on M4, which depends on M3) means the work is not really sequenced at all. In software projects, the critical path very often runs through integrations and data migration, because they depend on people outside the team.

Estimates as ranges

Put a low and a high figure on every milestone, in person-weeks, and add them up for the total. A single number at this stage hides how much is still unknown. Steve McConnell's "cone of uncertainty" describes estimate error that narrows as a project's decisions get made (Construx); at the end of discovery the range is narrower than at the first conversation, but it is still a range.

Practical habits:

Tighter near, looser far. The first milestone, which the team understands best, can have a narrow range; later ones wider.
Effort is not duration. Six person-weeks with three people may be two calendar weeks, or four if they are also on other work. Dates come from effort plus staffing plus the assumptions.
Sum the lows and the highs separately. Report the total as "34–46 person-weeks", not as the midpoint.

A filled-in example (invented)

An invented project: a mobile inspection app for a utilities company, with requirements numbered REQ-1 to REQ-24. Team assumption: three developers and one designer, with a two-week holiday freeze in late December.

ID	Name	Start	Target	Estimate (person-weeks)	Depends on	Requirements
M1	Sign-in, roles and device setup	Nov 3	Nov 28	6–8	—	REQ-1, REQ-2, REQ-3
M2	Offline inspection forms	Dec 1	Jan 30	14–20	M1	REQ-4 to REQ-12
M3	Billing system integration	Jan 5	Feb 27	8–12	M1	REQ-13 to REQ-17
M4	Reports and supervisor dashboard	Feb 2	Mar 13	6–9	M2	REQ-18 to REQ-22
M5	Pilot and hardening	Mar 16	Apr 10	4–6	M3, M4	REQ-23, REQ-24

Total: 38–55 person-weeks, target release April 10. M5 waits for two milestones here, which breaks the "one dependency" rule of thumb on purpose: the pilot needs both the integration and the reports. On a real plan you might split M5 so each part has a single predecessor.

The same plan on a month scale (each column is half a month):

            Nov     Dec     Jan     Feb     Mar     Apr
M1          ##
M2              ####    ##
M3                      ####
M4                          ##  ##
M5                                  ##  ##
                                            ^ release Apr 10

The critical path is M1, M2, M4, M5: the forms are the longest chain, and the holiday freeze sits inside M2. The billing integration (M3) has some slack, unless the billing system owner is slow to provide test access, which goes on the assumptions list.

Keeping the roadmap honest

A roadmap stays useful only if it is updated when the facts change:

Change a status by hand when the team knows, not when a date passes. "At risk" two weeks before a target is information; "late" afterwards is history.
Re-check the dependencies when scope changes. A new requirement linked to M2 moves everything on the critical path.
Review the assumptions at each milestone. If the team is two developers, not three, the dates move, and that is a decision to make openly.
Keep the link to requirements. When a requirement is dropped, remove it from its milestone and reduce the estimate, so the plan shrinks with the scope.

Here is how a finished roadmap reads in our example report, made for an invented project called Fieldwise: the total estimate as a range, the release date, a month-scale timeline, the milestone table with status and linked requirement counts, and the assumptions underneath.

In Discovery Phase AI, the roadmap stage holds the same fields: milestones with an ID, dates, a low–high person-week estimate, status, one dependency and linked requirements, a month-scale timeline, and a list of assumptions.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Client Documents in AI Tools: A Checklist for Agencies

Oleksandr Tytarenko — Fri, 23 Oct 2026 08:01:01 +0000

You can put client documents into an AI tool, but only after you know where the text goes, how long it is kept, whether it trains a model, who else processes it, and what your contract with the client allows. Those five answers differ a lot between a personal chat account and a business product built on a commercial API. The checklist below works for any vendor, and the last section shows how Discovery Phase AI answers it.

This is a practical checklist, not legal advice. Your client contract and your own counsel decide what is allowed.

What actually leaves your machine

Before comparing vendors, picture the path a document takes when you upload it:

Your browser sends the file to the tool's servers.
The tool may store it: the original file, extracted text, or only what it generates from it.
The tool sends text to a model provider, which is often a different company from the one whose app you use.
The model provider may keep inputs and outputs for a period, for abuse monitoring or debugging.
The result comes back and is saved in the tool, in your project, or nowhere.

Each hop is a place where a copy can live and a party that can read it. A good vendor can tell you, for every hop, whether a copy exists, for how long, and in which country. If the answer is "we are not sure", that is your answer.

It also matters what the documents hold. Discovery material is often more sensitive than it looks: names and contact details of client staff, unreleased plans, pricing, security details of existing systems. Some of that is personal data under laws such as the GDPR, which brings its own rules.

Questions to ask any AI vendor

Use this as a checklist. A vendor should answer each in writing, ideally on a public page.

Area	Question	A good answer sounds like
Storage	Are uploaded files stored? Where and for how long?	"Not stored", or a stated period and region
Training	Is my content used to train models, theirs or the provider's?	"No, by default", with the source for the provider's terms
Model provider	Which model provider processes the text?	A named company, not "trusted partners"
Provider retention	How long does the provider keep inputs and outputs?	A number of days, with exceptions listed
Sub-processors	Who else handles data (hosting, email, payments)?	A named list with what each receives
Location	Where are servers and the database?	A country or region
Access	Who inside the vendor can see my content?	A short, specific answer
Isolation	How is one customer's data kept from another's?	Server-side checks, not just the interface
Deletion	Can I delete projects and my account, and what happens to the data?	A self-service path with clear effects
Export	Can I get my content out in a usable format?	Named formats
Contracts	Can I sign a data processing agreement?	Yes, with how to request it
Assurance	What independent audits or certifications exist?	A specific report, or an honest "none yet"

The last row deserves honesty both ways. An audit report tells you a third party checked controls; a vendor without one is not automatically unsafe, but you should weigh their written answers more carefully and expect them to be specific.

Retention and training use

These are the two questions clients ask most, and they are often confused.

Training use means your text becomes material that improves a model, which other customers then use. For confidential work you want a clear "no" by default. Policies differ by product tier at the same provider. For example, OpenAI's help centre says it does not train on inputs or outputs from its business products and API by default, while personal ChatGPT accounts have an "Improve the model for everyone" setting that is on unless the user turns it off (OpenAI data controls FAQ). Pasting a client deck into a personal chat account is therefore a different decision from using a business product.

Retention means how long a copy exists, even if it never trains anything. A provider may keep API inputs and outputs for a short period. Anthropic, for instance, states that it deletes API inputs and outputs on its backend within 30 days by default, with exceptions such as a different agreement, enforcing its usage policy, or legal requirements (Anthropic privacy centre). Check the current page on the day you decide; these terms change.

Then ask the same questions of the app on top: does it keep the original files, and does it log the text of your prompts?

Contracts: DPA and sub-processors

If the documents include personal data and you or your client are subject to the GDPR, the AI vendor usually acts as a processor for that data, and Article 28 of the GDPR requires a written contract with it, commonly called a data processing agreement (DPA). It also requires the processor to get your authorisation before using sub-processors and to pass the same obligations down to them.

In practice, check three things:

Your client contract. Many service agreements restrict which third parties may see client material, or require notice before you use a new one. An AI tool and its model provider both count.
The vendor's DPA. It should name the sub-processors, the data location, and how international transfers are covered (for example Standard Contractual Clauses).
The sub-processor list. Hosting, model provider, email and payments are typical. Each should be named, with what it receives.

Controls inside your own team

Most leaks are not caused by a vendor. Set a few rules for your own people:

Use business accounts, not personal ones, for any client work, so the terms above actually apply.
Give access by project, not by company. A contractor on one client should not see another client's files.
Upload only what the task needs. A redacted transcript is often enough; strip bank details and passwords from anything you upload.
Keep a record of who changed what, so an AI-generated edit can be traced and reversed.
Tell the client. A line in the proposal saying which AI tools you use, and on what terms, prevents an awkward conversation later.
Plan the end. Know how you will export the deliverables and delete the workspace when the engagement ends.

How Discovery Phase AI answers these

These answers are taken from our security page and Privacy Policy, which describe what the product does today:

Files: uploaded decks, documents, transcripts and images are read in memory to draft the project and are not stored. Only the draft you review and save stays, as project content.
Model provider and training: AI requests go to Anthropic. We do not use your content to train models, and under Anthropic's commercial API terms it does not train on inputs and outputs by default.
AI behaviour: the model has no tools, cannot browse or change your project, and every suggestion is a proposal you apply or discard. Text from files is marked as untrusted, so instructions hidden in a document are not followed.
Sub-processors and location: Fly.io hosts the app and database in the United States (Virginia), Anthropic processes AI requests, Resend sends email and Paddle handles payments.
Isolation and access: each company is its own workspace, scoped on the server. Company Admins see every project; Company Members see only projects they are added to, with write or read access. On the Agency plan each client company stays separate.
History: every change to a stage is recorded with who made it and whether it came from a person, the AI chat or an update from files, and earlier versions can be restored.
Retention, export and deletion: AI usage records keep the feature, model and token counts, never the text, for 13 months. Project content exports as PDF, Word, PowerPoint or Markdown, and you can delete your account yourself.
Contracts: the Privacy Policy says that for project content we act as your processor, and that an organisation that needs a data processing agreement can request one by email.
Assurance: we do not claim a security certification or an independent audit. The route-by-route review described on the security page was our own.

Plan details, including which features each plan has, are on the pricing page.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.

Do You Need a Discovery Phase? When to Skip It

Oleksandr Tytarenko — Thu, 22 Oct 2026 08:01:23 +0000

You need a discovery phase when the scope, the users or the technical risks are unclear enough that a fixed estimate would be a guess. You can skip it, or shrink it to a few days, when the problem is familiar, one person decides, and the work looks like something the team has built before. Five questions below sort most projects into one of those two groups.

The short answer

Discovery buys certainty before you spend the build budget. It is worth paying for when the cost of being wrong is larger than the cost of finding out. That is true more often than buyers expect, and less often than some sellers claim.

Estimation research gives a sense of the stakes. Steve McConnell's "cone of uncertainty", built on Barry Boehm's earlier work, puts the error of an estimate made at the initial-concept stage at roughly 0.25x to 4x of the real figure, and describes that as close to the best case, not the worst (Construx). The range narrows only as decisions get made and written down. Discovery is the deliberate, paid version of that narrowing.

The UK government's service manual, which treats discovery as a standard first step for public services, puts a typical discovery at 4 to 8 weeks and notes that a team that already knows the problem well may need less (GOV.UK service manual). Private software projects often run shorter. For a fuller picture of what the phase produces, see discovery phase in software development.

Five questions that decide it

Answer each one honestly. Every "yes" is a reason to run discovery; three or more usually mean a full one.

Question	A "yes" looks like	Why it matters
1. Is the scope unclear?	The brief is a paragraph, a deck or a list of features without priorities	Without an agreed scope, any estimate is a price for a guess
2. Is the domain new to the team?	Regulated industry, unfamiliar workflows, jargon you had to look up	Hidden rules surface late and expensively
3. Are there many stakeholders?	Several departments, a sponsor who is not the day-to-day owner, outside partners	Conflicting needs have to be settled before building, not during
4. Is the budget or date fixed?	A grant, a board-approved figure, a launch tied to an event	A fixed envelope needs a scope that provably fits inside it
5. Are there integrations or data migrations?	An existing CRM, ERP, payment provider, legacy database	Integrations hide most of the technical risk

A few notes on reading the answers:

Question 4 cuts both ways. A fixed budget is a reason to run discovery, not to skip it to save money. The point is to find out what fits inside the number.
Question 5 is the one most often underrated. "We just need to connect to their system" can mean an afternoon or a quarter, depending on whether the other system has a usable interface and an owner who answers emails.
The answers come from evidence, not optimism. If you are not sure whether the scope is clear, ask two stakeholders to describe the first release separately and compare.

When to skip or shrink the discovery

There are honest cases where a full discovery is overhead:

A known pattern. A marketing site, a content update, a feature similar to three the team shipped last year on the same codebase.
One decision maker and a written spec. Someone who can answer questions within a day, plus requirements that already exist and are current.
A throwaway prototype. If the goal is to learn by building something small and discarding it, the prototype is the discovery.
A small, time-boxed budget. When the whole build is a few weeks of work, a multi-week discovery is out of proportion; a short brief and a working first slice teach more.
Continuing work. The next phase of a product the same team built, with the same people deciding.

In each case the risk does not vanish; it is just small enough to absorb in the build. Write down the assumptions anyway, so that when one turns out wrong it is a recorded change, not an argument.

What a 'light' discovery looks like

When the answer is "some discovery, not much", compress it to a few days instead of weeks. A light version that still holds up:

Read what exists first. Collect the brief, decks, emails and any old specs, and summarize them in a page.
Run two to four interviews. The decision maker, one or two users, and whoever owns the riskiest integration.
Write the one-page brief. Problem, goals with a measure each, users, and what is out of scope.
List the requirements with priorities. Must, Should, Could, Won't is enough at this size.
Name the risks and open questions. Each with an owner and a date to close it.
Give a range, not a number. Low and high effort for the first release, with the assumptions behind it.

The discovery phase checklist works as the quality bar for a light discovery: if a section of it does not apply, say so in one line rather than leaving it blank. Its first section is a quick test of whether you have talked to the right people:

Tools can shorten step 1; Discovery Phase AI, for example, drafts the background, stakeholders, goals and requirements from the files you upload, which you then review and correct in the interviews.

What it costs to skip it (the failure patterns)

Skipping discovery rarely fails loudly at the start. It fails in recognisable ways later:

The estimate was a price for a different project. The team quoted what they imagined; the client meant something larger. The gap turns into change requests and strained trust.
The late stakeholder. Security, legal or a department nobody interviewed sees the product near launch and blocks it until changes are made.
The integration surprise. The other system has no usable interface, rate limits, or data in a shape nobody expected, and the work grows after the price is agreed.
Building the wrong first release. Without agreed goals, the team builds the features that were easiest to describe, not the ones that matter most.
No shared definition of done. Without acceptance criteria, "finished" becomes a negotiation at the end.

A discovery turns most of these into written items before the build starts. In our example report, made for an invented project called Fieldwise, a missing partner API appears as a blocker and the technicians' distrust of the sync as a risk, each linked to the stage it affects:

None of these is guaranteed, and a short brief prevents some of them. The question is not whether discovery is good in general, but whether this project's unknowns are expensive enough to pay to remove them first. If you answered "yes" to three of the five questions above, they probably are.

Disclosure and a sample

If you just want to see what a finished discovery looks like, here is a complete sample report for an invented field-service app. No signup needed.

The original of this post is on our blog. Questions or corrections are welcome in the comments.

This post was drafted with AI assistance and edited by a human before publishing.