What's left for a PM when the whole field's frameworks are a single command away

Last week I sat and worked through several repos that collect skills for the engineering crowd: Karpathy's, Matt Pocock's, and the superpowers set. I wrote a run of blog posts reviewing them. All of them are about helping people who write code work in a more systematic way.

Then I tripped over another group that does not touch code at all. Instead it packs "the work of a product person" into skills wholesale, from setting strategy, running discovery, and talking to customers, to writing PRDs and reviewing work before it ships.

When I actually opened them, what caught me was not how much they can do. It was that the three come from wildly different corners: one YC president, one PM newsletter writer, and one independent product lead. Yet they say the exact same thing about one point, a point that changes the definition of the PM job.

I will tell it in three parts. First, the three real repos that pack the craft into skills. Then the point where all three agree. And finally how a product person should move.

Part 1Three repos that pack the craft into skills

gstack by Garry Tan: a whole engineering team in one person

Garry Tan, president and CEO of Y Combinator, open-sourced the stack he uses to build every day, called gstack. It turns Claude Code into a team of 20-odd specialists: people who see the work as a CEO, an engineer, a designer, QA, a security officer. The interesting part is not the headcount, it is that he forces every piece of work through a multi-lens review before it ships. The CEO lens asks whether this is genuinely a 10-star thing or a 3-star one dressed up. The engineering lens asks whether the architecture can take the edge cases. The design lens asks whether you even know what "good" looks like.

He writes it plainly in gstack's ETHOS:

"The engineering walls have come down. What is left is taste, judgment, and the courage to see it through."

This is not just a workflow. It is taste and the priority of decisions written and baked into software. Most teams skip these lenses; 3 out of 4 people working solo skip them entirely. Garry brought them back as a required gate.

pm-skills by Pawel Huryn: the PM curriculum as buttons

Pawel Huryn, who runs a product newsletter, gathered around 68 PM skills into one set, split across 9 categories, from strategy, discovery, market research, analytics, and execution, to go-to-market and growth. Each skill is not a loose prompt. It wraps a real, named framework with a lineage, Teresa Torres, Marty Cagan, Alberto Savoia, Strategyzer, together with step-by-step instructions for using it. His pitch reads:

"Generic AI gives you text. PM Skills gives you structure."

Want a SWOT, JTBD, RICE, pre-mortem, or market sizing? Call once and get the scaffold with blanks to fill. One in particular caught my eye, named intended-vs-implemented. It checks "the gap between what the document says and what the code actually does," a PM lens born precisely for the age when AI writes the code.

product-discovery-skills by Else van der Berg: discovery as a conveyor belt

Else van der Berg is an independent product lead, and she does it differently. Instead of collecting every discipline, she focuses on one thing, product discovery, and goes deep: 6 skills chained into a conveyor belt, from filtering whether an interview matches the target customer, to clustering opportunities across many interviews, to prioritizing them. All of it holds to Teresa Torres's continuous discovery approach. The rule she baked into the prioritizer is sharp:

"Don't chase an opportunity scoring below 4 in importance, no matter how many people mention it. One person who truly loves the product beats ten who are merely indifferent and never use it."

The clever part is that the ones that do not fit are not thrown away as junk. She treats them as a signal that the problem map may need to be redrawn.

Part 2The point where all three agree

These three did not coordinate. They come from different worlds, but line them up and one thread runs through all of them. When execution is cheap and fast to the point of nearly free, the cost of the work shifts from "doing" to "deciding."

Garry speaks from the engineering side. He claims that this year he ships code hundreds of times faster than he did 13 years ago (that figure is his own measurement, not a shared benchmark). But the point is not the number. His conclusion is that the engineering walls are down, and the new scarce thing is taste.

Pawel speaks from the PM side. He packed 68 frameworks so they can be called in seconds, which is the same as declaring that knowing a framework is no longer an advantage. These frameworks have become public goods; anyone can reach one just as fast. The irreplaceable work moves to choosing which framework fits this business, setting priorities (not just computing them), and pulling people in one direction.

Else speaks from the discovery side. Her "don't chase anything below 4" rule is not a formula. It is judgment she baked in so the system keeps reminding us, rather than deciding for us.

Put another way, all three land on the same sentence: knowledge is cheap, judgment is scarce. Frameworks, templates, and document production are all being squeezed cheap and fast. What stays expensive is knowing what to do, refusing to ship something bad, and knowing which result to trust.

And there is one more rule gstack states outright: AI can recommend, but a human makes the call.

"AI models recommend. Users decide." That is the rule that sits above all the others.

Two of them converging is a strong signal, but not a command. Both gstack's multi-lens review pipeline and Else's "human decides" rule rest on the same belief: the tools help you ask questions and guard against mistakes, but they do not decide for you.

Part 3So what should a product person do

The one rule to remember

If you take one thing away, let it be this. Let skills do the scaffolding and production, then spend the whole block of saved time on the deciding. Because that is the part of the job that is left.

Three things that are still yours

• Pick the framework that fits the context. A skill can hand you an OST or a SWOT in seconds, but it does not know which one the problem in front of you needs. That, you know.
• Check that the result matches what you intended. This is the heart of a skill like intended-vs-implemented. A pretty document does not mean the thing is right. A human has to read that gap.
• Be the one who makes the call. Especially when two AIs agree so convincingly, that is exactly the moment to be most careful.

How to start

You do not need to tear up your whole workflow. Try just this first.

1. Take one PM task you do over and over, say writing a PRD, running a competitive analysis, or sorting a backlog.
2. Find the framework you usually use for it, and let the AI do the scaffolding.
3. Time how much you saved, then ask yourself which "decision" that block of time should go into.
4. Don't trust the result outright. Apply the intended-vs-implemented idea: does what you got actually match what you intended?

These three are telling the same story from three directions. On the day execution keeps getting cheaper, what separates a strong product person from an average one will not be who knows more frameworks. It will be who has the taste to choose the right one, and the discipline not to ship something bad. For my part, I am piecing together my own skill stack out of these ideas. When it settles, I will come back and tell you more.