Recommended resources
The freely available resources this lesson will direct you to.
Hello again. Last lesson, you clarified what an AI Product Manager leads and where specialist input or approval is essential. Before developing a portfolio product, there is a more basic choice: which problem space should you work in? A convincing case study needs more than an interesting AI feature. You need enough understanding of the work, evidence that the problem matters, access to people who experience it, and a way to demonstrate your decisions without using confidential data.
Today you’ll compare potential AI product domains on those four dimensions. Allow about 40 minutes, including the resources and a first version of a portfolio domain scorecard.
Choose a problem space before choosing an AI feature
A domain is an area of work or customer need, such as software quality assurance or internal IT support. A use case is a more specific task within it, such as helping a QA team prepare a defect handover or helping support agents draft a ticket summary.
That distinction matters because a feature idea can sound attractive while its surrounding domain is difficult to investigate. You could build a polished ticket-summary demo, for example, but struggle to learn whether agents find handovers painful, what information they must preserve, or whether anyone would approve the use of real tickets. Conversely, a less eye-catching workflow you can observe and discuss with users may produce a much stronger PM case study.
Start by looking for work that is repetitive, blocked by scarce expertise, or difficult to begin because information is scattered. OpenAI’s guide offers these as ways to source possibilities, then introduces an impact-versus-effort framework for narrowing them. It is written for companies selecting internal use cases; we will adapt it to an individual selecting a portfolio domain, where access and demonstrability matter as much as organisational impact.
Identifying and scaling AI use cases
Read OpenAI’s guide to generate candidate problem spaces and see how it separates expected impact from effort. Treat its examples as possibilities to investigate, not evidence that your own target users have the same needs.
Under “Identifying opportunities for AI impact,” begin at the sentence introducing three workplace challenges. Read the three challenges, then continue to the “Action items” list beginning “Ask your teams to list scenarios and tasks where they:” and ending “Use these lists to start sourcing possible spaces for new use cases.” Under “Gathering and prioritizing use cases,” read from “The challenge then shifts from discovery to prioritization.” through the “Impact/effort framework” and its four categories, ending with the description of high-effort, low-impact work. Focus on the difference between spotting a task and establishing that it is worth pursuing.
Your engineering, QA, and delivery experience gives you several plausible starting points. It does not mean every familiar workflow contains a validated customer problem. Familiarity earns you better initial questions; conversations and other evidence must establish the need.
The four tests for a portfolio domain
Microsoft’s use-case template separates business viability, user desirability, and technical feasibility. Its questions about business value, key users, operational risks, safeguards, and whether AI fits are useful prompts when assessing a particular use case.
For your domain choice, use four tests:
-
Personal credibility. Can you explain the current workflow and its constraints accurately, and can you distinguish firsthand experience from assumptions? Your QA experience may help you frame questions about defect handovers. It would not, by itself, establish expertise in clinical triage or prove that you have previously owned product strategy.
-
Market demand. Is there reason to believe a defined group experiences a consequential problem, and that an organisation might invest in addressing it? Look for the frequency and cost of the problem, the current workaround, who benefits, who controls a budget, and whether existing products already address it. Job adverts mentioning an AI capability may signal employer interest in that area, but they do not prove customer demand for your proposed product.
-
User access. Can you reach people who perform or oversee the work and obtain candid accounts of what they do today? A former colleague willing to speak about their workflow may be valuable; access to an employer’s private tickets or customer records is a separate permission question. Do not take confidential material into a portfolio project or public AI tool without explicit authorisation.
-
Portfolio feasibility. Within your available study time, can you produce an honest case study: discovery evidence, a narrow product proposal, a prototype or workflow demonstration, and a way to assess its limitations? A no-code mock-up using invented examples can demonstrate a product decision. It cannot establish production accuracy, data permissions, or commercial viability.
Market attractiveness and portfolio feasibility are different decisions. A large, important market may be a poor first portfolio choice if you cannot reach its users or responsibly illustrate its workflow.
A useful further check sits across all four tests: why might AI improve this task over a simpler approach? Last lesson’s comparison of an AI draft with a standard template still applies. When information is predictable and a checklist would solve the problem, the simpler option may be better. At this stage, you need a plausible reason to investigate AI—not a commitment to use it.
Compare domains without disguising uncertainty as a score
Consider three candidate domains. The descriptions below are illustrative hypotheses, not findings from user research.
| Candidate domain and possible task | Credibility | Demand | User access | Portfolio feasibility |
|---|---|---|---|---|
| Software QA: help prepare a defect handover from varied issue reports | Strong starting knowledge from QA work; current practices still need checking | Plausible time or quality problem, unverified | Potentially reachable QA contacts, if willing to participate | A narrow workflow can be illustrated with invented defects |
| IT support operations: help draft escalated-ticket summaries | Some related delivery and technical context; support-agent workflow needs checking | Plausible handover problem, unverified | Depends on whether you can reach actual agents or team leads | A draft-and-review flow can use invented tickets |
| Clinical triage: help prioritise patient cases | No stated domain expertise | Potentially important need, but unverified for a defined user and buyer | No stated route to clinicians or patients | Difficult to demonstrate responsibly without specialist input and appropriate data |
The previous lessons used ticket summaries to explain PM decisions. That makes them a teaching example, not an automatic portfolio choice. On the information available, QA may be easier to discuss credibly and illustrate safely. If you can reach support agents but not QA practitioners, however, support operations could become the better choice. The deciding evidence is still missing.
A simple one-to-five score can make comparisons visible, but write a short evidence note beside every score: “based on my experience,” “contact identified but not yet approached,” or “assumption only.” Do not total the numbers as though an unknown demand score were a measurement. In particular, weak user access or an inability to demonstrate the work responsibly should be treated as a reason to pause, even if the other scores look high.
This short excerpt from Dianna Yau’s Product Strategy Interviews: market entry reinforces two useful habits: examine users and competitors rather than the idea alone, and state the conditions under which you would proceed. Its example concerns a company entering the smartphone market, so borrow the decision logic, not its market estimates, for your portfolio choice.
Product Strategy Interviews: market entry
Watch Dianna Yau’s “Product Strategy Interviews: market entry” for a compact example of evaluating a market and making a conditional recommendation.
In market questions, note the prompts about potential buyers, competitors, and customer needs. Then watch conditional decisions: focus on how a recommendation can specify what must be true to proceed rather than pretending the missing information is already known.
For a portfolio domain, a conditional decision might read: “I will start with QA handovers if I can speak with practitioners about recent examples and find that handover problems are consequential; otherwise I will compare another accessible workflow.” That is more defensible than “QA is the best AI market.”
Record a choice you can test
Spend about 10 minutes adding a domain-selection note to your portfolio file. Name two or three candidate domains and one narrowly defined task in each. For each domain, record your four assessments—credibility, demand, access, and feasibility—alongside the evidence you have today and the most important unknown. Then mark one provisional first choice and one alternative.
Keep the final recommendation short. Include what would make you continue, what would make you switch domains, and how you could illustrate the workflow without exposing employer or customer information. This is a selection note, not yet a validated problem statement or a claim that you have conducted discovery. You will test the assumptions in the next module.
Conclusion
A strong first AI PM portfolio domain is not simply the biggest market or the most sophisticated AI idea. It is a space where you can ask informed questions, find evidence of a meaningful user and business problem, reach relevant people, and demonstrate your reasoning responsibly. Keep uncertain assessments labelled as uncertain, and make your choice conditional on what you can learn.
In the next lesson, you’ll turn your provisional domain choice into an evidence-seeking problem statement—one that identifies whose problem you intend to investigate without assuming your proposed AI solution is already the answer.