If you know me, you know I'm a nerd and I like to learn new things. So when I first heard about the 10,000-hour rule, it actually intrigued me because I do like to learn new things. But experience and practice taught me that it sounds great until you realize most business and life challenges don't work that way.

Put in your hours at accounting or project management and you'll get better. The feedback is clear, the rules are stable, and practice compounds.

But strategy? Product development? Market positioning? Those exist in what researchers call "wicked" environments. The rules keep changing. You won't know for months if a decision was right. And by the time you get feedback, the landscape has shifted again.

This is why most of what matters in business can't be mastered through repetition alone. You need a different approach.

The Difference Between Kind and Wicked Problems

The 10,000-hour rule works in "kind" environments. Chess, classical music, accounting. Put in deliberate practice and you'll improve predictably.

Most business challenges aren't kind. They're wicked.

In wicked environments, the feedback is delayed and ambiguous. You launch a product and wait months to see if the positioning was right. You make a strategic bet and the market shifts before you get results. The patterns you learned last year might not apply this year.

This is especially true in growth strategy, product development, and market positioning. By the time you've logged enough hours to feel confident, the game has changed.

You need a different kind of mastery. Not deep expertise in a stable domain, but the ability to spot patterns across domains, transfer learning quickly, and rebuild your understanding as the landscape shifts.

How to Actually Learn in Wicked Environments

Here's what works: learning to see patterns across different domains and applying them to new situations.

This is about becoming what some call an expert generalist or T-shaped. You go deep in one area to understand how things actually work at a fundamental level. Then you use that depth to recognize when those same patterns show up in completely different domains.

I've used this approach for 20 years. Product design taught me about user mental models. That transferred directly to UX research, then to engineering leadership (teams have mental models too), then to AI implementation (understanding how models think). I didn't start from scratch each time because the underlying patterns were the same.

Deconstruct: Break It Down to First Principles

Most complexity in business is just assumptions no one questioned.

Strip those away and you find something simpler underneath.

This is what people call first principles thinking, but it's really just asking "what is this, really?" Most people skip that question. They look at what competitors do, what the industry accepts, what's always been done.

Sometimes that's fine. But if you want new insights, you have to look at the actual pieces.

Three things matter when you deconstruct something:

• What are the fundamental components?

• How do they actually connect?

• Which rules are real and which are just convention?

I use this constantly in product development. Instead of copying competitor features or following industry standards, I ask what actually creates value. What needs to exist for this to work? What could we remove and still solve the core problem?

The surprising thing isn't what you find. It's what isn't there. Strip away the assumptions and most complexity disappears.

AI can help with systematic breakdown. Here's a prompt I use:

You're helping me understand [TOPIC] from first principles.

Break this down into its fundamental components. For each one:
- What is it in the simplest terms?
- Why does it have to exist? (What breaks without it?)
- How does it connect to the other pieces?

Then identify:
- Assumptions people make that aren't actually necessary
- Unnecessary complexity that could be simplified
- Parts that seem essential but might not be

Give me plain language insights, not a formal analysis.

Draw Comparisons: Find Analogies in Unexpected Places

One of the fastest ways to understand something new is to ask "what does this remind me of?"

Your brain is built for pattern matching. Use that.

Customer retention might share structure with community building. Product launches might mirror event planning. B2B sales might follow patterns from dating. (Yes, really. Both involve qualification, courtship, commitment, and ongoing relationship management.)

Three questions help:

• What have I seen like this before?

• Where else does this pattern show up?

• What makes this case unique?

The point isn't just finding similarities. It's understanding why they exist and where they break down. That's where the useful insights live.

I once helped a product team struggling with user onboarding by drawing an analogy to improv comedy's "yes, and" principle. Instead of gating features behind achievement, we started each session by saying "yes" to what users wanted to do, then added gentle guidance. Engagement went up 40% in two weeks.

The analogy wasn't perfect. But it unlocked a different way of thinking about the problem.

AI is surprisingly good at finding non-obvious analogies. Here's how I prompt it:

Find three analogies for [TOPIC] from completely different domains.

For each analogy:
- What makes it structurally similar?
- Where does the comparison break down and why?
- What does this reveal that wasn't obvious before?

Focus on surprising comparisons that show me something I wouldn't have seen on my own.

Rebuild: New Mental Models Fore New Situations

Mental models are just useful shortcuts for understanding how things work. They're not perfect copies of reality. They're simplified frameworks that help you recognize patterns and make better decisions.

But here's the thing: every mental model has boundaries. Occam's Razor works great for technical problem-solving but can oversimplify human behavior. Second-order thinking is powerful for strategy but can lead to analysis paralysis in situations requiring fast decisions.

The skill isn't just having mental models. It's knowing when each one applies and when to set it aside.

Strong mental models help you make better decisions under uncertainty. Whether you're evaluating a partnership, planning a product roadmap, or allocating resources, having the right mental models means you make better calls faster.

The more you have, the clearer complex things become. I keep a running catalog in my commonplace book. Not because I'm trying to memorize them all, but because seeing connections between models often reveals something new.

AI can help you test and refine mental models. Here's my approach:

For [TOPIC], develop a mental model that:
- Captures the essential dynamics in 3 principles or fewer
- Can be explained in a single paragraph
- Generates testable predictions

Then:
- Test the model against 3 real-world examples
- Identify where it works best and worst
- Show how it changes decision-making

Focus on practical utility over theoretical completeness.

Why This Is Important For You

Here's what this approach gives you: the ability to enter new domains quickly without starting from scratch.

When I moved from UX design into product strategy, I didn't spend 10,000 hours learning strategy. I recognized that user research skills (identifying patterns, validating assumptions, testing hypotheses) transferred directly. The domain changed. The underlying patterns didn't. When Hello Alice needed to build AI capabilities, I didn't become an AI researcher. I recognized that product development principles (start with the problem, validate before building, measure what matters) applied just as much to AI as to traditional features.

This isn't about being shallow. It's about being strategic with where you invest deep learning time.

But let's be clear: there are still times when you need to put in the work. Teaching a few classes on how to use ChatGPT or Claude doesn't make you an AI expert. The world of AI is much broader than LLMs. If you need to understand RAG, agentic systems, or machine learning architectures at an implementation level - not just conceptually - you're going to need deep study in those specific areas.

The trick is knowing the difference. When can you transfer patterns from what you already know? When do you actually need domain-specific expertise? That judgment call is part of the skill.

Go deep on fundamental patterns. Transfer them broadly. But recognize when you've hit the limits of transfer and need to go deep again.

A Different Kind of Knowledge Capture

The best insights often come from unexpected sources.

I study everything from improv comedy to behavioral economics. Not to become an expert in every field, but to find ideas that connect with what I already know about design, technology, and business.

In wicked environments, the ability to extract useful knowledge from diverse sources isn't just helpful. It's essential for staying ahead.

I've developed a specific approach for this, adapted from keeping a commonplace book for 20+ years. It helps me turn information into knowledge I can actually use.

How I Organize What I Learn

When I capture something worth remembering, I sort it into three main categories:

Concepts need to be understood, not memorized. Network effects in business, for example, isn't just a definition. It's recognizing how they work and spotting opportunities to create them.

Facts are specific pieces of information worth keeping handy. I don't try to remember every market size or benchmark. But having key metrics readily available helps me make faster decisions.

Procedures are skills that need practice. Client communication protocols, facilitation techniques, strategic planning processes. The things that should become muscle memory.

Beyond these core categories, I track:

• Key Ideas - potential seeds for innovation, unexpected connections, counter-intuitive insights

• Insights - refined observations from connecting multiple ideas or seeing patterns across domains

• Quotes - sometimes an idea is best captured in someone else's words

• Habits - regular practices that drive results (different from one-time procedures)

• References - sources worth revisiting when I need deeper understanding

This isn't about collecting everything. It's about extracting what matters while staying focused on what creates value.

Using AI to Process Information at Scale

This framework becomes more powerful when you combine it with AI.

I have a specific prompt for processing articles, transcripts, books. Anything where I want to extract the useful knowledge without having to manually sort through everything.

It analyzes the content type first (technical material gets processed differently than creative content), then extracts concepts, facts, procedures, ideas, insights, quotes, and habits using the exact framework I described above.

What I get back is organized knowledge I can actually use, not just highlighted passages or saved articles I'll never read again.

If you want a copy of the prompt, reach out to me on LinkedIn and I'll send it over.

The goal isn't to collect everything. It's to capture the knowledge that matters for your work while building a foundation of insights you can draw from.

Two Approaches to Learning Broadly

Here's something I realized years ago: the competitive advantage often comes from connections others miss.

Studying broadly isn't just about collecting information. It's about developing pattern recognition across domains. I do this two ways.

Structured Learning Across Domains

I maintain what people call T-shaped knowledge. Deep expertise in product and AI implementation. Broad understanding of related fields like psychology, design thinking, strategic foresight, and organizational behavior.

This isn't random. Each adjacent field connects to my core work in specific ways:

Psychology helps me understand user behavior and team dynamics. Design thinking provides frameworks for problem-solving. Strategic foresight helps me think about long-term implications. Organizational behavior shows me why certain changes work and others don't.

AI can help you map out learning paths. Here's how I structure it:

You help people develop T-shaped knowledge: deep expertise in their core field plus broad understanding of related domains.

Based on this context:
- Core expertise: [your field]
- Main challenges: [what you're trying to solve]
- Interested in: [adjacent fields you're curious about]
- Time available: [how much you can invest]

Provide:
- Three most valuable adjacent fields to explore and why each connects
- One key mental model from each field that applies to my main challenges
- A simple weekly learning plan that fits my available time
- Two specific ways to apply insights from these fields to my current work

Keep it practical and focused on immediate value. Emphasize connections between fields rather than surface-level knowledge.

Opportunistic Pattern Recognition

Sometimes the best insights come from places you weren't expecting.

I keep my commonplace book open to ideas from anywhere. A conversation about improv comedy reveals something about product team dynamics. A documentary about architecture shows me something about information systems. A book about comedy writing teaches me about narrative structure in presentations.

This only works if you're actively looking for transferable patterns. Not "that's interesting." But "where else does this pattern show up? How does it connect to what I already know?"

The connections aren't always obvious at first. Sometimes it takes months before an idea from one domain suddenly unlocks understanding in another.

That's fine. The point isn't immediate application. It's building a rich mental library of patterns you can draw from when you need them.

What You're Actually Building

Here's what happens when you get good at this:

You stop seeing business challenges as isolated problems requiring specialized expertise. You start seeing patterns that repeat across different contexts.

A retention problem shares structure with community building. A product positioning challenge mirrors problems from political campaigns. A team coordination issue follows patterns from improv theater.

You're not becoming a superficial generalist. You're developing the ability to recognize fundamental patterns and apply them strategically.

That's a different kind of mastery. Not 10,000 hours of practice in stable environments. But the ability to transfer learning, adapt quickly, and see connections others miss.

In wicked environments, that's what actually matters.

Start with systematic deconstruction. When you encounter a new challenge, break it down before you try to solve it. What are the fundamental components? What assumptions are you making? What rules are real versus just convention? This five-minute analysis often reveals simpler solutions.

Build a catalog of mental models and analogies. When you find a useful framework or analogy, capture it. Over time, you'll have a collection of proven patterns you can apply to new situations. I keep mine in Notion, tagged by domain and type. Makes it easy to find the right tool when I need it.

Practice cross-domain pattern recognition deliberately. When you read something outside your field, actively look for transferable patterns. Where else does this show up? What does it remind you of? How could this apply to your current challenges? This becomes automatic with practice.

"Am I trying to memorize information, or am I building frameworks for understanding?" This shows whether you're collecting facts or developing genuine capability. Facts have short shelf lives in wicked environments. Frameworks help you adapt.

"Where can I go deep on fundamental patterns that transfer broadly?" This reveals whether you're being strategic with your learning investment. Don't go deep on domain-specific trivia. Go deep on core patterns that show up everywhere.

The 10,000-hour rule works for accounting. It doesn't work for the messy, complex problems that matter most in business.

In wicked environments, mastery isn't about repetition. It's about your ability to transfer learning across domains, break down complexity to first principles, spot analogies in unexpected places, and build mental models that work.

That's not something you can practice your way into. It's something you have to deliberately develop.

The good news? You can get dramatically better at this in months, not years. Because you're not building domain expertise from scratch. You're developing the meta-skills that let you learn anything faster.

That's the kind of mastery that actually compounds.