Most people use AI like a chatbot. You ask a question, get an answer, maybe ask a follow-up. It feels like a conversation, and that's fine for quick queries. But it's not a system.

A system produces consistent, repeatable results. A conversation does not.

The difference matters when you're building workflows. If you're a product manager, a designer, a developer, or anyone who turns raw input into professional output, you need more than back-and-forth chatter. You need a chain.

The Chain Pattern

The workflow chain pattern is simple: take a single input and run it through multiple AI-powered roles to produce different outputs. Each role gets its own prompt template. The input stays the same, the output changes based on who's producing it.

This separates people who chat with AI from people who have a system. Prompts, not conversations.

The pattern builds on the four-step workflow we teach: Audit, Redesign, Automate, and Chain. The first three steps get you to single prompts that work. The fourth step chains those prompts together into a repeatable system.

One Brief, Three Outputs

Let me show you how this works with a concrete example. Imagine you're building a reading list feature for your app. Your stakeholder sends you a messy paragraph:

Feature brief: "We need a way for users to save articles they find interesting so they can read them later, like a reading list. Should work on mobile and desktop. Maybe organize by topic. Users have been asking for this in feedback, they find stuff in their feed but lose it."

This single paragraph contains everything you need. But different roles need different outputs from it. A product manager needs a spec. A UX writer needs copy. A developer needs code.

Instead of chatting with AI about each one, you create three prompt templates. Each template specifies a role, context, task, and format. You paste the same brief into all three. You get three professional outputs in seconds.

Output 1: The PM Spec

Product managers need structure. User stories, acceptance criteria, edge cases. Here's the prompt template:

You are a product manager writing a spec for engineers. Here is a feature brief from a stakeholder:

"[PASTE FEATURE BRIEF HERE]"

Produce:
- A clear problem statement
- 3-5 user stories
- Acceptance criteria for the core story
- Edge cases to consider

Format: Structured product spec with clear sections.

Paste the reading list brief into that template and you get:

Problem statement: Users discover articles in their feed but have no persistent, organized space to save them for later reading. This causes content loss and repeated searching.
User stories:
1. As a reader, I want to save an article to my reading list so I can read it later.
2. As a reader, I want my reading list organized by topic so I can find related content.
3. As a reader, I want my reading list synced across devices so I can switch between mobile and desktop.

This spec would take a human PM two hours to write. The chain produces it in ten seconds. Swap the brief, keep the prompt.

Output 2: The UX Copy

UX writers don't care about acceptance criteria. They care about feature names, change log descriptions, in-app announcements, error messages. Different role, different prompt:

You are a UX writer at a tech company. Here is a feature brief:

"[PASTE FEATURE BRIEF HERE]"

Produce:
- A feature name (3 options)
- One-line change log description
- In-app announcement copy (under 100 words)
- Error messages for common failure states

Tone: Clear, friendly, concise.

Run the same reading list brief through this prompt and you get:

Feature name options: Reading List, Save for Later, Bookmarks
Change log: Save articles from your feed to a reading list and pick up where you left off.
In-app announcement: Never lose an article again. Tap the save icon on any story to add it to your reading list. Access your saved articles from the menu, synced across all your devices. Start building your reading list today.
Error messages: "Couldn't save article. Please check your connection and try again." / "Reading list is full. Remove some articles to save more."

The UX writer gets three feature name options, a concise change log, on-brand copy, and error messages. Same input, different output.

Output 3: The Developer Code

Developers need working code. Not descriptions, not user stories, code. Here's the prompt:

You are a senior developer with 20 years of experience in Python. You have a feature brief:

"[PASTE FEATURE BRIEF HERE]"

Generate a FastAPI backend with:
- Save article endpoint
- List articles endpoint
- Remove article endpoint
- Pydantic schemas
- Basic tests

Format: Single-file implementation, focused and functional.

This prompt produces actual working code. API endpoints, data models, test cases. The code might need review, but it's functional. It gives you a starting point, not a blank screen.

The Structure: Role, Context, Task, Format

Notice what each prompt template includes. Four elements, always in the same order:

  1. Role: Who is the AI acting as? Product manager, UX writer, senior developer.
  2. Context: What information does the AI need? The feature brief, constraints, technical details.
  3. Task: What should the AI produce? Spec, copy, code, analysis.
  4. Format: How should the output look? Structured document, numbered list, code block.

This structure works because it's explicit. The AI never has to guess what you want. You tell it who it is, what it's working with, what to produce, and how to format it.

When you're building your own chains, follow this structure. Don't mash everything into one sentence. Separate the four elements clearly. The extra clarity pays off in output quality.

The Common Mistake: Stuffing Roles

The most common mistake people make is stuffing multiple roles into one prompt. They write something like: "Act as both a product manager and a developer and give me a spec and code for this feature."

This doesn't work well. The model gets confused. It blends the roles together. You get mediocre spec and mediocre code, not great output for either role.

Keep roles separate. One prompt per role. Run the same input through each prompt. You get specialized output from each perspective. Then, if you need to combine them, do it yourself or ask the AI to synthesize the separate outputs.

The chain works for any role combination, not just PM/UX/Dev. Researcher, analyst, strategist. Writer, editor, publisher. Designer, copywriter, marketer. Pick the roles that match your workflow.

The Reuse Pattern

Here's where the system part really clicks. You write each prompt template once. You save it. You reuse it forever.

Create a folder structure. Maybe something like prompts/ with files like spec.md, copy.md, code.md. Each file contains your role, context, task, and format template. Leave a placeholder for the input: "[PASTE FEATURE BRIEF HERE]".

Next time a feature brief comes in, you open the three template files. You paste the brief into all three. You hit enter three times. Ten seconds later, you have a spec, copy, and code.

Swap the brief, keep the prompts.

This is the difference between chatting with AI and having a system. Chats start from scratch every time. Systems reuse what works. Prompts, not conversations.

Building Your Own Chains

The workflow chain pattern isn't limited to product development. Any repeatable workflow can benefit from chains:

The key is identifying the roles in your workflow. What outputs do you need regularly? What perspectives do you need? What formats work best?

Once you know the roles, write one prompt template for each. Test it with real inputs. Refine the structure. Save it where you can reuse it.

From Workshop to Workflow

This pattern comes from our second REPOSITION workshop, where we build live chains together. We've found that people understand the concept immediately, but the real breakthrough happens when they write their own templates.

Write the templates yourself. Don't copy mine. Your roles, your context, your tasks, your formats. The act of writing the template forces you to clarify what you actually need from each role.

Start with three roles. Any three. Write one prompt template for each. Save them. Test them with real input. See what works and what doesn't. Refine.

You'll find that the templates get better with use. You'll tweak the role definition. You'll adjust the context. You'll sharpen the task specification. You'll nail the format requirements.

After a few iterations, you have a system. Not a chat conversation. A system.

The Chain Advantage

Why bother with chains instead of just chatting? Three reasons:

Speed: Chains produce professional output in seconds, not hours. A PM spec takes two hours to write manually. The chain produces it in ten seconds. A UX writer needs an hour for feature copy. The chain produces three options in seconds.

Consistency: Chains produce the same format every time. Every spec follows the same structure. Every copy output includes the same elements. You stop reinventing the wheel with each feature.

Coverage: Chains ensure you don't miss perspectives. When you chat, you might forget to consider the UX angle or the edge cases. When you chain, every role gets its turn. You get comprehensive coverage automatically.

Getting Started

Don't overthink it. Pick one workflow you do regularly. Identify the roles involved. Write one prompt template for each role. Save them. Test them with real input.

Start small. Two or three roles. See how it feels. Notice where the templates need refinement. Notice how much faster you get to usable output.

The goal isn't to replace your judgment. The goal is to get to the point where you can exercise your judgment on better material, faster. Chains produce the raw material. You provide the strategic thinking.

Prompts, not conversations.

Frequently Asked Questions

Can I put multiple roles in one prompt?

No, don't do this. If you stuff multiple roles into one prompt, the model gets confused and produces mediocre output for all of them. Keep roles separate. Run the same input through different prompt templates, then combine the outputs if needed.

How many roles should I have in a chain?

Start with two or three. Any number works, but complexity increases. More roles means more templates to maintain. Focus on the roles that produce distinct, valuable outputs for your workflow.

Do I need different prompts for different inputs?

No, that's the point. You write one prompt template per role. You swap the input, keep the prompt. The same prompt template works for any feature brief, any project description, any stakeholder request that fits the role.

What if the output isn't good enough?

Refine your prompt template. Make the role more specific. Add more context. Sharpen the task specification. Be more explicit about format. The templates get better with iteration.

Can chains work for non-product workflows?

Absolutely. Research, analysis, writing, marketing, customer support, any workflow with repeatable roles and outputs. The pattern is universal: one input, multiple roles, chained outputs.