TutorialsWorkbench: From SOP to a Daily Workflow
Why a finished SOP still needs a workbench — the six-stage loop, the five-step build method, the copy-paste prompt, and the cross-role reuse formula.
What these notes are
The previous lesson got one task running. This lesson is about a day: an SOP handles a task, but it cannot decide what comes first today.
One line captures the relationship:
The SOP for one task is not the priority for one day.
Why a finished SOP still needs a workbench
Here is how the instructor transitions:
Daily reports, retrospectives and post breakdowns are each the SOP for one task. But as a product manager, every day I still have to decide which project comes first, what I deliver today, where yesterday's unfinished work goes, and who picks up the new tasks the retrospective produced. The workbench connects these.
Check your own pain points first
- Plans, projects, ad-hoc requests and reviews are scattered;
- You re-judge goals and priorities every single day;
- What you learn never flows back into the next round.
The workbench acceptance criteria
Open it and see what must be handled today; pick three pieces of work with inputs and outputs; turn the review into next-step actions.
A workbench that does all three is usable — it is not a good-looking dashboard.
Look at the finished loop first
Monthly / weekly OKR → project Gantt → action list → today's three things (input → output)
→ daily / weekly / monthly review → extracted actions flow back; archive when a project endsThe fields and destinations for each of the six stages:
| Stage | Workbench module | Key fields or deliverables | Where it goes next |
|---|---|---|---|
| Set direction | Monthly / weekly OKR | Goals, KRs, weekly plan, progress | Projects and actions |
| Schedule projects | Gantt chart | Tasks, owners, start and end dates, progress | Due reminders and the action list |
| Break into actions | Action list | Actions that are executable, checkable and produce a result | Today's three things |
| Execute today | Top three things | Input, expected output and status for each | Review and daily report |
| Learn and adjust | Daily / weekly / monthly review | What worked, problems, extracted actions | Action list or next OKR cycle |
| Keep the results | Project archive | Outcome, timeline, reusable methods | The next similar project |
Two details worth pausing on
- Overdue, due today, due soon and unfinished items all return to must handle today — yesterday's unfinished work does not disappear;
- Actions extracted in a review enter the action list so the next cycle can pick them up — this is the concrete mechanism behind experience flowing back.
Look back at the previous lesson: the project retrospective SOP now has an input source and a destination for its results; the daily report can reference the day's completion log, but still needs human review.
The five-step build method
List the tasks you repeat every week
For each one, record the trigger, the input, the steps, the completion criteria and where the result goes. Start with 1 or 2 common flows — do not spread out across everything at once.
Write your own business objects and data flow as a loop
Follow goal → project → action → today → review → feedback. Delete whatever you do not need — not every role needs a Gantt chart.
Ship the main chain that works the moment you open it
State the pinning rule for today, the task completion criteria and the review feedback; fields must be editable. Do not chase features in v1 — chase the fact that it opens and works.
Ask for flow tables, field tables, exception rules and an acceptance checklist first
Confirm the business logic before generating pages. Reverse that order and you get a good-looking prototype that is wrong.
Iterate on one real problem at a time
Record fields you cannot find, reminders you missed and actions that will not flow back. Fix one thing per round.
How the instructor actually iterated
The first version was six modules plus local storage; then the palette changed to lavender and warm cream; the OKR block was rebuilt from plain cards into a monthly / weekly matrix table; in-place editing and adding modules were added; and the Gantt chart became a task table on the left with a time grid on the right and draggable bars.
Every one of those changes came from a concrete problem discovered while using it. You do not need to copy every feature in your first version — get it running, then change it based on what you actually run into.
The copy-paste workbench build prompt
You are a product designer and front-end prototype developer. Design a personal workbench based on my own work SOP.
My role and work objects: [fill in];
The SOPs I run every week: [paste at least 2];
My current work loop: [fill in];
The priority rule for today's tasks: [fill in];
Task completion criteria: [fill in].
First output:
1. A flow table for goal → project → action → today's execution → review → feedback;
2. A field table for at most 4 core areas in the first version;
3. The data flow across areas;
4. Handling rules for missing information and overdue tasks;
5. An acceptance checklist that can be verified item by item.
Point out the business rules I have not made clear. Do not write code yet.
After I confirm the requirements, generate a single-file local HTML prototype. First-version requirements: must-handle-today pinned to the top; core fields editable; unfinished items do not disappear; the review can extract actions; data stored locally; JSON export / import plus a second confirmation for clearing; 3 sample tasks preloaded, one of them overdue; readable on both phone and desktop.Why this prompt is designed this way
| Design choice | Why |
|---|---|
| Do not write code yet | Generating pages before the logic is confirmed is the most expensive rework |
| Point out business rules I have not made clear | Makes AI help you find what you forgot |
| At most 4 core areas in v1 | Caps the scope so the first version actually finishes |
| 3 sample tasks, one overdue | Overdue handling is the easiest rule to forget, so a sample must cover it |
| Local storage plus JSON export / import | Your data stays yours, and it can be backed up and moved |
Three boundaries to state clearly
One: do not assume a static page inherently has AI reasoning, web fetching or cross-device sync. When those capabilities are needed, list the interfaces, services and acceptance methods separately.
Two: the local single-file approach is for getting something running on your own device. A single HTML file with browser localStorage and JSON backup is convenient to open, but it is not the same data across devices.
Three: sharing with a team or handling real business data requires separately designed permissions, server side and sync. Storing app keys in a static front end is suitable only for personal experiments.
How to reuse this in your own role
Reuse formula: keep the effective loop + replace the business objects + redefine today's pinning rule + state the completion criteria.
| Role | Goals and projects | Today's deliverable results | Where the review goes |
|---|---|---|---|
| Product manager | Metrics, requirements, versions | PRD, interview findings, acceptance checklist | Next version / action items |
| Teacher and curriculum | Learning goals, course development | Slides, homework feedback, learning records | Adjustments to the next lesson |
| Content creator | Content series, publishing plan | Topics, scripts, finished drafts | Topic library / content SOP |
| Sales | Customer stages, closing targets | Visit notes, proposals, agreed next steps | Customer follow-up |
The order learners should follow
- Copy the logic of the work loop first;
- Then swap the fields and sample data;
- Then adjust the priority rules;
- Use it for seven days before deciding what to add.
If a Gantt chart does not fit your tasks, replace it with a project list — you do not have to keep the same interface. The loop is the skeleton; the interface is replaceable.
Quality red lines
- Take facts, numbers, dates and names back to the source material;
- Desensitize or get permission for demo materials;
- AI output is a draft — publication and scheduling commitments are confirmed by a human;
- You can learn the method from someone else's content, but never copy their wording or experience.
Lesson recap
| Remember | In one sentence |
|---|---|
| Why a workbench | An SOP for one task cannot decide what comes first today |
| Acceptance criteria | See today's items, pick three, turn the review into actions |
| How to build | The five-step method — get the flow and field tables first, generate pages after |
| How to change it | Start from concrete problems found in use, one at a time |
| How to migrate | Keep the loop, replace the objects, redefine priorities, state the criteria |
The assignment for the next lesson is to connect all three lessons into one deliverable.
How to Use It: Three Hands-On Scenarios
Daily report, project retrospective and post breakdown — three complete prompts, each run through v1, an error hunt, a new rule and v2.
Assignment: Write your own SOP card, then turn it into a workbench
Three levels merged into one assignment — run a scenario to get SOP v2, apply it to a repeated task in your own role, then build a first-version workbench. All three required.