Documentation

Welcome to the platform documentation.

The platform helps founders, startup teams, and innovation leaders validate digital business ideas in a structured way. The goal is to make uncertainties visible early, check critical assumptions, and make decisions based on evidence rather than guesses.

Unlike classic product development approaches, the focus is not on shipping as fast as possible, but on learning as fast as possible. The platform follows Lean Startup principles and provides a structured framework for reviewing business ideas step by step, improving them, or realigning them when needed.

The goal is not to prove an idea as quickly as possible. The goal is to find out as early as possible which assumptions are actually true.

Table of Contents

• Lean Startup Principles
• Platform Validation Workflow
• Business Model Canvas
• Hypotheses
• Uncertainty Areas
• Priorities
• Evidence Types
• Canvas Mapping
• Metrics and Thresholds
• Experiments
• Measurements and Validation
• Overview Dashboard
• Making Decisions
• Versioning
• Best Practices
• Frequently Asked Questions
• Final Note

Lean Startup Principles

Why business ideas should be validated

Many business ideas fail not because of implementation, but because of false or untested assumptions. Often a lot of time is invested in building a product before it is clear whether a real problem exists, whether the target audience actually needs the solution, or whether people are willing to pay for it.

Typical risks are:

• The assumed problem does not exist or is not urgent enough.
• The target audience does not recognize the value of the solution.
• The solution does not match real user behavior.
• Customers are not willing to pay for the solution.
• The market is too small or too hard to reach.
• The implementation is technically, organizationally, or economically unrealistic.

The platform helps make such risks visible early and review them in a structured way.

The Lean Startup mindset

Lean Startup is an approach in which business ideas are not only planned, but tested early based on real evidence. Instead of building a complete product far in advance, the most important assumptions are formulated, tested, and evaluated.

The basic learning cycle is:

Assumptions are formulated => Tested => Learned from => Improved

This cycle is repeated until enough evidence exists to make a well-founded decision.

The point is not to make an idea look good or to confirm it as quickly as possible. The point is to learn early what works, what does not work, and which direction is worth pursuing.

Role of the platform

The platform digitally maps this learning process. It helps you:

• describe business ideas in a structured way
• make assumptions visible and reviewable
• document hypotheses, metrics, and experiments
• capture results in a traceable way
• derive validation status automatically
• preserve learning progress across versions

The platform does not run experiments automatically and does not replace customer feedback. It does, however, provide a clear workspace for organizing the full validation process in a traceable way.

Platform Validation Workflow

The typical workflow of the platform consists of several steps that build on one another.

Create an idea

An idea is the starting point of the entire validation process. It describes, at a high level, which problem should be solved and which solution is being considered.

Within the platform, an idea acts as the overarching workspace. It contains all versions, canvas content, hypotheses, experiments, measurements, and validation results.

Use the initial version

When an idea is created, a first version is created as well. This initial version is the starting point. All further changes, iterations, or pivots build on an existing version.

Versions help separate different development stages of an idea and make the learning process traceable.

Fill out the Business Model Canvas

The next step is to describe the business model in a structured way. The Business Model Canvas helps make the most important parts of an idea visible.

The canvas does not need to be perfect or complete at the beginning. It serves as a working base and can evolve with every new insight.

Derive hypotheses

Concrete hypotheses are derived from the canvas. A hypothesis is a testable assumption.

Example:

At least 10% of test users will subscribe to a paid plan for the validation tool within one month.

This statement can be tested. That is exactly why it is a suitable hypothesis.

Define metrics and experiments

For each hypothesis, you define how success should be measured. This includes a metric and a threshold.

You also plan an experiment that will be used to test the hypothesis. The experiment is documented in the platform, but carried out outside the platform.

Capture measurements

After an experiment has been carried out, the results are recorded as a measurement. This measurement contains the measured value, which is compared with the defined threshold.

Check the validation status

The platform derives the status of a hypothesis automatically from the experiment, metric, threshold, and measurement.

A hypothesis can have the following statuses:

• Not tested
• Validated
• Invalidated

Analyze the Overview

The Overview page shows the current validation status of a version. It makes visible which hypotheses have already been validated, invalidated, or not yet tested.

Decide on iteration or pivot

Based on the results, the user decides how the idea should be developed further.

An iteration is appropriate when the core idea still looks promising and should be refined further.

A pivot is appropriate when important assumptions have been disproved and a new direction should be explored.

The platform supports this decision with structured information, but does not make it automatically.

Business Model Canvas

What is a Business Model Canvas?

The Business Model Canvas is a tool for presenting a business model in a clear and compact way. It shows the central building blocks of a business idea and the assumptions behind them.

The canvas helps you look at an idea not only from the perspective of the solution, but also from the perspective of customers, market, revenue, activities, partners, and costs.

In the platform, the canvas forms the basis for later hypothesis building.

Customer segments

Customer segments describe who the solution is intended for.

Typical questions:

• Who has the problem?
• Which user groups should be reached?
• Are there different target groups?
• Who makes the purchasing decision?

Examples:

• Solo founders
• Startup teams
• Students

Value proposition

The value proposition describes the concrete benefit the solution provides.

Typical questions:

• Which problem is being solved?
• What benefit does the target group receive?
• Why should someone use this solution?
• What makes the solution different from existing alternatives?

Examples:

• Save time
• Reduce uncertainty
• Improve decisions

Channels

Channels describe how potential customers are reached.

Typical questions:

• Through which paths is the target group approached?
• How do customers learn about the solution?
• Which marketing or sales channels are realistic?

Examples:

• Website
• Search engines
• Social media

Customer relationships

Customer relationships describe how the relationship with the target group is established and maintained.

Typical questions:

• How are users supported?
• Is there self-service or personal support?
• How is trust built?
• How are customers kept active over time?

Examples:

• Self-service platform
• Documentation
• Email support

Revenue streams

Revenue streams describe how the solution generates money.

Typical questions:

• What do customers pay for?
• How is billing handled?
• Are there subscriptions, one-time payments, or other models?
• What willingness to pay exists?

Examples:

• Monthly subscription
• Freemium model
• One-time payment

Key resources

Key resources describe which resources are required for the business model.

Typical questions:

• Which technical resources are needed?
• Which people or skills are important?
• Which data, infrastructure, or tools are required?

Examples:

• Development team
• Cloud infrastructure
• Expertise

Key activities

Key activities describe which tasks are central for the business model to work.

Typical questions:

• What needs to be done regularly?
• Which activities create the main value?
• Which processes are critical?

Examples:

• Software development
• Product validation
• Marketing

Key partners

Key partners describe external partners that are important for the business model.

Typical questions:

• Which partners are needed?
• Which services are outsourced?
• Which collaborations can support success?

Examples:

• Payment provider
• Hosting provider
• Sales partner

Cost structure

The cost structure describes which costs are created by the business model.

Typical questions:

• Which fixed costs occur?
• Which variable costs occur?
• Which costs grow with usage?
• Which costs are critical for profitability?

Examples:

• Hosting
• Development
• Marketing

Hypotheses

What is a hypothesis?

A hypothesis is a testable assumption about a business idea.

Many statements about an idea are initially only guesses. A hypothesis makes that guess concrete, testable, and measurable.

Example of a good hypothesis:

At least 20% of surveyed founders would use a tool that helps them validate business ideas in a structured way.

This hypothesis is concrete because it contains a target group, an expected behavior, and a measurable quantity.

Example of a bad hypothesis:

Many people like the idea.

This statement is too vague. It does not define who is meant, what “like” means, or how success should be measured.

Why hypotheses matter

Hypotheses help you evaluate a business idea not as a whole, but as a set of individual assumptions that can be tested separately.

That makes it possible to see:

• which assumptions are especially critical
• which areas have already been tested
• where uncertainty still exists
• which experiments make sense next

Information collected when creating a hypothesis

When creating a hypothesis, several pieces of information are captured.

Typical fields include:

• hypothesis description
• uncertainty area
• priority
• evidence type
• canvas mapping
• later metric, experiment, and measurement

This structure helps ensure that hypotheses are not just collected, but systematically evaluated.

Uncertainty Areas

Each hypothesis is assigned to an uncertainty area. This makes it visible which kind of risk is being tested.

The platform distinguishes five areas:

• Problem
• Solution
• Market
• Monetization
• Execution

Problem

The problem area concerns whether the assumed problem actually exists and is relevant enough for the target group.

Typical questions:

• Does the target group really have this problem?
• Is the problem urgent enough?
• Is the problem already being actively solved today?
• Does the problem create real effort or pain?

Example:

At least 50% of the surveyed founders report experiencing difficulties in validating their business ideas in a structured manner within four weeks.

Problem hypotheses should often be tested very early. If no relevant problem exists, a solution is usually not worthwhile.

Solution

The solution area concerns whether the proposed solution actually solves the problem.

Typical questions:

• Does the target group understand the solution?
• Does the solution help with the concrete problem?
• Is the solution easy enough to use?
• Are there better alternatives?

Example:

At least 60% of founders rate the statement “The workspace helps me organize my validation activities more effectively” with at least 4 out of 5 points after four weeks of use.

Market

The market area concerns whether enough demand and a sufficiently reachable target group exist.

Typical questions:

• Are there enough potential customers?
• Is the target group reachable?
• Is there real interest?
• Is the market large enough for a viable business model?

Example:

At least 100 founders provide their email address on the idea validation platform’s landing page within one month.

Monetization

The monetization area concerns whether customers are willing to pay for the solution.

Typical questions:

• Is there willingness to pay?
• Which pricing model fits?
• Is the perceived value considered worth paying for?
• Are customers willing to subscribe?

Example:

At least 10% of test users subscribe to a CHF 9.90 monthly plan within one month.

Monetization hypotheses are especially important when the idea should become a financially viable product.

Execution

The execution area concerns whether the idea is technically, organizationally, or economically feasible.

Typical questions:

• Can the solution be built with the available resources?
• Is the technical complexity manageable?
• Can operations, security, and maintenance be implemented sensibly?
• Are important partners or resources available?

Example:

The first production-ready version of the platform can be developed and operated within six months by a team of no more than three developers using a cloud-based infrastructure.

Priorities

Priorities help identify the most important assumptions to validate first.

Not every hypothesis is equally critical. Some assumptions determine the success of the entire idea, while others are more about details.

High

A hypothesis with high priority concerns a central risk.

If it is wrong, the entire idea may be at risk.

Examples:

• The target group does not actually have the problem.
• Customers are not willing to pay.
• The solution is technically not feasible.

High-priority hypotheses should be validated early.

Medium

A hypothesis with medium priority is important, but not immediately existential.

Examples:

• One channel performs better than another.
• A target group prefers a specific feature.
• One pricing model is more attractive than another.

Low

A hypothesis with low priority concerns optimizations or less critical assumptions.

Examples:

• A specific wording improves conversion rate.
• An additional feature increases user satisfaction.
• A specific layout is preferred.

Low-priority hypotheses can be tested later.

Evidence Types

An evidence type describes the kind of insight used to validate a hypothesis.

The platform distinguishes four evidence types:

• Qualitative
• Quantitative
• Behavioral
• Monetary

Qualitative

Qualitative evidence is based on statements, opinions, observations, or open feedback.

Examples:

• Customer interviews
• open surveys
• feedback conversations
• usability observations

Qualitative evidence is especially helpful for understanding why people have a problem or why they consider a solution useful.

It is useful in early learning phases, but often harder to compare objectively.

Quantitative

Quantitative evidence is based on numbers and measurable results.

Examples:

• number of signups
• conversion rate
• click-through rate
• number of survey responses

Quantitative evidence helps show how often a behavior or level of interest occurs.

It is especially useful when clear target values can be defined.

Behavioral

Behavioral evidence shows what people actually do, not just what they say.

Examples:

• registration on a landing page
• click on a call to action
• use of a prototype
• start of a trial subscription

Behavioral evidence is often more meaningful than opinions because it reflects actual behavior.

Monetary

Monetary evidence shows whether people are willing to spend money.

Examples:

• purchase
• pre-order
• paid subscription
• binding payment intent

Monetary evidence is especially strong when validating willingness to pay and the business model.

Canvas Mapping

A hypothesis can be assigned to one or more canvas areas.

Example:

At least 80% of test users can complete a subscription purchase through an external payment provider within five minutes.

This hypothesis could be mapped to the following canvas areas:

• Key partners
• Key activities
• Revenue streams

Why is mapping useful?

Mapping helps make relationships within the business model visible.

It shows:

• which canvas areas have already been validated
• which areas still contain many open questions
• where the biggest risks lie
• which assumptions affect multiple parts of the business model

This makes the validation process easier to understand and evaluate.

Metrics and Thresholds

What is a metric?

A metric defines how success is measured.

Without a metric, a hypothesis is difficult to evaluate objectively.

Examples of metrics:

• number of signups
• conversion rate
• number of interview commitments
• revenue
• click-through rate
• number of active users

What is a threshold?

A threshold defines the result at which a hypothesis is considered fulfilled.

Example:

Metric: Number of signups

Threshold: >= 50

If at least 50 signups are reached, the success criterion is met.

The platform supports the following comparison operators:

• > Greater than
• >= Greater than or equal to
• = Equal to
• <= Less than or equal to
• < Less than

Units

Metrics can use freely defined units. The unit describes in what form a measurement is recorded and evaluated.

Typical units include for example:

• %
• signups
• clicks
• users
• visitors
• CHF
• downloads
• ratings

Example:

Conversion rate

• Unit: %
• Threshold: >= 10

This means that a conversion rate of at least 10% should be reached.

Example:

Signups

• Unit: signups
• Threshold: >= 50

This means that at least 50 signups should be reached.

Experiments

What is an experiment?

An experiment is a validation activity used to test a hypothesis.

Experiments are used to gather evidence.

Typical experiments are:

• customer interviews
• surveys
• landing pages
• ads
• prototype tests
• pricing experiments

What does the platform do with experiments?

The platform supports planning and documenting experiments.

An experiment can be described and assigned a status.

Typical statuses are:

• Planned
• Running
• Completed
• Cancelled

Important: the platform does not run experiments automatically.

That means:

• interviews are conducted outside the platform
• surveys are carried out with external tools
• landing pages or ad campaigns are run outside the platform
• the results are then recorded in the platform

Measurements and Validation

What is a measurement?

A measurement is the documented result of an experiment.

Examples:

• 63 signups
• 18 interview commitments
• 8% conversion rate
• CHF 240 revenue

The measurement is compared with the previously defined metric and threshold.

How does the validation status arise?

The platform derives the status of a hypothesis automatically.

The actual rule is:

• experiment completed
• metric with threshold available
• measurement available

Result: Validated or Invalidated

If the experiment is not yet completed or no sufficient data exists, the hypothesis remains in the Not tested status.

Not tested

A hypothesis is Not tested when there is not yet enough basis for evaluation.

That can mean:

• no experiment has been carried out yet
• the experiment is not yet completed
• no measurement has been recorded yet
• a threshold is missing

Validated

A hypothesis is Validated when the experiment is completed and the measurement meets the defined success criterion.

Example:

• Threshold: Signups >= 50
• Measurement: 63 signups
• Status: Validated

Invalidated

A hypothesis is Invalidated when the experiment is completed and the measurement does not meet the defined success criterion.

Example:

• Threshold: Signups >= 50
• Measurement: 18 signups
• Status: Invalidated

An invalidated hypothesis does not automatically mean the entire idea is bad. It does, however, show that a specific assumption could not be confirmed.

Overview Dashboard

The Overview page summarizes the current validation status of a version.

It is a central part of the platform because it shows not only individual hypotheses, but also the overall picture of the current idea.

What does the Overview show?

The Overview shows among other things:

• total number of hypotheses
• distribution by validation status
• distribution by priority
• distribution by evidence type
• evaluations per uncertainty area

For each uncertainty area, it is visible how many hypotheses there have been validated, invalidated, or not yet tested.

Why is this important?

Individual hypotheses matter. But the overall picture matters even more.

The Overview helps you identify:

• which areas have already been reviewed well
• where many open assumptions still exist
• which risks are especially critical
• which areas need more experiments

Making Decisions

The platform does not make business decisions automatically. It does, however, help prepare decisions more effectively.

Many validated hypotheses with high priority

This is a positive signal.

It shows that important assumptions are supported by evidence.

Still, you should check whether any central areas remain open, especially monetization and market.

Many invalidated hypotheses with high priority

This is a critical signal.

If central assumptions have been disproved, the idea should not simply be continued unchanged.

Possible consequences:

• re-examine the problem
• adjust the target group
• change the solution
• revise the business model
• create a pivot

Many not tested hypotheses

This means there is not yet enough evidence.

In that case, a major implementation decision should usually not be made yet. Instead, more experiments should be planned.

Validated problem hypotheses

Validated problem hypotheses indicate that there may be a real need or a relevant pain point.

That is often an important basis for further validation.

Invalidated problem hypotheses

When problem hypotheses are invalidated, you should proceed with particular caution.

Without a relevant problem, a solution is usually hard to justify.

Validated monetization hypotheses

Validated monetization hypotheses provide indications of willingness to pay.

This is especially important when the idea is meant to become a financially viable product.

Invalidated monetization hypotheses

If monetization hypotheses are invalidated, that does not necessarily mean the entire idea must be discarded.

Possible adjustments:

• different pricing model
• different target group
• different scope of service
• different payment logic

Versioning

Versioning helps document learning steps in a traceable way.

Instead of continuously overwriting an idea, new versions can be created. This keeps it visible how the idea has developed and which insights led to changes.

Initial version

The initial version is the first version of an idea.

It is created automatically when an idea is created and forms the starting point of the validation process.

Iteration

An iteration is used when the core idea still seems promising and should be developed further.

In an iteration, the current state is carried over completely.

Carried over:

• Canvas
• hypotheses
• metrics
• experiments
• measurements
• validation status

An iteration is appropriate when existing assumptions should be refined further or additional insights should be gathered.

Example:

The target group is interested, but the value proposition needs to be formulated more clearly.

Pivot

A pivot is used when important assumptions have been disproved and a new direction should be explored.

For a pivot, the following are carried over:

• Canvas
• validated hypotheses
• not tested hypotheses

The following are not carried over:

• invalidated hypotheses

A pivot helps you learn from disproved assumptions without losing the entire learning process.

Example:

The original target group shows no willingness to pay. Another target group may be more relevant.

Iteration or pivot?

An iteration is appropriate when the direction is basically right.

A pivot is appropriate when central assumptions have been disproved and a significant change is needed.

The platform provides the necessary information. The decision remains intentionally with the user.

Best Practices

Start with the biggest risks

Test the assumptions that determine whether the idea succeeds or fails.

A nice feature or a polished design matters less if it is still unclear whether a relevant problem exists at all.

Validate problems before solutions

Before testing a solution, it should be clear that the problem really exists.

A solution for a problem that is not relevant is rarely successful.

Make hypotheses concrete

A good hypothesis should be measurable.

Bad:

Users like the platform.

Better:

At least 30% of test users create at least three hypotheses within one week.

Use clear thresholds

Define in advance which result counts as success.

That prevents results from being interpreted retroactively to fit the desired outcome.

Weight behavior more heavily than opinions

People often say they would use or buy something. More meaningful, however, is what they actually do.

Behavioral and monetary evidence are therefore often especially valuable.

Document negative results too

Invalidated hypotheses are not a failure.

They show what does not work and help you make better decisions.

Test as specifically as possible

An experiment should ideally test one concrete assumption.

If too many things are tested at once, it becomes hard to tell why a result occurred.

Frequently Asked Questions

Does the platform run experiments automatically?

No. Experiments are planned and documented in the platform, but carried out outside the platform.

Does the platform automatically judge whether a business idea is good?

No. The platform evaluates individual hypotheses based on defined measurements and thresholds. The overall business decision remains with the user.

Can an idea have multiple versions?

Yes. An idea can have an initial version as well as additional iterations or pivots.

What is the difference between an iteration and a pivot?

An iteration develops the existing direction further and carries over the full current state.

A pivot changes the direction and carries over only validated and not tested hypotheses. Invalidated hypotheses are not carried over.

Does the canvas have to be fully completed?

No. The canvas can be filled out gradually. What matters is that the central assumptions are made visible.

Does every hypothesis need a metric?

For objective validation, every hypothesis should have a metric and a threshold. Without a measurable criterion, the status cannot be derived reliably.

What does Not tested mean?

Not tested means there is not yet enough basis for evaluation. This can be because there is no completed experiment or no measurement yet.

Is an invalidated hypothesis a bad thing?

No. An invalidated hypothesis is a learning result. It shows that an assumption could not be confirmed and should be revised or discarded.

Does the platform replace customer feedback?

No. Customer feedback happens outside the platform. The platform helps document and evaluate that feedback in a structured way.

Who is the platform for?

The platform is especially suitable for founders, startup teams, innovation leaders, and anyone who wants to validate digital business ideas in a structured way.

Final Note

The platform is not an idea generator and not an automated business coach.

It does not replace customer feedback, market research, or entrepreneurial judgment.

It does, however, provide a structured framework for making assumptions visible, planning experiments, documenting insights, and making decisions based on evidence rather than guesses.

The goal is not to confirm every idea.

The goal is to learn faster which ideas truly have potential.