The most expensive mobile product mistake is not a technical bug. It is spending months building a feature that does not solve an important problem. Validating an idea before writing code helps separate real demand from a team’s assumption.

Start with a problem, not features

Describe the problem in one sentence: who has it, when it appears, and how people solve it today. Then speak with people from the audience and ask about the last real instance, not a hypothetical “would you use this?” Behavior is usually more reliable than intent.

What to validate

  • How often the problem occurs and what it costs.
  • Current alternatives and their limitations.
  • The moment when people would change a habit.
  • The words users use to describe the need.

The YouTube Go story shows why field research matters. The team did not assume that users simply wanted “lighter video”; they studied how people understood data costs and which formats helped them make a decision.

A minimum experiment

Before building an app, test a one-page description, a prototype of the core journey, a manually delivered service, or a waitlist. Define the success criterion first: target sign-ups, completed test journeys, or repeat requests.

A strong validation does not guarantee success. It reduces uncertainty and shows which problem deserves attention first. That saves team time and makes the eventual MVP much more precise.

Source: Google Design: Making YouTube Go.