Archived version. The current syllabus is at jaymargalus.com/foundations.
Jay Margalus
◆ ENT 1000 · The project

Make something AI will replace.

Your team's project is a working automation that replaces one inefficiency. Not an app idea. Not a plan for a company that doesn't exist. A thing that runs, inside a real organization, that could become a business.

What counts as an inefficiency

Work a person does today that is repetitive, rule-bound, or mostly about moving information from one place to another. Four buckets:

  • A process. Done the same way every week by hand: intake, scheduling, invoicing, reordering, onboarding, filings.
  • A decision. Made repeatedly against criteria someone could write down: approve or reject, which vendor, what price, who gets the slot.
  • A discovery task. Finding things out: leads, competitors, applications, grants, permits, price changes.
  • An outreach task. Reaching people: follow-ups, reminders, first contact, review requests, renewals.

Any function of a business is fair game: marketing, sales, customer success, product, accounting, legal, HR, IT, customer service, R&D, operations. Examples and the questions for finding one are on the hunt.

The "ten more customers" test

Your first organization is a design partner, not the business. The business is everyone else with the same problem. Before your team commits, name ten other organizations that do this same work the same way, and a reason each would pay to stop. If you can't, the problem is too local. Pick another.

That's why campus organizations and problems you already know from the inside are out of bounds as design partners. They're easy to reach and they make boring businesses. Your design partner can be in Lexington. Your market cannot be.

The touch-point model

Every inefficiency has the same shape: information comes in, a decision gets made, information goes out. Your harness works at three touch points along that path. At each one it does some or all of four jobs:

  1. Gather the inputs.
  2. Synthesize them into something a person can read in a minute.
  3. Sense-make: flag what matters, what's anomalous, what the options are.
  4. Disseminate: send the result to whoever needs it, in the form they need it.

The decision stays with a human unless you can write a rule that makes it safe to delegate. Where the human stays in the loop, and why, is a design decision you'll defend to the judges.

The rules

  • Real organization, outside your life. A business, nonprofit, practice, farm, shop, or firm. Not your household, not W&L student life. A university office counts only if the process is one offices everywhere share.
  • A named process owner who does this work today and agrees to three meetings: discovery, prototype 1, deployment.
  • Watch it first. Your team shadows the process for sixty minutes before building anything.
  • Talk to real people, and keep talking. Eight conversations by Week 5, two more per team every week from Week 3 through Week 10, twenty minimum. Roommates, classmates, friends, and family don't count. Record with permission or take verbatim notes with three exact quotes each. Your harness can transcribe; you have to be in the room.
  • Every prototype names its hypothesis. What assumption it tests, what result would prove you wrong, what happened. A polished demo with no hypothesis is a screenshot, not evidence.
  • Measure the baseline in Week 5. Minutes per week, error rate, how often it's late, in the process owner's own numbers. You report them again in Week 12.
  • Nothing leaves the building without a hand on it. Until deploy week, your harness never sends an email, text, or post to anyone outside your team on its own. It drafts; the owner clicks send. In Week 11 you may hand it the send button for one touch point, in writing, with a log of everything it sent.
  • Run it for real. On real inputs, in the partner's organization, five working days by the end of Week 11. Fake-data demos don't count.
  • Keep an assumptions ledger. Every belief the project rests on, with a status: untested, testing, confirmed, killed. It starts in the Brief and lives in your agents' memory from Week 5. It's the first thing I look at when you ask "is this working?"

Why this and not a startup idea

Every founder's real first job is finding the work nobody wants to do and doing it better. The inefficiency hunt is opportunity finding with the training wheels on. The businesses that get built in the next ten years are mostly this: someone noticed a process a person did slowly, replaced it, and then found the other ten thousand people doing the same thing. Learning to see those is the skill. Building one is the proof. Finding the ten is the business.

The road

WhenMilestoneWho
Sep 16Three inefficiencies each; teams formIndividual
Sep 25Inefficiency BriefTeam
Oct 9Discovery Pack: eight conversations, sixty minutes observed, baselineTeam
Oct 14Prototype 1 with the process owner; alumni panelTeam
Oct 16Business Case, one pageTeam
Oct 19Harness v1 running on sample inputsIndividual
Oct 30Validation Report: prototype 2, twenty real inputsTeam
Nov 16–20Deploy week: five days liveTeam
Nov 17 / 19Pitch video due / Video Pitch CompetitionTeam
Dec 4 / 11Deployment Log / Final DossierTeam