Building AI Products: From User Problem to Tested Workflow

Building AI products starts with a user problem you can observe, followed by a small workflow whose results you can check. Define what the product may do, what it must refuse, and how a person recovers when it fails before expanding the feature set.

fenbs keeps the product decisions and lessons outside any one assistant, so a new session can use the agreed requirements. The product itself still needs its own implementation, tests, and operating controls. Start with one useful outcome rather than a collection of impressive demonstrations.

How do you start with a testable user problem?

1. Name one user and one repeated task. For example, a support coordinator turns an incoming request into a draft reply using an approved policy.
2. Observe the current process. Record the inputs, the checks people perform, and what happens when the policy does not answer the question.
3. Write the expected outcome. A useful draft should quote the relevant policy, distinguish missing information, and remain unsent until reviewed.
4. Build the smallest complete path, including review and recovery. Compare it with the existing process using the same sample requests.
5. Decide whether to continue using the results. Keep failures and reviewer effort visible instead of counting generated drafts alone.

A discovery conversation should establish whether the problem exists before asking whether people like an AI solution. Ask a coordinator to show a recent difficult request. You may discover that finding the approved policy is the bottleneck, while drafting the reply is already easy.

What should the first product actually do?

Write a narrow promise in ordinary language: given an approved policy and a support request, prepare a suggested reply with the supporting passage. Then list exclusions, such as changing account details or promising an exception. These boundaries guide the interface, implementation, and review.

Consider a simpler baseline, such as a searchable policy page and a reply template. If that solves the task more reliably, the AI feature needs a stronger reason to exist. Compare total time through approval, including corrections, rather than the speed of the first response.

The NIST AI Risk Management Framework↗ (opens in a new tab) provides a voluntary approach to considering trustworthiness through AI design, development, use, and evaluation. Use it to ask who could be affected by a wrong answer, then make those risks concrete in your own requirements.

For adjacent questions, see building an AI chatbot for conversational interfaces, AI for product management for planning work, AI for product development for broader development tasks, AI for product marketing for marketing workflows, and AI in building construction for construction uses.

How do you test behavior before adding features?

Build a small collection of realistic examples and write the expected behavior before running the model. Include straightforward requests, incomplete requests, conflicting policies, and requests outside the product boundary. Keep some examples separate from the ones used to improve the prompts.

Run important examples more than once and inspect the complete output, including citations and proposed actions. A correct final sentence does not excuse a leaked document or an unauthorized step. Record which version of the instructions, model, and reference material produced the result.

Use fenbs Decisions and rules to preserve the human-approved acceptance criteria, so the assistant improving the prompt and the assistant reviewing the interface start with the same requirements.

Which product decisions need a durable record?

Save decisions that change what someone builds next: the intended user, permitted data, review boundary, accepted failure behavior, and conditions for stopping a trial. Include who chose the option, why, and which question remains unresolved. A confident assistant suggestion is still only a suggestion.

For the support example, a person might decide that every draft needs a policy passage and that sending stays manual. Record a later change explicitly rather than editing the old reasoning out of existence. The next developer should understand whether automatic sending is prohibited or simply not built yet.

How should people review AI-assisted implementation?

Ask for one reviewable change at a time: an input check, a draft screen, or a citation test. Require the assistant to explain assumptions and identify checks it actually ran. A generated test is useful only if it checks the requirement independently enough to expose a mistake.

Keep normal software security work in the plan. NIST's Secure Software Development Framework↗ (opens in a new tab) describes practices for preparing development, protecting software, producing secure software, and responding to vulnerabilities. AI-generated code still needs dependency review, access checks, and careful handling of secrets.

For the broader discipline of reviewing assistance in daily work, use how to use AI at work. Whatever coding assistant you choose, keep a reviewer who understands this product's requirements and can explain how the implementation meets them.

How to do this with fenbs

1. Create a free account and add a project named for the user outcome, such as reviewed support drafts.
2. Add tasks for the baseline, the smallest workflow, and the evaluation examples. Put the implementation steps in each task's plan.
3. Record the product owner's approved boundaries in Decisions and rules. Leave unresolved choices open for a person to decide.
4. Connect a supported assistant using MCP, a standard connection for outside tools. Ask it to read the project context before working.
5. Save the checks performed, remaining failures, and Where we left off. Add a lesson when a failure reveals a reusable improvement.

fenbs is not the right fit for serving model requests or running your evaluation suite. Use it for the work record; keep source code, test execution, and production monitoring in the systems built for those jobs.

What should happen after the first trial?

Review results with the people doing the task. Look at unsupported answers, abandoned drafts, review effort, and failure recovery. Agree which problems block expansion and who owns the next check. Do not treat a successful demonstration as permission to remove review.

Keep the durable explanation small enough to read. An AI brain is useful here when it preserves the decisions and progress that change the next action. Explore the AI at work library when you need another specific workflow to test.