Course 08 · Systems Mindset

Stop putting out fires. Build the machine.

Most founders spend every day attending emergencies. The ones who scale write each process down ONCE, hand it to Claude, and let the machine handle the fire before it starts.

◷ 11 min read· MentorMe Academy

The one idea

There are two ways to run a business. The first is to wake up, see what's on fire, and put it out. The second is to build systems so solid that the fire never starts — and when something does break, the system catches it. The first feels productive. The second is the only one that scales.

The unlock isn't working harder. It's writing down every repeating process exactly once, in a single document, and handing that document to Claude. Claude turns it into robust automations you never have to touch again. That document has a name: a PRD — a Product Requirements Document.

Why a PRD changes everything: when you describe a task to AI in a chat, you get a one-off. When you describe your whole operation in a PRD, Claude builds a system — every workflow, every notification, every edge case — and it builds the same thing the same way every time.

What goes in the PRD

A PRD is not a tech document. It's you, explaining your business to someone who's going to build it for you. Write it in plain language. The sections that matter:

  1. The business in one paragraph. What you sell, who buys, how money changes hands.
  2. Every workflow, start to finish. "Customer books → pays → gets a confirmation → gets a contract → signs → I deliver → I follow up." Write the whole journey, step by step.
  3. Every notification. Who gets told what, when, and on which channel (SMS / email).
  4. The edge cases. What happens on a refund, a no-show, an upsell, a swap-out. The boring stuff is where systems beat people.
  5. The tools. Stripe for payments, Twilio for SMS, Resend for email, N8N to wire it together. (The next three courses build exactly this.)

The PRD prompt — copy it

You are my senior operations engineer. I'm going to describe my business and I want you to turn it into a Product Requirements Document (PRD) I can hand to a build team (and to Claude) to automate the whole thing in n8n. === MY BUSINESS === - What I sell / who buys / how I get paid: [...] - The full customer journey, step by step, from first contact to after the job: [...] - Every message a customer or I should receive, and when (SMS or email): [...] - Edge cases: refunds, no-shows, upsells, repeat customers: [...] === WHAT I WANT BACK === 1. A clean PRD with: overview, user flows (numbered), a list of every automated workflow, every notification (trigger -> channel -> message), data I need to store, and the tools per step. 2. Flag anything I forgot — the boring edge cases that break real businesses. 3. Keep it in plain English. No jargon. This is a map, not code. Ask me up to 5 clarifying questions first, then write the PRD.

Do it — step by step

  1. Brain-dump every repeating task you do in a week. Bookings, invoices, reminders, follow-ups, content.
  2. Run the prompt above. Answer Claude's questions honestly — the gaps are where your business leaks.
  3. Read the PRD like a CEO. If a workflow is wrong, it's a one-line fix now instead of a rebuild later.
  4. Hand the PRD to Claude in n8n (Courses 9–11) and let it build the workflows one at a time.
  5. Keep the PRD. It's the single source of truth for every brand you run — change the doc, rebuild the system.
Charge for this: a documented operations PRD — the map of someone's entire business, ready to automate — is a $500–$1,500 deliverable on its own, before you build a single workflow.