PM Job in the Age of Cheap Software

Cheap Software Made Your PM Job Harder, Not Easier — Here's the New Job

Nate B Jones · ~13 min · Deep Dive Document
Video thumbnail
⏱ ~13 min 🎤 Nate B Jones 🏷 Product Management · Software Abundance · Governance · Prototype Commons · AI Strategy

Overview

Nate B Jones argues that the PM conversation about AI has been stuck on prototyping — PMs using Lovable, Claude Code, or Codex to build faster. That's table stakes now. The real shift is that AI collapsed the cost of creating software, which moved the bottleneck from "can we build this?" to "should the company rely on this?" Product management is becoming the discipline that classifies software abundance into market value — or decides to delete it. He introduces two frameworks: the Prototype Commons (the messy informal space where employee-built tools sprout before anyone classifies them) and the Production Class Ladder (a 4-rung system from personal tools to customer-facing products, where demotion matters as much as promotion).

1 Prototyping Is Table Stakes

▶ 0:00

Nate opens by pushing back on the dominant PM narrative: "PMs are becoming prototypers." Yes, PMs are using Lovable, Claude Code, Codex — but that's not the heart of where product is going. That's just table stakes.

The deeper truth: AI makes generation easier, so it moves the bottleneck. The question is no longer about building capacity. It's about where to point scarce human judgment in a world of software abundance.

💡 "The prototyping advice is oversold. AI makes generation easier — so it moves the bottleneck, and we need to be intentional about how we leverage scarce human intelligence."

2 Microsoft's Million-Asset Reality Check

▶ 1:14

Microsoft has built over 1 million Power Platform assets internally:

  • 18,000+ robot/agent environments
  • 170,000 Power Apps
  • 50,000 Power Automate flows
  • 1,200 chatbots

The obvious story: low-code + AI let more people build. The real story: product management is moving from rationing scarce engineering to classifying software abundance.

What arrives in the product conversation is no longer just a request — it's often a working artifact: a dashboard, a workflow, a lightweight app, an agent that already touches the system of record. So the old question ("should I build this?") is replaced by: "Somebody already built something — should the company rely on it?"

3 The Non-Technical PM Is Finished

▶ 2:30

Nate is direct: there's not much room left for the non-technical PM. Not that every PM needs to become an engineer, but AI products are technical systems where technical aspects are "profoundly determinative of overall behavior."

Product decisions now involve:

  • Model behavior and agent loops
  • Data access and workflow boundaries
  • Retrieval and evaluation strategies
  • Latency, cost, and permissions
  • Failure modes

A PM who cannot reason about these things is missing the product.

However: AI doesn't empty human value from product work — it shifts the bottleneck. When software production gets cheaper, the scarcest thing is great judgment about what ought to exist, what ought to be deleted, who the product is for, and what standard it needs to meet.

4 Where the Old PM Filter Breaks Down

▶ 3:45

The old PM job was built around scarcity. When software is expensive, the company needs a filter: PRDs, roadmap reviews, planning cycles, launch checklists, prioritization meetings. All designed so engineering time is consumed deliberately. The PM was the filter.

AI destroys that filter because it changes what people can produce before they ever reach product and engineering. The top of the funnel used to be words, mockups, spreadsheets, and persuasion. Now it's:

  • Working tools and dashboards
  • Automations and agents
  • "Half real products" — zombie products

A PM can no longer passively wait for polished business cases. The useful signal may already be running inside a team, along with a lot of noise that isn't useful.

The instinct some PMs have — "prototyping is now our job and nobody else's" — is wrong. Everybody's job is to prototype now. A customer service rep might build an agent that reveals customer demand the official product doesn't support. The PM's job isn't to gate who builds — it's to find where the good ideas are emerging as artifacts.

5 Broad Building Meets Governance Risk

▶ 5:20

The company needs broad building because that's where new demand becomes visible. But broad building without judgment becomes sprawl — useful work stays hidden, risky work spreads without support, nobody knows which tools the business depends on.

Microsoft's approach: governance built around inventory, telemetry, permission review, environment controls, and data policy — not to stop employees from building, but to let them build while protecting the company.

The risk is real: GitGuardian's 2026 report found 1.2 million AI service secrets exposed on public GitHub in 2025 (up 81% year-over-year). Faster creation means more credentials, more local workflows, more integrations, more places for access to leak.

Product leaders inherit that problem when useful tools spread before anyone decides what class of thing they are. "What data does it touch? What systems does it write to? Who owns it?" — these are now product questions, not just engineering questions.

6 Market Judgment Is the New Scarce Thing

▶ 6:40

Now that first versions are cheap, the PM's questions become razor-sharp:

  • Why are we building this at all?
  • Which customer problem is really worth solving?
  • Which workflow is close enough to money, retention, and trust to form a good habit?
  • Which competitor feature is just noise?
  • Which customer request is a symptom of a deeper issue?
  • Which internal prototype reveals real demand vs local convenience for one team?
💡 "That's not product management. That is product judgment."

7 The Prototype Commons

▶ 7:49

The Prototype Commons is Nate's term for the informal space where new tools appear before the company has classified them — scripts, dashboards, agents, automations, half-real products built because employees can finally solve problems that never made it onto a roadmap.

It's messy but extremely valuable — it reveals:

  • Hidden demand
  • Missing platform primitives
  • Customer pain
  • Internal workflows the official product process hasn't understood

But a commons needs stewardship. If nobody owns it, useful work stays invisible and risky work spreads. If product shows up only to say no, employees will start hiding useful tools until something breaks.

The better PM posture: open discovery — "Show us what you made. What problem does it solve? Who uses it? What data does it touch? What did you learn?"

8 The Production Class Ladder

▶ 9:30

A 4-rung framework for classifying software in the age of abundance:

1
Personal Tool
For one person. Can be scrappy. Stay away from sensitive data unless the company has rules for local handling. Minimal standards required.
2
Team Beta
Used by a small group. Needs an owner + backup owner, a short description, systems it touches, why it benefits the team, and a failure plan.
3
Supported Internal Product
Software the company depends on. Needs product ownership, platform partnership, access management, monitoring, documentation, support, auditability, and a change process.
4
Customer-Facing Product / Feature
Part of the company's external offering. Needs the usual product standards plus AI-specific evals and governance where the surface requires it.

The key insight: these are fundamentally different classes and shouldn't be mixed. The first version and the supported version don't have to be the same thing. In the old model, PMs decided what entered engineering → that became supported → that became official software. In the new model, PMs also decide what gets promoted out of the Prototype Commons.

9 Demotion Matters as Much as Promotion

▶ 11:00

A ladder that only moves upward becomes a junk drawer — everything eventually gets to production, becoming a pile of old obligations nobody wants to own. Intentional demotion is critical.

Nate's decision rule for PMs:

  • Stop asking only whether your team can build faster
  • Ask what class of software you're looking at (personal / team beta / supported / customer-facing)
  • Ask the harder question: Should this exist? Who is it for? What standard does it need to meet? What are we willing to rely on?

Three failure modes if you don't have a ladder:

  • "We don't know" → graveyard of demos
  • "Everything goes to production" → chaos
  • "Only central product may build" → waste the creative capacity AI just unlocked

The right answer: default-allow for experimentation + very intentional promotion path governed by product for work the business will rely on.

💡 "For so long, we've had to say 'we can't build everything.' Now we finally get to play the other side of the game board: 'we can build everything — what should we build?'"

🎯 Key Takeaways

🔑 Key Takeaways

  • Prototyping is table stakes, not the job — every PM can use AI to prototype now. The real shift is classifying software abundance into market value or deleting it
  • Microsoft's 1M+ Power Platform assets show the future — the artifact arrives before the request. The PM question moves from "should I build this?" to "should the company rely on this?"
  • The non-technical PM is running out of room — product decisions now require understanding model behavior, agent loops, data access, evals, permissions, and failure modes
  • AI moved the bottleneck, not emptied the role — the scarcest thing is now great judgment about what ought to exist, what to delete, and what standard to demand
  • The old PM filter is broken — PRDs and prioritization meetings were built for scarce engineering. Now the top of the funnel is working artifacts, not words
  • Everyone prototypes now — that's good — a customer service rep's agent might reveal demand the official product missed. The PM discovers, not gates
  • The Prototype Commons needs stewardship — the messy space where employee tools sprout is valuable, but without stewardship useful work stays hidden and risky work spreads
  • The Production Class Ladder is the framework — personal tool → team beta → supported internal product → customer-facing. Each rung has explicit requirements
  • Demotion matters as much as promotion — a ladder that only moves up becomes a junk drawer of dead obligations. Intentional demotion prevents new tech debt
  • The decision rule: default-allow + intentional promotion — let experimentation flourish, but apply rigorous product judgment to what the business will rely on

🔗 Resources & Links

Timestamp Index

▶ 0:00 Product management in the age of AI
▶ 1:14 Microsoft's million-asset reality check
▶ 2:30 Why the non-technical PM is finished
▶ 3:45 Where the old PM filter breaks down
▶ 5:20 Broad building meets governance risk
▶ 6:40 Market judgment is the new scarce thing
▶ 7:44 What's the new job?
▶ 8:30 The prototype commons
▶ 9:30 The production class ladder (4 rungs)
▶ 11:00 Why demotion matters as much as promotion
▶ 11:50 The decision rule for post-prototype PMs
☰ View all