By the time I redesigned the curriculum at Apttus, I thought I understood what production-ready meant. I had changed the first question — moved from "what do we need to cover?" to "what does this participant need to be able to do on day one back at work?" I had built a bank of real-world use cases drawn from actual implementations. The program was better. Feedback had improved. Managers were telling me the new hires were ramping faster. I had found the problem and I had fixed it.
Then a senior colleague attended one of my sessions.
He stayed afterward. He was generous — not dismissive, not congratulatory. He sat with me for an hour and asked me questions I wasn't ready for. Not about the content, not about the delivery. About the taxonomy. Specifically: he wanted to know what level I thought my program was reaching. I told him application level. Participants were configuring the product, working through real use cases, demonstrating they could do the thing.
He looked at me and said something I have thought about almost every day since. "If you're going to train solution architects, you have to do what solution architects do."
I didn't fully understand it yet. But I understood enough to know that my definition of production-ready had a ceiling — and I had built that ceiling myself.
What Bloom actually built
Benjamin Bloom published his taxonomy of educational objectives in 1956. It has since been revised, debated, and cited in approximately every L&D strategy document ever written. Most practitioners know the six levels: remember, understand, apply, analyse, evaluate, create. Most programs write learning objectives at the "apply" level and consider the job done.
The problem is not with the taxonomy. The problem is with the ceiling people impose on it — and the honesty gap between what the learning objective says and what the exercise actually demands.
Here is what those six levels look like in a technical training room, stripped of academic language:
The colleague's point was surgical. My program was reaching Apply — genuinely, not just on paper. But I was training solution architects. 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. Those are not the same cognitive task. And no amount of good content at Apply level closes that gap.
You cannot design a program that demands more than you've become. I hadn't become what the program required. I just didn't know it yet.
The restructure — and what it actually produced
The response to the colleague's diagnosis wasn't a better version of the existing program. It was a different structure entirely. We split the curriculum into three levels: Basic, Intermediate, and Advanced. Basic and Intermediate continued to evolve — real use cases, scaffolded complexity, the design principles from the previous iteration. Those programs kept getting better through iteration and a growing use case bank. They remained taught courses.
Advanced became something different in kind.
The Production Readiness Practicum was not a taught course. There were no lectures. There were no demos. It was a facilitated simulation — twenty hours across four sessions — built around a purpose-built scenario org that accumulated complexity as the program progressed. Each session introduced a new real-world situation. Participants worked in small cross-client groups of three to four people. The facilitator did not play the role of instructor. The facilitator played the role of product owner — the person with requirements, constraints, and opinions, not answers.
Participants were evaluated on their judgment and their documentation. Not on whether they caught every defect. Not on completion. On the quality of their thinking under conditions that resembled the job.
That shift in evaluation design was itself significant. Assessment at Create level cannot be a checkbox. You cannot evaluate design judgment with a rubric that has right answers. We adopted the TOGAF architectural review framework as the evaluation scaffold — and I insisted on a panel of evaluators, not a single instructor assessment. I was barely finding my footing as a facilitator for this format. I was not qualified to be the sole judge of whether a solution design was sound. That required practitioners — people who had done the job, who could assess the thinking, not just the output.
Getting that panel together was not easy. It meant begging colleagues to keep their Friday afternoons free, coordinating across schedules, making the case over and over that an hour of their time was worth it. It was a hard sell every time. I made it because I had no other option. The assessment had to be credible even when I wasn't yet fully formed as a facilitator. Taking myself out of the centre of the evaluation was not modesty. It was the only structurally honest thing to do.
The first session
I was not ready.
I knew that in the way you know things but don't let yourself fully believe them. I had built the scenarios. I understood the product. I had the use cases, the org design, the complexity arc across four sessions. I had designed every element of the Practicum. And I had not yet done, at any meaningful level of accountability, what I was asking participants to do. I was not yet a solution architect. I was a trainer who had studied architecture, certified in it, worked alongside it — but had not been responsible for a design that failed or succeeded in a real client environment.
One participant smelled it within the first hour.
He was a veteran. Experienced, sharp, and determined to be the most credible person in the room. That combination — genuine expertise plus a need to establish dominance — produces a particular kind of participant. He began testing me. Specific, pointed questions designed less to learn than to locate the boundary of what I knew and expose it to the room. He found it. And once he found it, he didn't stop.
Twenty hours of that is a long time. What starts as one person heckling has a way of creating permission for others. The room shifts. You lose the thread of what you were trying to do. You make mistakes you wouldn't ordinarily make — small ones, but visible ones, and in that context every mistake is fuel. By the end of the three days I had been made to look, in front of a room full of new colleagues, like someone who had built a program they had no business running.
He was not entirely wrong. That is the honest thing to say.
He has continued to say so, to anyone who will listen, in the years since. That part is his problem, not mine. But the three days were mine to own.
The sit-down
Afterward, I met with my mentor and my manager. I came in worried about my reputation — what the batch would take back to the floor, what it would mean for how I was perceived, what damage had been done. I had spent the days since the session running that calculation. It felt urgent.
They were not interested in it.
My reputation was not on the list of action items. It was not a deliverable. The conversation was about the program — what had been exposed, what it meant for the next batch, what I was going to do to make sure it didn't happen again. More study. More practice. Get closer to the work of architecture before facilitating a room of architects. The only answer to the gap the session had revealed was to close it. Not manage the perception of it. Close it.
The advice I received about my reputation was brief: you'll get over it.
That was the right answer. I didn't love it at the time. But it was right.
The program needed fixing. My reputation was not the program. Those two things were not the same problem, and treating them as though they were would have produced the wrong solution to both.
What came after — and what it took to get there
The work that followed was not a single redesign. It was a series of iterations across multiple sessions and workshops — each one surfacing something the previous one had missed, each one adding precision to the use case bank, the evaluation criteria, the complexity arc of the scenario org. The program that eventually produced the IBM Americas results was not the program I had designed after the colleague's advice. It was what that program became after compounding iteration — some of it planned, much of it learned the hard way.
At IBM, a CPQ and workflow rollout for 300 users across the Americas. Improvement in customer conversion. Revenue leakage eliminated. Quoting errors down. Those numbers did not come from a single training session. They came from participants who had been through a curriculum that had been designed, broken, rebuilt, and refined until it was actually producing the capability the job demanded — not the capability the syllabus claimed to produce.
The difference between those two things is the entire point.
The audit move — what I do now before anything else
Bloom's taxonomy enters my design process twice. Once at the start, to establish where the program needs to terminate — what cognitive level the job actually demands, described honestly, without flattering the design. And once after the first draft, as an audit.
The audit is blunt. I go through every module and ask: what is the hardest thing participants do here, without guidance, without the answer available? Then I name the level that task actually represents — not the level I wrote in the learning objective, but the level the exercise demands in practice. A walkthrough is not Apply. A documented exercise with the steps visible is not Apply. Apply means unguided configuration of a feature the participant has been taught. Analyse means a novel problem. Evaluate means a recommendation under conditions of genuine uncertainty. Create means design without a template.