Artifacts: problem brief / PRD-lite

The discovery artifact must retain the logic of the solution: observation, problem, segment, evidence, assumptions, and the next test. If a document cannot be quickly updated after a new fact or it does not affect the choice of the team, its form has become more important than the work itself.

What is a problem brief and why is it necessary?

Definition

A problem brief is a one-page document that captures the essence of a business problem or an unmet user need. It appears at the earliest stage of Discovery, when the goal is to separate the real problem from the substitution of goals, to set the task so that the team and stakeholders speak the same language.

Why do you need it?

Competent problem brief allows you not to waste time on solutions without an important reason. It helps to cement the overall focus: what problem we are talking about, how it is confirmed, what is the value hypothesis, who will suffer if nothing is changed.

Problem brief for B2B SaaS

For example, a customer can’t find the right analytics for expenses within their company. The problem brief is fixed: The problem is a long search for reports → managers spend too much time → business loses money because of mistakes.
Additional: how the problem was identified (interview, analytics), a brief description of the scale, a list of affected roles.

PRD-lite: a simple solution specification

What is it?

PRD-lite is a shortened version of the Product Requirements Document that reflects only the essentials for a quick hypothesis test. In essence, this is a logical continuation of the problem brief: the team quickly describes what and why it will do to quickly validate the solution.

Why not the standard PRD

Regular PRD is cumbersome and slows down the discaveri. In PRD-lite, 1-2 pages are quite enough, where the goal, key requirements, MVP boundaries, how success will be measured and what NOT to do is fixed.

PRD-lite for a new filter in the product

The problem is that users lose deals because they can’t filter orders quickly.
The solution is to add a visual filter according to the status of the application to the main list.
The success metric is the time to find the right application and the percentage of users who applied the filter during the week.

How to prepare and use: checklist

Instructions for training

1. First fix the problem in the problem brief.
2. Check that there is confirmation from user interviews or analytics.
3. Find out what purpose and success metric the experiment should cover.
4. In PRD-lite, briefly write down the idea of the solution and why, specify the MVP, the risks and what you will not do.
5. Show both papers to key stakeholders before development starts.

Example:

In discovery-production practices, teams make such documents in Notion/Confluence, gathering quick links to data sources, new insights as they progress—not just once.

Mistakes and anti-patterns

Reality problems

It’s often wrong.

• Confuse the wording of the problem with the description of the desired solution
• There is no confirmation of the problem (naked hypothesis without support) PRD-lite turns into a long sheet or loses focus of value
• Skip communication with the development at the start, losing details

Example from life:

Inside the team decided that the user is uncomfortable to enter phones – and immediately began to do auto-completion, without checking whether this is really a key pain and often enter numbers manually.

What a good discovery artifact looks like

Principles

• It is clear why you need a document: to quickly fix / defend the hypothesis, not for the sake of a tick.
• Sufficient volume for informed decision and planning of fast tests
• Regular updates. Relevance is more important than format.

Example:

For the flow of discovery experiments in B2B fintech, all problem brief and PRD-lite were built into one database, from which it is easy to choose old initiatives, so as not to procreate duplicates and reuse the developments.

Recommended references for further reading

1. Product Discovery Techniques — Google Devs
2. Product Discovery Guide — Mind the Product
3. How to Create a PRD that isn’t a Waste of Time — SVPG

FAQ

1. Is it possible to combine PRD-lite and problem brief into one document?

Yes, if there are few questions and the audience is compact. The main thing is not to lose the structure: first the problem, then the solution.

2. When do you need a long PRD?

A long PRD may be warranted for a complex inter-team or regulatory initiative. In discovery, start with a minimal document that saves the problem, evidence, risks, and the next test; expand it as the cost of the error and the number of participants in the solution rise.

3. Who is responsible for preparing these artifacts?

Usually a product manager or a Discovery team leader, but it is important to engage analysts and designers to justify the problems.

4. Is it possible not to write documents in Discovery?

Without any artifact, the team quickly loses focus. At least a note is better than nothing.

5. Where to find such artifacts: Figma, Notion, Google Docs?

Depends on the team culture. It is better to easily comment, update and share links. Most often, notion or confluence.

6. What good examples can you see?

Recommended templates from SVPG and collections on Mind the Product (links above). There are real structures and options for quick tests.