← Back to Blog

When Everyone's a Product Manager: Navigating Chaos, Pricing Experiments, and AI's Gaming Revolution

• product-management, organizational-design, pricing-strategy, generative-ai, gaming, product-operations, experimentation, trust, velocity, alignment

I've watched a pattern repeat itself across dozens of product organizations: the moment a company reaches a certain velocity, someone outside the product team—usually engineering, sometimes sales—starts shipping features directly to production. The first time it happens, it feels like a breach of protocol. The tenth time, it feels like organizational entropy.

But here's what nobody tells you: this isn't always a problem to solve. Sometimes it's a signal worth reading.

Let me break down what's actually happening in modern product organizations, drawing from recent community discussions that reveal deeper truths about how we build, price, and innovate with AI products.

The Non-PM Production Problem: Symptom or Strategy?

When engineers, designers, or other stakeholders start shipping directly to production without PM involvement, most product leaders treat it as a governance failure. They're not entirely wrong—but they're missing the more interesting question: Why is this happening now?

Three Scenarios, Three Different Responses

After analyzing dozens of cases where non-PMs bypass traditional product processes, three distinct patterns emerge:

Scenario 1: The Velocity Trap

Your engineering team is moving faster than your product process can accommodate. They see obvious bugs, clear improvements, or technical debt that's blocking progress. Waiting for a PM to write a spec, prioritize it, and schedule it feels like bureaucratic theater.

What's actually broken: Your process has become a bottleneck, not a value multiplier.

The fix: Establish clear swim lanes. Not everything needs the same level of product involvement. Create a framework that distinguishes between:

The key insight? Product management's value isn't in controlling every change—it's in ensuring the right level of thinking happens for each type of change.

Scenario 2: The Trust Deficit

Sometimes people route around product management because they don't trust the function to make good decisions. This is painful to acknowledge, but it's more common than we admit.

I've seen this manifest when:

What's actually broken: The product function hasn't earned its authority through demonstrated value.

The fix: This requires rebuilding credibility through:

You can't mandate respect for the product function. You have to earn it by making everyone else's work more successful.

Scenario 3: The Empowerment Feature

Sometimes non-PMs shipping to production isn't a bug—it's a feature of high-performing organizations. Companies like Amazon, Stripe, and Linear have deliberately designed systems where engineers own outcomes, not just outputs.

The difference? These organizations have:

What's actually broken: Nothing. You might be witnessing organizational maturity.

The fix: Lean into it. Evolve your PM role from gatekeeper to:

Claude's Pricing A/B Test: A Masterclass in What Not to Do

Recent community discussions highlighted Anthropic's controversial approach to pricing experimentation with Claude Code. Users discovered they were being charged different rates for the same service—some paying significantly more than others for identical API access.

The backlash was swift and instructive.

Why Pricing A/B Tests Are Uniquely Dangerous

I've run dozens of A/B tests across various product surfaces, but pricing tests occupy a special category of risk. Here's why:

The Fairness Heuristic

Humans have a deeply ingrained sense of fairness, especially around transactions. When users discover they're paying more than others for identical value, it triggers a visceral response that goes beyond rational economics.

Behavioral economics research consistently shows that people will reject objectively good deals if they perceive unfairness in the process. The famous "ultimatum game" demonstrates this: people would rather get nothing than accept an unfair split.

The Trust Tax

Every pricing experiment extracts trust from your relationship with users. You might gain data about price sensitivity, but you lose something harder to measure: the belief that you're dealing with users in good faith.

For B2B products especially, this matters enormously. Your users aren't just customers—they're advocates, partners, and often the champions who got your product approved within their organizations. Discovering they've been paying more than their peers doesn't just make them angry; it makes them look foolish to their colleagues.

A Better Framework for Pricing Experimentation

Transparency First

If you're going to test pricing, consider making the experiment explicit:

Yes, this introduces some bias into your experiment. But it preserves trust, which is worth more than perfectly clean data.

Test on New Cohorts

Rather than varying prices for existing users, test new pricing on new signups. This creates natural segmentation without the fairness violation. Users don't feel cheated because they never had access to different pricing.

Value-Based Differentiation

If you want to test price sensitivity, test it alongside value differentiation:

Users understand paying different amounts for different value. They don't understand paying different amounts for identical value.

The Grandfather Clause

When pricing must change, protect existing users. Grandfather them into their current rates or provide generous transition periods. This costs you revenue in the short term but builds loyalty that compounds over years.

Generative AI in Gaming: The Sleeper Application

While most product builders focus on AI's impact on productivity tools, something more interesting is happening in gaming—and the lessons apply far beyond entertainment.

Why Gaming Is AI's Proving Ground

Expectation Management

Gamers expect NPCs to be somewhat unpredictable, occasionally nonsensical, and imperfect. This makes gaming one of the few domains where AI's current limitations become features rather than bugs.

In a productivity tool, an AI that occasionally hallucinates is a liability. In a game, an NPC that says something unexpected can create memorable moments.

Iteration Speed

Games are updated frequently, with players expecting regular patches and balance changes. This gives developers room to experiment with AI behaviors, gather feedback, and iterate rapidly.

Compare this to, say, medical AI or financial AI, where the stakes are higher and the iteration cycles are measured in months or years.

Economic Alignment

Generative AI's costs align well with gaming economics. Players are accustomed to paying for experiences, expansions, and content. The marginal cost of AI inference can be built into pricing models without shocking users.

Three Emerging Patterns in AI Gaming

Dynamic Narrative Generation

Instead of branching storylines with predetermined outcomes, some games are experimenting with AI-generated narrative that responds to player choices in real-time.

The key insight: Don't try to generate entire stories. Use AI to fill in the gaps between hand-crafted narrative moments. Think of it as procedural generation for dialogue and plot, with human-designed anchor points ensuring coherent structure.

Adaptive Difficulty

Traditional difficulty settings are blunt instruments: easy, medium, hard. AI enables something more nuanced—systems that adjust challenge dynamically based on player behavior, skill development, and engagement signals.

The product lesson: AI excels at personalization when you have clear feedback loops. Gaming provides instant signals (did the player die, quit, or continue?) that make training and tuning AI systems tractable.

Emergent Social Dynamics

Some of the most interesting applications involve AI-powered NPCs that create social dynamics within game worlds. These aren't just chatbots—they're characters with goals, relationships, and memory who populate virtual spaces.

The broader implication: We're learning how to design AI agents that exist in persistent environments with other agents and humans. The lessons from gaming will inform how we build AI assistants that operate in professional environments.

What Product Builders Should Actually Do

Let me translate these observations into actionable frameworks:

Build Process Flexibility, Not Process Rigidity

The organizations that scale successfully aren't the ones with the most detailed processes—they're the ones with the most flexible frameworks.

Action item: Audit your product development process. For each step, ask:

Then create tiered processes that match the stakes. Not everything needs the same level of rigor.

Treat Pricing as Brand Communication

Every pricing decision sends a message about how you view your relationship with customers. Before you experiment with pricing:

Action item: Write down the message your pricing strategy sends. Then ask:

Price for the relationship you want, not just the revenue you need.

Experiment Where Expectations Are Flexible

AI products work best in domains where users expect imperfection and value novelty over consistency.

Action item: Map your product surface area along two dimensions:

AI features belong in the high-novelty, low-perfection-expectation quadrant. Don't force them into critical paths where reliability matters more than creativity.

Design for Trust Recovery

Mistakes will happen. The question isn't whether you'll break trust—it's how quickly you can rebuild it.

Action item: For any controversial change (pricing, features, process), prepare:

The organizations that maintain trust aren't the ones that never screw up—they're the ones that fix problems faster than users can lose faith.

The Meta-Pattern: Organizational Velocity vs. Organizational Alignment

Behind all these discussions—non-PMs shipping to production, pricing experiments, AI in gaming—lies a fundamental tension that every product organization must navigate:

Velocity wants to move fast, experiment, and empower individuals to make decisions.

Alignment wants to ensure consistency, protect brand value, and coordinate across teams.

Neither is wrong. The question is: which matters more for your current stage?

Early-stage companies die from too much alignment and not enough velocity. They overthink, over-process, and move too slowly to find product-market fit.

Late-stage companies die from too much velocity and not enough alignment. They ship inconsistent experiences, confuse users, and erode brand value through uncoordinated decisions.

The hard part? Most companies need to shift their balance as they grow, and that shift requires unlearning behaviors that made them successful.

What I'm Watching

A few signals I'm tracking that might indicate broader shifts:

The Unbundling of Product Management

As tools improve and context becomes more distributed, the traditional PM role is fragmenting. Some companies are splitting it into:

This isn't necessarily better, but it's a response to the expanding scope of what "product management" means.

Pricing Transparency as Competitive Advantage

A few companies are experimenting with radical pricing transparency—publishing their unit economics, explaining exactly how they calculate prices, and committing to public pricing principles.

Early data suggests this builds trust faster than traditional approaches, especially in B2B markets where procurement teams are increasingly sophisticated.

AI as Co-Creator, Not Tool

The gaming experiments reveal something broader: we're moving from AI as a tool we use to AI as an agent we collaborate with. This shift changes interface design, expectation management, and how we think about product boundaries.

Products that treat AI as a collaborator rather than a feature will likely capture more value—and create more interesting experiences.

The Real Question

All of these community discussions—the process debates, the pricing controversies, the AI experiments—circle around a deeper question:

How do we build products in an environment of increasing complexity, faster change, and higher user expectations?

There's no single answer. But there are principles:

The best product builders I know don't follow rigid playbooks. They develop judgment about when to apply which principles, and they remain curious about why things work the way they do.

That's the real skill we're all developing: not just building products, but building the organizational systems that make great products possible.

And sometimes, that means letting non-PMs ship to production—not because the process broke down, but because the process evolved.

Related reading