Defining the Platform’s Primary User and Decision-Support Problem

Hello, and welcome to the capstone-framing module. This course will progressively turn an enterprise intelligence-platform concept into a buildable, governable, deployed product. Before choosing services, models, databases, or cloud infrastructure, we need to decide whose consequential work the platform improves.

This first lesson establishes a disciplined starting point: identify one primary user and articulate the decision-support problem that makes the platform worth building. The result is a working problem hypothesis—not a feature list, not an architecture, and not yet a business case.

---

Start with the problem, not the AI

An enterprise intelligence platform can easily become an unfocused promise: “a chatbot over company documents,” “an AI assistant for everyone,” or “a central knowledge hub.” Each phrase names a technology or a broad aspiration. None says who is struggling, what decision they must make, or why the current process is inadequate.

A useful capstone begins with a narrower claim:

A defined person, in a recurring work situation, must make or recommend a decision under uncertainty. The platform should improve the evidence available to that person while preserving appropriate human judgment.

NNgroup’s short explainer establishes why this matters and introduces the structure we will use.

A strong statement contains three connected elements:

1. User: a specific role or researched user segment, described in a way that recalls its operating context.
2. Need: an action the person needs to perform, expressed without assuming a product feature.
3. Goal or insight: why that need matters to the person and the organization.

The familiar format is:

[A specific user] needs [to perform an action] in order to [achieve a meaningful goal].

For this capstone, add one more layer beneath that sentence: the decision being supported. Decision support is more precise than information access. A platform is not valuable merely because it retrieves documents; it is valuable if better evidence helps a responsible person decide, recommend, prioritize, approve, or escalate more effectively.

---

Choose a primary user, not “all enterprise employees”

Enterprise products involve many parties, but they do not initially serve all parties equally. The primary user is the role whose recurring decision problem will drive the first product scope. This is not necessarily the budget holder, the executive sponsor, the data owner, or the administrator.

For example, an enterprise intelligence platform may eventually involve:

Role	Relationship to the platform
Primary user	Uses the platform during a meaningful workflow to make or recommend a decision.
Executive sponsor	Funds or authorizes the initiative.
Subject-matter expert	Supplies context, reviews evidence, or validates an answer.
Data owner	Controls access to enterprise data sources.
Security, legal, and risk teams	Define acceptable controls and usage boundaries.
Indirect beneficiary	Benefits from a better decision without operating the platform directly.

These roles all matter, and later lessons will map them systematically. For now, selecting a primary user prevents the platform from becoming a compromise among incompatible needs.

A useful primary-user description includes:

• Role and decision rights: What is this person authorized or accountable to recommend or decide?
• Operating cadence: Is the problem triggered daily, weekly, during a quarterly review, or only during incidents?
• Information environment: Which systems, documents, teams, and data sources must they currently consult?
• Pressure or consequence: What happens when the decision is slow, poorly evidenced, inconsistent, or impossible to explain?
• Observable behavior: What do they do today to compensate? Search folders, request spreadsheets, convene meetings, or manually reconcile contradictory reports?

Avoid labels such as “executives,” “employees,” or “business users.” They conceal meaningful differences in authority, workflow, access, and risk. “A director of strategic operations preparing investment recommendations for a monthly portfolio review” is a usable starting point; “leadership” is not.

A persona is not a fictional biography. In this context, it is a concise operational model of a segment whose work is sufficiently similar to design for. The tagline should remind the team of the user’s situation, not add decorative detail.

For the capstone, use this working primary-user hypothesis:

Priya, a Director of Strategic Operations who prepares recurring investment recommendations across business units.

This is deliberately a hypothesis. If your own enterprise domain is different, substitute an equivalent role with real decision responsibility. What must remain constant is the specificity: one role, one recurring decision context, and one initial source of value.

---

Define the decision-support problem

“Help Priya find information” is too weak. It says nothing about the decision, the cost of uncertainty, or the form of support required.

Instead, frame the problem around a decision moment. For this capstone, the decision moment is a portfolio review in which Priya must recommend whether an initiative should be funded, deferred, stopped, or sequenced differently.

The work is difficult because the relevant evidence is often fragmented:

• initiative proposals and business cases;
• budgets, spend, and expected benefits;
• delivery status and operational metrics;
• risk registers and audit findings;
• architecture dependencies and security constraints;
• meeting notes, policy documents, and prior decisions.

The difficulty is not simply the volume of documents. It is the need to assemble current, permissioned, and conflicting evidence into a recommendation that can withstand challenge from finance, technology, operations, and risk leaders.

A good decision-support problem therefore identifies six elements:

Element	Capstone working hypothesis
Decision owner	Director of Strategic Operations
Decision or recommendation	Recommend whether to fund, defer, stop, or resequence an initiative
Trigger and cadence	Preparation for recurring portfolio reviews and ad hoc executive requests
Current friction	Manual search, spreadsheet reconciliation, repeated requests to experts, and difficulty locating prior rationale
Consequence	Slower decisions, inconsistent recommendations, missed dependencies, and weak auditability
Required support	Permission-aware evidence synthesis, source traceability, comparison of relevant facts, and explicit uncertainty

Notice what is absent: “build a RAG chatbot,” “add a dashboard,” “use an agent,” or “create an AWS microservice.” Those may later become implementation choices. They are not the problem.

The distinction is important because a decision-support product must support judgment, not merely generate fluent text. In this scenario, the platform should help Priya:

• locate relevant evidence within the bounds of her permissions;
• identify evidence that supports, contradicts, or fails to answer a claim;
• compare initiatives against explicit decision criteria;
• see citations and the currency of source material;
• recognize uncertainty and seek human input when evidence is incomplete.

It should not silently make the funding decision. Portfolio choices involve strategic trade-offs, accountability, organizational context, and potentially high financial consequences. The human decision owner remains responsible.

---

Decide where AI helps—and where it should not decide

AI is appropriate only if it offers a material improvement over simpler alternatives. A keyword search, curated dashboard, standard workflow, or deterministic rule may be more reliable for some portions of a task.

The People + AI Guidebook provides a useful lens: begin with the human problem, examine the current workflow, and ask whether AI contributes unique value rather than starting with “Where can we use AI?”

For Priya’s decision-support workflow, AI has plausible value in tasks where language and evidence are varied:

• retrieving semantically related documents even when terminology differs;
• summarizing long reports while preserving links to source passages;
• extracting candidate risks, dependencies, assumptions, and unresolved questions;
• drafting a comparison that Priya can inspect and revise;
• highlighting disagreement among sources or gaps in the available evidence.

Yet several aspects should remain explicitly human-led:

AI may assist with	A responsible human retains
Finding, grouping, and summarizing evidence	Setting decision criteria and strategic priorities
Drafting a comparison of options	Weighing trade-offs among cost, risk, timing, and organizational impact
Flagging missing or contradictory information	Deciding whether evidence is sufficient
Preparing a recommendation draft	Approving, communicating, and owning the final recommendation

This is augmentation, not full automation. It fits a high-stakes enterprise setting because the system improves the person’s capacity to reason with evidence without pretending to replace their accountability.

---

Turn the hypothesis into a user-need statement

The NNgroup article offers two disciplines that are particularly useful here: make the user specific, and phrase the need as a verb rather than as a feature. Read the framework, then apply it to the capstone.

Here is a weak version:

A manager needs an AI chatbot that searches documents so they can make better decisions.

It fails for several reasons. “Manager” is generic; “AI chatbot” prescribes a solution; “better decisions” has no decision context; and it obscures why the work is difficult.

Here is the capstone’s stronger working statement:

Priya, a Director of Strategic Operations preparing recurring investment recommendations across business units, needs to assemble and compare current, permissioned evidence about initiative value, delivery status, dependencies, and risk in order to recommend a defensible portfolio action without relying on manual document chasing or untraceable summaries.

This statement works because it:

• identifies an operationally specific user;
• names actions rather than features: assemble and compare;
• anchors the need in a recurrent, consequential decision;
• includes the relevant evidence domains without committing to a technical interface;
• identifies the deeper outcome: a defensible recommendation, not simply a faster search.

It is still only a hypothesis until supported by research. A leadership team may believe portfolio reviews are the most important pain point, while actual directors may report that missing access permissions, inconsistent data definitions, or unclear decision rights are the real blockers. The purpose of this statement is to make such assumptions visible and testable.

---

Your capstone framing artifact

Create a one-page “Primary User and Decision-Support Problem” artifact. Treat it as version 0.1: concise enough for stakeholders to challenge, concrete enough to guide the next lessons.

Use the following structure.

1. Primary user

Name and role:
Priya, Director of Strategic Operations.

Tagline:
Prepares cross-business-unit investment recommendations for portfolio review.

Decision authority:
Recommends a portfolio action; executive committee members retain final approval.

2. Decision moment

Decision:
Whether an initiative should be funded, deferred, stopped, or resequenced.

Cadence and trigger:
Monthly portfolio reviews, plus time-sensitive executive requests.

Decision consequence:
Capital allocation, delivery capacity, risk exposure, and strategic focus may all be affected.

3. Current workflow and friction

Record the current process in plain language: which sources are consulted, which people are asked for information, where delays arise, and what makes evidence hard to trust or compare. Separate observed facts from assumptions.

A compact evidence log is useful:

Claim	Evidence currently available	Confidence
Portfolio recommendations require information from multiple repositories	Interview observation, workflow walk-through, or known process documentation	Confirmed or to validate
Priya spends substantial time reconciling information manually	Interview, time sample, or self-report	To validate
Decision-makers need source traceability	Governance expectation, stakeholder interview, or policy	To validate

4. User-need statement

Use the working statement above, adjusting only where your organizational context supplies better evidence. Do not insert solution terms such as “chatbot,” “agent,” “vector database,” or “dashboard.”

5. Product boundary

State one sentence that keeps the first platform scope honest:

The platform supports evidence gathering and recommendation preparation; it does not autonomously allocate funding or replace the accountable decision-maker.

This boundary will matter later when you design authorization, retrieval, agent tools, human approvals, safety controls, and audit trails.

---

Key takeaways

A viable enterprise intelligence platform begins with a specific user in a specific decision moment, not a generic promise to “apply AI.” The primary user is the person whose recurring workflow defines the initial product scope; they are not automatically the executive sponsor, data owner, or final approver.

For this capstone, the working focus is a Director of Strategic Operations preparing evidence-backed portfolio recommendations. The platform’s role is to augment judgment through permission-aware, traceable evidence synthesis while leaving high-stakes accountability with people.

Next, you will turn this framing into measurable business and user outcomes: defining the baseline, target, and time horizon that make it possible to determine whether the platform actually improves the decision-support workflow.