Problem framing and assumptions

A good wording of a problem sets the user, context, obstacle, and observable consequence, but does not hide the solution inside. After framing, write out assumptions about value, behavior, channel, technology, and economics; be the first to test the one whose error will destroy the entire initiative.

Why you need framing and assumptions

Why Just Going to a Solution is a Bad Strategy

Any product team knows the temptation: faster in prototyping and piloting. But without a clear definition of the problem, it is easy to build unnecessary features. Framing and critique of hypotheses help steer the effort to the right point.

Example from practice
The B2B SaaS team decided to add a chatbot for support to the site. Without a clear understanding of the problem, a month later we got low usage. Framing showed that users did not have a lack of support, but an uncomfortable navigation in the product. Focusing on another issue saved months of work and budget.

The role of assumptions in discovery

Assumptions are what you believe to be true without proof. Without verification, they become traps and costly mistakes.

Example
The “health” mobile team suggested users were not filling out the diary because of the form being too long. Removed the excess, but still the retention has not grown. Then they interviewed users and found out that it was the uneven reminders. Assumptions testing changed the whole focus of discovery iteration.

How to correctly formulate the problem

Identify what is blocking the user, not what you want to do.

Framie problem in the format: “The user experiences X because Y leads to Z.”

Implementation in teams
At the start of the discovery session, the team does not write features (“add a button”), but scenarios: the buyer throws the basket at the payment stage, because he is afraid of erroneous write-off. It helps to remember that the focus is always on the user, not on technology.

Good problem framing: examples and mistakes

All right. The user often loses access to the support chat because it is unclear where and when he works, which delays the solution of the issue.

Bad: Let’s do an online chat without a work schedule.

** Anti-patterns:**
Feature framing, vague wording (“make it more convenient”, “add something”).

How to work with assumptions

How to find assumptions and prioritize them

For each problem, write out what the team thinks is self-evident: what the user wants, knows, knows.

Matrix impact/risks: If the assumption turns out to be false, how much does it affect the success of the decision?

Application:
The group discusses: we assume that customers will buy a subscription for a new feature. Let’s put it first for testing through custdev or experiment.

How to Check Assumptions – Quick Techniques

1. User interviews – get to the root, hear real motivation.
*2. Fake Door Experiments – to enable you to click and try an unavailable feature and measure interest.
**3. Data analysis: Confirm a hypothesis with actions, not words.

Example
In the product found: users allegedly want patterns. The Templates button leads to a stub with a questionnaire. Only 4% of clicks are clicked on – the rest pass by. So the assumption of high need is not confirmed.

How to document work: frameworks and formats

Problem statement format

There are standard canvases and formulas:

Jobs To Be Done:
When I want to be, I want to be.

HMW (How might we…):
How can we help a character do something to get value?

Example of JTBD in a real team When a user returns to the service after a break, they want to quickly remember what is planned so as not to waste time navigating.

Simple template for assumptions

It’s usually written down: We believe that [the assumption], and if we are wrong, there will be a [negative consequence].

** Example:**
We believe that users will want to launch exports, and if we are wrong, we will invest time in vain, and the feature will not be in demand.

See ProductPlan

How not to fall into traps

Typical errors

1. Start building a solution before checking the problem 2. Do not separate personal opinions from user insights 3. Do not make assumptions explicitly 4. Consider that any assumption is confirmed after one interview

Anti-team patterns

• The meeting discusses “what you would like”, without relying on data.
• The question is, “What will happen if the assumption is untrue?”

FAQ

What is the problem of framing at the start of discovery? It focuses the team on the real need, allows you not to get carried away with solutions that users do not need.

**How do you know that assumption is critical to success? Risk Assessment: If this assumption is wrong, the team will lose the most time or resources on unnecessary work.

**How do you make sure the problem reflects real user behavior? **
Observe users, communicate with them, look for confirmation in data and analytics.

**Is it possible to change the problem framing after the first stages of discovery? Yeah, that’s normal practice. Often, the focus shifts after the first interview, experimentation, or analysis.

**When can assumptions be considered verified? When independent confirmations are obtained through different methods: interviews, experiments, metrics.

Where to find templates and checklists on the topic? Recommended Atlassian Team Playbook, ProductPlan. There are structures for framing and validating assumptions.