ExperianMy first experience inside a structured innovation team, and the thinking about product validation I have applied in every role since

1. The Situation

Before Experian I had spent several years in a commercially driven environment with direct ownership over supplier relationships, third-party roadmaps, and live product decisions. I moved quickly and learned by doing.

Experian was my first experience inside a structured innovation team: a small group whose job was to develop net-new consumer products, none of them yet generating revenue. The team evaluated ideas rigorously before committing to build them, and the thinking behind that evaluation changed how I approach product development.

2. You Will Always Find Out

Product validation starts from a single uncomfortable truth: you will always find out whether an idea has product-market fit. Every product, built fully or not, eventually meets the market and gets its answer. The only variable is how much has been invested by the time that happens.

Most product ideas do not succeed. Sometimes it is the idea itself, sometimes it is the framing, the positioning, or the commercial model. The gap between what a product’s creator believes it is worth and what a customer actually values is almost always larger than expected, and the reasons are varied. That is the statistical reality of innovation.

If you build the full product before testing the idea, finding out costs months and significant budget. If you test the idea before committing to it, finding out costs days and a small ad spend. So you delay investment for as long as possible, and make decisions based on evidence rather than assumption.

Product thinking: You will always find out whether an idea has product-market fit. The only variable is how much you have invested by the time you find out.

3. Make It Specific Enough to Test

The first discipline with any new idea is making it specific enough to test.

Specificity is what makes a proposition testable. “Let’s do something in identity protection” sounds interesting, but a proposition earns its value when it is precise enough to generate a question worth answering.

That means expressing every idea as a value hypothesis: because this specific problem is felt by this specific person, they will value this specific solution. Each clause is a separate claim that can be tested independently.

Consider a rental proposition I worked on: because landlords screen tenants on credit history, a person with a thin credit file who has been declined a tenancy will value a service that presents their financial profile to prospective landlords in a way that demonstrates reliability. That is testable. You can ask whether people in that situation exist in sufficient numbers, whether the problem is felt as described, and whether they would value that specific form of resolution.

Breaking a proposition into its components also tells you where to look if a test fails. Was the customer assumption wrong? The problem assumption? The solution assumption? Each gives a different answer about what to do next.

4. Would They Actually Change?

A proposition can pass the specificity test and still fail a harder one: would the customer actually change their behaviour to adopt the product?

This is what asking about the reasonable alternative forces you to confront. What does the person do today, in the absence of the product? The honest answer, more often than product teams want to admit, is that they manage. The problem exists but it is tolerable. Their workaround is imperfect but familiar, costs them nothing new, and requires no change. A new product asks them to do something different: pay for something, learn something, trust something new. That is a real ask against a baseline of fine, actually.

Back to the rental proposition. A person with a thin credit file trying to secure a property does things today. They offer a larger deposit. They provide extra references. They explain their circumstances directly to the landlord. These workarounds are imperfect. They work often enough. The question is: is this problem painful enough, and frequent enough, that people would adopt a product to address it, or are they mostly getting through without one?

The reasonable alternative is the most grounding question in early product development and the most frequently skipped. The answer is sometimes that people are genuinely fine with the problem they have. That is a valid answer, and it is better to know it before building than after.

Product thinking: The reasonable alternative is a comparison to doing nothing. If doing nothing is acceptable, the problem is unlikely to change behaviour.

5. Is It Yours to Build?

Even a well-specified proposition, with a genuine problem and a customer who would change their behaviour to solve it, still needs to fit the team or organisation building it.

Then there is purpose fit. Does this idea sit within the scope of what you are for? Does your position, your data, your expertise, or your relationships give you a natural advantage in pursuing it? If someone else built this instead, would they be starting from the same place as you?

The reason this matters is to focus effort where it compounds. Experian had assets in consumer credit data, financial identity, and regulatory trust. A proposition that drew on none of those assets was simply one anyone could pursue, starting from the same point as everyone else. Experian building a pair of trainers is where you end up if the question goes unasked.

This question applies beyond Experian. Any product team deciding what to build next, or any individual deciding where to spend time, benefits from asking not only “will this work?” but “are we the right people to make it work, and does our position give us a genuine head start?”

6. Test Before You Commit

Once a proposition had passed those filters, the work was to test it at the lowest possible cost before committing to building it.

The team used a ladder of progressively more expensive experiments: flat designs shown to users, clickable prototypes, live marketing pages promoted through search and display advertising, partial prototypes where parts of the experience were simulated manually, and full working prototypes. Each rung cost more than the one before. The discipline was to answer the most pressing question at the cheapest stage before spending more.

The sequencing was deliberate. Desirability came first: do customers actually want this? Feasibility came second: can we build it? Commercial viability came third: can we make money from it? This order matters because desirability is the gate everything else depends on. Confirm that someone wants it before investing in whether it can be built.

The marketing page test was the most instructive tool in the ladder. You built a page for a product that did not yet exist, described it as if it were live, promoted it through paid search and display, and measured what real people did. Not research participants giving polite feedback in a room. Real people, making real decisions with their own time and attention.

The search terms that brought them to the page were particularly revealing. They showed how customers described their own problem, in their own words, without prompting. Running several pages with different framings of the same proposition showed which description resonated and which left people indifferent. All of this before any product had been built.

Safety Owl, a product designed to help parents, teachers, and children manage online safety risks, went through user research with real families, including sessions at a school. What parents described as their primary fears was, in several cases, different from what the original proposition had assumed. The testing sharpened both the hypothesis and the design considerably.

7. Keep Testing as You Build

The same thinking applies through development.

A prototype that functions is evidence that the product works mechanically. Whether the right hypothesis is being tested is a separate question. As you build, you are making continuous assumptions about the solution: which features matter most, what the product should do first, which problem it should prioritise. Each of those assumptions can be right or wrong, and the cost of discovering a wrong one compounds the longer it goes untested.

The same questions that apply before building apply during it. Is what you are building actually addressing the problem? Are the features you are adding genuinely improving the customer’s situation, or are you building assumptions on top of assumptions? Would the customer, at this stage of the product, still prefer what they had before?

Some products reach a point where the core mechanism appears to be working but the underlying assumption is fundamentally flawed (something I explore further in the Tracr story). Iteration alone cannot fix that. The validation mindset is what prompts you to step back and question whether the right thing is being measured at all.

Pivoting is a normal part of this. A pivot is the discovery that a hypothesis was wrong, at a stage when changing direction is still cheap. Successful products, in retrospect, look like straight lines. What actually happened was a series of adjustments as the team learned that the original hypothesis needed revision. Expecting this, and preserving the ability to respond to it, is the whole point.

8. What I Carried Forward

The practices from this period were later adopted more widely across the business, and the thinking has stayed with me since.

The argument extends further: product organisations succeed or fail based on how they balance commercial and technology forces, and validating before investing is a structural condition for sustainable speed. I explored that in “The Role of Product, and What Comes Next”.

The tools have changed since then. Building is cheaper. Experiments are faster and cheaper to run. The threshold at which it becomes tempting to skip validation and simply build has shifted. The underlying logic remains. You can move faster than ever and still commit heavily to the wrong direction if the hypothesis goes untested. Modern technology changes the calculations. The reasoning holds.

What I took from this period is a set of questions I ask by default:

• What problem does this actually solve, and does the customer feel it?
• What do they do today without the product, and is that tolerable?
• Is this ours to build, and does our position give us a genuine advantage?
• What is the cheapest way to find out whether we are right?
• As we build, are we still solving the right problem?

Experian was where I learned to ask them. I have applied them in every role since.

For a recent example of the same thinking applied at the start of a client engagement, see the Medico-Legal Agency Engagement story. For a demonstration of the same framework applied to an open ideation brief, generating and invalidating ideas before arriving at a surviving proposition, see Start With the Problem.