Building a digital product is one of the most significant investments an organization can make. It is also one of the easiest to get wrong. Startups face up to 90 percent new product development failure rates,1 and most of those failures share a common origin: organizations committed to building before they were ready to build.
These are not questions for your developers. They are questions for your leadership — the people who will ultimately determine whether the product succeeds or fails. A strong answer is specific, documented, and agreed upon by the people making product decisions. A weak answer is vague, assumed, or exists only in one person's head.
This is the most important question on this list, and the one most organizations answer too broadly. "Small business owners" is not a specific enough answer. "Independent family law attorneys at firms with two to five staff members who currently manage client document intake through email and spreadsheets" is a specific answer. The more precisely you can describe the person this product is built for, the better every subsequent product decision will be.
A useful test: can you name three to five real people who fit the description? If you cannot, the definition is still too broad.
A one-to-two paragraph description of the primary user that includes their role, the context in which they will use the product, what they are currently doing to solve the problem this product addresses, and what specifically frustrates them about that current approach.
A demographic category, a job title without context, or a description so broad it could apply to millions of people.
The question is not "what does this product do?" That is a feature question. The question is "what specific pain does this product remove from the person in Question 1, and how significant is that pain?" Significance matters. A product that saves a paralegal 45 minutes per client intake is solving a significant problem. A product that saves them two minutes is not, regardless of how elegantly it does so.
A one-sentence problem statement in the user's language. "Family law paralegals spend three to four hours per new client case manually requesting, tracking, and organizing documents across email, text, and phone calls, with no reliable way to know what is outstanding at any given time."
A solution description disguised as a problem statement. "There is no good tool for document management in family law." That is an observation about the market, not a description of a specific user pain.
Most organizations know what they want to build. Very few have defined, before building it, what success actually looks like in measurable terms. Without a defined success metric, you have no way to evaluate whether the product is performing, and no basis for making prioritization decisions about what to build next.
Two to three specific, measurable outcomes with a timeframe. "Within 90 days of launch, 80 percent of active users complete a full client intake workflow without abandoning. Average time per intake is reduced from 3.5 hours to under 45 minutes."
Outputs mistaken for outcomes. "We will have 100 users in 90 days." Users are an output. What those users do with the product is the outcome.
One of the most expensive mistakes in product development is building a complete product before validating that the core concept works. Companies using minimum viable products to validate ideas before full builds are 62 percent more likely to succeed.2 The purpose of defining a minimum version is not to build something cheap — it is to identify the smallest functional version that allows you to test whether the core assumption in Question 2 is correct.
A specific description of the minimum set of capabilities that would allow a real user to complete the primary workflow the product is designed to support. Not a list of features that would be nice to have, but the bare minimum that solves the core problem.
A phased feature list that still starts with a full product in Phase 1. Phasing features is not the same as defining a minimum viable product. The question is what you can remove, not what you can defer.
Products built without clear decision ownership accumulate conflicting inputs, stall on unresolved disagreements, and end up serving no one's priorities well. 35 percent of companies add features to close deals rather than to improve value.3 This is almost always a symptom of unclear decision ownership. One person needs to own the product vision and have the authority to make final decisions on what gets built, what gets deferred, and what does not belong in the product at all.
A named individual with a defined scope of authority. "The product owner is [name]. They have final decision authority on the roadmap and feature prioritization. Escalation to leadership is required only for decisions that affect the core product vision or require budget above [threshold]."
A committee, a consensus model, or an answer that defers to whoever is asking for the feature. Shared ownership of product decisions is the same as no ownership.
This question is different from Question 3. Question 3 defines long-term product success. This question defines what your organization needs to see in the first 90 days after launch to confirm the product is on the right track. 90 days is long enough for real patterns to emerge from real usage, and short enough that you can course-correct if those patterns are not what you expected.
Three to five specific observations you expect to make within 90 days that would confirm the product is working as intended. "Within 90 days, at least 20 users have completed a full intake workflow without abandoning. At least 15 have returned to start a second intake."
"We will evaluate where we are at 90 days." That is not a success definition. That is a calendar reminder.
Using This Guide
These six questions work best when answered in writing, reviewed by the core team, and documented before any development work begins. The process of writing the answers often surfaces disagreements and assumptions that are better resolved before development starts than after.
If your team cannot agree on clear answers to all six questions, that disagreement is the most important thing to resolve before committing to a build. A development team cannot build a product that its leadership team has not yet defined. If your team can answer all six questions clearly and specifically, you have the strategic foundation that most products lack when development begins.