2026-02-20 · 12 min read

The Layer Below

The Layer Below

I. The February 2020 Moment

Matt Shumer, the CEO of HyperWrite, wrote something in Fortune last week that I haven't been able to shake:

"I think we're in the 'this seems overblown' phase of something much, much bigger than Covid."

He's talking about AI. And I think he's right. Not because I read about it, but because I'm living inside it. I'm a PM at Shopify. I don't write production code. Or rather, I didn't. That sentence doesn't mean what it used to mean.

Something is shifting underneath me, and I don't mean the macro trend pieces or the Twitter discourse. I mean the actual ground I stand on every day: the craft of product management, the shape of my job, the things that make me useful. It all feels different now, and I've been trying to figure out why.

I think I finally have a frame for it.

Key takeaways

  • The wall between understanding a problem and building the solution was institutional, not technical. AI just removed it, and for PMs that changes the job.
  • "The layer below" your craft is the substrate it runs on. For PMs that layer was always code, and for the first time you can work in it daily, not just nod at it.
  • The general method wins: a PM who prototypes and tests in an afternoon out-learns one who specs and waits six weeks. In practice the gap compounds.
  • What survives is judgment, taste, and problem selection. Coordination overhead was scaffolding around the fact that PMs couldn't build.
  • The asymmetry is the whole argument: small, reversible downside to engaging; large, role-defining downside to sitting out.

II. The Essays That Got Us Here

Three essays shaped how a generation thinks about technology and building. Reading them in sequence today feels like watching someone slowly zoom in on your face.

In 2011, Marc Andreessen wrote "Why Software Is Eating the World." The argument was about industries: software companies were devouring every sector, and infrastructure costs had dropped from $150,000/month to $1,500/month. Every company would become a software company. He was right. It happened. The transformation was at the level of companies.

In 2020, Andreessen wrote "It's Time to Build." This one was about will. The pandemic had exposed that America didn't lack money or talent. It lacked the desire to build. The problem wasn't supply of resources. It was supply of ambition. The unit of analysis shrank from companies to communities.

And in 2019, Rich Sutton published "The Bitter Lesson," which doesn't get cited alongside those two but should. It's a one-page essay from an AI researcher, and the core claim is devastating in its simplicity:

"The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin."

The lesson is "bitter" because it's anti-human. We keep trying to encode our expertise into systems, and raw computation keeps beating us. The specialized method always loses to the general one, given enough compute.

Thread them together and you get a progression. Software eats industries in 2011. The real constraint is will, not resources, in 2020. Computation eats expertise in 2019. Each essay zooms in closer. Companies, then communities, then individuals.

Now it's 2026, and the zoom has reached you. Specifically, it's reached the people who used to sit adjacent to building, managing it, coordinating it, specifying it, but never quite doing it.

People like me.

III. The Layer Below

Boris Cherny is the creator of Claude Code at Anthropic. On a recent episode of Lenny's Podcast, he said something that crystallized everything I'd been feeling:

"Whenever I work with engineers, I love when people go a layer deeper and try to figure out what's going on."

The idea is simple. To get great at your craft, you need to understand the layer below it. If you're an application developer, understanding compilers and runtimes makes you better. If you're a systems engineer, understanding hardware makes you better. The layer below isn't your job, but it's the substrate your job runs on. Understanding it changes how you think.

For PMs, the layer below has always been code. Not in the abstract "PMs should learn SQL" way that gets nodded at in onboarding and promptly ignored. I mean the actual, material reality of software: the systems, the architecture, the constraints, the trade-offs that determine what gets built and how fast.

For my entire career, that layer was behind a wall. I could learn about it. I could ask smart questions about it. I could read architecture docs and nod. But I couldn't work in it. The wall between "understanding the problem" and "building the solution" was thick and institutional. It was the org chart, the sprint process, the handoff rituals, the Jira board.

AI didn't just make coding easier. It took the wall down.

For the first time, the PM can touch the layer below. Not as a weekend hobby, but as a daily working reality. I'm building prototypes in my actual product domain. I'm reading diffs on pull requests I initiated. I'm constructing systems (not production systems, but real systems that do real things) to organize my own work and my team's information.

And Boris's insight is that this isn't a nice-to-have. It's how you get great at your craft.

Jensen Huang has a competing frame. At a conference in 2024, he told students: "Don't learn to code, learn to farm." His argument: domain expertise is the new moat. If you're a biologist, your edge is biology, not Python. The programming language is now English.

I think Huang is half right. Domain expertise matters enormously. But domain expertise alone is what PMs have been running on for years, and it's not enough anymore. The real moat is domain expertise plus the layer below: understanding your users and the systems that serve them, knowing what to build and being able to test the idea in code before it ever enters a sprint.

Neither alone is sufficient. Together, they're a new kind of capability that didn't exist eighteen months ago.

IV. The Evidence

This isn't prediction. It's pattern recognition. The evidence is already in, and it isn't one anecdote. It's the same move happening across companies that don't coordinate with each other.

V. The Bitter Lesson for PMs

Here's where Sutton's essay hits home.

His lesson was about AI research: don't hand-encode human knowledge into systems, use general methods that scale with computation, because the specialized approach always loses.

Apply it to product management. The PM who writes a detailed spec, runs it through a sprint planning meeting, negotiates scope with engineering, manages the ticket through QA, and ships in six weeks is running the specialized method. It's a process designed around a constraint: the PM can't build.

The PM who writes a clear problem statement, opens Claude Code, builds a working prototype in an afternoon, tests it with users, and then hands the validated direction to engineering for production hardening is running the general method. It leverages computation. It scales.

In practice the second PM ships faster. But more importantly, the second PM learns faster. They're working in the problem and the solution at the same time. They see the trade-offs engineers see. They discover edge cases by bumping into them, not by reviewing a spec. The layer below isn't abstract to them anymore.

This is uncomfortable for a lot of PMs, and I want to be honest about why. Much of what we call "PM craft" is coordination overhead that exists because PMs can't build. The stakeholder alignment, the sprint rituals, the roadmap negotiations: these aren't the craft. They're the scaffolding we built around the fact that we needed other people's hands to make things real.

Remove that constraint and the scaffolding becomes visible for what it is.

What remains is the part that was always the actual craft: taste, judgment, user empathy, problem selection, strategic framing. Looking at a market and deciding what matters. Sitting with a user and hearing what they actually mean, not what they literally say. Knowing when not to build.

These don't go away. They get amplified by building. When you can prototype your intuition and test it the same day, your judgment gets feedback loops it never had. Taste goes from an opinion in a meeting to a testable hypothesis.

VI. The New Math

Zoom out to the economics.

In 2011, Andreessen's "eating the world" essay noted that infrastructure costs had dropped from $150,000/month to $1,500/month. That was the inflection point that enabled software startups to eat industries.

Today, the cost of building a working software prototype dropped from $1,500/month to $20/month. That's a Claude subscription. The same order-of-magnitude collapse, but now the unit isn't "a startup." It's a person.

In 2011, the line was "every company is a software company." In 2026, the line is "every person is a software company."

Sam Altman says the world wants 100x, maybe 1,000x more software than currently exists. At the same time, the cost to produce software is plummeting. Roughly twenty-five percent of Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated.

Here's the tension no one talks about enough: demand for software is exploding while the cost to build it collapses. The people in the middle of that equation, the translators and coordinators whose job was to bridge the gap between idea and implementation, get squeezed. The people who can build ride the wave.

Matt Shumer puts it starkly: "AI doesn't leave a convenient gap to move into." Unlike past waves of automation, where displaced workers could shift to adjacent roles, AI compresses the entire stack. It doesn't eliminate one layer and leave the others intact. It makes every layer thinner at once.

The PMs who get this will be fine. Better than fine. They'll be more capable than any PM in history, because they'll have the one thing no previous generation of PMs had: the ability to build.

The ones who don't get it will spend the next few years wondering why every reorg shrinks their team and expands the scope of the people around them.

What would make this wrong? Invert it. Deep engineers are still the ones who harden a prototype for production, lock down its security, and make it survive scale, and none of that comes free with a prompt. A builder-PM who ships fast can just as easily ship org debt: half-real systems nobody else can maintain. And the $20/mo figure is a sleight of hand, because it prices the tool, not the judgment, and the base rate suggests judgment is still the scarce input. The argument holds only if you treat building as a way to sharpen judgment, not a substitute for it.

VII. What To Do About It

I'm not going to be preachy about this. But I'll share what's working for me, in practice, as a short checklist.

Checklist: how to start

  • Start with the layer below your craft, not generic "learning to code." I didn't take a Python course. I started building tools for my own PM work: systems to organize meeting notes, search my knowledge base, generate briefings before meetings. The motivation was immediate and personal. The code is a means, not an end.
  • Build something real this week. Not a tutorial app. Not a to-do list. Something your team actually needs: a prototype of an idea you've been sitting on, a dashboard that answers a question you keep asking. The bar for "real" is "someone other than you would use it."
  • Treat AI like infrastructure, not magic. This is Boris's framing, and it's the right one. Don't use AI as a parlor trick. Build systems around it, create repeatable workflows. The value compounds when AI is embedded in your process, not summoned for one-off tricks.
  • Follow Karpathy's progression. Start with vibe coding: let the AI do everything, accept the output, feel the spark of "I made this." Then, within weeks, you start reading the code, questioning the architecture, understanding the trade-offs. The discipline comes after the spark. That progression from "vibe coding" to "agentic engineering" is your roadmap.

And before you decide whether any of this is worth your time, understand the asymmetry. The upside of engaging is becoming a more capable PM; the downside of sitting out is having your role redefined without your input. Those aren't symmetric risks. A quick filter for the next thing you might build:

Decision filter

  • Is this a tool for my own craft, where the motivation is immediate?
  • Would someone other than me actually use it?
  • Is the downside small and reversible, and the upside a capability I keep?
  • If I only had two hours this week, would I still build it?

VIII. It's Time to Build (Your Own Capabilities)

Andreessen wrote in 2020:

"The problem is desire. We need to want these things."

For years, PMs had a ready excuse: "I'd build that, but I need an engineer." That excuse just died. The supply constraint on building collapsed. What's left is pure will.

The layer below is open. The tools cost $20/month. Boris Cherny, the person who built the tool, says everyone at Anthropic codes, regardless of title. LinkedIn renamed the role. Spotify's best engineers supervise AI instead of writing code. My own CEO put AI usage on my performance review.

This isn't "PMs should become engineers." That misses the point entirely. PMs should become builders. Different thing. A builder understands the problem deeply, has opinions about the solution, and can make real things that test those opinions. A builder works in the layer they manage, not above it.

The bitter lesson for PMs is the same one Sutton wrote about for AI research: the general method wins. Computation doesn't care about your process, your alignment meetings, or your sprint velocity. It cares about clear problem statements and the will to build.

The ground is shifting. You can feel it if you're paying attention. The question isn't whether to learn the layer below. The question is whether you're going to keep standing above it while it moves.

Morgan Holland leads product on Shopify's Monetization team. He's been building software since the '90s, and these days he builds his own tools and agents with Claude Code, including a self-improving personal assistant system. He writes about growth, monetization, and AI-native operating at morgz.org.