James McAulay worked on growth at ElevenLabs and grew his latest business to £100K a month in 95 days, without hiring a single FTE.

Claude Code can be the most powerful system in the world.

I’ve now built you several Operating Systems you can run out of it: for content, for PM, your team, and for your company.

The missing piece was a Growth OS. So today, I present you one. And I haven’t just ported over what works for me.

I’ve brought on James McAulay who worked on growth at ElevenLabs and grew his latest business, Agent Accelerator, to £100K a month in 95 days, without hiring a single FTE.

He’s open-sourced everything. And it works.

Halfway through our recording, James ran a Claude Code skill on my site. A few minutes later it returned posts with no SEO description, long titles, crawlability issues, duplicate content…

(Which I’ve now fixed, with this growth OS).

1. How the Growth OS Works

You open Claude Code inside it, and it has three layers: tools with APIs, everyday skills, and routines that improve the setup.

Tools with APIs

James only adopts a tool if it has a good API or CLI, like Stripe, PostHog, Attio, Firecrawl, DataForSEO, vidIQ, Kit, Apollo

Everyday skills

Morning standup, weekly and monthly retros, PRD skill, SEO audit, tone-of-voice, YouTube packaging, competitor scan

Routines that improve the setup

The system improves itself from your usage, as weekly scheduled jobs look at how you work. It even suggests new skills and other connections you might want to add.

The repo is growth-agents on his GitHub. It installs with a couple of commands and runs in Claude Code, Codex, Hermes and OpenClaw.

It’s built for a full-stack growth person or a company’s first growth hire. If you’re a specialist (a product marketer or SEO lead), the onboarding asks about your goals and adjusts the system to your role.

2. How to set up your Growth OS

So you don’t actually need a new folder for this. If you’ve got a second brain already, the folder where all your notes live, just put the OS in there.

Clone the repo and run the install commands from the README. Then open Claude Code. Run the onboarding and Claude goes through everything you’ve already got in there before it asks you a single question.

It’ll ask if you want rapid or full setup. James makes everyone he teaches do the full two hour setup. We did rapid on camera because we were short on time. Try the full one on yours if you can.

What to wire into Claude Code

Connect everything as fast as you can.

The two most important are analytics and Git:

1. We did PostHog via MCP.
2. Read-only access to Git is key. Your team might not let you ship code, but it helps you get the right PRs ready.

The OS will help you so never forget PostHog events again. Every event says when it fires, where it fires, and what to measure with it:

Pre-AI, you’d only see data that clean under a god-tier PM. Now, it comes with the OS.

The core loop: actually learning from experiments

Running a test is easy but concluding it with definitive learnings is a feat unknown to many. I know it may sound harsh but shiny-object syndrome pulls us onto the next big idea, and at year’s end we are left with a pile of PostHog experiments with no recorded learnings.

The OS solves for the exact problem:

• Every experiment gets a file with these fields before anything ships.
• A playbook for A/B tests is set up, and it stops you from reading a result early. The weekly retro and the daily standup both read the list of running experiments and tell you when one is ready to review. They also catch stale tests.
• Experiments only build on each other when a template forces the baseline and confounders up front and a weekly loop forces the learning at the end.

3. How to run growth experiments with no engineer

The way growth was done before, you’d wait on an engineer before any test could happen. Now growth people can run experiments themselves. That’s how James thinks about it.

We no longer need to wait for engineers to build growth experiments.

Gate 1 — PRD

Say you want a new page on the marketing site. What the system does is help you have the discipline to write a PRD where you answer key questions like: What metric will it move? So use the PRD skill to write a draft.

Gate 2 — Multi-agent refine

Then refine it with the multi-agent refine skill. This is cool. It launches subagents to critique your PRD, each using a different angle. Then a lead agent creates a master critique and priority list of action items to do.

Then — Ship

THEN ask Claude Code to build your feature.

Example: SEO

Here’s the whole loop in action with SEO.

Start with the SEO audit skill:

It’s a remix from Corey Haines’s Marketing Skills collection. But James added a few tools that really upgrades them:

1. Firecrawl which turns any website into Markdown, because when you ask Claude to scrape a site, it often hits Cloudflare blocks or misreads the page. Firecrawl fixes that.
2. DataForSEO is one of my favorite finds for this episodes. It’s a super cheap SEO API. Once you give Claude Code the key, it can research any term for you, just for a few cents.
3. The Lighthouse CLI runs Google’s page speed tests from the terminal. Before, you’d open PageSpeed, run the test, export it, save it and hand it to the agent yourself.

What it found on my site was that my search traffic was about 25K visits in May and has dropped to about 10K.

Then, it can help you ship the changes. I had it execute on this whole action plan:

Try it yourself! It’s pretty magical.

Final Words

How autonomous are growth agents, really?

Is the ‘autonomous’ part overhyped? Mostly, yes. A lot of the people on LinkedIn and X claiming autonomous agents are either burning tokens on low-value work, or running an agent that does most basic stuff.

But, on the other hand, people also don’t realize an agent can improve itself. That part is autonomous, and really cool.

So go use the Growth OS, push on its autonomy, but don’t expect it to work without you.

The full episode write-up is on Product Growth.

I asked the founder of Zynga to go to the whiteboard and teach his Proven Better New framework from scratch.

Billions of people have played Mark Pincus’s games. He founded Zynga, and for years I walked past the Zynga building in San Francisco every day.

Mark just published Life at the Speed of Play. The book’s subtext is how to launch products people love.

So I asked him to go to the whiteboard and teach his Proven Better New framework from scratch.

I use this framework myself when I think about building products. But I’d guess only 10% of you know it well.

By the end of this post, you will know:

• Why every great product starts as a copy
• Where the line is between stealing well and getting it wrong
• How to sort your roadmap into proven, better and new

1. How to use Proven/Better/New to Build Better Products

The big online poker sites used to make you download before you play a single hand.

Mark noticed that the moment you ask for a download, you lose at least 80% of your audience. That’s his number, not a benchmark.

So he copied the leading poker tables down to the chip colors and removed the download.

Then he added the one new thing: your Facebook and MySpace friends could sit at your table.

Mark’s most controversial idea is that copying is okay.

All music, movies, stories and games are derivative. Every artist builds on the artists before them.

But there is a line between taking inspiration and copying blatantly. That line comes down to taste.

Steve Jobs was a master of copying and appreciated it deeply. Bill Gates copied from the same place, Xerox PARC.

Then the two copied each other. Gates was worse at the trick, so it looked like he was just copying Apple.

“can you learn from other people’s proven success and emulate it perfectly, but have it feel new to people?”

Your instinct is right 95% of the time. But assume your idea is probably wrong.

Proven Better New lets you act on both at once.

Proven is any part of the experience that already works for this audience on this platform, so you copy it click by click and pixel by pixel.

New is your novel idea and your innovation zone. Your job is to isolate it so your launch measures that idea and nothing else.

2. How to tell better from new

Would 10 out of 10 people who use the proven product today choose it? If they all agree, call it better.

If only you think so, call it new. This test isn’t always easy, and most mistakes go in one of two directions.

“What you think is better is called new. What they all think is better is better.”

The first is calling your own idea better. Take Mark’s family assistant built to compete with Instinct, the AI assistant that works over text. I tested Instinct for AI by Aakash.

Putting the whole family in one thread feels like an obvious improvement to the person building it. Under the test it is new.

Mark left the Better column empty:

“I have no ideas today that I could say 10 out of 10 Instinct users would call better than Instinct.”

The second is calling a removal better. Rejecting something that looks like an issue feels like progress.

But if it already works, removing something proven is a bet like any other. Zynga copied the neighbor bar from FarmTown, where the other player has to accept your request.

It looks like friction. Mark says calling its removal better “would have made our product less viral.”

People at Zynga still repeat his mantra that all new fails.

If you expect that from the start, you won’t be disappointed or let a failing idea linger too long.

But when new does work, we need to have a reverence for it.

So discount the hope you have for your own new idea. And pay close attention to new that’s working out in the market, because that new just became proven.

Consumer AI didn’t feel investable to Mark back in June. With Instinct at a $10B valuation, it feels a lot more investable today.

3. When to ship less new

The earlier you are in a platform shift, the less new you should pursue.

Mark’s proof is Hay Day. Supercell’s game looked like Zynga’s FarmVille 2.

In his words, “it was 0% new.” What changed was the better: it loaded faster, it had shorter crop cycle times and it had touch.

Late in a cycle it flips. Nobody wants a new farm game now, and you’d need “a lot of new.”

AI is early. So a lot of low-hanging fruit is always going to be there.

It is best to be disciplined about it and look for where you can be better because of AI.

Write down which part of your AI product is actually new. If it’s more than one thing, you’re running two experiments in one launch.

4. How to test 100 ideas before you build one

AI lets you make an MVP in months instead of a year and a working version in minutes.

Mark thinks that speed is a trap, because it tempts you to skip the top of the funnel and go straight to the whole product.

So you end up failing too slowly.

He had just argued about it with Eric Ries, whose Lean Startup gave us the MVP: “the problem with MVP is the word viable.”

Once you call something viable you start thinking it could be your launch product. I made a similar point in 2022 in “MVP”: the most misused term in tech.

The MVP is the version that tests your most critical assumption. Mark’s funnel test goes one step earlier and checks demand before there is a product at all.

His proof was a post by Rohan Nayak, CEO of Pocket Entertainment, the company behind Pocket FM.

Pocket FM runs a 90-second video trailer of an audio drama as its ad.

When an ad’s click-through rate goes from 2% to 2.25%, customer acquisition cost drops about 30%. Rohan Nayak, Pocket FM

Mark’s reading is that once they hit 2.25% in any country, they could grow to $10 million in ARR in three months.

Rohan’s own numbers are narrower: France to $10M in 3 months, and 8 months to figure the engine out.

Mark says he could “vibe code something at least good enough to be the website behind an ad” and send an agent into France, Italy and Saudi to see if it gets a 2.25% click-through rate.

Here is how to run it:

1. Write the teardown. Fill in the proven slots for the closest competitor at click-level detail.
2. Generate concepts. A batch of names and one-line value props for each bet. Ask the agent to flag where it needs you to brainstorm.
3. Vibe-code one page that’s just good enough to catch an ad click.
4. Run web ads. Mobile ad platforms may not let you advertise without an App Store listing.

Pick your click-through bar before you look at results. Then check absolute performance against your quality bar and relative performance across variants. Double down on what clears both.

Pocket FM’s own benchmarks from Rohan’s post are 2.5% CTR and 55% 3-second through-play on a 90-second trailer. Pick yours from your own funnel.

Try this first

Open your roadmap and write proven, better or new next to every item. Anything you can’t point to a competitor doing is new.

If one launch carries more than one new, you’ve found your first cut.

The full episode write-up is on Product Growth.

A Spotify PM’s plugin cut the company’s Claude Code token use by up to 90%. I tested it on real code to find out what you can actually save.

A Spotify PM’s post on cutting Claude Code token use by 90% was all over LinkedIn in November. I tested it on real code to find out what you can actually save.

The way Spotify uses Claude Code is wild. Their co-CEO, on an earnings call, shared that most of their senior engineers

“haven’t written a single line of code since December.”

Here is what engineering looks like at Spotify. An engineer calls Claude to fix a bug from Slack on their morning commute, and they push the fix live before they even get to the office. At a company with 7,300 employees, that results in a huge Claude bill.

So it’s pretty crazy that they managed to reduce it by up to 90% with a PM’s help. I wanted to know whether you could get similar savings, so I ran the test myself.

1. How Spotify got a 90% cost cut

Spotify built its own coding agent called Honk. Engineers can just tag Honk in Slack:

1. Honk reads the codebase and writes the change.
2. Spotify’s tests run on it.
3. A person reviews it before it ships.

Honk now merges 1,000 code changes every 10 days. That pace used to take 3 months at Spotify.

But all that reading runs up a pretty high token bill. So a Spotify PM built Shunt.

It’s a plugin that blocks Claude from reading any file over 350 lines in full. Instead, a cheaper model (they use Gemini Flash) reads it.

In their tests, they saw an 82% to 94% reduction in tokens on big files. On a 162K-line Java monorepo, they saw a 90% cut on average. They also open-sourced the plugin. It’s on GitHub in a repo with 3,186 stars.

That’s just their experience, though. And you might imagine Anthropic has incorporated some of the learnings, right?

So I set out to test it myself: where does your Claude Code bill actually go?

2. How AI is charged

First, a quick recap on how you rack up those huge AI bills.

There are 4 elements to your bill: input, cache write, cache read and output. Each is priced pretty differently. For Opus 5.5, for instance:

• Input: $4 per million tokens
• Cache write: $5 to $8 per million
• Cache read: 20 cents per million
• Output: $20 per million

What that means for coding is really interesting. I had Opus answer 4 questions on a big open-source Java codebase, and here’s where the money went:

94% of the bill was reading. Can you believe that?

85% went to cache write and 9% went to cache read. The output, even though it’s priced so high, was only 6% of the bill.

That first read of every big file is exactly what Spotify’s trick hands to a cheaper model.

3. What savings you can expect

I ran the test across 2 codebases: my Land a PM Job repos (78K lines) and Apache Commons Lang, whose biggest files run 9,800 lines. I asked the models to answer questions that forced reads across files. One example was to trace a payment link through an admin tool, through Stripe code, to a site.

And I tested this 2 ways. First, with a simple prompt that encouraged use of a cheaper model, which looked like this:

Use Haiku subagents for the reading, one file per subagent, and have each return the main claims with exact quotes. You do the weighing, and check each quote before you use it.

The second way was to use Spotify’s hook, ported to Claude Code. I also ran everything twice: once in normal Claude Code, which can search your files, and once with search turned off, so Claude had to read whole files. Here are the results:

1. When Claude had to read whole files, the tricks paid off. On Commons Lang, the cost went down 76%, and 87% with Spotify’s hook.
2. But on my own repos, the Spotify hook actually cost more. The one-sentence prompt did help, cutting costs 53%, which is the most important takeaway.
3. In Claude Code, there’s very little to save. If you’re in Claude Code itself, it’s already going to do searches. It looks up the few lines it needs instead of reading whole files, so the sentence added cost, 19% to 36% more. But if you hit the models directly, this hook really matters. That means any agent you build on the API without a search tool, or any job where Claude has to read whole files, like code reviews and migrations.

From a quality point of view, all these models did fine. So you can get the cost savings on a codebase without any decrease in quality.

So if your team has Claude read whole files, you can expect big savings. But if you mainly ask Claude to find and fix things, Claude Code is already doing the cheap thing.

4. How to get the savings yourself

• Look at how your team uses Claude first. If it’s mostly search and edit, skip the trick. It added cost in every one of those runs.
• If Claude reads big files whole, start with the sentence. It saved money on both codebases. Spotify’s hook saved the most on Commons Lang but backfired on our repos, so test it on yours for a week first.
• Roll it out to the whole team by committing it to your repo: the sentence in CLAUDE.md, the hook in .claude/settings.json. That way every engineer gets it.
• Open every cheap answer before you trust the saving. In one of our early runs, a 91% “saving” was Claude refusing to do the job.

To size it, multiply what each read-heavy run saves by how many of those runs your team does in a month. On our repos, that’s $0.72 × 3 runs a day × 20 engineers × 21 workdays, or about $900 a month. It’s an estimate, so measure a week before and after.

Spotify’s 90% is real for teams whose Claude reads whole files. Figure out which kind of team you are first, then copy the part that fits.

I first wrote this up in AI by Aakash, along with the week’s AI news.

Model PM has become the most lucrative sub-field inside of product management, with a 60% premium over PMs outside AI.

I had AI pull every open PM listing across 95 company career pages. The median base pay of model PMs was by far the highest:

Model PM has become the most lucrative sub-field inside of product management, with a 60% premium over PMs outside AI.

Lest you think this is just a level effect, actually it’s the opposite. The gap is similar at the mid, senior, and staff levels.

But how did it acquire such a hefty premium?

There’s a skill shortage

It’s basic economics. The skills are in short supply.

Madhu Guru led product for Gemini and Veo, plus Nano Banana, and he’s now a senior director of AI at Meta.

He estimated <75 people globally have the depth needed for this role:

He says AI-native product not model here, however given his role on Gemini at the time, I read this as “model PM.”

You need a unique combination of model and PM knowhow. This is good news for you, though. With the right work, you can acquire the skillset, and nab a model PM job.

What is a model PM

AI PM is a broad term. And under it, it holds at least 4 different types of PM jobs:

The sub-categories of AI PM have yet to well emerge. You could make 6 cuts, or 2 cuts. This cut of 4, though, I think is a useful mental model.

Model PMs are the PMs actually building the models. They sit alongside the model research team which is mainly AI researchers and engineers.

They need to be able to win respect from engineers who may have billion dollar pay packages (rumored for folks like Nat Friedman and Andrej Karpathy)!

This means they can’t lose the thread in a conversation on pre-training v post-training or gradient descent vs deep learning. They are not only tracking those terms but using them correctly themselves.

AI Platform PMs are also building AI tools, but not models. They are building APIs, agent tools, eval tools that other teams build on.

AI-Native PMs are building products where a model is the engine. They are at AI companies like Sierra, Glean, and Decagon.

Applied AI PMs are building AI features inside a product that existed before AI. This is the biggest bucket by far, and they are at companies like Freshworks and Amazon.

Analyzing the backgrounds of model PMs

Let’s look at a real model PM, Barkley Dai:

Barkley works at Luma AI, which, valued at $4B, has one of the best video models. He broke in after working AR and GenAI at TikTok, and before that being a PM at Tencent and Kuaishou. And before that, he went to Yale.

That’s a typical path into model PM: tier 1 University → $100B market cap (Kuaishou) → $500B market cap (Tencent) → $500B valuation (Bytedance) → Model PM.

Notice that he doesn’t have a Ph.D. He wasn’t an engineer. He studied computer science at Yale, and he’s had a PM career since then. Three and a half years before breaking in as the 1st product hire at Luma.

And he progressively moved closer to models at each step. At TikTok, he started in AR. Then, he moved into GenAI effects (AI feature). Then he started in Luma on Growth projects. Then, he got closer to the models.

That is a very common path for PMs to break in, though it’s not the only one. I went through all 316 model PMs on LinkedIn and here’s what I learned:

Let’s start with the 5 headline stats at the top and walk through what we learn from each:

• 85% of model PMs were PMs before. Model PM is a sub-specialty of PM. It’s not a separate field altogether. You go on needing PM chops, not just model chops.
• 64% of model PMs have a technical degree. Model PMs are on average technical. That’s because, even if they aren’t engineering themselves, they spend their day with researchers and engineers more than say a consumer UX PM. At the same time, one third of model PMs don’t have a technical degree. So it’s not a requirement.
• 28% of model PMs were founders. This seems to be one of the most reliable signals to a lab that you’re not just a PM, but a builder. But it’s not everyone!
• 24% have an MBA. Having an MBA can be a signal that you might make a good PM, but it’s clearly not a requirement.
• Only 2% have a Ph.D. This one really stuck out to me. I expected many more model PMs to be former researchers, but that’s not the case at all.

Second, there’s a really broad mix of backgrounds of where people landed after college.

PM is by far the largest at 24%, and, surprisingly data or research is the smallest at 6%! There’s a healthy mix of other backgrounds represented, as well: 22% in Consulting / VC, 17% engineering, 15% marketing/sales/ ops, and 7% their own startup.

Third, the real path is going to be unique to you:

• Yonatan Wolf was an APM through GPM at Google. Then he became a model PM at… Google.
• Matteus Pan was an associate at BCG, then a GPM at Dropbox, then a head of product. Then he became an MTS at Thinking Machines.
• Steven Pecht went from McKinsey to BizOps at Google, to PM at Google, to Head of Product outside Google, and then back to Google as a Model PM.
• Grant Gardner spent time as an Eng Manager, then CPO/CTO, then was a Staff PM at Meta Horizon before joining Meta Superintelligence Labs.

You can write your own story into the field, and that’s what we’ll help you do through the rest of the piece.

The rest of the guide, including who is hiring model PMs, what the job is like in the top labs, the skills and the toolkit, is in Model PM: The Complete Guide.

I put together the very best hiring and compensation data in the world to build you the ultimate guide to the PM market.

This is wild. Of the 10 companies that hired the most PMs in the world over the last year, 4 are banks or payment networks.

Capital One’s count includes an unusually large May and June 2025. Outside those two months, it hired slightly fewer PMs than the year before.

Amazon and Google are at the top, as you’d expect. Amazon made 691 outside PM hires worldwide in the 12 months to April 2026, and Google made 507. Right after them is Capital One.

Then Microsoft. JPMorgan Chase and Mastercard both sit ahead of Meta, and Visa is just behind Walmart.

If you’re only thinking about big tech, you’re missing a significant portion of the PM market. Capital One, JPMorgan Chase and Mastercard all hired more PMs than Meta.

On the other hand, if you look at job board data (what most reports look at), you’d see something different. TrueUp, for instance, shows 7,267 open PM jobs at tech companies this month, up 77% from the 2023 low.

This report doesn’t mislead you with postings. It looks at actual hires: people who started a PM job at a new employer. Hires, not ads. Look at the difference between postings and hires. It’s a totally different trend.

Since 2023, postings are up 77%. Hires are down 18%, and the 2026 number is an early read.

I teamed up with Alex Hamilton and the team at Live Data Technologies, who track job changes across about 126 million professional profiles.

I also teamed up with Zuhayeer Musa and the team at Levels.fyi, who bring the pay data.

And this isn’t only a Levels report. 276 of you answered my pay survey, so every pay cut sits next to what Product Growth readers told me they earn.

Together, we put together the most comprehensive, in-depth and accurate report on the PM hiring market that exists anywhere.

I’ve published on this before. Last November, I published the definitive report on the AI PM market.

This is the update. And this time it covers the whole PM market, globally, with all the data you need.

The state of the PM job market in 2026

The craziest trend in the PM job market is something you probably already knew.

PM hiring is down. We’ve been talking about it for years now.

The end of the ZIRP era in 2022 was a great time to be job switching. Since then, the market hasn’t been as good.

But it’s not all doom and gloom. Even though PM hiring is down 45% since 2022, it’s mostly been flat through 2023, 2024 and 2025.

In 2026, the numbers are looking down, but I wouldn’t read too much into it, because it’s just February to June. It’s an early signal, though, that 2026 is down 19% from 2025. That is a little bit concerning.

On the AI PM side, there are no concerns at all. AI PM hiring is up 2.5x since 2022, and up 10% from 2025 as well.

That’s the core insight, and the most important thing I got from this research: PM hiring is down, and AI PM hiring is up.

But there are more insights I put together that I think are really worth knowing about this market.

The 2023 reset is still holding

As we covered, the big drop was in 2023. Man, was it a bad year to be in the PM market.

Since then the market has barely moved: down 3.8% in 2024 and up 5.2% in 2025. The 2026 early read is down about 19%, with May and June still filling in.

When you look closely at 2023, the drop happened earliest and hardest in the US, which was down 41%.

Since then, the US has actually held up better: down about 10% in 2026, against 23% everywhere else.

The cleanest way to really look at the market is hires per exit. That is to say, how many PMs does a company hire from outside for every PM who leaves?

The dotted line is one outside hire for every exit. That’s when the field is flat.

Back in 2022, when PM was growing, we saw 1.16 outside PM hires for every PM who left. That’s 16% more people coming in than going out.

Since then, it has come down: 0.94 in 2023, 0.92 in 2024 and 0.92 in 2025.

And here you can see that AI PM is the title that’s been growing like crazy. Its outside hires ran 89% above exits in 2022, 74% in 2023, 72% in 2024, and 47% in 2025.

Now, this isn’t a perfect metric either. It doesn’t mean PM teams shrink 8% a year, because promotions and internal moves still fill seats.

What it does mean is that the outside door is narrower, and that’s what matters when you’re searching for a job.

That door is much wider in AI PM and narrower in PM overall.

So if your search feels harder than the one you ran in 2022, this is why.

Though PM hiring is down, PM pay is up

You might think that with PM hiring dynamics changing the way they did, and hiring down, pay would be down too.

That’s not the case at all.

I looked at all of the PM compensation submitted to Levels.fyi by year. Median compensation has been going up: $220K in 2022, then $210K in 2023. Yes, there was a drop there. But it was $224K in 2024, $236K in 2025, and now $250K in 2026.

So PM pay at the median is up 14% from 2022. Meanwhile, US PM hires are down 48%.

Here’s what it looks like when you put pay and PM hires on the same chart, indexed to 100 for where they were in 2022.

Pay is median total compensation. Hires are US outside hires. Dotted line is 2022.

As you can see, AI PM hires are up to 215 and pay is up to 114. Meanwhile, all PM hires are down to 52. In people, US AI PM hires went from 389 to 835.

That’s the real story of the market. It’s what you see when you look at the three variables that matter, and it’s what most of the prior hiring reports you’d find online miss.

So what’s going on with that 14% increase in pay?

Part of it is level mix. If you hold the level fixed, the jump is smaller. At Levels.fyi’s L3, for example, the median went from $306K to $319K, up 4.5%.

PM pay did not fall with PM hiring. Hiring is massively down, but pay is up. And so are PM levels.

The PM field has gotten more senior

That’s right: the fear everybody had is kind of true.

The share of PMs who reported as super junior, which is coded as L1 in the Levels.fyi data, is down from 17% in 2022 to 11% of reports in 2026. That’s pretty wild.

Now, Levels.fyi is trying to synchronize levels across all companies. So here’s what those levels look like, for US PMs over the last 12 months:

• L1: 5 years of experience at the median, median pay $175K
• L2: 7 years, $228K
• L3: 9 years, $296K
• L4: 12 years, $385K
• L5: 16 years, $500K

So you can think of L3 as a senior PM, and L5 as a principal-level PM.

Companies have different ladders on top of these. For instance, a Google L5 PM is an L3 on Levels.fyi, and a Google L6 is an L4. A Meta L5 PM is an L3, and an L6 is an L4.

If we look across the levels, we see some interesting trends. Across L3, L4 and L5, the share of PMs went up, from 50% to 61% of reports.

So PMs have gotten more senior. The people with PM experience are progressing, and fewer people are entering PM at the bottom.

And in terms of pay, interestingly, the most junior and the most senior PM pay is down:

• L5 pay is down 18%, from $511K to $419K
• L1 is down 16%

On the other hand, the middle of the range is up: L2, L3 and L4 are up 5.0%, 4.5% and 5.8%.

Weigh the five levels by how many PMs reported at each one, and pay is up about 6%. Nearly all of that comes from the shift to higher levels.

About 3 in 10 submissions don’t carry a level, so I can’t split the full 14% exactly, and L1 and L5 are the smaller, noisier groups. Read this as directional.

PMs have gotten more senior, and the middle tier of PMs is getting paid more.

Who hires the most PMs

One of the numbers I was most keen to look at is who the top hirers of PMs are, and how their hiring has changed over time.

The results were fascinating.

Most of big tech made fewer outside PM hires this year. Meta is down 30% (366 to 256). Microsoft is down 31% (625 to 431). Amazon is down 21% (870 to 691). Google held level. It was pretty brutal there.

On the other hand, the financial companies actually increased their PM hiring: JPMorgan Chase is up 17% (345 to 404), Visa is up 32% (165 to 217) and Mastercard is up 55% (219 to 339).

So there’s almost been a shift from tech companies to financial companies in the PM market over the past year. That’s one of the most significant things I learned in this research.

Now zoom out. These are only the top 10, and together they made 3,756 of the 79,164 outside PM hires worldwide.

The top 10 made under 5% of PM hires worldwide. When everybody talks about those big companies, the tail is where 95% of the hiring is.

I covered the full report, including the regional cuts, the AI PM deep dive and the pay by level, geography and employer, in the full piece on Product Growth.

If you want a PM role at Anthropic, like this Claude Tag one that pays $385,000 to $460,000, you’ll have to do homework.

That’s right, like back in school.

And here’s the interesting twist. They don’t want you to use Claude unless they say so:

Anthropic is not the only company giving out take-homes. Databricks, OpenAI, Uber and Stripe all give them out too.

I wanted to get a sense of how prevalent they are, so I turned to two proprietary data sources.

For my upcoming book, I’ve been interviewing people about what they face in AI PM interviews:

• 40% (8 of the 20) of the people I’ve interviewed said they faced a take-home or a past-project presentation in the past 12 months.
• 31% (4 of the 13) of the hiring managers I’ve interviewed give them when they hire.

In my cohorts of 160 job seekers over the past year:

• 45% of them have faced at least one, and about 16% of their processes overall have asked for homework.
• Experiences have been heavily localized. One gaming PM in India has seen them in 100% of his processes.

That gives you a good idea of how prevalent these really are: around 40–45% of PM job seekers face at least one, and between 16–31% of PM processes ask for them.

So why do PMs still get homework, and how should you handle it?

Why they assign it

One reason is just pure math. There are too many candidates and not enough interviewers. Homework acts as a filtering mechanism.

But the bigger reason is evidence. In 1998, Schmidt & Hunter looked at how items like structured interviews, work sample tests, and unstructured interviews predicted job performance.

Work sample tests ranked #1:

Frankly, I’m the same way. I don’t hire anyone unless I work with them first. It’s easy to fib an interview. It’s pretty hard to fib taste on a work sample test.

Who assigns it

I’ve scoured the web, interviewed 20 PMs and 13 hiring managers for my book, and coached 160 job seekers in my cohorts.

Here is what I found across 23 companies:

Amazon, Airbnb, Anthropic, Uber, Intuit, and Databricks all regularly assign homework or presentations. Stripe, Netflix, OpenAI, Atlassian, Salesforce, Microsoft, and Apple do based on the role. (Anecdotally, when I got a PM offer at Apple in 2019, they didn’t have homework.)

Those companies are all huge, but that’s because that’s where the public data is. Startups and scale-ups are, if anything, more likely to give you homework:

• I’ve assigned homework in nearly every PM role I’ve hired for, at thredUP (series C-E) and at Apollo.io (series B-C).
• PM coach Sumant Malhotra has coached folks who saw it at Razorpay, Retool and CrowdStrike.
• One Blind thread said take-homes have “already become standard for a lot of non-FAANG” companies, “mostly series a-d companies.”

So if you’re interviewing at a Series A to D company, you’re more likely to get one. Homework also seems to cluster at AI-native companies and scale-ups, in particular.

What they ask

I’ve figured out that what they ask generally breaks down into 5 main categories. This mental mapping is helpful to understand the universe of what they ask:

• The PRD: This is what you think it is. They want to see if you can really master this core PM skill.
• The strategy or roadmap: They want to see if you can define where the product should go and what to do first.
• The case study: They give you a made-up product problem to solve, like Uber’s “make rides to 10,000 person events magical.”
• The past project: You walk them through something you’ve previously shipped, usually a feature (more junior roles) or a strategy (more senior roles).
• The AI prototype: This is the newest variant, seen most at AI companies where they are looking for builder PMs.

Here’s what that looks like in practice. These are real prompts my cohort members shared this year:

As you can see, they’re all a bit different. So you can’t just build one homework and use it everywhere. You need to have a custom approach to each one.

Doing that well starts with getting inside the heads of the companies asking us.

What they’re looking for

After coaching so many people through these, I’ve realized you really need to understand the psychology to create a great answer.

Based on my experience inside many of these rooms, as well as the interviews for my book, there are three major things I want to call out:

1. Does it beat what they read internally? This is the most important one. Companies want bar-raisers, so your document has to be better than the docs already circulating there.
2. Is there a real insight? Pasting the prompt into ChatGPT or Claude gets everyone the same answer. They want something that could only come from you.
3. Who worked the hardest? Extra research, writing quality, organization and proofreading all get compared across candidates. They’ll often run it through a detector like Pangram to see how hand-written it is.

The most important thing to remember is that what’s being graded is whether your judgment adds something that AI can’t produce for anyone else with the same prompt.

The two full homework examples, the prompts and the process I give my cohort are in the full playbook.

I sat down with the head of AI engineering at Salesforce, who runs the 700-person org behind its AI products.

I got a chance to sit down with the head of AI engineering at Salesforce.

Jayesh Govindarajan leads the teams behind the $190B SaaS giant’s AI products.

This was recorded live at Dreamforce, so it’s a bit different than my typical podcast. In this piece: why he thinks the SDLC should be replaced with an ADLC, the path to building an AI-native product team at Salesforce scale, and what Salesforce looks for when hiring PMs.

Why the SDLC should be replaced with an ADLC

We’ve all lived the SDLC, software development lifecycle. For most of us, it looks something like plan it, build it, test it, ship it, look at the results.

The big change with AI is that every few months, a new model ships with new capabilities. For the past couple years, that’s meant a lot of progress on long-running agentic tasks.

What this means for product builders is that you need to extend the capabilities of the agent you built. You need to tune how it serves the existing capabilities, and you need to keep doing that.

Jayesh noticed that his teams would go back and rework every agent they built, often simplifying it because the new model can do more on its own.

That’s pretty different from prior tech we built on. Did you ever have to dedicate sprints to SQL getting an upgrade? It didn’t happen often, right?

And so that’s why we need a new software development lifecycle, which Jayesh calls the ADLC:

The reason you have to keep rebuilding the agent is because of drift.

The agent works. For instance, an agent answers refund questions grounded on the refund policy doc.

But then someone rewrites the doc, the update isn’t clear, and the code doesn’t change. As a result, the refunds come out too big.

That’s a big problem. So then you have to detect it.

You have to figure out what context changed, and whether it changed the right way or the wrong way. Then you have to correct it in production.

So the ADLC is built to accommodate that. We go from a linear process to a continual iteration.

Of course, we all sort of had a continual iteration, but here Jayesh is just codifying it. We go from observe, build, test, evaluate, deploy.

And so now we just continuously expect to rebuild our products.

That’s also why we’re so picky about what we put into our product, because we know it’s going to have a high maintenance cost when it’s an AI feature.

We’re going to spend a ton of money, time and energy on evaluating and observing that well.

So evals become incredibly important, and we need to embrace that continuous shipping methodology.

Every AI feature you ship is one you’ll keep rebuilding. Budget for evals and observability before you budget for the build.

The path to building an AI-native product team at Salesforce scale

One of the things I consistently see from my readers is that you guys are having to work on building AI-native product teams. You’re being asked to do that.

So I spent a lot of time with Jayesh understanding how he has rebuilt how 700 people work inside of Salesforce.

We broke the path down into 6 steps:

Step 1. Give teams a choice of tools. This is one of the most important takeaways I had from our conversation: execs shouldn’t pick the winner.

The goal for product leaders is to let teams choose. Do they want to use Codex? Do they want to use Claude Code? Do they want to use Cursor?

That’s how Jayesh’s teams moved from Cursor to Claude Code without a mandate.

As he watches the performance of the best, he helps others learn from that. But he is enabling all tools.

Step 2. Make Slack the operating system. I think this is something a lot of people attempting this sort of tooling shift miss.

You want to find a tool where you are always available asynchronously. For many people that is Slack.

Slack can become the home for your company OS Slack bot. It can even become the home for user feedback from your customers, with Slack Connect.

In Slack, PMs can get feedback on a prototype directly from a customer.

Step 3. Make the agent deterministic. One of the things you’ll encounter when you build these is there are some points where you don’t want to have two answers.

In the case of Salesforce’s agents, for instance, they do not want to have two numbers for pipeline. You can’t have one say 25 million and one 20 million.

That’s going to be a big problem.

So they use something called Agent Script, which allows them to identify which parts of the agent should have deterministic answers.

This was a really interesting nuance he brought up that I think other builders might not have. It points to the importance of getting this question answered: Where should I be using LLM AI? When should I be using determinism inside of my AI feature?

Step 4. Become eval first. Jayesh told the story of how his data science and engineering teams differed.

Data science teams were already eval native. Because they came up through the era of predictive AI, they always expected a model to be wrong some of the time and wrote tests against outcomes.

But most of his engineers, on the other hand, came from the deterministic world, where a test passes or fails. Those are the teams us PMs need to help become eval first.

What it means to be eval first is that you decide how you’ll grade the agent before you trust it. Essentially, each eval checks something.

And generic evals really don’t cut it. So as a PM, you develop or bring in the subject matter expertise to really win in the domain you’re delivering an agent for.

Step 5. Wire feedback to the roadmap. For Jayesh’s org, this means that every forward deployed engineer posts to one Slack channel. Each post is tagged as a paper cut or a feature request, and PMs match it against the roadmap.

When they do build something specific for a customer, they ask, should we be building this for everyone?

This allows you to learn directly from the field in order to improve your product.

Step 6. Roll out one win, then go wide. This is the classic pilot advice, but I was asking Jayesh where teams go wrong, and he brought it up as super important.

You have to find that area where you are going to show value.

Once you do that, then you go wall to wall with this sort of an ADLC instead of your normal SDLC.

What Salesforce looks for when hiring PMs

I’ve written about this a lot here. AI PMs have two skills that a regular PM doesn’t: AI prototyping and AI evals.

Jayesh agreed that those are the two most important, but when he’s screening, here’s what he’s looking for first:

1. Agency. This is actually the thing Jayesh finds in short supply, and I probably agree when hiring on my own team.

You want people who are high agency, and so that’s what he looks for first.

2. An agent-native mindset. Are you the type of person who, after doing a task a few times by hand, then teaches an agent to do it? That’s what he’s looking for.

3. Skepticism. You want to love the power of AI, but at the same time, you can’t believe everything.

This means you’re checking every output before you’re shipping it.

4. Craftsmanship. Craftsmanship applies to the product as much as the docs. You need to be able to sign your name on absolutely everything that lives in the product and the docs that you send out.

In particular, Jayesh finds red flags in people who send prototypes that look like every other prototype, or long docs that are just sent as a checkbox.

5. Setting the bar. This is probably the most important area for PMs, always. Can you say what good looks like?

Because if you can, that’s how you set up the evals and the test cases that we talked about being so important.

A good PM is an AI PM who understands AI prototyping and AI evals and brings these five character traits.

So if you want to get into Salesforce, where PM pay runs from $194K to $487K, with a median around $290K, this is what you’ll need.

I noticed they have a Senior Agentic Product Manager job open right now that’s really good.

Dreamforce did pay for my travel to the conference, but they did not make any requirements about what content I post. In fact, they were kind enough to provide the entire recording space and access to Jayesh for this episode. So thanks to Salesforce!

I first wrote this up in The Growth Podcast newsletter, with the full episode on YouTube.

We’ve been talking about the personal agent space for weeks now (Grok Bot, Hermes, Dots, Instinct, Muse), and we have been waiting to see what Anthropic will bring to the table.

For my money, Claude Code is the best AI harness, but can Duet replace it?

Spoiler alert, I don’t think so, but it’s an interesting surface. So let’s go take a look at Duet.

What Duet is

So Duet is basically a new tab inside your Claude app.

The idea is that it’s going to be more proactive. It’s going to nudge you with tasks that need your attention, and it runs on channels, almost like Slack.

They don’t actually surface a model picker, which is interesting. It runs on Opus 5.5. For someone like me who runs a lot of tasks on Sonnet, that is an unfortunate cost. There’s also no effort picker.

If you think about Duet, it’s almost like a simplified view into Claude.

It does piggyback off your existing Claude memory, skills and connected apps. That’s its big benefit for a power user like me who lives inside Claude.

If you’re like that, you might get some benefits. But to be totally honest, most of it needs to be prompted.

Here’s an example. I needed to connect it to my Content OS repo:

I’ve generally found that they haven’t made the recall very good yet, especially of local Claude Code sessions.

How to set it up

Step 1: join the waitlist

I ended up exercising some of my Anthropic connections to get off of it as soon as I did. You may have to wait a little longer.

Step 2: connect your apps

If you’ve connected Claude to all your apps, Duet already inherits all those connectors, which is great.

Step 3: see what it already knows

One thing I tested was what it knows about me, and here’s what it showed:

You can see it’s a pretty good landscape. I was impressed. This is one of the benefits of Duet being Duet.

The top features

I haven’t seen a lot of these in most of the content I looked at, videos and articles. I don’t know if they’re out of date or if the authors didn’t see them. But basically, Duet has these concepts of groups and channels.

Here’s how I’ve set mine up: Content, Cohort and Personal. You can choose your own way. I also set up a chief of staff.

Everything, channels and groups

Everything is one feed for every ask.

Channels are separate chats for one stream of work, like newsletter, podcast or webinar. Groups hold channels together.

I asked it in Everything to plan next week’s newsletter, podcasts and webinar. It split that into tasks and filed them into the newsletter, podcast, LinkedIn and email channels on its own.

Instructions and a chief of staff channel

Each channel keeps its own standing instructions. I made one channel my hub and asked it to direct the others. It rewrote its own instructions to read every other channel and give me status across all of them.

The Everything channel is pretty powerful. It’s the catch-all. You can use it as your chief of staff, or keep it for blanket questions. I chose the chief of staff model, which I got from Grok Bot.

It’s not built into Duet. You have to set it up yourself, and here’s how I did it:

The daily heartbeat

One of the defining features: every morning you get a brief on what’s on your plate across all your channels, what work it did overnight, and what it might want to do today.

That’s how it’s proactive. It’s a daily heartbeat, which you’re probably familiar with if you’ve used something like OpenClaw.

One of the cool things it does: it gives you buttons to choose options, so letting it help you takes even less effort.

What makes Duet work is that it’s one Claude across all your channels. At least, it aspires to be. Perhaps when they build it fully, it will be.

The design touches

Duet has several design concepts that make me think they had a really strong designer working on it. One idea: task cards that open like this.

Another cool thing: you can attach a GitHub repo to a channel. That’s not something I’m familiar with in regular Claude, but you can do it in Duet.

It asks before it acts

Every email it drafts, every change to my posting queue and every payment waits for my yes.

How I’d set it up from day one

• Connect your inbox, calendar, Slack, Drive, Notion, Stripe and the other basics.
• Connect your product analytics too. Mine is in PostHog.
• Set up a group for each business line, plus one for personal, with the right channels inside.
• Ask each channel something proactive to get it started.
• Start teaching them. The conversations get a lot better once you’ve taught them for a while.
• Create a chief of staff channel and dictate your goals to it.

The jobs I gave it

I gave it the same jobs I gave Dots, Grok Bot, Muse and Instinct.

What I observed was it mostly helped me in reading and drafting responses, and struggled with taking actions:

It saved me time on anything inside my calendar, my inbox or my Slack connections. But outside of that, I had to do almost everything by myself.

Where it saved me time

Meeting prep. It was good at preparing for my meetings, much better than the other personal agents, because of the context it had from my Claude, as I’ve been running it for months. It understood all the nuances from Slack.

Morning brief. It told me what to skip. And because of all that context, it was much more refined, and my to-do list was much shorter.

Same was the case with the email replies:

It caught a broken page before I did. I asked if my new webinar page was live. It found the page, then told me nobody could register. The signup still said “Registration opens shortly” because the session was never created in WebinarJam.

It audited my posting queue. It flagged the six worst scheduled posts. They included a broken line and a stale “Cohort 5 starts Nov 9” in posts going out after Nov 9. It changed nothing until I said so.

Where it cost me time

It made things up as me. It claimed things I had never told it. So every draft in my own voice needs a line-by-line check. I would rather write things on my own, or rely on Grok Bot or Dots.

The twist: once it had my repo, it did the opposite. It wrote “I need these from you rather than making anything up.” It invents when context is thin and asks when context is rich.

It doesn’t know where to look. I asked how our site stats were doing. It checked my mail and asked me where my stats live. When I told it to use my repo, it asked for the repo name, after suggesting “aakashg/content-os” itself.

It stops outside Claude. Muse and Instinct can make calls and take actions for me. Duet can’t pay without Link or Shop Pay. It can’t use LinkedIn yet.

My verdict

After using Duet for the last week, I can confidently say Instinct is still my favorite.

You can text Instinct. Instinct is more proactive. And Instinct handles numbers and money stuff much better. I was less shy about handing that over.

Since Duet is a competitor in this personal agent race, I compared it against the things that worked well on the other tools I’ve evaluated. Here’s what came out:

In my Dots post, I split the personal agent market into two races. One is personal tasks, where Muse and Instinct lead. The other is work tasks, where Grok Bot, Hermes and Dots lead.

Duet doesn’t fit either race. It’s a unified agent. The same app ran my newsletter queue, my podcast prep, my workouts and my subscriptions.

So does Duet have judgment? Yes, once it has the material. It found the one broken thing on a page and caught bad posts in my queue. It stopped inventing the moment it had my repo. It falls short when it has to go find that material.

Here’s my updated decision tree:

• Personal tasks: use Muse if you live in Meta’s apps, else pick Instinct.
• One agent for work and life, and you live inside Claude: use Duet.
• Lots of work tasks and you live inside ChatGPT: use Dots.
• Grok Bot is still the strongest work agent overall.

I first wrote this up in AI by Aakash, along with the week’s AI news.

Most of your product team can’t tell your strategy. Check with them now.

I’ve done this at nearly every company I worked at, and often did this with team members of PMs I managed. You ask an engineer, “Hey, what’s your guys’ strategy?” You’re met with a shrug.

I call it the strategy crisis.

The math on a product team

If you run the math on a product team, they’re pretty expensive. 5 engineers at $300K, plus 1 designer and 1 PM at $250K each, is $1.5M + $0.5M = $2M fully loaded for a product team in the United States.

If you’re spending $2M and not every team understands the strategy, that’s a huge loss. That’s why I believe most product teams need to spend more time on product strategy.

After 16 years of trial and error, here are the 19 rules I would call out. Let’s go deep on seven of them.

0. Your strategy has to help your team say no

This is the most important, and that’s why it gets the 0 label.

Tim Herbig said it well on my podcast recently. Does whatever we’re calling strategy help the team say no to something? If it doesn’t, it’s not a strategy.

I once had a team I was part of with 14 priorities. Every org picked the 6 close to them and just said yes to everything they were doing. There was no strategy then. We were just pursuing 14 different agendas.

Growth actually clicked when we narrowed to 3 and cut half of the projects everybody was working on.

1. If the opposite is stupid, you made no choice

This test comes from Roger Martin, who I also had on the show. It’s called the stupidity flip.

You take a line of your strategy and you flip it. If that flip is stupid, then you haven’t actually made a choice, you’ve just stated the obvious.

3. Cheap features make wrong choices expensive

This one’s a mouthful, but it’s worth unpacking. AI has made features pretty cheap, but what that means is that we have to make the right choices. We have to avoid filling our product full of AI slop, and a good product strategy helps you get there.

7. Make your target audience comically narrow

This idea comes from Andy Johns. It’s all too easy to choose a broad user group because you want to serve your whole revenue base. But what you need to understand is that product strategy in particular does better when it’s focused on a very specific group. It doesn’t mean you have to neglect everyone else, just that you have a specific priority when you are building the product so you can build the product tastefully.

8. AI by itself is not a value proposition

We’ve all seen the cycle. It happened like crazy in 2024 and 2025. Executives and boards pushed us to add AI to everything, and the metrics didn’t move at all.

If you’re going to use AI, it needs to be in order to solve more of the customer’s use case, make their lives easier or more fun. That’s when it becomes a value proposition.

13. Tokens used is not a value exchange

This one deserves some unpacking. You don’t want to just charge 30% more than Anthropic and pass that on to your users and make that your pricing model. That’s an underdeveloped pricing model, and it’s really a value exchange for Anthropic. You want to think about what changes for your customer and price based on that.

18. A strategy doesn’t have to cover everything

I want to end here because it emphasizes number 7 as well. You can still build some part of your focus on things that aren’t in your strategy. You can still build to quality. You can still have low bugs. You can still target your free group, even if your strategy is focused on your paid group.

The point of strategy is to focus your 80% of work on the 20% that’s going to give you the most impact. Think Pareto in real life with your product.

Go deeper

If you want to go deeper on product strategy and learn from my 16 years of lessons, watch Tim’s episode, then Roger’s. Then read my guide to building product strategy in the age of AI.

What rule would you add?

When I started in product management back in 2008, the PRD was essentially a glorified permission document. The reason we wrote it was that building was the most expensive thing we could do. So we wanted buy-in from all the stakeholders.

As you know, AI has changed that. Now a prototype is just a prompt away. That means the order of work in product development should change.

You should go from idea straight to 5 prototypes. Then you should find the best prototype and write the PRD for the survivor. Your PRD becomes a decision record more than a permission document. That’s what this template is built for.

It starts like the classic PRD

You’ll notice it’s similar to the classic PRD. We have a problem with the number, with user quotes. We have a hypothesis with scope and non-goals. Those are the ingredients that made a good PRD in the past, and they still make a good one now.

The behavior contract is the big change

One of the biggest changes for AI features is the behavior contract. In my opinion, the best behavior contract is 15 to 25 examples that cross the spectrum of good, bad, and amazing responses.

Success metrics keep it scientific

The next important thing a PRD should include is success metrics. That’s how we maintain the scientific process with our features and don’t just ship AI slop at the wall, but only graduate features that hit our success metric. Good success metrics cover the metric to graduate, and if it’s an AI feature, they cover the golden set of offline evals.

Record the rollout

The next thing I think still makes sense to document in a PRD is the rollout. You want that decision recorded. What is the exposure, the duration, the number? You also want people to know when you might flip the kill switch on a feature, and who is responsible for that.

A great PRD keeps evolving

Just like before, a great PRD isn’t a snapshot in time. It keeps evolving. So I recommend you add your results link to the top of your PRD.

On some teams the PRD is optional. But most teams I talk to aren’t going that lean. It might be because they work in a regulated industry, or because they work at scale. Whatever the case, this page is for you.

More on working this way

These are my guides on each piece of it:

1. AI PRDs
2. The history of the modern PRD
3. How to build golden data sets
4. The process of whittling down from 5 prototypes to 1

How would you change it?