Bloom's Taxonomy is a production checklist, not an academic framework

By the time I redesigned the curriculum at Apttus, I thought I understood "production-ready." The programme had real use cases, scaffolded complexity, manager feedback confirming new hires were ramping faster. Then a senior colleague sat in on a session, stayed after, and asked me one question I wasn't ready for: where on Bloom's Taxonomy did I think this programme actually landed.

My honest answer was Apply. Participants could configure the product unguided, without the answer nearby. By most measures of corporate training, that's a strong result — most programmes stall at Understand. But the colleague's point was surgical: I was training solution architects, and solution architects don't apply known solutions. They evaluate requirements, diagnose constraints, and create designs for problems they haven't seen before. I was producing people who could replicate. The job demanded people who could design. No amount of good content at Apply level closes that gap, because Apply and Create are not the same cognitive task.

Bloom's Taxonomy, treated honestly, is not a wall chart for instructional designers. It's a ceiling-detector. Six levels, ascending: Remember, Understand, Apply, Analyse, Evaluate, Create.

The audit that follows from this is blunt, and I now run it on every programme I design, at two points: once at the start, to name honestly what cognitive level the job actually demands — not what flatters the syllabus — and once after the first draft, module by module. The question each time is the same: what is the hardest thing a participant does here, without guidance, without the answer available? Then name the level that task actually represents, not the level written in the learning objective. A walkthrough is not Apply. A documented exercise with the steps visible is not Apply.

What followed the colleague's diagnosis at Apttus wasn't a better version of the same programme — it was a structurally different one for the advanced tier: no lectures, no demos, a facilitated simulation built around a scenario organisation that accumulated complexity across four sessions. Evaluation moved to a practitioner panel using the TOGAF architectural review framework, because assessing design judgment at Create level cannot be done with a rubric that has right answers, and I was not yet qualified to be the sole judge of whether a solution held up.

The first session of that redesigned programme is its own story — a veteran participant located the edge of what I knew within the hour and didn't let the room forget it. He wasn't entirely wrong. What mattered afterward wasn't managing that; my mentor was clear the conversation was about the programme, not my reputation. Close the gap or name it honestly — those are the only two options. The version of the programme that eventually produced the IBM Americas results — CPQ and workflow rollout for 300 users, measurable improvement in customer conversion, quoting errors down — was what that redesign became after several more rounds of the same audit, not the version that came out of the first attempt.

The question underneath all of it is the one the colleague gave me, rephrased: what is the hardest thing this participant will face in the real world, without support, on a day when it matters? Whatever cognitive level that demands — Analyse, Evaluate, Create — that is the target. Everything before it is scaffolding. Calling a ceiling a learning objective doesn't make it a destination.

Further reading: Bloom, B.S. (Ed.) (1956). Taxonomy of Educational Objectives. David McKay Company. · Anderson & Krathwohl (Eds.) (2001). A Taxonomy for Learning, Teaching, and Assessing. Longman. · Kirschner, Sweller & Clark (2006). Why minimal guidance during instruction does not work. Educational Psychologist, 41(2).