A digital product can fail long before users ever see the first version.

The failure may begin with a misunderstood customer problem, an assumption that was never tested, a feature list built around opinions, unclear product requirements, unrealistic expectations, or a technical decision made before the product itself is properly defined.

This is why the first stage of digital product development should not be treated as a waiting room before coding begins. It is where some of the most important product decisions are made.

Research from the Project Management Institute has repeatedly connected poor requirements management with project problems. In one PMI study, 47% of unsuccessful projects were reported to fail to meet goals because of poor requirements management, while 5.1% of project and program spending was reported as wasted because of poor requirements management.

The lesson is straightforward: building faster does not help if the team is building the wrong product.

A strong digital product development process therefore starts before engineering. It starts with understanding the problem, validating assumptions, defining the product clearly, assessing feasibility and deciding what should actually be built.

The Real Problem Is Often Not the Code

When a digital product struggles after launch, development is often the easiest part to blame.

Teams may ask:

• Was the technology wrong?
• Was the application too slow?
• Was the design confusing?
• Did development take too long?
• Should the company have used another framework?
• Was the development team large enough?

These questions matter, but they can come too late.

The more fundamental question is:

Did the team make the right product decisions before development started?

Consider a company planning a new customer service platform.

The initial requirement might be:

“We need an AI chatbot that can answer customer questions.”

That sounds like a development requirement.

But it does not explain:

• What customer problem is being solved?
• Which customers experience the problem?
• How frequently does it happen?
• What are customers doing today?
• Why are existing channels insufficient?
• What questions should the system answer?
• What happens when the AI cannot answer?
• How will success be measured?
• Is a chatbot actually the right solution?

If these questions remain unanswered, development can still begin. Engineers can build the chatbot. Designers can create the interface. QA can test the workflows.

The team may even launch successfully.

But technical completion does not necessarily mean product success.

The GOV.UK Service Manual recommends understanding users and their needs before planning, designing or building a service because discovery helps teams understand the problem and scope the service appropriately.

The Cost of Getting the Product Definition Wrong

One of the strongest arguments for early product discovery is that problems generally become harder to change as development progresses.

An incorrect assumption discovered during a workshop may take minutes to discuss.

The same assumption discovered after design may require redesign.

If it reaches development, the team may need to rewrite code, change APIs or database structures and update tests.

If it reaches production, the business may also need to deal with customer complaints, operational disruption, migration work and reputational consequences.

A PMI-published discussion of requirements research cites a relative repair-cost model in which correcting a requirements defect early can cost 1×, while correcting the same defect during design can cost 10×, and after deployment can reach 100× the early-stage cost.

7 Decisions That Can Make or Break a Digital Product Before Development

1. Solving the Wrong Problem

The first and most important decision is identifying the actual problem.

A product idea often begins with a solution:

• “We need an app.”
• “We need AI.”
• “We need a dashboard.”
• “We need automation.”
• “We need a marketplace.”
• “We need a mobile version.”

But a solution is not the same thing as a problem.

Suppose a company says:

“We need a mobile application for our customers.”

The product team should ask why.

Perhaps customers are struggling because they cannot track service requests easily.

In that case, the real requirement may be better service-request visibility, not necessarily a mobile application.

The solution could involve:

• a responsive web experience,
• a customer portal,
• SMS notifications,
• an application,
• or a combination of these.

The GOV.UK Service Standard specifically recommends focusing on the user's problem rather than a predetermined solution and testing assumptions early because the actual problem may differ from what the team initially believes.

Problem-first thinking

The second column gives the product team something more valuable than a feature request: a problem that can be investigated.

2. Assuming You Know What Users Want

Internal stakeholders often know the business extremely well.

That does not automatically mean they know how users experience the product.

A product team may hear:

“Customers want this feature.”

But where did that statement come from?

It could be based on:

• one customer conversation,
• a sales team's feedback,
• an executive opinion,
• a competitor's feature,
• a support ticket,
• an assumption,
• or actual research.

These sources are not equivalent.

User research turns assumptions into questions that can be tested.

The GOV.UK guidance recommends identifying assumptions and turning them into research questions rather than treating opinions as established facts.

From assumption to evidence

This changes the product conversation.

Instead of asking “What should we build?”, the team begins asking “What do we need to learn?”

That is a much stronger starting point.

3. Treating Features as the Product Strategy

A long feature list can create the illusion of progress.

For example:

Proposed product

• User registration
• Login
• Dashboard
• Notifications
• Chat
• AI assistant
• Analytics
• Payments
• Social sharing
• Recommendations
• Admin panel
• Integrations
• Mobile application

It looks comprehensive.

But it does not answer the most important question:

Which problem is the product expected to solve first?

Adding features before validating the core product can increase complexity without increasing value.

A better approach is to connect every major feature to a specific user or business outcome.

This creates a connection between feature → problem → outcome.

Without that connection, feature development can become an expensive exercise in assumption.

4. Building an MVP Without Defining What “Minimum” Means

The term MVP is widely used in digital product development, but teams often interpret it differently.

For one organization, an MVP means:

“The smallest version that tests whether customers need the product.”

For another, it means:

“The first version with enough features to sell.”

For another, it becomes:

“Everything we want, but with fewer design details.”

These are very different approaches.

A useful MVP should be connected to a learning objective.

Instead of:

Build 15 features and launch quickly.

Try:

Identify the most important product assumption and build the smallest experience capable of testing it.

For example, suppose the assumption is:

Small businesses will pay for automated invoice reminders.

The MVP does not necessarily need:

• a complex analytics suite,
• ten payment integrations,
• advanced personalization,
• multiple dashboards,
• mobile applications,
• or dozens of notification settings.

It may need only enough functionality to test whether businesses experience the problem, use the solution and see sufficient value to continue using it.

This reduces unnecessary development while producing useful evidence.

5. Ignoring Technical Feasibility Until After Product Design

Product discovery should not be purely about customers.

Technology matters too.

A product can solve a genuine problem and still become difficult to deliver if technical constraints are ignored.

For example:

• required APIs may not exist,
• third-party systems may have restrictive limits,
• data may be incomplete,
• security requirements may be significant,
• infrastructure costs may be high,
• legacy systems may be difficult to integrate,
• AI workloads may require expensive infrastructure,
• regulatory requirements may affect architecture.

That is why product, design and engineering should collaborate early.

Early feasibility checklist

The objective is not to make every technical decision before product discovery is complete.

The objective is to identify expensive technical surprises early.

6. Measuring the Wrong Definition of Success

Another product can fail because the team defines success as delivery.

For example:

“The application was launched successfully.”

That tells you something about execution.

It does not tell you whether the product created value.

A stronger product scorecard could include:

This distinction matters because shipping a product and succeeding with a product are different outcomes.

The development team can meet every technical requirement while the product fails to achieve its business objective.

7. Allowing Stakeholder Opinions to Become Requirements

Stakeholder input is valuable.

But not every stakeholder statement should immediately become a product requirement.

Imagine five stakeholders provide these requests:

• Sales wants a CRM integration.
• Marketing wants social sharing.
• Finance wants subscription billing.
• Operations wants automation.
• Customers want faster support.

If all five requests become immediate development priorities, the product can quickly become overloaded.

Instead, the product team should evaluate each request against common criteria.

A practical prioritization framework

This creates a more disciplined path from idea → evidence → priority → requirement.

What Product Discovery Should Actually Produce

Product discovery is sometimes misunderstood as a collection of meetings.

It should produce decisions.

By the end of an effective discovery phase, the team should have a clearer understanding of:

1. Who the product is for
2. What problem those users experience
3. Why the problem matters
4. How users solve it today
5. What alternatives already exist
6. What the product needs to accomplish
7. Which assumptions remain uncertain
8. What should be tested next
9. What the MVP should contain
10. Whether the idea is technically and commercially feasible

The GOV.UK Service Manual similarly recommends discovery research around users, current behaviour, problems and desired outcomes before planning, designing or building a service.

A Better Pre-Development Decision Framework

Before development begins, product teams can use a simple five-layer framework.

Layer 1: Problem

What problem are we solving?

If the answer is vague, do not move directly to development.

Layer 2: User

Who experiences this problem?

Identify actual user groups rather than defining the audience as “everyone.”

Layer 3: Evidence

What evidence shows that this problem exists?

Use interviews, analytics, support data, market research, observation and other appropriate evidence.

Layer 4: Solution

What is the smallest solution that can address the problem?

Only after understanding the problem should the team start defining features.

Layer 5: Success

How will we know whether the solution worked?

Define measurable outcomes before development begins.

The framework

This framework does not eliminate uncertainty.

It makes uncertainty visible.

That is important because hidden uncertainty is much harder to manage than documented uncertainty.

The Warning Signs That a Product Is Not Ready for Development

Some signals should make a product team pause before engineering begins.

Warning Sign 1: “We will figure out the requirements during development.”

Requirements will change during development. That is normal.

But starting without understanding the fundamental problem, target users and product objective creates unnecessary risk.

Warning Sign 2: “Our competitor has this feature.”

A competitor's feature is evidence that a solution exists.

It is not proof that your users need the same solution.

Warning Sign 3: “The CEO wants it.”

Leadership input matters.

But executive preference should still be connected to customer needs, business objectives and evidence.

Warning Sign 4: “We need to launch quickly, so there is no time for discovery.”

This can create a false trade-off.

Discovery does not have to mean months of research.

The goal is to answer the most important uncertainties before the team makes expensive commitments.

Warning Sign 5: “We already know what users want.”

If the product team cannot explain how that knowledge was obtained, the statement may still be an assumption.

Warning Sign 6: “Let's add it now and remove it later.”

Removing functionality later can still carry design, development, testing, documentation and maintenance costs.

Warning Sign 7: “Success means launching.”

Launch is a milestone.

It is not necessarily the product outcome.

How AI Can Help Before Development Starts

AI is also changing the discovery and requirements phase.

Modern AI-assisted workflows can help teams:

• summarize interview transcripts,
• identify recurring themes,
• convert conversations into draft requirements,
• identify missing acceptance criteria,
• organize customer feedback,
• analyze support conversations,
• generate prototype concepts,
• compare product assumptions,
• create initial user stories.

IBM's recent discussion of generative AI in software delivery specifically highlights requirements work such as converting unstructured conversations into structured user stories and identifying missing requirements.

However, AI should support product discovery rather than replace customer validation.

An AI system can organize what users said.

It cannot automatically prove that the underlying product idea has market demand.

The distinction is important:

AI can accelerate learning. It cannot turn an untested assumption into evidence simply by generating more documentation.

From Product Idea to Development-Ready Brief

Before handing a product to engineering, teams can create a concise development-readiness document.

Product Development Readiness Checklist

This does not mean every detail needs to be finalized.

In fact, excessive upfront documentation can create another problem: teams may spend too much time documenting assumptions instead of testing them.

The objective is decision readiness, not documentation for its own sake.

Discovery Is Not About Predicting the Future

No discovery process can guarantee product success.

Markets change.

Competitors respond.

Customer behaviour evolves.

Technology changes.

Business priorities shift.

That means product development must remain iterative.

The GOV.UK guidance recommends continuing user research through development and live phases so teams can respond to changing user behaviour, test new features and continuously improve the service.

A useful product lifecycle therefore looks less like:

Idea → Requirements → Code → Launch

and more like:

Idea → Research → Assumptions → Validation → Prototype → MVP → Measurement → Learning → Improvement

The second model accepts uncertainty instead of pretending it does not exist.

The Economics of Starting With the Right Questions

There is an understandable temptation to measure discovery by its immediate cost.

A workshop takes time.

User interviews require resources.

Prototypes require design effort.

Technical feasibility analysis requires engineering involvement.

But the better question is:

What does this activity prevent us from building incorrectly?

If two weeks of discovery prevent months of development on a product nobody needs, discovery is not simply an additional cost.

It is a risk-control mechanism.

PMI research has long emphasized that requirements problems can create rework, cost overruns and delays, while early requirements work can reduce the impact of those problems.

The exact return will differ from one organization to another, so teams should not treat historical statistics as a guaranteed saving for their own project.

Instead, they should use the principle:

Spend more effort reducing high-cost uncertainty before committing to high-cost execution.

A Practical Pre-Development Workshop

For teams preparing to build a digital product, a one-day workshop can be structured around seven questions.

1. What problem are we solving?

Write the problem without mentioning the proposed technology.

2. Who experiences it?

Identify the specific user group.

3. What evidence do we have?

Separate facts from assumptions.

4. How is the problem solved today?

Understand existing alternatives and workarounds.

5. What is the smallest useful solution?

Define the initial product boundary.

6. What could make the solution fail?

List technical, market, operational and adoption risks.

7. What must we learn before development?

Turn unknowns into research questions.

The output should not simply be a large requirements document.

It should be a clear set of decisions and remaining uncertainties.

Digital Product Failure Often Starts With a Decision, Not a Defect

A failed product is not always caused by bad code.

Sometimes the code performs exactly as designed.

The problem is that the design was based on an incorrect assumption.

The team may have:

• solved the wrong problem,
• targeted the wrong user,
• prioritized the wrong feature,
• underestimated technical constraints,
• misunderstood the customer journey,
• measured the wrong outcome,
• or launched without a clear definition of success.

This is why digital product development should begin with product thinking rather than immediately with engineering execution.

The earlier a team can identify uncertainty, test assumptions and clarify requirements, the fewer expensive decisions it has to reverse later.

Conclusion

Digital product development should not begin with code; it should begin with clarity. Before investing in design and engineering, businesses need to understand the problem they are solving, the users experiencing it, the evidence supporting the idea, and the outcomes they expect to achieve. Validating assumptions, defining a focused MVP, assessing technical feasibility, and establishing meaningful success metrics can help teams reduce unnecessary rework and make better development decisions. No discovery process can guarantee product success, but a structured approach can make uncertainty visible and help businesses avoid committing significant resources to the wrong product direction. Ultimately, the goal is not simply to build and launch a digital product, but to build something that solves a meaningful problem and can continue to evolve with its users and business goals.