DIGITAL PRODUCT DEVELOPMENT | Define the Product Before You Build It — Turn a User Problem into a Clear, Testable Product Specification

Introduction:

A digital product begins long before its

first screen is designed or its first line of code is written.

It begins when someone identifies a problem worth solving and develops a sufficiently clear understanding of the people experiencing it, the outcome they need, and the role technology could play in producing that outcome.

This distinction matters because building software and building a successful digital product are different activities.

Software can function exactly as its developer intended and still fail its users. An application may have a polished interface, modern architecture, and sophisticated features, yet remain difficult to understand, inconvenient to use, or poorly suited to the problem it was supposed to solve.

The underlying failure may not be technical. The product may never have been defined properly.

Digital product development is the discipline of transforming a problem, opportunity, or user need into a solution that can be designed, built, tested, delivered, maintained, and improved. It combines user understanding, product decisions, design, engineering, quality assurance, operations, and business reasoning.

This chapter establishes the first discipline in that process: defining the product before committing substantial resources to building it.

You will learn to distinguish a product idea from a product specification, identify intended users and their needs, define measurable outcomes, establish the boundaries of the first release, write testable requirements, and produce a practical document that a designer, developer, product owner, or AI-assisted development tool can use.

The objective is not to produce paperwork for its own sake. It is to reduce avoidable misunderstanding and make the eventual product easier to build, evaluate, and improve.

1. What Is a Digital Product?

A digital product is a product whose principal functionality, delivery, or user value depends on digital technology.

Examples include:

• A website that helps customers find and compare services.
• A mobile application that manages personal finances.
• A web application that creates and edits documents.
• A software tool that automates repetitive business tasks.
• An online learning platform.
• A subscription-based software service.
• A digital publication or educational resource library.
• An application programming interface (API) that allows other software systems to exchange information or access functionality.

Some products combine digital and physical components. An online ordering system, for example, may coordinate physical inventory, digital payments, customer communication, and delivery operations.

The product is not necessarily just its software interface. Its full experience may include onboarding, customer support, account management, payment processing, documentation, data handling, and the procedures used to deliver the promised outcome.

Consider an application that helps customers locate printing businesses.

Its visible interface might contain search fields, business profiles, price lists, order forms, and payment screens. But the complete product may also require:

• Accurate business listings.
• A process for updating prices.
• Rules for handling unavailable services.
• Secure account management.
• Clear order-status information.
• A method for resolving disputes.
• Notifications that reach the right person.
• A process for correcting inaccurate information.

If these supporting elements are neglected, the interface may look complete while the product remains unreliable.

A useful starting principle is therefore:

Define the complete user outcome, not merely the software screens.

2. Distinguish the Idea, the Product, and the Specification

These three concepts are related, but they serve different purposes.

2.1 The product idea

An idea describes a possible solution at a relatively high level.

For example:

Build an application that connects customers with printing businesses.

This statement communicates a direction. It does not explain which customers are being served, how they currently obtain printing services, which problems are most important, or what the application must do to solve them.

An idea can be promising without being sufficiently precise to guide development.

2.2 The product

The product is the actual solution and the experience it provides to its intended users.

In the printing example, the product might allow customers to discover nearby or remote printing providers, compare relevant services, request quotations, submit files, place orders, and track progress.

The exact scope depends on the users' needs, the operating model, technical feasibility, and available resources.

2.3 The product specification

A product specification describes what the product is intended to accomplish and the requirements and constraints that guide its implementation.

It may define:

• Intended users and their goals.
• Problems the product addresses.
• Core user journeys.
• Required capabilities.
• Business rules.
• Data requirements.
• Security and privacy expectations.
• Performance and accessibility requirements.
• Acceptance criteria.
• Explicit exclusions.
• Questions that still require investigation.

The specification connects the product idea to implementation.

It does not need to describe every future feature. It must be sufficiently clear to guide the decisions that matter now.

Why the distinction matters

Imagine instructing a developer to build a marketplace.

The developer might interpret this as a directory of businesses. Another developer might build a full ordering system. A third might include customer accounts, online payments, delivery tracking, messaging, reviews, and automated commissions.

All three could reasonably claim to have built a marketplace, yet their products would differ substantially in cost, complexity, and functionality.

A specification narrows that interpretive gap.

3. Start With the User's Problem, Not the Feature List

One of the most common product-development mistakes is to begin by listing features.

A founder might say:

• The application needs a dashboard.
• It needs notifications.
• It needs artificial intelligence.
• It needs payment integration.
• It needs a mobile interface.

These are proposed capabilities. They do not establish whether the product solves an important problem.

A more useful starting point is to investigate the circumstances in which a user needs help.

3.1 Identify the intended user

Avoid descriptions that are too broad to guide decisions.

"Everyone who uses the Internet" is rarely a useful initial target group.

A more specific description might be:

Small-business owners who regularly order printed marketing materials but struggle to compare providers, confirm specifications, and obtain reliable delivery estimates.

This description gives the product team a starting hypothesis about the user's circumstances.

It is not yet proof that the group experiences the problem frequently or would use the proposed solution. That requires research.

3.2 Describe the situation

Ask what happens before, during, and after the user encounters the problem.

For the printing example:

1. A business needs flyers for an upcoming promotion.
2. The owner searches online or contacts several printing shops.
3. Each provider offers different packages, prices, and turnaround times.
4. The owner must clarify quantities, paper specifications, finishing, and delivery.
5. The owner compares the quotations and chooses a provider.
6. The order is submitted and the owner waits for confirmation.
7. If the deadline changes or an error occurs, the owner must contact the provider.

This sequence reveals where friction may occur.

The important observation is that the problem is not necessarily "there is no printing app." The underlying difficulty may be that information is fragmented, quotations are inconsistent, or order progress is uncertain.

A useful product could address one or several of these difficulties. The correct choice should be informed by evidence and the product's intended scope.

3.3 Understand existing alternatives

Users rarely do nothing about every problem. They may use telephone calls, messaging applications, spreadsheets, social media pages, personal contacts, or established suppliers.

These alternatives matter because they reveal existing habits and expectations.

Investigate:

• What users currently do.
• How frequently they do it.
• How much time or money it consumes.
• Where errors or delays occur.
• What they like about the current method.
• What they dislike.
• What prevents them from switching.
• Whether the problem is serious enough to justify a new solution.

Do not assume that an existing process is worthless because it is manual. A familiar telephone call may be more convenient than creating an account and learning a complicated application.

The new product must offer a meaningful improvement over the alternatives available to its intended users.

4. Translate Problems Into Desired Outcomes

A problem describes an undesirable situation. An outcome describes the improvement the user wants.

For example:

Problem	Desired outcome
Prices are scattered across different channels.	Compare relevant prices without repeatedly contacting providers.
Service specifications are unclear.	Understand what is included in each quotation.
Order confirmation is delayed.	Receive reliable confirmation that an order has been accepted.
Order progress is difficult to determine.	Know the current status and expected next step.
Providers receive incomplete instructions.	Submit complete, understandable order specifications.

Outcomes help prevent feature decisions from becoming arbitrary.

Suppose the desired outcome is to help customers compare printing prices. A structured price list may be more important than a sophisticated recommendation engine.

Suppose the main difficulty is uncertainty about delivery. Accurate status updates and clear responsibility for order changes may matter more than decorative dashboard features.

The product should be evaluated according to whether it produces the intended outcomes, not merely whether it contains the planned features.

4.1 Write a problem statement

A useful problem statement can follow this structure:

[Specific user] experiences [problem] when [situation], causing [consequence]. The user needs a way to [desired outcome].

Example:

Small-business owners ordering promotional printing often struggle to compare providers because prices, specifications, and turnaround estimates are presented inconsistently, making it difficult to choose a suitable service with confidence. They need a clear way to compare relevant offers and understand the terms of each order.

This is a working hypothesis, not a verified research finding.

If interviews or observed behaviour contradict it, revise the statement.

4.2 Write an outcome statement

A complementary statement describes what success should look like:

Help customers identify suitable printing providers, understand comparable offers, and submit complete orders with fewer unnecessary clarification steps.

This is more useful than a vague objective such as "make printing easier" because it suggests observable behaviour.

However, it still needs specific measures before it can support a rigorous evaluation.

5. Define the Product's Value Proposition

A value proposition explains why the intended user should choose the product rather than continue with an alternative.

It connects four elements:

1. The intended user.
2. The problem or goal.
3. The improvement offered.
4. The reason the proposed solution is useful or meaningfully different.

For example:

For small businesses that need promotional printing, the platform provides a structured way to discover providers, compare service details, and manage orders without relying entirely on scattered messages and individual quotations.

This describes a potential value proposition. Whether it is convincing depends on actual customer needs and the quality of the implemented service.

A useful value proposition should answer three questions:

• Relevance: Does the product address something the intended user genuinely cares about?
• Clarity: Can the user understand what the product does?
• Differentiation: Why might the user prefer it to existing alternatives?

Differentiation does not always require a unique technology. A product may be more useful because it is easier to navigate, works reliably on low-cost devices, communicates prices clearly, supports familiar payment methods, or offers dependable local assistance.

Technology is a means of delivering value. It is not, by itself, evidence of value.

6. Establish the Product's Boundaries

A product cannot do everything in its first release.

Time, money, technical complexity, available information, operational capacity, and user attention all impose constraints.

Without explicit boundaries, product scope tends to expand. Every new idea appears useful, and every requested feature seems urgent. The result can be an expensive, delayed, difficult-to-test system.

Scope management begins by deciding what belongs in the product and what does not.

6.1 Separate essential capabilities from enhancements

For the printing marketplace, a possible first release might include:

Essential capabilities

• Display verified or clearly identified printing businesses.
• Show available services and relevant specifications.
• Provide a way to request a quotation or submit an order enquiry.
• Allow the provider to respond.
• Communicate the order's current status when an order is accepted.
• Provide a clear method for customers to contact support.

Possible later enhancements

• Automated price calculation for complex jobs.
• Integrated delivery dispatch.
• Loyalty rewards.
• Advanced provider analytics.
• AI-assisted design recommendations.
• Multiple currencies.
• Complex promotional campaigns.
• Automated dispute classification.

These lists are illustrative. Research might reveal that some apparently advanced capability is essential, or that a proposed essential feature is unnecessary.

The objective is to make deliberate choices.

6.2 Use a scope classification

Classify proposed capabilities into four groups:

• Required: Necessary for the first release to fulfil its primary purpose.
• Important: Valuable, but the product can deliver its core outcome without it initially.
• Optional: Useful enhancements with relatively low priority.
• Excluded for now: Deliberately outside the current release.

An excluded feature is not necessarily a bad idea. It is a decision to protect the current product's focus.

6.3 Define the first release around a complete journey

A first release should support a meaningful end-to-end user journey rather than consist of disconnected features.

For example:

Customer discovers a provider → reviews services → submits an enquiry → receives a response → confirms the order with the provider → receives a status update.

If the product promises online ordering, the journey may need to continue through order confirmation and payment. If it promises delivery tracking, it needs a credible source of delivery-status information.

The release must deliver the outcome it promises.

A smaller, coherent product is often easier to evaluate than a larger product whose essential workflow remains incomplete.

7. Model the User Journey Before Specifying Screens

A user journey describes the sequence of steps a person takes to accomplish a goal.

It is not the same as a screen list.

A screen list might contain a home page, search page, business profile, order page, and dashboard. A journey explains why the user visits those screens and what must happen at each stage.

Consider the customer journey for requesting a printing quotation.

Stage	User's goal	Product responsibility
Discover	Find suitable providers.	Present relevant providers and search options.
Evaluate	Understand services and terms.	Show service details, specifications, and available pricing information.
Specify	Explain the required job.	Collect quantity, dimensions, material, finishing, deadline, and other necessary details.
Submit	Send a complete enquiry.	Validate the information and confirm submission.
Receive response	Understand the offer.	Present the provider's response and make its terms clear.
Decide	Accept, reject, or ask questions.	Support the next action without misleading the customer about order status.

This analysis reveals product requirements that a screen-first approach may miss.

For example, if the customer selects a delivery deadline, the system needs to distinguish between a requested date and a date the provider has actually confirmed.

If prices vary according to paper, quantity, or finishing, the interface must not present an indicative price as a guaranteed final price.

If an enquiry fails to submit, the user needs a clear error message and a safe way to retry.

These details are part of product behaviour, not minor interface decoration.

8. Convert the Product Definition Into Requirements

A requirement states something the product must do or a condition it must satisfy.

Requirements should be specific enough to guide implementation and verification without prematurely dictating every technical detail.

A useful specification distinguishes functional requirements from non-functional requirements and business rules.

8.1 Functional requirements

Functional requirements describe system behaviour.

Examples:

• The system shall allow a visitor to view published printing-business profiles.
• The system shall display the services offered by each published provider.
• The system shall allow a customer to submit a quotation request with the required job details.
• The system shall confirm when a request has been successfully recorded.
• The system shall allow an authorized provider to view requests assigned to that provider.
• The system shall record changes to an order's status.

These statements are more actionable than "the platform should be user-friendly" or "the system should manage orders."

8.2 Business rules

Business rules define the conditions under which the product operates.

Examples:

• Only authorized provider accounts may edit their own business profiles.
• A quotation must identify the services and terms it covers.
• A requested deadline must not be represented as confirmed until the relevant provider has accepted it.
• A cancelled order must not be presented as active.
• A customer must receive a clear indication when an enquiry has not been submitted successfully.

Business rules are especially important in marketplaces, financial applications, booking systems, and other products where multiple parties have different responsibilities.

8.3 Non-functional requirements

Non-functional requirements describe qualities and constraints that affect how well the system operates.

They may cover:

• Performance.
• Reliability.
• Security.
• Privacy.
• Accessibility.
• Compatibility.
• Maintainability.
• Availability.
• Scalability.
• Data retention.
• Recovery after failure.

For example:

The quotation-request form must remain usable on supported mobile devices and clearly identify any required fields that have not been completed.

This is a useful usability requirement.

A performance requirement should be more precise where possible:

Under the agreed test conditions, the search-results endpoint should return a response within the specified time limit for the defined workload.

The exact limit and workload must be chosen for the product. Do not insert arbitrary numbers merely to make a specification look technical.

Likewise, "the application must be secure" is too broad to verify. It should be decomposed into appropriate controls, such as access restrictions, secure session handling, input validation, protected data transmission, backups, and tested recovery procedures.

Security requirements must reflect the product's data, users, threat exposure, and applicable obligations.

8.4 Data requirements

Identify what information the product needs to collect, store, display, update, and delete.

For a quotation request, the relevant information might include:

• Request identifier.
• Customer contact information.
• Selected provider.
• Printing specifications.
• Quantity.
• Requested deadline.
• Uploaded artwork, if supported.
• Submission time.
• Request status.
• Provider response.
• Relevant communication history.

Not every field should be collected automatically. Each item should have a legitimate purpose.

Personal information and uploaded files introduce additional questions about access, storage, retention, consent where required, and deletion.

Collecting less unnecessary information can reduce privacy risk and simplify implementation.

9. Write Acceptance Criteria That Can Be Tested

A requirement describes what the product must do. Acceptance criteria specify the conditions under which the requirement can be considered satisfied.

Without acceptance criteria, a developer and a product owner may disagree about what "finished" means.

Consider the requirement:

Customers must be able to submit a quotation request.

That statement leaves many questions unanswered.

What happens if a required field is missing? What if the network connection fails? How does the customer know the request was recorded? Can the customer accidentally submit the same request repeatedly?

Acceptance criteria make expected behaviour explicit.

Example: Quotation-request submission

Requirement: The customer can submit a quotation request for a selected provider.

Acceptance criteria:

1. The form identifies all mandatory fields.
2. The system prevents submission when mandatory information is missing or invalid.
3. The system explains which fields need correction.
4. A valid submission creates a recorded request associated with the selected provider.
5. The customer receives confirmation only after the system has successfully recorded the request.
6. If submission fails, the customer receives an understandable error message.
7. The system does not expose the request to unauthorized providers or users.
8. Retrying after a network failure should not unintentionally create duplicate requests when the implementation uses appropriate duplicate-submission protection.

The final criterion is particularly important. A user may tap a submission button twice because the connection is slow. The product should account for realistic behaviour, not only the ideal path.

9.1 Use Given–When–Then where useful

The Given–When–Then format can express acceptance criteria as scenarios:

Given a customer has completed all required quotation fields,

When the customer submits the request and the server successfully records it,

Then the system displays a confirmation and makes the request available to the authorized provider.

A failure scenario might be:

Given the customer's device loses connectivity before the request is recorded,

When the submission cannot be completed,

Then the system must not falsely confirm success and should explain how the customer can retry.

This format is useful for turning requirements into manual tests or automated test cases.

It is not mandatory for every requirement. A concise checklist or another structured format may be more appropriate for simple functionality.

10. Define How Success Will Be Measured

A product needs a way to determine whether it is producing the intended outcome.

Without measurement, teams may mistake activity for progress.

Examples of activity include the number of features released, lines of code written, meetings held, or designs completed.

These can help manage delivery, but they do not establish whether users benefit from the product.

A better measurement framework connects product goals to observable results.

10.1 Distinguish output from outcome

Output	Outcome
A search feature has been released.	Users can find suitable providers more effectively.
A quotation form has been completed.	More enquiries contain enough information for providers to respond.
Notifications have been implemented.	Users receive important updates reliably and understand what action is required.
A dashboard has been built.	Providers can complete important tasks with less unnecessary effort.

The output is what the team delivers. The outcome is the change the product is intended to create.

10.2 Select meaningful metrics

For the printing marketplace, possible measures include:

• Percentage of submitted requests that contain the information providers need.
• Percentage of requests receiving a provider response within a defined period.
• Time between request submission and first response.
• Percentage of enquiries that progress to accepted orders.
• Frequency of duplicate or incomplete requests.
• Rate of users abandoning the enquiry process.
• Customer-reported difficulty in completing the task.

Each measure needs a clear definition.

For example, "response time" must specify the start event, the end event, and whether the calculation uses a mean, median, percentile, or another statistic.

A high enquiry count alone may be misleading. It could reflect genuine demand, repeated submissions, irrelevant enquiries, or users who never receive a response.

Metrics should be interpreted together and in context. They are evidence for decisions, not substitutes for understanding users.

10.3 Establish a baseline before claiming improvement

If you want to claim that a product saves time, first establish how long the relevant task takes under the existing process.

Then measure the new process using a comparable method.

If no reliable baseline exists, begin collecting one. Do not invent a percentage improvement for a proposal, product page, or performance report.

Early products may not have enough users to support statistically reliable conclusions. In that case, combine carefully observed usability tests, interviews, operational records, and other appropriate evidence while acknowledging the limitations.

11. Account for Constraints and Risks

A product definition should reflect the conditions under which the product must operate.

Constraints are not necessarily defects in the project. They are realities that shape design decisions.

Technical constraints

Examples include integration limitations, device compatibility, hosting capacity, data availability, legacy systems, and the skills of the development team.

Financial constraints

These include the available development budget, ongoing hosting costs, payment-processing fees, support expenses, licensing, and maintenance.

A product that can be built but cannot be operated or maintained within the available resources is not ready for responsible delivery.

User constraints

Users may have slow connections, limited data allowances, older devices, limited storage, small screens, or varying levels of digital literacy.

These conditions may affect whether the product should prioritize lightweight pages, low-bandwidth workflows, accessible language, saved progress, or alternatives to large file uploads.

Operational constraints

A marketplace may depend on providers maintaining accurate listings, responding to customers, fulfilling orders, and resolving disputes.

Software cannot guarantee these actions merely by providing a dashboard.

The operating model must define responsibilities and procedures.

Legal and trust constraints

Depending on the product and jurisdiction, requirements may involve privacy, consumer protection, payment obligations, intellectual property, accessibility, electronic communications, and data security.

Identify relevant obligations early and obtain qualified advice when necessary. A product specification is not a substitute for legal review.

Risk register

Record significant risks in a simple table:

Risk	Possible consequence	Mitigation or investigation
Provider prices are outdated.	Customers make decisions using misleading information.	Define price-update responsibilities and show when information was last confirmed.
Customers submit incomplete specifications.	Delays, incorrect quotations, and repeated communication.	Use structured fields and clear validation.
Network failures interrupt submissions.	Lost enquiries or duplicate requests.	Test failure handling, confirmation logic, and safe retries.
Providers do not respond.	Customers lose confidence in the marketplace.	Define response expectations and monitor provider activity.
Sensitive files are exposed.	Privacy, intellectual-property, and trust harms.	Restrict access, secure file storage, and define retention and deletion rules.

The table should be updated as the team learns more. A risk that is initially uncertain may later be confirmed, reduced, or shown to be irrelevant.

12. Choose the Right Technical Solution After Defining the Need

Product definition should guide technology selection, not the other way around.

A team may prefer a particular programming language, framework, cloud provider, AI model, or no-code platform. These preferences can be relevant, but they should not determine the product's requirements without justification.

Start by identifying what the system must support.

For example:

• Does it need user accounts?
• Does it need different permission levels?
• Must users upload files?
• Does it handle payments?
• Does it require real-time updates?
• How much information must it store?
• Does it integrate with existing services?
• What availability and recovery expectations apply?
• Who will maintain it after launch?
• What skills and budget are available?

Then compare implementation approaches against these needs.

A simple directory may be suitable for a content-management system. A complex marketplace with orders, permissions, payment states, and provider workflows may require a more specialized application architecture. A no-code tool may be appropriate for an initial workflow test, while a custom application may become preferable as requirements become more demanding.

There is no universally best stack.

A sound decision balances fitness for purpose, cost, delivery speed, reliability, security, maintainability, portability, and the team's capabilities.

The same principle applies to AI-assisted development. A clear specification makes it easier to instruct an AI coding tool, evaluate the generated implementation, and identify missing functionality. AI-generated code must still be reviewed, tested, secured, and maintained.

13. Create a Product Brief

A product brief condenses the product's purpose, users, scope, and expected outcomes into a document that guides further work.

It is not a complete technical specification. It is a foundation from which more detailed requirements, designs, architectures, and test plans can be developed.

Use the following template.

Digital Product Brief

1. Product name

Working name for the product.

2. Product summary

Describe the product in a few sentences, including the problem it addresses and the principal outcome it provides.

3. Intended users

Identify the primary user group and the circumstances in which they need the product.

4. Problem statement

Describe the problem, its context, and its consequences. Distinguish verified evidence from assumptions.

5. Existing alternatives

Document how users currently solve the problem and where those approaches fall short.

6. Value proposition

Explain why the intended user might prefer the product to the available alternatives.

7. Primary user outcome

State what the user should be able to accomplish.

8. Core user journey

List the essential steps from the user's initial need to the successful completion of the task.

9. First-release scope

List the capabilities required to deliver the primary outcome.

10. Exclusions

Record features and responsibilities that are deliberately outside the current release.

11. Functional requirements

Describe the behaviours the system must support.

12. Non-functional requirements

Specify expectations for performance, reliability, security, accessibility, compatibility, and other relevant quality attributes.

13. Data and permissions

Identify necessary information, who may access it, and any important retention or deletion requirements.

14. Success measures

Define how the team will evaluate whether the product delivers its intended outcome.

15. Constraints

Record budget, schedule, technology, operational, and user-environment constraints.

16. Risks and open questions

List uncertainties that could materially affect product decisions.

17. Acceptance criteria

Define the conditions that must be met before the core user journey is considered complete.

18. Ownership and maintenance

Identify who will operate the product, respond to problems, update content or data, and maintain the system.

This brief should evolve as evidence improves. Important changes should be documented so that the team understands why the product's direction or requirements have changed.

14. Worked Example: Define a Small Digital Product

Suppose a developer wants to build a web application that helps small businesses create professional quotation documents.

The initial idea is:

Build an AI quotation generator.

This is too vague to guide development. It leaves open questions about the user, the document, the required information, the role of AI, and the expected result.

A more useful product definition follows.

Product summary

A lightweight web application that helps small service businesses create consistent customer quotations from structured job details and export them as documents.

Intended users

Small service-business owners who prepare customer quotations repeatedly and need a more consistent process.

This is an initial target hypothesis, not evidence that every small business needs such a product.

Problem statement

Some service businesses prepare quotations manually using copied documents, spreadsheets, or word processors. Their documents may be inconsistent, and repeated entry of customer and job details can consume time.

The frequency and seriousness of these problems must be investigated with representative users.

Primary outcome

Enable a business owner to create, review, and export a complete quotation using a repeatable process.

Core journey

1. Open the application.
2. Enter business details or select a saved profile.
3. Enter customer information.
4. Add the work description, quantities, rates, and applicable charges.
5. Review calculated totals.
6. Preview the quotation.
7. Export the document.
8. Save or retrieve the quotation when supported by the chosen design.

First-release capabilities

• Capture business and customer details.
• Add and edit quotation line items.
• Calculate line totals and the overall total.
• Display the quotation in a consistent format.
• Validate required information.
• Export a readable document.
• Explain validation or export failures.

Explicit exclusions

The first release does not automatically send invoices, collect payments, provide accounting reports, manage inventory, or generate legally authoritative tax advice.

These exclusions can be revisited if research reveals that they are necessary for the intended users.

Sample functional requirement

The application shall calculate each line item's total from its quantity and unit rate, then calculate the quotation total according to the configured rules for discounts and applicable charges.

Sample acceptance criteria

• A user can add, edit, and remove line items.
• The application recalculates totals after a relevant change.
• Invalid numeric entries are rejected or clearly flagged.
• Displayed totals agree with the defined calculation rules.
• The exported document reflects the final reviewed quotation.
• A failed export does not falsely indicate that a file was successfully created.

Sample success measures

• Percentage of test users who complete a quotation without assistance.
• Number and type of calculation or data-entry errors.
• Time required to produce a comparable quotation using the existing process and the new application.
• Percentage of exported documents that meet the agreed completeness and readability criteria.

Important design decision

Should the product include AI?

Not necessarily.

AI might help draft descriptions or convert rough notes into a structured starting point. However, arithmetic, required-field validation, and document formatting should use dependable, testable mechanisms where appropriate.

If AI is introduced, its output should be reviewable before the quotation is finalized. The product should not silently invent prices, quantities, contractual terms, or tax treatment.

The product's purpose is to help users produce reliable quotations. AI is only one possible implementation choice.

This example demonstrates how a broad idea becomes a product that can be designed, built, and tested.

15. Prepare the Specification for Design and Development

A specification is useful only if the people implementing the product can understand and apply it.

Before development begins, review the document for the following qualities.

Clarity

Can a designer or developer understand what each important requirement means without guessing about the intended behaviour?

Consistency

Do the requirements agree with one another? For example, does the product promise anonymous use while another requirement demands account registration for every action?

Testability

Can someone determine whether the requirement has been satisfied through observation, inspection, measurement, or a defined test?

Feasibility

Can the requirement be implemented within the known technical, financial, operational, and schedule constraints—or does it require further investigation?

Traceability

Can each important requirement be connected to a user need, business rule, risk, or product outcome?

Traceability helps prevent unnecessary features from entering the product simply because someone suggested them.

Appropriate detail

Does the specification contain enough detail to guide implementation without prematurely locking the team into decisions that should be explored through design or technical investigation?

Not every detail needs to be settled before work begins. Unknowns should be recorded and investigated in a controlled way rather than disguised as decisions.

Change control

When a requirement changes, record what changed, why it changed, which other requirements or tests are affected, and who approved the decision when approval is required.

A specification should not become an obstacle to learning. It should provide a reliable account of the product's current intended behaviour.

16. Common Product-Definition Failures

Failure 1: Building for an imaginary user

The team assumes what people need without observing their circumstances.

Correction: Investigate actual behaviour, interview relevant users, examine existing alternatives, and test important assumptions.

Failure 2: Confusing feature quantity with product value

The team keeps adding functionality without improving the primary user outcome.

Correction: Link each major feature to a defined need, outcome, or necessary operational requirement.

Failure 3: Leaving business rules implicit

The team builds an interface but leaves important decisions undefined.

Correction: Document conditions, permissions, state changes, exceptions, and responsibilities.

Failure 4: Specifying only the ideal path

The team defines what happens when everything works but ignores failures, cancellations, retries, and invalid input.

Correction: Specify normal, alternative, and failure scenarios for important user journeys.

Failure 5: Using vague quality requirements

The specification says the product must be fast, secure, reliable, or easy to use without defining what those words mean in context.

Correction: Translate each important quality into appropriate, testable expectations.

Failure 6: Choosing technology before understanding the problem

The team starts with a preferred framework or AI platform and then forces the product into its limitations.

Correction: Establish the user outcome, requirements, constraints, and operating model before evaluating implementation options.

Failure 7: Treating the specification as permanent

The team refuses to adapt when evidence shows that an assumption was wrong.

Correction: Maintain a versioned, evidence-informed specification and manage changes deliberately.

Failure 8: Treating the specification as a substitute for testing

The team assumes that because requirements are documented, the product will satisfy them.

Correction: Verify implemented behaviour against acceptance criteria and test the actual experience with representative users.

17. Practical Exercise: Produce a Product Brief

Choose one digital product idea. It can be a website, mobile application, business tool, educational platform, marketplace, automation system, or another digital service.

Do not begin by writing a feature list.

Work through the following tasks.

Task 1 — Identify the user

Describe one primary user group and the situation in which the product would be useful.

Task 2 — Investigate the problem

Record how users currently handle the task. Identify the evidence you have and the assumptions you still need to test.

Task 3 — Define the outcome

Write one sentence describing what the user should be able to accomplish.

Task 4 — State the value proposition

Explain why the user might prefer the proposed solution to the alternatives.

Task 5 — Map the core journey

List the steps required to achieve the primary outcome, including any important decisions or handoffs.

Task 6 — Establish scope

Identify the minimum set of capabilities needed to deliver a complete, useful first release. Record deliberate exclusions.

Task 7 — Write requirements

Create at least five functional requirements and identify the most important non-functional requirements, business rules, and data responsibilities.

Task 8 — Define acceptance criteria

Choose three important requirements and write observable conditions that determine whether each has been satisfied.

Task 9 — Select success measures

Define how you will evaluate the product's usefulness. Where possible, identify a baseline or explain how you will collect one.

Task 10 — Record risks and unknowns

List the assumptions that could cause the product to fail, exceed the available budget, expose users to harm, or become difficult to operate.

Task 11 — Review the brief

Ask someone unfamiliar with the idea to read the specification. Identify where they make different assumptions from yours.

Revise the document until the important behaviours and boundaries are sufficiently clear.

Completion standard

Your product brief is ready to guide the next stage when:

• The intended user and problem are clearly identified.
• The desired outcome is specific.
• The first-release scope is bounded.
• Important requirements are testable.
• The core journey accounts for significant exceptions.
• Constraints and major risks are documented.
• Success can be evaluated using defined evidence.
• Unresolved questions are visible rather than hidden.

The brief does not need to answer every future question. It needs to establish a dependable starting point for product design and technical planning.

Conclusion

Product development is not simply the process of turning ideas into code. It is the process of turning an understood need into a solution that can reliably produce a useful outcome.

A product specification connects the user's problem to the product's intended behaviour. It clarifies what should be built, why it matters, what belongs in the first release, how success will be evaluated, and which uncertainties require further investigation.

This discipline reduces avoidable ambiguity without pretending that every decision can be made in advance.

The essential practice is straightforward:

Understand the problem. Define the outcome. Establish the scope. Specify the behaviour. Make success testable.

When these foundations are clear, design and engineering become more purposeful, and the team has a stronger basis for deciding what to build, what to postpone, and what evidence should guide the next decision.

References and Further Study

• International Organization for Standardization (ISO), ISO 9241-210 — Human-centred design for interactive systems.
• Scrum Guide, The Scrum Guide, for understanding product goals, backlogs, and iterative delivery.
• GOV.UK, Service Manual, for practical guidance on user needs, service design, and building services around users.
• Atlassian, Product requirements, for further discussion of documenting and managing product requirements.
• OWASP, Application Security Verification Standard, for a structured reference to application security requirements and verification.

Use these references to deepen your understanding. Select the standards and practices appropriate to the product's context, and consult current official documentation when establishing implementation or compliance requirements. 

Image: StudioRed