Welcome {{ first_name | folks }}! 👋

This edition of The Product-Led Geek will take 6 minutes to read and you’ll learn:

Let’s go!

Executive 1:1 Growth Review from a Top 3% Agency Ranked by Google

For in-market PLG teams. Bring your goals, KPIs, and recent results. Our senior growth team will test your strategy, find the fastest wins, and deliver a custom audit + action plan. The session is a free 20-minute executive review.

Please support our sponsors!

Three years ago, I wrote a guide on how to build a best-in-class PLG organisation.

I talked about squads, ratios, and cross-functional harmony.

I recently went back and read it, and it made me realise just how quickly things have evolved.

The principles - focusing on the user, owning the growth model - were right. But the mechanics of how we do those things have changed considerably.

In 2022/2023, the primary constraint on growth was bandwidth.

You had a backlog of ten ideas, but you only had enough engineering hours to ship two.

In 2026, the constraint is judgement.

AI can build the solution faster than you can decide if it’s the right one. The bottleneck has shifted from building to deciding.

Here is what a best-in-class PLG team looks like today.

In the old world, I recommended a specific golden ratio for a PLG squad:

(along with shared data science resource).

That structure existed to manage friction.

You needed a dedicated designer because moving pixels took days.

You needed 3-5 engineers because writing code was slow.

You needed a PM just to coordinate the traffic between these people.

In an AI-native product team, that ratio is obsolete.

Today, the high-performing growth unit is tighter. It looks like this:

The ratio hasn’t shrunk because we want to save money. It shrunk because small AI-first teams move faster.

When you remove the need for three extra people to be in the standup (if not remove the need for a standup altogether), you not only reduce headcount; you also eliminate communication and coordination tax.

I previously said one of the PM's jobs was to "prioritise what they build based on whether the motion supports the overall growth model".

That remains true, but the nature of the work has shifted fundamentally.

Karri Saarinen, the CEO of Linear, put this best: "PMs are becoming more like Editors."

In 2024, a PM was a traffic controller. Most - for wrong or right - spent 50% of their time writing tickets, managing JIRA, and "unblocking" the team. They were defined by their ability to coordinate.

In 2026, the PM is an Editor.

Because the cost of prototyping has dropped to near zero, the PM doesn't just write a spec; they generate the solution.

They use AI tools to build the first draft of the feature - the UI, the copy, even the basic logic. They don't hand a wireframe to a designer and wait three days. They hand a working (and often ugly) prototype to the engineers.

This is a profound shift in responsibility. As Karri notes, when the cost of creation drops, the value of curation skyrockets. The PM’s job is no longer to ask "Can we build this?" It is to look at the three versions the AI generated and say, "That one. But make it behave this way instead."

But….You Cannot Edit if You Don't Know the Reader

In the old model, PMs often got caught in the build trap - spending so much time managing the process that they lost touch with the customer.

In 2026, you have no excuse. By automating the building, the PM is forced to become deeply human again.

To be a great Editor, you have to be the ultimate proxy for the user. You must be truly at one with their needs and, more importantly, anticipate the changing ways in which they consume software.

The AI can build anything, but it doesn't know what to build. If you aren't grounded in the user's reality in the market, you will just be using AI to generate high-speed slop.

If the PM is the Editor, what happens to the engineers?

They stop being bricklayers and become System Architects.

In the old model, we hired engineers to type code. In the new model, as Karri points out, engineers focus on system design, data integrity, and reliability. They are the ones who make sure the "magical" solution the AI spit out actually scales and doesn't leak customer data.

This is why I suggest a 1:2 ratio. You need fewer hands to type, but you need better minds to verify.

The engineers in a 2026 PLG pod are senior. They look at the code generated by the AI and treat it like a junior dev’s pull request: they audit it, refine it, and merge it.

You might notice I removed the dedicated designer from the pod. This may be controversial, but I believe it to be necessary because I see the definition of design splitting.

In the past, part of Design was meant making artifacts - screens, mockups, and assets. In 2026, AI handles the artifacts. If you have a rigorous design system, the PM-as-Editor can prompt an AI to "create an invite modal using our standard patterns," and the result will be 95% production-ready.

Embedding a designer in every pod is now an overhead. In 2026, Design Systems become the team-level Design role.

But that doesn't mean the role of Design disappears. As Karri argues, it becomes more important, but more abstract:

Because AI agents act directly on our input, the quality of that input is everything. If the intent is muddy, the AI will generate sh*te at the speed of light.

Therefore, Design becomes a Platform Role (1 Designer supporting multiple pods), but they aren't there to move rectangles. They are there to Shape the Intent. They work with the PMs to define the constraints and the tradeoffs before the prototyping begins. They ensure we are solving the right problem before we let the AI solve it. And they build the "Brand LLM" - the components and guidelines that ensure the AI outputs quality.

The same applies to the Decision Scientist. In 2024, I said they were needed to "help join the dots with data".

Now that text-to-SQL is solved, we don't need analysts to pull numbers. We need Decision Scientists to act as Truth Architects. They ensure the instrumentation is clean and help the PM distinguish between AI-discovered correlation and actual causation.

A core responsibility of a PLG team has always been to own the Growth Model: the document that quantifies how you acquire users, how they translate into revenue, and the loops that drive that engine.

In the old days, the Growth Model was typically a spreadsheet. It was a static map of the territory. You used it to manually spot constraints - "Oh, our viral loop is plateauing" - and then you spun up a project to fix it.

In 2026, the Growth Model isn't a spreadsheet. It’s a simulation.

We now have the tooling to hook our analytics directly into AI models.

So, instead of a PM staring at a dashboard to guess why acquisition slowed down, the system will be able to model the loops in real-time (product opportunity?)

The job of the PLG team changes from maintaining the model to architecting it.

The AI does the maths. You do the strategy.

If execution is cheap, what becomes expensive?

Judgement.

I previously advised looking for internal mobility and people who are "collaborative". Those are still good traits. But in an AI-native org, everyone - from the PM to the Engineer to the Platform Designer - needs a new baseline set of skills.

You are no longer hiring people to turn cranks. You are hiring people to govern high-speed machines.

Whether hiring a PM or a Senior Engineer, you should look for these two traits above all else:

1. Discernment (Taste)

When an AI can generate 10 variations of a landing page (or 10 refactors of a feature) in a minute, you don't need someone who can make the 11th version. You need someone who can look at the 10 options and instantly identify the 8 that are rubbish.

In a world of infinite, average-quality content and code, the ability to spot quality is the rarest skill.

2. Systems Thinking

AI agents are uniquely bad at understanding second-order effects. An agent narrowly optimised for conversion will happily coerce the wrong type of users into signing up, destroying your long-term retention.

Every member of the new Growth Pod needs to be a systems thinker. They need to intuitively understand that changing a variable in the acquisition loop will cause pressure in the monetisation loop. If they can't model the whole machine in their head (with the help of simulations), they cannot safely operate the controls.

If you are building a PLG org today, here is the key update:

The goal hasn't changed: "Create, evolve, and optimise whole product experiences". But we finally have the tools to do it at the speed of thought.

Don't let your org chart slow you down.

Book a free 1:1 consultation call with me - I keep a handful of slots open each week for founders and product growth leaders to explore working together and get some free advice along the way. Book a call.

Sponsor this newsletter - Reach over 8000 founders, leaders and operators working in product and growth at some of the world’s best tech companies including Paypal, Adobe, Canva, Miro, Amplitude, Google, Meta, Tailscale, Twilio and Salesforce.

PS: Thanks again to our sponsor: Galactic Fed