Module 8 of 8 — Capstone

Your Brainstorming System

6 min read

By this point in the course, you have seven distinct tools: a de-anchoring protocol (M1), a SCAMPER and random-stimulus divergence method (M2), a red teaming framework (M3), Six Thinking Hats for structured parallel thinking (M4), a convergence process with three decision tools (M5), a cross-domain import technique (M6), and an understanding of the homogenization problem and how to counter it (M7). Seven tools is too many to apply in every session. The task now is to design a system — a personal workflow that decides which tools to use, when, and in what sequence, based on the type of brainstorming problem you're facing.

A system is different from a toolkit. A toolkit is a list of things you might do. A system is a decision process: given this type of problem, in this context, with these constraints, here's the sequence I run. Systems are reusable. You design them once and apply them repeatedly, adjusting based on what you learn. The goal of this capstone is to produce a documented personal brainstorming system that you can actually use — not a completed assignment, but a working artifact.

Most brainstorming systems fail not because the tools are wrong but because they're applied inconsistently. You use de-anchoring when you remember it. You run SCAMPER when you have time. You skip convergence when the meeting ends. A documented system removes the dependence on memory and mood. It's your external scaffold for the moments when you're under pressure and the easiest path is to do what you've always done.

What you'll be able to do

Design a personal brainstorming system that specifies when to use each tool from modules 1–7
Document the decision logic: which problem types trigger which sequences
Identify the two or three tools from the course that most address your current brainstorming weaknesses
Build a "minimum viable" version of your system for time-constrained situations (under 20 minutes)
Articulate how your system addresses the homogenization risk from Module 7

Portfolio Artifact Build Lab — Personal Brainstorming System A personal brainstorming system document — decision logic for four problem types, full sequence for at least one, minimum-viable shortcut, homogenization countermeasure, and a reflection on which prior modules most changed your default approach.

Scenario

Six Months Later

5 min read

Imagine it's six months from today. You've just been given 48 hours to prepare ideas for an important decision — a project pitch, a strategy session, a creative brief, a personal decision. You have no facilitator, no team structure, no one to remind you to run the red team or use the Hats. You have the tools from this course and whatever system you built to apply them.

In the scenario where you have no system, you do what you always did before this course — which was probably some version of "think hard and write things down." The tools you learned become memories rather than habits. Some of them you'll use once and forget. The course will have given you knowledge without giving you practice infrastructure.

In the scenario where you have a documented system, you open it. It tells you: for a high-stakes creative brief with a 48-hour window, run de-anchoring first (20 minutes), then SCAMPER for the two most promising anchors (30 minutes), then a 15-minute red team pass on the SCAMPER results. Convergence at 90 minutes. The system makes the decision about what to do so that you can spend your time doing it.

What happens in the first scenario? You spend the first twenty minutes deciding what approach to take. Then you try something that feels vaguely familiar. Then you run out of time and commit to whatever you have. The tools you learned are all technically available to you — you just didn't reach for them because there was no mechanism to trigger them.

The difference between the two scenarios is not knowledge. You have the same tools in both. The difference is infrastructure. A documented system is the infrastructure that converts course knowledge into applied practice. It's the difference between knowing how to do a thing and doing it when it counts.

This module builds the second scenario.

You're not writing a summary of what you learned. You're building an artifact you'll actually open six months from now when the 48-hour clock starts. That artifact is a decision document: for each type of brainstorming problem you regularly face, what do you do, in what order, and what's the fastest version that still works? The lab walks you through every step of building it.

Lesson

Designing Your Personal System

7 min read

A brainstorming system is a decision tree, not a checklist. The difference: a checklist assumes you run everything every time. A decision tree has conditions — "if the problem is high-stakes and you have time, run the full SCAMPER; if you have 20 minutes, run just Substitute and Reverse." The decision tree is what makes the system actually usable under pressure. A checklist you can't complete in time becomes a checklist you skip entirely.

Designing your system requires four components. Each builds on the last and together they produce a document you can actually use.

System Design Framework

1. Problem Taxonomy Define four types of brainstorming problems you regularly face. Examples: "high-stakes creative decision, open timeline" / "time-pressured quick ideation" / "team decision with competing perspectives" / "personal or career decision." Each type gets its own sequence. The taxonomy is the foundation — if the types are too vague, the sequences won't apply cleanly.

2. Sequence Selection For each problem type, choose 2–4 tools from the course that best address that type. Order them deliberately: divergence before convergence (M1/M2/M6 before M5), de-anchoring before SCAMPER (M1 before M2), red team before commitment (M3 before deciding). The ordering is not arbitrary — it reflects the cognitive work each tool requires.

3. Minimum Viable Version For each problem type, what's the shortest version that still produces a meaningfully better outcome than no system? Usually one divergence tool plus one convergence tool. This is the 20-minute version. If you don't define it, you'll skip the system under time pressure — which is exactly when you most need it.

4. Homogenization Countermeasure Every system needs one explicit practice that preserves variance. Either solo ideation before any AI input (M1 protocol), staggered AI use across team members, or dedicated time for non-AI-generated ideas. The countermeasure must be named and located in the system — "I'll do this before step 2" — not left as a general intention.

Governance Standards — The Regulatory Layer

O*NET — Critical Thinking (4.A.4.a) Critical thinking is the evaluation function throughout your system — it's what decides which tools to apply, which SCAMPER results to pursue, which red team outcomes to take seriously. A system without explicit critical thinking checkpoints drifts toward confirmation of existing preferences. Each sequence decision you make is a critical thinking exercise.

O*NET — Complex Problem Solving (2.B.3.g) Complex problem solving requires diagnosing the problem correctly before selecting a solution approach. Your problem taxonomy is a complex problem solving exercise — it requires you to identify what makes each problem type different and select methods accordingly. The taxonomy itself is the application of this competency.

O*NET — Systems Evaluation (6.A.1.b) Systems evaluation applies to your brainstorming system itself: after using it several times, does the sequence you chose actually produce better ideas? Does the minimum viable version hold up under pressure? Systems evaluation is how you improve the system rather than just repeating it. Build a review cycle into the document from the start.

O*NET — Active Learning (4.A.6.b) Active learning means the system should improve with use. Build a feedback loop: after each brainstorming session, note which step produced the most value and which you would skip next time. This is how the system becomes yours rather than remaining a course template. A system that doesn't adapt is a system you'll eventually abandon.

Context

Three Things That Make Systems Work

5 min read

You've learned seven tools across eight modules. You've seen them applied to real problems. The question now is what converts that learning into something durable. Three principles determine whether a brainstorming system actually gets used.

1. It has to be written down.

A system that exists only in memory is not a system — it's a reminder that you should probably use your tools. The only reliable test of whether you have a system is whether you can open a document and read what to do next without having to think about it. The act of writing forces you to make the implicit explicit: which problem types do you face? In what order do the tools work? What does "done" look like? If you can't answer those questions in writing, the system isn't finished yet.

2. The minimum viable version matters more than the full version.

You will not use a 6-step process when you have 20 minutes and a deadline. The full version is for the sessions when you have time and a lot riding on the outcome. The minimum viable version is for every other session — and every other session is most sessions. If the minimum viable version doesn't exist in your system, the system will go unused under exactly the conditions where you need it most. Build the short version first, then extend it for the cases where you have time to go further.

3. The system tells you when you're skipping something important.

The reason to document your system is not just to follow it. It's to know when you're deviating from it. If you open your system document and skip straight to convergence without running any divergence, the document makes that choice visible. You can decide to skip — sometimes that's right — but the document prevents unconscious omission. Without documentation, it's just a meeting that ended faster than planned. With documentation, it's a deliberate shortcut you can evaluate afterward.

You'll build your personal brainstorming system in the lab. The AI will walk you through the system design framework, help you test it against a real problem, and give you a working artifact by the end of the session. This is the capstone — the system you leave with is the output of the course.

BUILD LAB

Your Brainstorming System

⏱ 40–60 minutes

Your Role

System Designer You're designing your personal brainstorming system. You bring your four problem types, work through the sequence selection, define your minimum viable version, and add your homogenization countermeasure. The output is a document you can actually use.

AI Role

System Coach Guides you through the system design framework step by step. Asks you to justify your tool selections. Tests your system against a real problem. Pushes back on sequences that skip important steps. Helps you stress-test the minimum viable version.

Framework Reminders

Problem taxonomy firstDefine four problem types before selecting any sequences. Vague types produce unusable sequences.

Minimum viable version requiredEvery problem type needs a version that works in 20 minutes or less. Without it, the system won't survive pressure.

Homogenization countermeasureOne explicit practice that preserves variance. Not a general intention — a named step with a location in your sequence.

System must be writtenIf it's not on the page, it's not a system. The artifact is the output.

Completion

Produce a documented personal brainstorming system with all four required elements: problem taxonomy, sequences (with at least one full sequence), minimum viable version for each type, and homogenization countermeasure.

Shift + Enter for a new line

✓ Module Complete

You've completed Module 8 of 8.

Back to Courses →