Book a meeting

An MVP that gives an answer before the budget runs out.

We find the main uncertainty, choose the shortest way to test it and build only the part of the product needed for the next decision.

Discuss new product See our approach

Hypothesis · Risk · Verification · Data · Solution · Investment

“We need to build an MVP quickly and enter the market” First we get an answer. Then we increase the investment

Problem not in number features

A reduced product is not an MVP if it does not help make a specific decision.

The team may remove some features, launch the first version quickly and still fail to test the main assumption. Users see a product, but the business does not understand whether the problem matters, whether people change their behaviour or whether they are ready to pay.

We first determine the decision the business must make, then design the minimum evidence sufficient for that decision.

What happens next

The next stage is planned not on facts, but on the desire to fix the first version with additional features.

Time and budget grow while the main question remains unanswered.

MVP is not the minimum product. The minimum investment sufficient for a reliable answer.

Uncertainty funnel: idea, assumptions, main risk, test, fact and decision

Idea · assumptions · main risk · test · fact · decision

Uncertainty · cost of mistakes

The most expensive assumptions are those that that was tested only after the entire product was developed.

At the start of a new product, more is unknown than known. The problem is not uncertainty itself, but investing in segment, value, behaviour, monetisation and architecture at once without testing any of them separately.

The budget was spent on a product version

Verification began after launch

  • collected requirements from different participants
  • chose features by voting
  • designed all major sections
  • built the full foundation
  • launched immediately to a broad audience
  • started finding out after launch which problem the product solves better than alternatives

If the main assumption is not confirmed, the change must concern the product logic, not just a feature

The budget was invested in an answer

Every stage is based on a fact

  • defined one key decision
  • found the riskiest assumption
  • chose a sufficient testing method
  • limited the segment and scenario
  • fixed the criteria in advance
  • increased scope only after receiving facts

Every next stage is based on a confirmed decision, not an expanding cost of the initial mistake

We do not reduce product ambition. We reduce the amount that the business risks losing on every untested assumption.

When needed test

MVP is needed when, before a large business investment, lacks answers, not features.

  1. 01

    It is unknown whether the problem matters enough

    The risk is building a convenient solution for a challenge users are not ready to change behaviour or pay for.

  2. 02

    It is unclear who the first segment is

    The risk of creating a compromise product for several audiences and being essential to none.

  3. 03

    The team understands the value, but users have not validated it

    The risk of investing in a solution that does not fit the real context.

  4. 04

    It is unknown whether users will complete the key scenario

    The risk of building a system around behaviour that does not occur in practice.

  5. 05

    Monetisation exists only in a financial model

    The risk of getting interest without willingness to pay.

  6. 06

    The entire platform is planned for launch at once

    The risk of testing several assumptions at once and not understanding the reason for the result.

An MVP is not needed if the main uncertainty has already been tested and the challenge is scaling a validated model.

We use an MVP only where testing is cheaper may prevent a more expensive mistake.

Strategy → evidence → decision

Strategy defines which assumptions to test. The MVP format which evidence will be sufficient.

  1. 01Business decisionWhat the company will decide after testing: continue, change the segment, revise the model or stop the project.
  2. 02AssumptionWhich fact is still unknown and could make the next investment wrong.
  3. 03Segment and scenarioWhose behaviour will provide a relevant answer and which action the user must complete.
  4. 04Method testingInterviews, a prototype, a manual service, a demand test, a concierge approach or a working version.
  5. 05CriterionWhich result will be sufficient for the next decision.
  6. 06Next investmentWhat is worth building after receiving the answers.

01 · Interviews and research

When you need to understand the problem, context and current alternatives.

  • Tests whether the problem exists and how costly it is for the user
  • Does not verify whether people change behaviour in a real journey
  • Development not needed

We do not start with questions about what we can build in time. We start with questions what evidence is needed for the next investment.

Method

Before the first layout, we determine not product features but assumptions, which may make them unnecessary.

Natalia Sheker is personally responsible for the product hypothesis, risk priorities, testing format and first-version boundaries.

You discuss the product with a person responsible for which questions are tested and whether the answers are reliable.

  1. 01

    We separate facts from assumptions

    We document what the team knows, believes and cannot yet prove. The budget is not spent on confidence that exists only inside the team.

  2. 02

    We find the most expensive questions

    We define the assumptions whose failure would devalue most of the next stage. Critical risk is tested before secondary risk.

  3. 03

    We choose the minimum proof

    We define the least expensive format that will provide a reliable enough answer. We develop only where the necessary data cannot be obtained otherwise.

  4. 04

    We design a complete journey

    We create not a set of separate screens, but a path from need to result. The user demonstrates real behaviour instead of evaluating a concept.

  5. 05

    we document decision criteria

    Before launch, we define which data leads to continuation, change or stopping. The team does not continue investing simply because it has already spent money.

I – Questions

The key assumptions

Which business decisions follow the test and what they may change.

II – Evidence

A sufficient format

The least expensive way to get a reliable answer, including an option without development.

III – Criteria

Decision conditions

What it means to continue, change direction or stop the project.

Our result is not simply a launched MVP. It is a set of decisions the business can make based on its own evidence.

Result stage

After the strategy stage, you know what must be tested, how to test it and how much to invest in getting answers.

  1. 01

    Map of facts and assumptions

    What is already known, what needs proof and which decisions depend on it.

  2. 02

    Risk priorities

    Which assumption needs to be tested first.

  3. 03

    Target segment

    Whose behaviour will provide a relevant answer.

  4. 04

    Product hypothesis

    Which problem, value and behaviour change are being tested.

  5. 05

    Testing format

    Research, prototype, manual scenario, demand test or working MVP.

  6. 06

    Complete user scenario

    Which action the user must complete from need to result.

  7. 07

    Boundaries first version

    What must be created, what can be done manually and what does not need testing yet.

  8. 08

    Decision criteria

    Under which conditions we continue, change or stop the product.

  9. 09

    Next-investment plan

    What is developed after the hypotheses are confirmed.

  10. 10

    basis for estimate

    An agreed scope instead of an approximate feature list.

Stage artefact: assumption map, risk priorities and decision criteria

Materials that remain with the client after the first stage

The result stage has standalone value and does not oblige you to order an MVP or further development with Sheker.Agency. If the main assumptions can be tested without development, we will not sell you development.

Launch context

A new product does not launch in a vacuum. Business, data, brand existing systems affect the speed of testing.

I

Existing business and team

which customers, channels and capabilities can already be used, who makes decisions and who will be responsible for the product after launch.

II

Data

What information is already available and what is missing for testing.

III

Acquisition channel

How the product will get its first relevant users.

IV

Existing systems

What needs to be integrated now and what can wait until the model is validated.

V

Brand legal constraints

What affects the testing method, communication and work with users.

VI

Operational part

which actions can be done manually for a while without distorting the test result.

We do not add the entire future product infrastructure to the MVP, if it is not needed to answer the current questions.

After launch

After launch, we do not seek confirmation of the idea. We seek data for the next decisions.

01

Does the segment recognise the problem

02

Does it understand the proposed value

03

Does it start the key scenario

04

Does it reach the result

05

Does it repeat the behaviour

06

Is it ready to leave data, time or money

07

Where manual help is needed

08

Which assumption became the next constraint

  1. A

    Continue

    The core hypothesis is confirmed; investment can increase.

  2. B

    Change

    The problem exists, but the segment, value or journey needs review.

  3. C

    Stop

    The data do not confirm sufficient value for the next stage.

Stopping the wrong direction after an inexpensive test is also a result that saves the client money and months of work.

Typical situations

Three decisions that change testing cost.

We do not publish customer metrics or internal data. We show the decision logic and what it enabled the team to decide.

The entire platform was planned at once

Starting assumption

The product will work only when all roles, sections and integrations are ready.

Superficial decision

Build the full foundation and launch to a broad audience to “collect feedback”.

Key question

Which single assumption, if wrong, devalues most of this work?

Testing method

One segment and one completed journey with fixed success criteria.

Solution made possible

The business saw real behaviour before investing in the rest of the platform and changed the priority of sections.

A corporate idea without a defined first segment

Starting assumption

The product is needed by several different audiences at once, so it must support all their journeys.

Superficial decision

Collect requirements from all interested departments and implement a compromise.

Key question

Whose behaviour will provide the most reliable answer about value?

Testing method

Interviews and a prototype for one segment with the most expensive problem.

Solution made possible

The first-version scope was reduced and the other audiences’ requirements moved to later stages.

The value could be tested manually

Starting assumption

Testing demand value without automation is impossible.

Superficial decision

Build a system with automated journeys to validate demand first.

Key question

Does the result create value if a person performs it for now, rather than a system?

Testing method

Manual service for a limited number of users with fixed criteria.

Solution made possible

We automated only the steps that confirmed value and repeatability.

Format and cost

The first-version budget is determined not by the number of desired features, but by The cost of sufficient evidence for the next business decision.

Strategy and plan testing4–6 weeks

from $10 000

The product’s key question and the way to obtain a reliable answer.

  • Research, assumption map and risk priorities
  • Target segment and product hypothesis
  • Testing format and scenario
  • Decision criteria
  • Boundaries first version and basis for estimate

The stage has standalone value. If development is not needed for testing, the result will be a test plan without building an MVP.

Send an enquiry

Working MVPfrom 8 weeks

from $25 000

Working evidence sufficient to test the main hypothesis.

  • Strategy and architecture
  • One target segment and one completed journey
  • Minimum necessary roles and data
  • analytics testing and launch
  • Data collection and a decision about the next stage

This is not a shortened copy of the future product.

Send an enquiry

Launch and growth productfrom 12 weeks

Custom scope

Typical projects start at $50,000. The exact budget is determined after the strategy stage and depends on the validated model.

  • complexity of the key journey, roles and data
  • Integrations and security
  • Launch channel and operating model
  • level of uncertainty
  • Scope next stage

A product is not estimated by feature count.

Send an enquiry

{{prices require final approval from the Sheker.Agency owner before publication}}

Enquiry

Before assessing the MVP, we need to determine which questions it must answer.

In the first conversation, we discuss the idea, business context, segment, main assumptions and decisions you must make. We define whether testing needs development, a prototype, a manual journey or another format.

If answer can get without creation product, we will say about this to start costs.







    We will send confirmation and a meeting link. No presentations – straight to your numbers.

    The first conversation is about the product’s most expensive assumption and the cheapest reliable way to test it, not selling the largest development team. Project materials will not be published or shared with third parties.

    Related services Development SaaS-products Development B2B-platforms Development marketplaces Development digital products

    INFO@SHEKER.AGENCY+38 097 789 84 09
    +38 098 698 94 77
    Viber · Telegram · WhatsApp