Blog

Ethan Mollick has a scaffolding problem. He’s spent years making the case for AI as a learning partner — Co-Intelligence is genuinely persuasive on this — but the research on AI-assisted learning keeps surfacing a troubling pattern: when people use AI as scaffolding to learn complex skills, they often become dependent on the scaffold rather than developing the underlying capability.

This isn’t unique to AI. Apprenticeship models have been solving — and sometimes creating — this problem for centuries. The master-apprentice relationship is the oldest answer to the question of how you transfer tacit knowledge from someone who has it to someone who doesn’t. It also predates every digital learning system by millennia, and it still works better than most of them. Understanding why tells you a lot about where AI learning tools succeed and where they’re going to fail.

The Scaffolding Paradox in Practice

Here’s the problem in concrete terms: I’ve built a 20-agent AI system that handles significant portions of my workflow. I write better first drafts faster, synthesize research more thoroughly, and spot patterns across data sets that I would have missed before. These are genuine capability improvements.

But when I assess the people on my teams who have adopted AI tools most enthusiastically, I’m noticing something uncomfortable: their AI-assisted work product is improving, but their independent judgment on the same types of problems isn’t improving at the same rate. They’re getting better outputs with AI. They’re not necessarily getting better at the underlying reasoning that generates good outputs.

This is exactly what educational technology research on scaffolding has documented for decades. Scaffolding that removes the struggle of learning — that answers the question before the learner has grappled with it — produces more efficient short-term outputs and less durable long-term capability. Students who use calculator apps become faster at arithmetic and slower at mathematical reasoning. Writers who use grammar checkers produce cleaner prose and develop weaker editorial instincts. The scaffold substitutes for the learning rather than accelerating it.

What Apprenticeship Gets Right That AI Scaffolding Usually Misses

The master-apprentice model works because it’s built on three principles that most AI learning tools violate:

Context before process. Apprentices don’t get handed a manual. They observe the master working in real contexts — seeing the judgment calls, the trade-offs, the moments of uncertainty before decisions. The learning is embedded in practice, not abstracted into steps. Most AI tutoring optimizes for process efficiency: here’s the template, here’s the workflow, here are the five steps. The tacit knowledge of when to apply which approach — the judgment layer — doesn’t transfer through templates.

Struggle as pedagogy. Good mentors don’t rescue apprentices from difficulty; they use difficulty as the teaching medium. The moment the apprentice gets stuck is often the highest-value learning moment — it surfaces where their mental model diverges from reality. AI scaffolding tends to eliminate this. Stuck on a document? AI drafts it. Can’t find the right framing? AI suggests five. The struggle that would have built capability gets bypassed entirely.

Progressive responsibility transfer. The best apprenticeship relationships follow a deliberate arc from observation to supported practice to independent execution with feedback to autonomous work. This progression is designed, not accidental. Most AI tools don’t have a model of the learner’s development over time — they just answer whatever question is asked, at whatever level of support is requested, with no view toward building toward independence.

What This Means for Building AI Learning Tools

The AI learning products that will create durable value are the ones that preserve productive struggle rather than eliminating it. Practically, this means:

Design for delayed assistance. The most sophisticated AI tutoring designs I’ve seen require users to make their own attempt before unlocking AI assistance. This preserves the learning that happens in the struggle phase while preventing frustration from becoming discouragement. The friction is intentional — it’s doing work.

Ask questions instead of providing answers. An AI that responds to “how do I approach this problem?” with a clarifying question — “what have you tried so far, and where did that break down?” — is building the learner’s reasoning. An AI that just answers the question is substituting for it. Mollick’s own research on AI pedagogy points in this direction: the AI-as-Socrates model outperforms the AI-as-encyclopedia model for capability development.

Build mental models explicitly. Scaffolding that helps users understand why something works — not just what to do next — builds transferable reasoning rather than step-following. This is harder to build and harder to measure, which is why most AI tools don’t do it. But it’s the difference between producing capable practitioners and producing tool-dependent process followers.

The Stakes Are Higher Than They Look

If you’re building AI tools that people use for learning or skill development — whether that’s a sales enablement tool, a customer service training platform, an onboarding system, or an educational product — the scaffolding question determines whether your product creates lasting value or lasting dependency.

Products that make people capable compound in value. Users become more effective over time, credit the tool for helping them get there, and advocate for it because they can point to real skill growth. Products that create dependency are fragile — valuable when present, debilitating when absent, and increasingly resented when users realize they haven’t actually grown.

I’ve seen this dynamic in the platforms we’ve built for ministry and faith formation: tools designed to make practices easier often made practitioners weaker. The same dynamic shows up in corporate learning systems, sales tools, and product development processes. The question isn’t whether AI can help people work through complex tasks. It’s whether it’s helping them build the judgment to work through those tasks more independently over time.

If you’re thinking about how AI tools change the skill requirements for product roles, this connects directly to the hiring question: the PMs who will be most valuable in an AI-native organization are the ones who’ve built judgment, not just the ones who’ve built AI fluency.

Your Turn: Apply This Today

Designing for learning — rather than just task completion — requires intentional choices. Here’s where to start:

• Audit your AI features for scaffolding vs. substitution. For each AI feature in your product, ask: does this help users develop capability, or does it complete the task so thoroughly that users stop developing the underlying skill? If it’s the latter, you have a dependency risk.
• Design one “fade-the-scaffold” feature this quarter. Identify an AI assist that new users need but experienced users don’t. Build a mechanism that gradually reduces the assist as user competency grows — like training wheels that automatically come off.
• Interview users about what they’ve learned from your product. Ask: “What can you do now that you couldn’t before you started using us?” If the answer is “nothing — the AI just does it for me,” you’re building dependency, not capability. Both can be valid business models, but know which one you’re running.
• Add a “learning mode” vs. “efficiency mode” toggle to high-dependency features. Let users choose whether they want the AI to do it for them or guide them through doing it themselves. The toggle itself signals that you’ve thought about skill development.
• Evaluate your retention metrics through a dependency lens. High retention can mean high value or high lock-in. Ask: are users retained because the product makes them better, or because they can no longer function without it? The distinction matters for long-term product health and user trust.
• Build a “transfer test” into your user research. Periodically ask long-term users to attempt their core task without AI assistance, then with it. Measure the gap. If the gap is growing over time, your scaffold has become a crutch.

If you’re thinking about AI collaboration in product teams more broadly, this scaffolding question is the flip side of the AI-as-coworker conversation — both are about how humans and AI systems should divide cognitive labor over time.

Building AI tools for learning, training, or skill development — and want to design for capability growth rather than dependency? I consult with product teams on AI-assisted learning design, scaffolding strategy, and building products that create durable user value. Let’s talk.

Barry Schwartz’s research on choice overload — documented in The Paradox of Choice — showed that more options reliably make people less satisfied and less likely to choose. The famous jam study: a display with 24 varieties attracted more browsers but generated far fewer purchases than a display with 6. More options, less action.

AI has created a jam aisle with infinite varieties, and most product teams are treating it like a feature advantage. Every conversation about “AI capabilities” sounds like a menu planning session: look at everything we can do. The technology can theoretically do anything, so the assumption is that users want access to everything.

They don’t. And the products that understand this are going to win.

AI Feature Creep Is a Choice Paradox Problem

The pattern plays out the same way across AI product launches I’ve seen: a team builds a genuinely capable AI feature and launches it with broad capability — “ask it anything,” “summarize any document,” “generate whatever you need.” Usage is lower than expected. User feedback is confused. The team concludes the AI isn’t good enough and invests in improving the underlying model, when the real problem is the interface design choice to expose unlimited capability without opinionated defaults.

When I first started using GPT-4 for product work, I stared at the blank prompt box for longer than I’d like to admit. The capability was extraordinary. The interface was paralysis-inducing. Every time I sat down to use it, I first had to decide what to use it for — which was itself cognitive work that the tool didn’t help with.

Adding constraints made it more valuable, not less. “Analyze this data” got mediocre results. “Analyze this data for three specific insights about user retention that I might be missing” got genuinely useful outputs. The constraint reduced choice for the AI and for me, and the outputs improved dramatically.

The Curation Advantage Is Underexploited

Look at how the best AI product integrations actually work. Replit’s AI coding assistance doesn’t give you a generic AI chat interface. It offers contextually relevant, constrained actions: fix this bug, explain this function, write tests for this code. Each action is integrated into the development workflow rather than floating as a generic capability. The AI does more because it’s been given less to choose from.

Notion’s AI implementation shows the same principle: when you highlight text, it surfaces contextually relevant options based on content type rather than displaying all possible AI actions. The AI is making choices about what choices to offer, which is the genuinely hard product design problem.

Choice architecture research tells us users don’t want fewer options — they want intelligently structured ones. The goal isn’t to eliminate capability. It’s to make good default choices for users so they can focus cognitive resources on the work that matters rather than on deciding how to use the tool.

Three Design Principles for Fighting AI Choice Overload

Lead with workflow, not capability. Don’t present what the AI can do in the abstract. Present what users are trying to accomplish and show AI as the accelerant for specific, recognizable tasks. “Summarize this meeting” is a task. “AI-powered meeting assistant with transcription, action item extraction, sentiment analysis, and searchable archives” is a capability list that makes users wonder which part to try first.

Default to constrained, allow expansion. Ship with opinionated defaults that work for 80% of use cases. Make it possible to unlock broader capability, but don’t lead with it. Users who need the full flexibility will find it. Users who don’t will get value faster and with less friction. The majority of your users will never need the advanced settings — designing for them first is a mistake.

Let AI curate its own interfaces. The most sophisticated AI product design pattern: use AI to decide what choices to offer users, based on context. This is what the best implementations do — contextual, dynamic option presentation that reduces the meta-choice burden. You’re not hiding capability. You’re surfacing the right capability at the right moment.

The Counter-intuitive Competitive Advantage

In a market where every competitor is adding AI capabilities, the counter-intuitive competitive advantage is ruthless curation. The product that makes users feel capable and focused beats the product that makes users feel overwhelmed, even if the overwhelmed product has technically superior AI.

This is Schwartz’s insight applied to product strategy: the winning AI products won’t be the ones with the most features. They’ll be the ones that make the most confident choices on behalf of users, removing the cognitive burden of deciding how to use powerful tools. Those are design decisions, not model decisions — and they’re available to any team willing to make opinionated calls about what matters most for their users.

If you’re thinking about how AI feature design connects to user trust over time, the inversion framework is worth running on any AI feature launch: explicitly ask how unlimited capability exposure could destroy user confidence, and design against those failure modes.

Your Turn: Apply This Today

Your next sprint planning is an opportunity to say no more deliberately. Here’s how:

• Conduct a “choice audit” on your core workflow. Walk through the main path a new user takes in your product. Count every decision they’re asked to make before they get to value. If it’s more than five, you have a choice overload problem to solve.
• Apply the “brilliant friend” test to your AI features. Would a brilliant friend with your product’s capabilities offer 12 options and ask you to choose — or would they just give you the best answer? Redesign your AI features to behave like the friend, not the dropdown menu.
• Eliminate one “power user” feature from your primary navigation this sprint. Identify a feature that 80% of your users never touch. Move it to an advanced settings section. Measure whether new user activation improves. It almost always does.
• Rewrite your AI feature descriptions to emphasize what they decide for the user. Instead of “Choose from 8 AI writing styles,” try “We’ll match the right tone for your audience.” Confidence in the system builds trust. Choice signals uncertainty.
• Set a “maximum options” standard for your product design system. Define explicitly: no UI element presents more than N choices at a time without progressive disclosure. Make it a design constraint, not a suggestion.
• Interview users who churned in the evaluation phase. Ask them: “Was there a moment where you felt overwhelmed or unsure what to do next?” If you hear it more than twice, you’ve found the choice overload drop point. Fix that before you add another feature.

Building AI features and fighting the instinct to expose every capability you’ve built? I consult with product teams on AI product strategy, feature prioritization, and the design decisions that create durable user value. Let’s talk.

Peter Drucker wrote The Effective Executive in 1967, before knowledge work had fully displaced industrial work as the dominant mode of economic value creation. His core argument: effectiveness — producing the right results — is a discipline that can be learned. Efficiency — doing things faster — is a distraction if you’re doing the wrong things.

Seventy years later, AI is making Drucker’s distinction more urgent, not less. I’ve been running a 20-agent AI system for eight months. My output has never been higher — specs drafted faster, research synthesized in minutes, emails triaged and responded to before I’ve even looked at my inbox. My impact? That’s a different question, and a harder one to answer.

The AI Productivity Paradox

Here are the three traps I’ve observed across multiple organizations implementing AI tools, including my own teams:

The Tool Trap: Teams adopt AI without changing their work design. The result is faster generation of the same ineffective outputs. The company was already producing too many status updates, too many options without clear decision criteria, too many documents nobody reads. AI helps them produce more of that, faster. The work product volume goes up. The decisions don’t get better.

The Volume Trap: Individual contributors use AI to produce more — more analysis, more options, more documents. Their managers now have twice as much to review with no additional capacity for review. Decision quality decreases as cognitive load on decision-makers increases. The people who benefit most from AI productivity tools are often creating bottlenecks for the people above them.

The Speed Trap: AI enables rapid iteration, so teams iterate rapidly — on problems that aren’t well-defined. Speed without clear objectives doesn’t compress learning cycles. It just burns through resources faster on the wrong problems. I’ve watched teams use AI to generate ten variations of a product concept before anyone had agreed on what problem the product was solving.

What AI Does to Drucker’s Framework

Drucker defined knowledge workers as people whose tool is their own knowledge — whose productive output is the application of informed judgment to complex problems. The paradox: AI dramatically amplifies the volume of work knowledge workers can produce while doing almost nothing to improve the quality of their judgment.

I can draft a product strategy document in 20 minutes with AI assistance. That used to take four hours. The time savings are real. But strategy isn’t about document creation — it’s about making difficult choices with incomplete information, building conviction in a direction when reasonable people disagree, and committing resources before you have certainty. AI doesn’t do any of that. It helps me produce the artifact of strategic thinking faster, not the strategic thinking itself.

When I was at a consulting firm early in my career, I could generate competitive analyses, user journey maps, and market segmentation frameworks faster than anyone on the team. But I was optimizing for the wrong thing. The clients didn’t need more frameworks — they needed clearer decision-making. My AI-enabled productivity made me feel more valuable while I was actually less impactful than the partner who spent three hours in a room with a client asking uncomfortable questions with no slides in sight.

What Effective AI Use Actually Looks Like

The organizations getting AI right share a common pattern: they redesigned work around outcomes, not activities. They asked “what decisions do we need to make better?” before they asked “what tasks can AI help with?”

One product team I work with stopped using AI to generate more user personas. They use it to interrogate existing ones — to find the gaps, contradictions, and unstated assumptions in their current understanding of users. Same tool, completely different question. The AI generates more variance and sharper challenges to their existing beliefs rather than more artifacts that confirm them.

Another team uses AI specifically to reduce the volume of options they present to decision-makers — not increase it. They generate ten options, use AI to stress-test each one, and present three with clear trade-off analysis. Less volume, higher decision quality, faster leadership alignment.

The diagnostic question Drucker would apply is simple: Which decisions are better because of your AI use? Not “how much more am I producing?” but “where is my judgment actually improving, and where am I just producing more?” If you can’t name specific decisions that got better, you’re in the Tool Trap — generating more output without improving what matters.

The Manager’s Job in an AI-Enabled Team

Drucker argued that the manager’s job is to create the conditions for effective knowledge work — which means designing systems where people apply their judgment to problems worth solving, not just problems they can solve quickly.

In an AI-enabled team, that job gets harder before it gets easier. You have to resist the temptation to measure productivity by AI tool adoption rates, document generation speed, or throughput metrics that feel like evidence of progress. You have to build the clarity about outcomes that makes it possible to distinguish effective AI use from sophisticated busywork.

This connects directly to how you hire: the skills that matter most in AI-era product roles are exactly the ones Drucker would have valued — judgment, the ability to define the right problem, and the discipline to focus on outcomes rather than outputs. AI amplifies those skills in people who already have them. It amplifies the wrong behaviors in people who don’t.

Read Drucker’s foundational work on knowledge worker effectiveness with AI in mind and it lands differently than it did in 1967. The core problem he identified — confusing activity for effectiveness — is harder to see now, because the activity looks more impressive than ever.

Your Turn: Apply This Today

The productivity paradox is real. Here’s how to manage it intentionally rather than fall into it:

• Audit your team’s AI-assisted work for effectiveness, not just speed. Pick three AI-assisted outputs from the last month. Ask: did these advance the right problem, or did they efficiently answer the wrong question? Speed on the wrong task is still waste.
• Define your team’s “high-judgment” work explicitly. Make a list of the five to seven tasks in your product process that require the deepest human judgment and institutional knowledge. Protect those tasks from AI defaulting. Don’t let speed pressure push judgment work to the AI.
• Build a “contribution mapping” practice. For each team member, map what they uniquely contribute that AI cannot — relationships, contextual judgment, pattern recognition from experience. Use this to structure their AI assistance: AI handles the mechanics, humans handle the judgment calls.
• Set a “problem definition review” before every sprint. Spend 15 minutes at the start of each sprint asking: are we solving the right problem? AI makes execution so fast that teams skip problem definition. Don’t let the tool’s speed become your team’s blind spot.
• Track “decision quality” as a leading indicator. Measure how often your team changes direction after shipping — a proxy for whether the initial problem definition was correct. If the rate is climbing while productivity is up, you have a Drucker paradox on your hands.
• Create space for the “slow thinking” that AI cannot do. Block dedicated time in your team’s calendar — not for AI-assisted work, but for hard thinking without a prompt interface open. Strategic insight requires uninterrupted reflection. Protect it.

The organizational pattern that creates this paradox — shipping more without improving decisions — is the same thing driving the feature factory problem: speed without selection pressure.

Implementing AI tools across a product team and finding that productivity is up but outcomes aren’t? I consult with organizations on AI-enabled work design, team effectiveness, and building the management disciplines that turn AI capability into actual impact. Let’s talk.