Problem validation before building: a practical sequence

Problem validation before building

Problem validation before building is the work of checking that a specific group has a painful, recurring job, and that they already spend time or money on workarounds, before you commit to a product build. You are not asking whether people like your idea. You are looking for past behaviour, repeated friction, and language they use without prompting. A clear problem statement beats a feature list at this stage.

This article is for founders and innovation leads in Switzerland who are tempted to open a repo or hire a builder first. It stays on the problem layer. For landing pages, concierge tests, interviews, and pre-sales as a full menu, see how to validate a startup idea. That guide is broader; here the focus is narrower: prove the problem is worth a build decision.

Problem validation

Evidence that a defined group experiences a job often enough and painfully enough to change behaviour.

Solution validation

Evidence that your proposed product changes behaviour or wins a commitment, usually after the problem is credible.

Assumption

One sentence you could falsify, for example who hurts, how often, and what they do today instead.

How to run problem validation before you write code

Treat the work as a short sequence, not a one-off chat. You can finish the first pass in a week if you keep the scope tight.

1. Write the problem in one sentence

   Name the person, the situation, and the cost today (time, money, risk, embarrassment). If you cannot name all three, you are still at idea stage.

2. List where the pain shows up

   Inbox, spreadsheet, phone call, paper folder, agency invoice. The place tells you who to interview and what to watch for.

3. Interview for past behaviour

   Ask for the last time the problem happened, what they tried, and what they paid. Do not show your solution until the story is on the table.

4. Score pain and frequency

   Note how often it happens and whether they already hired, bought, or built a workaround. Enthusiasm for your pitch is not a score.

5. Decide what would falsify the problem

   Write what you would need to hear to park the idea. If nothing could change your mind, you are not validating, you are collecting reassurance.

What counts as evidence, and what does not

Strong signals look boring: a recurring story across strangers, the same workaround in three interviews, money already spent on a partial fix, or a process everyone hates but nobody has replaced because the alternatives failed.

Weak signals include “great idea” from friends, a full waitlist with no follow-up action, a single enthusiastic buyer who will not put time on the calendar, and desk research that only proves the market exists on paper. Trends and reports can set context; they do not replace behaviour in your segment.

What problem validation does not prove

Even solid problem validation leaves gaps. It does not show that your feature set wins, that strangers will pay your price, that acquisition will work, or that you can build and operate the product within your constraints. It also does not protect the idea: under Swiss practice, ideas as such cannot be protected, only how you execute and what you brand (IGE overview on ideas).

A made-up example: supplier reminders in a small firm

A made-up example: a founder targets office managers in firms with 20–80 staff in German-speaking Switzerland. The hypothesis is that chasing suppliers for missing delivery notes wastes several hours a week and causes invoice delays. They interview eight managers they do not know personally. Six describe the same loop: email the supplier, wait, ask finance, escalate internally. Four already use a shared spreadsheet someone built years ago. None mention an app the founder pitched. Two say they would not add another login for “just reminders”. The founder parks the app idea and reframes the problem as “finance needs proof of delivery before approval”, which points to a different buyer and a sharper test. No code was written; the falsifier was “managers will not adopt a standalone reminder tool”.

Who should push harder, and who should skip

When the Product Validation Package fits

The Product Validation Package fits when the problem looks real enough to test with a deployed product, paid acquisition, and measured usage, not when you still need the first dozen honest interviews. Weeks 1 to 4 ship a real app; weeks 5 onward test whether behaviour matches the problem you validated on paper. If you are not there yet, stay in discovery before you book a build conversation on the contact page.