From idea to useful product: how I build with AI agents

Building with AI can make the first version of an idea feel much closer. You can move from a rough description to a draft, a design, or working code. The next question is whether that work helps someone do something they care about.

I bring product, UX, design, development, and marketing together in my work. Agents help with parts of that process, but the product still needs a clear problem, a coherent experience, and evidence from people using it.

This is the workflow I use to organize that journey. You can apply it to a small service page, a learning resource, or a first product experiment.

1. Write the problem before the backlog

Start with a person and a situation. What are they trying to do? Where does the current experience become difficult? What have you actually observed, and what are you assuming?

An agent can help organize research and compare options. Your brief should keep observations, interpretations, and unanswered questions separate. A confident summary is not a substitute for customer evidence.

Try this sentence: “For [specific person] who needs to [job], we want to make [step] easier. We believe [change] may help, and we will look for [observable evidence].”

2. Choose one useful slice

A first version should let you learn something specific. It does not have to contain every idea in your notes.

Imagine a consultant wants to turn discovery notes into a usable project brief. A small first version might produce an editable brief from approved sample notes, clearly mark missing facts, and let the consultant review the output. Team permissions, a marketplace, and a large integration catalog can wait until there is evidence they are needed.

That example is a proposed product exercise, not a claim about a shipped Waymaker feature.

3. Define the roles and the decisions

I organize agent-assisted work around a few jobs. Research prepares the evidence. Product work defines the scope. Design makes the journey understandable. Development implements the behavior. Review checks it against the purpose. Marketing helps the right people understand what exists.

A role is a responsibility, not necessarily a separate agent. Add another assistant when it has a useful bounded job. Keep the brief and decisions in a shared place so the next task starts with the current context.

4. Design the whole experience

My design review includes more than the first screen. What does a new visitor need to understand? What do they do next? What happens when information is missing? Can they return to the work? How does the experience behave on a phone?

Tools such as Figma and coding agents can help turn the structure into something inspectable. I still need to choose the hierarchy, language, and interaction that fit the user’s task.

For the sample project-brief tool, the missing-information state matters as much as the polished output. If the notes do not include a budget, the product should make that gap visible rather than invent a number.

5. Ask for implementation evidence

A useful build handoff tells you what changed, where it changed, how it was checked, and what remains uncertain. That makes review possible without treating an agent’s confidence as proof.

Check representative inputs and the relevant user actions. Compare the result with the brief. If you publish a site, visit the live page and follow its next step. If the change relies on another service, verify the part of that connection that is in scope.

Keep release status precise: planned, implemented, checked, and live mean different things. A product can be live while customer demand is still unproven.

6. Put the first version in front of someone

The next useful learning often comes from watching someone try the task. Where do they hesitate? What do they expect? Does the output help them continue their work?

For the project-brief example, ask a consultant to review a brief made from a safe sample and identify what they would need to change before using it. Record the corrections and the time involved. Do not infer willingness to pay from a polite compliment.

Marketing belongs in this loop too. Explain the problem, show the current capability honestly, and give the right person a clear next action. What people ask about can help shape the next version.

A product brief you can reuse

We are helping [person] accomplish [job]. Our evidence so far is [sources or observations]. The smallest useful version is [one journey]. Use [approved context and existing tools]. Preserve [constraints]. Flag missing information. Prepare [deliverables]. Check [behaviors and examples]. Report what is implemented, what is verified, and what still needs a decision. Our next learning question is [question].

Keep the brief short enough to maintain. Add decisions as you make them, and update old assumptions when the evidence changes. Otherwise, more agents can mean more versions of the same misunderstanding.

Where Waymaker fits

Waymaker is where we bring together the work of understanding yourself as a builder, choosing a direction, and taking the next useful step. Explore the Waymaker method and the current Cameron and AI-agent overview to see how the approach is presented in the product.

The workflow in this article spans the tools I use across my work; it is not a promise that every external tool or automated step is built into Waymaker. Choose the support that fits your current project.

For a personal look at the tools and working rhythm, read my behind-the-scenes article on The Wealth Experiment. For a team delivery example, read how we organize AI-assisted client work.

You can begin with one person, one problem, and one useful next step. That is enough to give the agents a meaningful job—and give yourself something real to learn from.