Recommended resources
The freely available resources this lesson will direct you to.
Hello again. Last lesson, you made a provisional portfolio-domain choice using credibility, demand, user access, and feasibility. That choice gives you a place to investigate; it does not yet establish that a particular customer problem exists. To finish this module, you’ll turn one narrow task in that domain into an evidence-seeking problem statement: a clear account of what you suspect, whom it might affect, and what you need to find out. Allow about 40 minutes, including the resources and a draft for your portfolio file.
Frame the problem without deciding the solution
It is tempting to start a portfolio case study with a feature: “Build an AI assistant that writes defect summaries.” But that sentence does not tell you whether anyone struggles with the current handoff, what they do about it, or whether a template would help more than AI. A problem statement gives your investigation a focus while leaving possible solutions open.
The Double Diamond diagram places Discover and Define before Develop and Deliver. For this lesson, the useful distinction is between exploring what may be happening in a workflow and choosing a specific problem to examine more closely. Defining that focus does not mean you have already validated it.
Nielsen Norman Group’s Problem Statements in UX Discovery explains what to include in a statement and why early versions need not settle the root cause. Read the indicated parts before drafting.
Problem Statements in UX Discovery - NN/G
Read Nielsen Norman Group’s guidance for a concise, solution-neutral statement that can direct discovery rather than claim to complete it.
In “How to Write a Problem Statement,” read the three components, from the numbered list through the paragraph on organisational impact. Then, in the same section, read the five Ws, starting at the paragraph introducing that technique and ending just before the writing-quality guidance. Finally, read the scope guidance, from the explanation of focusing on one problem through the instruction to redraft. Notice especially that an unknown cause can remain unknown.
The article describes statements often written with research already in hand. Yours is earlier-stage. Keep its structure—context, affected people, and possible impact—but label unverified claims as hypotheses. Your experience in QA or delivery can help you identify a plausible workflow; it cannot substitute for accounts from people doing that work now.
Make the statement specific enough to investigate
A useful first draft answers four practical questions in two or three sentences:
- Who and when? Name an observable group and a particular moment in its work, not “all software teams.”
- What may be difficult? Describe the task or friction without naming a feature to build.
- Why might it matter? Separate a possible consequence for the person doing the work from a possible consequence for the organisation.
- What remains uncertain? Identify the most important fact or cause that discovery must establish.
You might use this scaffold, then rewrite it in natural language:
We suspect that [specific people], when [situation occurs], have difficulty [doing a task or achieving a goal]. This may [affect their work] and [affect an organisational outcome]. We still need to learn [the critical unknowns].
Treat “because” with care. If you know a cause from reliable evidence, include it. If you merely suspect that incomplete reports, unclear ownership, or scattered information cause the difficulty, say so—or leave the cause open. Naming a cause too confidently could steer you away from what users actually experience.
Compare these two illustrative drafts for a QA portfolio domain:
Premature solution: “QA teams need an AI tool that automatically produces complete defect handovers so developers can fix bugs faster.”
Evidence-seeking problem: “We suspect that QA engineers in distributed software teams have to revisit defect reports when developers request clarification after a handoff. If this happens often, interruptions may take time from testing and slow defect resolution. We need to learn how often it occurs, what prompts the requests, and how teams handle them today.”
The second draft defines a person, a work moment, and possible user and business consequences. It does not assert that clarification requests are common, that report quality is the cause, or that AI is the answer. Those are precisely the matters to investigate. It also stays narrow: “defect handoffs” is more workable for a portfolio case study than “improve software quality.”
Give each claim a route to evidence
A statement becomes evidence-seeking when it can be checked and changed. Keep a brief evidence note beside the statement, distinguishing what you know, what you infer from experience, and what you have not checked. For the illustrative QA statement, relevant evidence might include practitioners’ accounts of recent handoffs, their current workarounds, and—only where access is authorised—records showing whether clarification and rework occur. A memory from your own QA career is a useful lead, but it should be labelled as past experience, not current customer research.
The AltexSoft video Customer Interviews for Product Discovery offers a short preview of the kind of evidence you will seek. Focus on its contrast between recent events and predictions about a tool that does not yet exist; you will design and conduct interviews in the next module.
Customer Interviews for Product Discovery
Watch AltexSoft’s “Customer Interviews for Product Discovery” for a quick illustration of how to probe a suspected problem without pitching a solution.
Watch probing beneath answers to see why a reported difficulty needs clarification. Continue with recent experiences, which contrasts asking about what people did with asking them to imagine using a future tool. For your statement, concentrate on what could confirm—or weaken—its central claim.
Evidence seeking also requires an honest revision condition. If practitioners rarely encounter the difficulty, resolve it easily, or say a different group bears the cost, change the statement. If the friction is real but stems from a policy or handoff convention rather than missing information, change your account of the problem. You do not need to defend the first draft to produce a strong case study; showing how evidence changed your thinking is valuable product-management work.
Add a first draft to your portfolio file
Use about 12 minutes to carry your provisional choice forward from last lesson. Select one task in that domain and save a short entry with:
- A two- or three-sentence provisional problem statement naming the people, work situation, suspected friction, possible user and organisational impact, and a key unknown. Keep AI and other proposed solutions out of it.
- An evidence note identifying which claims come from your own experience and which remain assumptions. Do not invent interview findings, frequencies, or savings.
- A revision condition: the finding that would most seriously weaken your statement or make you choose a different problem.
If you chose IT support rather than QA, use the same structure for a specific moment such as escalation handoffs. If you cannot yet identify a reachable person who does the task, record that as a limitation rather than writing as though access were assured. You can investigate workflows without copying confidential employer tickets or entering customer information into an AI tool.
Conclusion
Your portfolio problem statement is a focused starting hypothesis, not a verdict and not a feature proposal. It names whose work you want to understand, where difficulty might occur, why it could matter, and what evidence could change your mind. Keep it concise, solution-neutral, and explicit about uncertainty.
In the next module, you’ll turn this statement into assumptions to test, then learn how to gather and use customer evidence to revise it.