The Technology World's Bard: What I Learned About Myself at Product School's PMC Class (and Didn't)

The Everyman Role: When Formality Meets Intuition

After seven years on my open source journey, I recently completed Product School’s Product Management course with mixed feelings. On a scale of 1-10, I’d rate the experience around a 4 – it confirmed some practices I’ve developed naturally, but the excessive formality felt at odds with the fluid, adaptable nature of effective product management.

The course refreshed concepts I’d encountered in my 2019 Masters in Tech Management, my 2021 Nielsen Norman Group UX courses, and my 2020 SAFE Agile training. What I found most interesting wasn’t what I learned, but the confirmation that much of what makes a good product manager is absorbed through osmosis while actually doing the work.

The Product Manager as Technology’s Bard

If software development were a medieval guild, product managers would be the bards – able to speak the language of multiple disciplines, translate between specialists, and tell the story that weaves various elements together. Like the bard, we’re not the deepest experts in any single craft, but our value comes from breadth rather than depth.

The course confirmed this “jack of all trades” nature of the role, but perhaps overcompensated by attempting to formalize what is inherently an adaptive, context-sensitive position. The rigidity of some frameworks seemed to miss the fluid, improvisational aspects that make product management effective in the real world.

Frameworks: Useful Templates or Unnecessary Bureaucracy?

The course covered several frameworks that, while intellectually interesting, often felt like they formalized common sense rather than providing genuinely new insights. Here’s my take on some of the major examples:

Design Sprints: Structure for Creativity or Creativity in Spite of Structure?

Google Ventures’ Design Sprint methodology offers a five-day process for rapidly prototyping and testing solutions:

Preparation:

• Select a substantial problem
• Assemble diverse team members
• Schedule user testing participants
• Designate a facilitator
• Prepare necessary materials

The Five-Day Process:

• Day 1: Define challenge and context
• Day 2: Generate solutions (lightning demos, “Crazy Eights”)
• Day 3: Vote on promising concepts
• Day 4: Build a prototype
• Day 5: Test with users

While this structure can be helpful, especially for teams without established processes, it sometimes felt like it added administrative overhead to what successful teams do organically. The best product teams I’ve worked with achieve the same outcomes without necessarily following such a rigid timeline.

AARRR: Pirate Metrics or Obvious Progression?

Dave McClure’s AARRR framework outlines a sequence for growing products:

• Acquisition: How users discover your product
• Activation: Their first meaningful experience
• Retention: How often they return
• Referral: Whether they tell others
• Revenue: How the product monetizes

While logically sound, this framework essentially codifies an obvious progression. Most product people intuitively understand that users need to find your product before they can use it, and need to use it before they’ll pay for it. The framework provides a helpful acronym but doesn’t offer particularly profound insights beyond common sense.

Product-Market Fit (PMF) Funnel: Quantifying the Qualitative

The PMF funnel approach suggests:

1. Define what PMF looks like
2. Quantify indicators of PMF
3. Threshold: Set targets
4. Roadmap: Plan features to hit thresholds

This framework attempts to make PMF more concrete, which is valuable in theory. However, it sometimes risks reducing a nuanced, qualitative achievement to mere metrics. The best product managers I know sense PMF through a combination of quantitative and qualitative signals that resist such neat categorization.

The Hero’s Journey in Product Development

Applying Joseph Campbell’s narrative structure to product development:

• Call to Adventure: The initial problem
• Supernatural Aid: Tools and resources
• Threshold Crossing: Commitment to using the product
• Transformation: Enhanced user capabilities

This metaphorical framework was actually one of the more valuable concepts, as it provides a lens for understanding the emotional journey users take. Yet even here, the course presented it as more formulaic than the fluid, user-centered approach that effective product managers develop through experience.

MVC Architecture: Engineering Meets Product

The course revisited the Model-View-Controller architectural pattern as a way for product managers to understand software structure. While this pattern is fundamental to software engineering, the presentation felt more like a Computer Science 101 lecture than practical product management knowledge.

The breakdown was thorough but didn’t bridge the gap between technical architecture and product thinking in a meaningful way. For someone already familiar with technical concepts, it was redundant; for non-technical PMs, it might have been too abstract without clearer connections to daily product work.

API-First Prototyping: The Objective-Mode-Prototype Loop

Another framework introduced was the API-thinking prototyping cycle:

1. Objective: Define what you need to learn
2. Mode: Choose the appropriate prototyping method
3. Prototype: Create the minimal viable test
4. Learn: Gather insights from testing
5. Iterate: Refine based on learnings

This approach has merit, especially for tech products, but again presented as overly formalized what experienced product people do naturally. It’s essentially the scientific method repackaged for product development, which is useful conceptually but hardly revolutionary.

What I Actually Learned About Myself

The most valuable takeaway wasn’t from the course content itself, but from my reaction to it. I realized that after years of hands-on product work, I’ve developed a more organic, adaptive approach that sometimes conflicts with overly formalized methodologies.

What made me a “4 out of 10” product manager in the course’s eyes might actually be strengths in the real world:

• Flexibility over rigid frameworks
• Intuition informed by experience
• Comfort with ambiguity
• Ability to adapt approaches to context
• Preference for simplicity over process-for-process-sake

The Product Manager as a Multidisciplinary Force

One concept that did resonate was the multidisciplinary nature of the product role. The idea that a PM stands at the intersection of design, engineering, marketing, business development, and customer experience rings true. However, rather than being a jack-of-all-trades-master-of-none, successful PMs develop enough fluency in each discipline to facilitate effective collaboration and decision-making.

DIY Retro Tools: Practical Applications Missing

The course sparked one practical idea: creating my own retrospective tool. Having needed facilitated retrospectives twice at my company but finding the cost prohibitive, I realized I could develop a shared session format that would achieve similar outcomes without the expense.

Interestingly, this practical application wasn’t directly taught in the course but emerged from my own problem-solving approach to real-world challenges. This highlights a key limitation of formalized PM education – the most valuable solutions often come from creative adaptation to specific contexts rather than applying pre-packaged frameworks.

The Value of Formality vs. The Cost of Bureaucracy

While there’s certainly value in formalizing knowledge and creating shared vocabularies, the course sometimes crossed into what felt like unnecessary bureaucracy. Effective product management often requires:

1. Rapid adaptation rather than slavish adherence to frameworks
2. Contextual judgment over one-size-fits-all approaches
3. Elegant simplicity instead of process complexity
4. Practical outcomes over methodological purity

Looking Forward: The Bard’s Path

Moving forward, I’ll take the useful vocabulary and structured thinking from the course while maintaining the adaptive, intuitive approach that has served me well. The technology world needs its bards – generalists who can speak multiple languages, adapt to changing contexts, and weave coherent narratives from diverse inputs.

For others considering formal product management education, I’d suggest viewing frameworks as tools in your toolkit rather than rigid rules to follow. The most effective product managers I know use formal methodologies as starting points, then adapt based on context and experience.

In the end, product management might be one field where too much formality can actually hinder success. Like the medieval bard, the best product managers combine structured knowledge with improvisation, adaptability, and a keen sense of their audience’s needs – qualities that resist complete formalization, no matter how comprehensive the course.