Over the next 12 weeks, I’m going to write about each one of those competencies: what it is, why it’s important, and how it’s changing in the age of AI. I’m also running a free workshop series for each competency to dive deep into how you can level up and answer the questions that are top of mind.

Join the Top 1% Builder Series

The Top 1% Builder Series is a free 12-part live workshop series (one week per competency) with Ravi for product managers, leaders, founders, designers, engineers, and builders who want to ship products customers love — with AI amplifying the judgment they already have. Live attendance is free. Replays and slides are available to paid Top 1% Builder Club members.

Join the Top 1% Builder Series →

Product thinking matters more than ever

I published the Product Competency Toolkit in April 2020, a few months into the COVID-19 lockdown. Since then, thousands of PMs and product leaders have used the 12 competencies to reflect on their work and help their teams level up.

Today the job of building products is going through radical change — so profound that some folks believe the product job itself is disappearing. It’s easy to see why that fear has taken hold. Companies are downsizing, much as they did in the early days of COVID-19, and increasingly shifting dollars from talent to tokens.

I see a very different future. The product job doesn’t go away. It matters more.

More people than ever will create products. And that means one of the most in-demand skills in the AI era will be product thinking — the type of thinking that has long been at the center of product management.

Product management isn’t dead or going away. Instead, the aperture is widening on who does the work. This toolkit began as a framework for product managers. Today, its competencies apply to anyone responsible for turning customer needs into valuable products.

Let’s look at the first of those competencies.

Product Definition, defined.

Product Definition is the ability to define requirements, functionality, and context in a clear, actionable form that enables humans and agents to deliver the right product.

Execute flawlessly

The competencies are organized into four areas:

• Product Execution — getting the right product built well

• Customer Insight — understanding the people you build for

• Product Strategy — choosing the outcomes that matter

• Influencing People — rallying people around the org to make it so

The foundation of successful product management is Product Execution, the ability to work with a cross-functional team to define, build, and launch well-designed, stable products. The best product builders strive to execute flawlessly. They know there is already enough risk in understanding customer needs and crafting the strategy around those needs. They can’t afford unforced errors.

AI raises the stakes. Teams now include agents that can turn direction into working software at remarkable speed.

Strong execution requires extraordinary attention to detail at every step:

• Product Definition — defining the right product

• Product Delivery — working with people and agents to build it right

• Product Quality — ensuring high quality at launch and beyond

Flawless execution starts with Product Definition — the team cannot possibly succeed if they do not understand what needs to be built.

Feature Specification → Product Definition

In the original toolkit, I called this competency Feature Specification. Today, I call it Product Definition. The job was never just to write a spec. It was to make clear what we’re building and why. Now, that clarity can come from a working prototype, a written document, or ideally the two evolving together. The artifact changes. The responsibility doesn’t.

PMs were context engineers long before AI took hold — but until recently, that context was designed primarily for people.

PMs are the original context engineers. In the past, they created the context for the team to build the right product. Now, that context guides both people and agents.

A good PRD (or spec) is not simply a document. It is the shared understanding created through specs, prototypes, tickets, conversations, and decisions — the framework the team operates within.

Product Definition is the art of rallying the team around an outcome and giving people — and now agents — enough context to build the right product.

How Product Definition evolves with AI

Until recently, product definition happened primarily through written specifications. Detailed designs and working prototypes were expensive, so they appeared later. Today, you can sometimes create a working prototype faster than a PRD.

That makes it possible to define products at much higher fidelity. A working prototype can align stakeholders around a shared picture of the intended product and give customers something tangible to react to earlier in the process.

This increased fidelity matters even more when agents participate in the work. Inadequate context forces agents to fill gaps with defaults. Unexamined defaults produce generic output: slop.

The old problem was too little context. Written specifications offered a low-fidelity description, leaving the team to interpret what the product should be. The new problem is often too much context. Teams accumulate long PRDs, multiple prototypes, review feedback, and hundreds of AI-generated decisions. People cannot tell which details reflect product intent, which are incidental, and which remain open. More context is not necessarily better context.

The challenge is to choose the right artifacts and synthesize them into one concise, coherent, executable definition. That definition must communicate:

• The story behind the product

• Why it deserves to exist

• What success looks like

• How the functionality and user experience should work

• What’s in, what’s out, and what’s undecided

Product Definition is not a one-time handoff. The PRD, prototype, and team’s understanding evolve together as the team explores, reviews, tests, and builds.

How it feels to master Product Definition

You know how to assemble exactly the context the work demands — neither vague nor overwhelming.

You have moved from writing specifications to engineering context. You use PRDs, prototypes, product reviews, and handoff artifacts as one connected system. You know what each artifact should communicate, what it should leave to another artifact, and how the pieces should evolve together.

You empower the team by giving people and agents enough context to make strong decisions without drowning them in information. The result is a shared, actionable definition — not more documentation, but less translation, less rework, and better decisions made earlier.

Product Definition from APM to CPO

All 12 competencies matter at every level, but their relative importance — and what excellence looks like — changes as your scope grows. Product Execution is critical early in your career. As you become more senior, Product Strategy and Influencing People become the critical path to growth.

A simple ladder captures the shift:

• Product managers build products.

• Product leaders build the teams that build products.

• Product executives build the systems that build the teams that build products.

AI doesn’t flatten that ladder. More people can build, and ICs can have more impact than ever. But leadership matters more as teams move faster — a faster car needs steadier steering.

Every competency climbs the same ladder, including Product Definition. Early on, product builders learn to define product work clearly enough for others to build. Product leaders help their teams meet the same bar, while great product executives build systems that give the entire product development organization the context to do its best work.

The goal of Product Definition never changes: a team that knows what to build and why. What changes is the work it takes to get there.

Early in your career, that means framing the problem, setting scope, and making decisions clear. The bar is simple — do people and agents have the context they need to build the right product?

As you start managing a team, the work turns to reviewing other people’s specs and keeping the team aligned. At the most senior levels — VP or Chief Product Officer — Product Definition becomes a system: setting standards, improving review processes, and giving every team and agent the context it needs.

Its importance shifts, too. Early on, Product Definition is the bedrock of success. Later, the roadmap and strategy claim more of your time. But the work doesn’t disappear. Executives build the systems every team uses to define the right product — so those teams have what they need to execute flawlessly.

Senior leaders know the hardest part of product isn’t building. It’s figuring out what to build at all.

Next week: Product Delivery — turning a clear, shared definition into a working product that creates value for customers.

Dive deeper into Product Definition

The free Product Competency Toolkit dives deep into the 12 competencies that turn good product builders into remarkable ones. Updated entirely for the AI era, it explains how each competency is evolving — whether you want to improve your own craft, coach your team, or help your entire organization level up.

It’s for anyone building products across product, design, engineering, marketing, leadership, or a venture of their own.

Get the Product Competency Toolkit →

I remember one conversation vividly. It started with the idea that the typical 1:5 PM-to-engineer ratio makes sense for the average PM, but the best PMs can handle much more. One PM bragged that he was working with 10 engineers and barely breaking a sweat. Someone else jumped in: “No, no, no. The best PM I ever worked with had 30 engineers.”

This got me wondering.

Was the PM supporting 30 engineers really three times smarter, better, or faster than the PM supporting 10?

At TripAdvisor, we stayed pretty close to the 1:5 PM-to-engineer ratio. Many of the PMs on my team then are now VPs and CPOs. It certainly was not a talent issue.

That debate has since moved beyond ratios. The question is no longer: How many engineers can a PM support? It is:

Do we even need PMs at all?

Build products customers can’t live without

The free Product Competency Toolkit dives deep into the 12 competencies that turn good product builders into remarkable ones. Updated entirely for the AI era, it explains how each competency is evolving — whether you want to improve your own craft, coach your team, or help your entire organization level up.

It’s for anyone building products across product, design, engineering, marketing, leadership, or a venture of their own.

Get the Product Competency Toolkit

The death of product management is greatly exaggerated

Claire Vo put the argument bluntly: “Product Management Is Dead.” AI, she argued, can draft documents, process feedback, prioritize features, and generate wireframes. The traditional product trio is giving way to smaller teams of “AI-powered triple threats” who work across product, design, and engineering.

Brian Chesky created a similar stir when he said Airbnb had “got rid of the classic product management function.”

Then Tom Verrilli, Whatnot’s chief product officer, went further: “We regret that product management exists.”

The line sounds like an obituary. His actual argument is more interesting. Whatnot refuses to hire a PM simply because an engineering team exists. It adds one when there is a specific need. Verrilli believes engineers and designers should have enough customer and business context to make good product decisions themselves. Otherwise, a large PM function can “infantilize” capable partners by shielding them from that work.

Similarly, Brian Chesky’s view is more nuanced. Airbnb did not get rid of product work. It combined product management with product marketing, elevated design, and asked product managers to understand not only how to develop a product, but how to explain it.

The product role is shifting. That part is true. As AI takes on more coordination, documentation, and synthesis, the PM as project coordinator, requirements writer, and professional meeting attendee will fade.

What remains is the work that always mattered: judgment, strategy, and a deep understanding of customers. AI raises the stakes for all three. A team moving at 100 miles an hour needs stronger steering than one moving at 10. As building accelerates, knowing where you’re going becomes more important — not less.

A team moving at 100 miles an hour needs stronger steering than one moving at 10.

But that work does not have to live inside a traditionally defined PM role — and increasingly won’t. In the strongest product cultures, founders, designers, engineers, researchers, marketers, and others play an important part.

Which brings us back to the ratio question: When one PM supports 30 engineers, what’s really going on?

The PM-to-engineer ratio tells you where the work lives

A PM-to-engineer ratio does not measure the PM’s talent, bandwidth, or importance.

It measures the organization around the PM.

A PM supporting 30 engineers might work in an organization where the founder sets a clear strategy, designers stay close to customers, engineers help define the product, researchers surface unmet needs, and marketers understand how the product will reach the market.

Or that PM might be an exhausted ticket writer supporting 30 engineers who build whatever sales, executives, or the loudest customer requests.

The ratio is identical. The product cultures are opposites.

The least and most product-centric companies can both end up with fewer PMs — for very different reasons.

The least product-centric companies see PMs as overhead. In the name of efficiency, they cut headcount, whittling away at the role while encouraging everyone to build and ship. The visible work survives because it must. Tickets still need to be written. Questions still need answers. Releases still need coordination.

The job collapses to execution.

The important but less urgent work slips away:

• Nobody talks to customers.

• Nobody owns the vision.

• Nobody connects features to business outcomes.

• Nobody protects the quality bar.

• The team focuses on building, not deciding what to build.

The most product-centric companies arrive at fewer PMs from the opposite direction. Product thinking is not trapped inside the PM function. Founders, designers, engineers, researchers, marketers, and other partners share the work. Their contributions amplify each PM rather than leave the PM stretched thin.

These companies have not eliminated product management. They have built a culture around it.

The 12 activities that cannot disappear

I originally created the Product Competency Toolkit as an individual development model. PMs use it to understand their strengths and gaps. Managers use it to coach people, evaluate teams, and make better hiring decisions.

But the framework can be read another way. The 12 competencies are not merely the skills of a strong PM. They are the work a strong product organization must do.

The system covers Product Execution, Customer Insight, Product Strategy, and Influencing People.

There is a lot to master — and inherent tension in the work. Product builders must be empathetic and analytical, qualitative and quantitative. They need fastidious attention to detail and the ability to think in broad abstractions. The best are creative innovators and rigorous optimizers.

Join the Top 1% Builder Series

The Top 1% Builder Series is a free 12-part live workshop series (one week per competency) with Ravi for product managers, leaders, founders, designers, engineers, and builders who want to ship products customers love — with AI amplifying the judgment they already have. Live attendance is free. Replays and slides are available to paid Top 1% Builder Club members.

Join the Top 1% Builder Series

Product management is a team sport

Product management is consequential work, too broad for any one person to master. Remarkable products are built by teams. Each person contributes from a different vantage point, bringing the expertise, insight, and relationships needed to make the product better.

Engineering contributes to Product Definition, Delivery, and Quality. Design and research contribute to Voice of the Customer and User Experience Design. Data science brings Fluency with Data. Sales, marketing, operations, and finance help connect strategy to business outcomes. Team Leadership and Managing Up draw on everyone.

These people are not peripheral stakeholders for a PM to “manage.” They are part of the product system.

This is why strong product companies can run with very different ratios. A PM does not need to spend hours combing through data when the team has an excellent data scientist. A designer who is deeply connected to customers may shoulder more of the discovery work. An engineer can shape the product through prototypes, technical judgment, and a clear understanding of the user.

Lots of people can contribute, but someone still needs to own the outcome. Each activity needs the right people involved and a way to make sure the work happens consistently. Otherwise “everyone owns it” becomes another way to say nobody does.

Strong product organizations make this division of labor explicit. Weak ones copy the org chart, but miss the point.

When building gets cheaper, judgment gets more valuable

AI changes both the speed of product development and who can participate in it. It can generate code, synthesize research, create prototypes, and draft specifications. An engineer, designer, marketer, or founder can now bring a working prototype to the table instead of an opinion.

When building was expensive, capacity imposed discipline. Teams had to choose carefully because every direction consumed scarce engineering time. As that constraint weakens, teams can explore more ideas and produce more versions faster.

AI shifts the bottleneck from building products to judging what deserves to ship.

The challenge is no longer generating another option. It is knowing which option solves a meaningful customer problem, fits the strategy, meets the quality bar, and deserves to reach customers. Empathy, judgment, strategy, alignment, culture, and taste are not secondary to building. They determine whether faster building creates progress or noise.

The idea that everyone should be rolling up their sleeves and building is exactly the wrong one. We don’t need every PM putting a little extra pressure on the gas pedal. We actually need PMs and product orgs spending more time figuring out where we should be going — and probably less time building.

For teams that have been constrained by build capacity for as long as they can remember, the idea that not everyone should contribute to that build capacity is disorienting. But it is absolutely the thing that will separate the companies building what their customers want from companies that are just force-feeding their customers new features to clear their backlog.

Is your product culture shrinking?

The least and most product-centric companies can arrive at the same conclusion — fewer PMs — for entirely different reasons.

After rounds of layoffs, I worry many companies are watching their product culture shrink. The remaining PMs do not have enough bandwidth to do the full job, and the rest of the organization is not picking up the work.

The 12 product management competencies can help diagnose the problem and decide how to solve it.

Take the 12 competencies and ask:

• Who is accountable for each one?

• Who contributes?

• What evidence shows that the work is happening?

• Where does it slow down or disappear?

• What closes the gap: sharper priorities, clear ownership, more people, or stronger partners?

Be honest. Do not write “Product owns strategy” if nobody can explain the strategy. Do not write “Engineering owns quality” if bugs are piling up. Do not write “Everyone talks to customers” if nobody actually does.

The goal is not to return to a particular PM:eng ratio. It is to make sure the work to create remarkable products still gets done.

You can eliminate the PM role. You can flatten the team. You can distribute the responsibilities. But the work remains.

Product managers may be optional — but only if the rest of your company is ready to do the work.

Product management is not.

Earlier this week I spoke with a PM who was laid off from her first product role. She’s been looking for a few months, and she asked me if there’s still a career here. Last week in Berlin, at one of the biggest product conferences in Europe, I heard some version of her question in every hallway.

Here’s my answer. Yes. Your hard-won skills still matter. AI made building software much cheaper, and that puts the hard parts of product work in sharper focus: judgment, craft, and understanding your customer. Those still move at human speed. Product management isn’t dead, and it isn’t optional. The job is shifting from deciding what’s worth building to deciding what’s worth shipping.

Yesterday, I taught a live workshop for product builders around the world—from Los Angeles and Berlin to Mumbai, Singapore, and a stormy Nantucket.

They’re building products that matter: better elder care, earlier cancer screening, smarter sales and accounting tools, less food waste, and better treatment for hypertension. Others arrived with more personal questions: How do I stay relevant as a developer? Do I find another job or build something of my own? One had just been laid off from a director role.

They came to build — and to figure out where they fit in a world being reshaped by AI. This article is for them, and for you if that sounds familiar. You’ll get the workshop’s core ideas, the 12 product competencies explained from scratch, a way to find your shape, and a plan for this week.

Below is a practical recap of the workshop. You can also watch the full replay free until 11:59 PM PDT on September 30, 2026.

Watch the Replay

Password: ?7kcy?tY

For access to the replay and slides after September 30, join the Top 1% Builder Club. Membership is $25 a month, or $180 a year through September 30.

Join now 👉

Three claims that can’t all be true

You’ve heard the three claims:

1. Everyone is going to lose their job.

2. Product management is dead.

3. Anyone can do your job now.

The claims don’t agree with each other. If anyone can do your job, the job can’t also be dead. The people saying these things don’t seem to notice they’re arguing with each other.

Here’s what I see when I talk to product people every week:

Nobody is less busy than before. If AI were taking the job, you’d expect the opposite.

Some of the hype looks to me like fear-mongering in the interest of other people’s economic gain, a lot like the crypto hype from a couple years ago. The tough part is real: companies are downsizing. But some of them are starting to hire back, and they’re learning what they gave up.

Don’t trade talent for tokens.

So if AI isn’t taking the job, what is it doing to it?

What changes when building gets cheap

Product management “best practices” were built on one idea: building working software is expensive. So we designed systems around that cost. Specs came first, because they’re cheap to write. If there was enough conviction, we moved to wireframes, then detailed designs, then engineering.

It worked like an assembly line, one phase after another, each one gating risk.AI collapses that cost. It’s now sometimes faster to build a working prototype than to write a PRD. Earlier this week I gave a talk at Ford, the company that invented the assembly line, and even they are rethinking how software gets made.

The jazz band replaces the assembly line

Like a jazz band, design, engineering, and product each have their own instrument to play — we don’t need everyone on drums. Now, they riff off each other, and the lead moves from player to player depending on the question in front of you. You can go back to the beginning. You can skip a step. You can build a lot of things you never ship, and the thing you do launch is more tied to what creates value for customers and for the company.

One attendee wrote that this will be tough for companies that still think command and control is the way. Another wrote that AI has increased command and control at their company, not small-team empowerment. these are common failure modes that I hear about all the time. Read to the end for thoughts on how to improve accountability and how to get engineers excited about this new model of working

Minimum viable gives way to most lovable

We shipped minimum viable products for one reason: building was so expensive. How many customers want a product that barely solves their problem? None. We did it for ourselves, not for them. Now we can aim for the most lovable product. Build more. Test more. Throw more away. Ship less, and ship better.

That adds a step before launch, where you decide whether to launch at all. After the hard work of building something, it’s painful to consider that we might not ship what we built. In the past, when the cost of building working software was so expensive, that pain was too great to bear.

Now, curation is an essential step in the product development life cycle. Some of the best products will be defined by what teams choose not to ship — by holding the line on what is customer-worthy.

This point is controversial, and teams ask me, “If we built it, why not ship it and A/B test it?” You probably don’t have the traffic to test everything to significance. Your customers don’t want the product changing under them every week. And we’ve all used products that feel like an accumulation of A/B tests instead of something thoughtfully designed.

Cut the ship. Choosing not to ship takes courage and discipline.

This is the shift from prioritizer to curator:

• When building was expensive, the question was “is this worth building?”

• Now the question is “is this worth shipping?”

Want to get better at deciding what deserves to ship? Join Now and bring your own product to office hours with me.

Join now 👉

AI gets you to the hard part faster

AI doesn’t make our job easier. It gets us to the hard part faster.

AI speeds up the work machines can do: writing and shipping code, analyzing data, drafting PRDs, generating tickets and status reports. It doesn’t speed up the work people do. Talking to customers. Helping them build new habits. Getting a room of stakeholders to line up behind a decision. Convincing your boss, which may take longer now, because everything is moving so fast that conviction matters more before you pick a direction.

One attendee put it in one line in the chat: “Product building: move at AI speed. Product management: move at human speed.” Another added, “You can share data faster, but that does not imply a shared understanding.”

There are also two kinds of speed: velocity and latency. Most people try to get faster by maximizing velocity. The better move is to minimize latency, the time from an idea to a result.

Speed doesn’t come from maximizing velocity. It comes from minimizing latency.

Here’s the test I use on any company. If changing a button from “Shop” to “Buy now” would raise conversion, can you ship that today or tomorrow, or does it take a month? the code change won’t take long at all, and never did. Yet for many companies, it can take a month or more for that change to work its way through the process. AI might be helping those companies write more code, but it’s not helping them move any faster.

The 12 product competencies, from scratch

I first published the product competencies in 2020, weeks into lockdown, as the Product Competency Toolkit. Thousands of people used them to understand themselves, level up their teams, and chart a career on purpose instead of by accident. I’ve now rebuilt them for the AI era.

They’re the 12 skills I think a team needs to build products customers can’t live without. No single person is great at all 12, and a well-rounded team needs people with different strengths. They apply to anyone who contributes to product, not only people with a PM title. The list looks a lot like the old one, because the shape of the job hasn’t changed much. What changed is how you do each one.

Product Execution: getting the right product built well

Product Definition is deciding what the product is and getting that across so a team can build it. It used to mean writing static specs. Now you can define a product with a working prototype, and engineer context for humans and AI agents alike.

Product Delivery is working with engineering to get the product built. The old goal was to hand off a spec and protect the sprint. Now you shape the product as it emerges, with humans and agents in the loop.

Product quality is making sure the product works, reliably, in a way customers can trust. It used to be a checkpoint. Now it’s a living system, because products are personalized, capabilities change, and models drift.

Customer Insight: understanding the people you build for

Fluency with data is using data to understand why customers do what they do. It used to be reporting, dashboards, and SQL. Now you can build causal models of customer behavior, starting from the decisions you need to make.

Voice of the customer is hearing what customers tell you. Now you can use LLMs to turn feedback and transcripts into a sharp picture of your customer, and put a prototype in front of them that they can see as vividly as you do.

User experience design is shaping the door customers walk through to get value from your product. Interfaces used to mirror the software underneath, so customers had to mold how they work to fit. Natural interfaces like chat and voice change that. Descript lets you edit a video as a script instead of a timeline.

Product Strategy: choosing the outcomes that matter

Business Outcome Ownership is being responsible for moving the metrics that matter. It used to mean rationing scarce engineering time. Now capacity is abundant, so the skill is the judgment to point it at the right outcomes. Motion isn’t value.

Product Vision and Roadmapping is setting the direction and planning how to get there. Now you can define a North Star and build toward it at the pace OpenAI and Anthropic innovate. When you move that fast, knowing your direction matters more.

Strategic Impact is the sum of your business outcomes over time. A roadmap is an accumulation of features. Strategic impact is an accumulation of smart business outcomes, so the goal now is compounding wins.

Influencing people: leading in every direction

Stakeholder Inclusion is leading across. I renamed it from Stakeholder Management, because things move too fast to manage everyone involved, which is like herding cats. Customer support, sales, and forward deployed engineers all have a view on what to ship, and now they can build prototypes that add to the conversation instead of constraining it.

Team Leadership is coaching the people on your team to do the best work they’ve every done. AI takes over coordination work like slinging JIRA tickets, so you can coach a team whose strengths fit together. I don’t think everyone will become a super IC — a company without leaders can’t lead.

Managing Up is getting the support you need from executives, by being seen as an ally in helping them achieve their strategy. Leadership decisions used to be slow and manual, with quarterly business reviews. Now they need to be fast.

Want the deep dive on all 12, including a 36-question assessment and AI skills for each one? Join Now and get them the day they ship.

Join now 👉

Find your product management strengths

You can’t be equally good at all 12 competencies. Nobody is. Individuals should be spiky, and teams should be well-rounded. Your shape is the pattern of where you’re strong and where you’re not, and it tells you what to build on and who you need beside you.

Find your strengths, and cover your gaps

Ask your peers and your manager what you do best. That’s where you’ll build remarkable products, and where you’ll stay ahead of AI no matter how good it gets. I cited a McKinsey study, done with the search firm Egon Zehnder, finding that organizations that encourage people to be spiky outperform organizations that focus on fixing weaknesses. An attendee shared a line from a mentor that says it well: “You’re hired because of your strengths, so don’t stop working on them.”

Then cover your gaps, but don’t chase them. Say you get your energy from User Experience and Voice of the Customer, and less from Fluency with Data. You still need data fluency to make a great product, but it doesn’t have to come from you. You can lean on a data analyst, or decide to invest in getting better.

It’s also why I don’t believe in the “full stack builder” — a single person that is expected to do it all. One week the advice is that every PM should spend time shipping their own code. The next week it’s that PMs are the bottleneck. Both can’t be true. It’s impossible to be great at everything a great PM needs, let alone everything a great engineer, designer, user researcher, and data analyst needs.

In the live hot seat, a product leader named Voice of the Customer as his spike. He described how people can say they want a boat or a bus, when the real problem is that they live on the other side of the lake and they’re stuck. That’s the muscle: hearing the emotion and the reason behind what people say. I think empathy with customers separates you from everyone else, and it’s where you add the most value as context for AI.

Take the 5-minute Product Competency Assessment

1. Go to ravi-mehta.com/assessment.

2. Enter your title and roughly where you sit in your organization. The tool shows what’s expected of you at that level, even if you’re not a PM.

3. Rate each competency as on track, outperforming, or needing focus. On the first page, the colored boxes only show how important that competency is at your level, so press Next to rate yourself.

4. Mark up to 3 as outperforming. If your gut says you’re good at something, trust it. The cap of 3 is the point, because it forces a shape.

5. Mark up to 3 where you need focus. That could be something you want to improve, or something that isn’t in your wheelhouse. The other 6 are on track.

6. Download your report (as a PDF, Word doc, or Markdown file). Need some coaching? Paste the Markdown file into ChatGPT and ask some key questions on how to get better.

Then ask your manager to take it too, and compare notes. Where do you agree you’re outperforming? Where do you agree you need focus? Where do you disagree? Spend 10 minutes on that before your next one-on-one. I think it leads to the most valuable one-on-one you’ve had in a while.

Know your spike and want to make it sharper? Join Now and take your shape to office hours with me.

Join now 👉

Build a team from shapes

A team has a shape too: the sum of the shapes of the people on it. A PM who’s great at User Experience Design and Voice of the Customer can lean on a data analyst. A PM who’s great with data but light on user experience can lean on a designer. When you hire, describe the shape of the person you want, not only the job description, and push yourself to hire someone different from the average on the team.

Stack the shapes of 10 people and you may find a well-rounded team. Or you may find everyone bunched around one shape. A growth team, for example, is often focused on Business Outcome Ownership and Fluency with Data, and that can create blind spots, like treating customers as if they’re in a petri dish.

I described an example from the travel industry: HomeAway prides itself on being a data-driven company and was able to consistently drive growth using an analytical approach. They were the number one vacation rental company for many years. Airbnb took a more well-rounded approach, thinking about vacation rentals not just as a transaction between a property owner and a renter, but as a human social interaction between a host and a guest. They rethought the marketplace by putting customer empathy at the center. With that reframe, they grew faster and now eclipse HomeAway in market share.

Leaders need a talent roadmap the way PMs need a product roadmap.

Three hard questions

Who’s accountable when everyone can contribute?

Let everyone contribute, and be clear about who’s accountable for the bar. Engineering is accountable for software quality, scalability, performance, and architecture. Design is accountable for design systems, interaction patterns, and the fulfillment of the user experience. Product is accountable for impact and business outcomes.

If you try to limit what people do, you create seams between teams. If someone in customer support wants to make a prototype, that’s great. If a designer wants to write code, that’s great. Include the right people, and don’t dilute the decision. It should be made in the name of the customer, not in the name of the stakeholders.

How do I get engineers to play jazz?

Ask what they’re worried about. On teams that resist, I think a lot of it is fear. If AI can write all of this code, what is my job? Will everyone else write code and leave me to clean it up? Will I become a full-time code reviewer who no longer a code creator?

Ground rules help. The one I like most: prototypes are for learning, and production software is for shipping. Someone shows a prototype to a VP, and the VP says it’s done, let’s ship it. If you agree up front to throw the prototype away and let engineers build the real thing the right way, they stop worrying about inheriting code that doesn’t fit their stack — they stop worrying about having to clean up someone else’s mess.

Instead, engineers can focus on working quickly with you and others to solve for the customer. They can focus more on what their code is actually mean to do (to create features customers love). Once engineers work this way, it can be intoxicating.

Stuck on a hard question you can’t take to your own team? Join the Top 1% Builder Club and bring it to office hours with me.

Join now 👉

What does progression look like if every PM works the same way?

An attendee asked this one live. It depends on whether the company gives ICs real decision rights. If every PM is expected to be a full-stack IC, those people need to be empowered to make decisions, check in code, move metrics, and set strategy. Most companies want the expectation without the empowerment.

The day before the workshop, someone wrote to me after moving from a manager role to an IC role. They have a set of pull requests ready to commit, nobody is reviewing them, and they don’t have approval rights on the repo, so the work is stuck. Help your leaders step back and look at what’s happening on the ground: what’s moving faster, what isn’t, and where you’re stepping on each other’s toes. Another attendee, who manages a large team, wrote that ICs are desperate to understand the larger company strategy, and that this leadership work isn’t going away. I agree.

Questions we didn’t get to

We ran out of time before these, and we’ll answer as many as we can next week. Look out for the email.

• How does AI change the decision between being a manager and being a high-agency IC?

• How do we use a competency gap to move up a level? Can we see an example of how levels work within a competency?

• If the most lovable product means bigger bets, how does that fit with the jazz band?

• How does this apply to businesses that deliver physical products, where prototyping isn’t nearly free?

• If building gets cheaper but customer learning still moves at human speed, does discovery become the real bottleneck?

• Has building actually gotten faster, when engineers report a 10 to 15% productivity gain?

Your workshop resources

My goal is to create the most valuable place for people who want to build remarkable products:

• Shape assessment: ravi-mehta.com/assessment. A 5-minute self-assessment across the 12 competencies, free, for anyone who contributes to product:

• Product Competency In-Depth Assessment and AI Skills (coming soon, for Club members): a 36-question deep dive on all 12 competencies, with AI skills for each one. Club members get it the day it ships.

• Free live 12-week series (fall 2026): https://luma.com/top-1-builder-series. One competency per week, starting Thursday, October 8. Free live this fall only. In 2027 the series is paywalled. The first session covers product definition and how PRDs and prototypes work together.

• Top 1% Builder on Substack: blog.ravi-mehta.com/subscribe. Free subscribers get my last 4 weeks of articles and the free live series. The Club adds the rest.

• Workshop replay: Watch on Zoom, password ?7kcy?tY. Free until 11:59 PM PDT on September 30, 2026, then open to Club members. Slides are for Club members.

Jump to a topic in the replay: the three claims at 5:43, building gets cheap at 10:30, the jazz band at 11:12, curation at 14:31, the 12 competencies at 16:49, the assessment at 34:17, strengths and gaps at 44:28, the live hot seat at 1:01:12, accountability at 1:08:03, latency at 1:13:38, engineers at 1:16:08, and team shapes at 1:22:17.

Your next steps

This week

1. Take the shape assessment. Mark up to 3 competencies where you outperform and up to 3 where you need focus.

2. Ask your manager or a trusted colleague to take it, and compare notes for 10 minutes before your next one-on-one.

3. Pick one strength and ask a peer and your manager what they see in it.

4. For each gap, decide whether to cover it with a teammate or invest in it. Don’t chase it.

5. Ask how long it would take to ship a button label change. If the answer is a month, find the step that adds the delay.

This month

• Join the free live series starting October 8, and attend the session for your sharpest competency.

• If you lead a team, put your team’s shapes side by side and look for where they bunch up and where the gaps are.

• Decide with your engineering partners where prototypes stop and production software starts, and write it down.

• When you hire, describe the shape you want, not only the job description.

What’s in the Club

The Top 1% Builder Club is designed to help you build products customers people love, remarkably.

Free for everyone

• My last 4 weeks of articles on Substack

• The 12-week Top 1% Builder Series (a deep dive on the 12 competencies) live attendance only. (Replays and decks sent to paid members.)

• The Product Competency Assessment and the fully updated Product Competency Toolkit

• Yesterday’s workshop replay until 11:59 PM PDT on September 30, 2026

Club members add

• The workshop replay and slides, after September 30

• Replays of every session in the live series, plus the hot seats

• Office hours with me, for your real product questions

• The Product Competency In-Depth Assessment and AI Skills: a 36-question deep dive on all 12 competencies, with AI skills for each one (coming soon)

• The 12-part course on demand (coming early 2027)

• Club perks, including course discounts, AI tools, and community (coming soon)

• The full archive: 100K+ words from 20+ years leading product at Facebook, TripAdvisor, Xbox, Microsoft, and Tinder and consulting with some of the most recognizable names in tech

A paid subscriber wrote: “It should be required reading for any product folks in the AI era.”

Why I priced it this way

Jeff Bezos has said he wanted there to be so much value in Amazon Prime that you’d feel it was irresponsible not to buy it. I want the Club to work the same way.

I put everything I could into it: the full archive, the course, office hours with me, the deep-dive assessment and AI skills, and a live series that’s free this fall so you can bring your team. I set the price so it’s accessible and sustainable, which lets me keep showing up for the product world I care about. My bar is simple. It should be some of the highest ROI you get on your own growth.

Two ways to join

• $25 a month. Everything in the Club. Cancel any time.

• $180 a year, about 5 months free compared with paying monthly. This price ends at 11:59 PM PDT on September 30, 2026. From October 1, the annual price is $250.

Ready to become a remarkable product builder?

Join now 👉

Try it risk-free. If the Club isn’t for you, email us within 30 days for a full refund. Wondering if you can expense it? Most likely. Substack gives you a receipt, and group subscriptions cover a whole team. If you’re bringing a team, reply to this email and we’ll help you choose the right option.

Founding membership with the AI Strategy Lab

For 20 people, the Club plus a workshop I first taught to product leaders in Berlin last week.

• $500 a year, 20 seats. It includes a full year of the Club. Enrollment is limited to 20 seats.

• Two live AI Strategy Lab workshops, 2 hours each, with me, starting early December.

• What you get: the Berlin frameworks on how customer expectations are shifting, your AI disruption risk, and the anatomy of a winning AI product. Plus the Lab workbook, my feedback on your strategy, and a 90-day plan.

• Why it exists: most organizations have lots of output and too little judgment in it. The question is shifting from “are people using AI?” to “are we building better products because of it?”

• Only offered here. When it ships in 2027, the Lab is expected to cost $3,000 or more. Founding members get a full refund any time before the first Lab.

You got this

The PM I spoke with yesterday was asking whether there’s still a career here. Underneath, I think she was asking whether being good at building products still counts.

It does. The market is hard right now. Companies are downsizing, and the loudest voices keep telling you the ground is gone. But AI didn’t take the PM job. It exposed the one we should have been doing all along: the judgment, the craft, and the empathy for the person on the other side of the screen. That’s what turns a great product builder into a remarkable one, and a product that ships fast into one that customers love.

Reply with what you’re building, or the question you’re carrying. I read what comes in.

Ready to build products customers love the most? Join Now.

Join now 👉

Ravi

P.S. Thank you to everyone who shared what they’re building and asked hard questions. Your ideas made the workshop better, and I quoted several of them above. Thank you also to the product leader who sat in the hot seat. If you’ve been quietly wondering, “Do my hard-won skills still matter?” you’re not alone, and they do. Take the 5-minute assessment, and bring your shape to the first live session on October 8. Reply to this email with questions, or join the conversation in the Top 1% Builder community.

About the author. Hi, I’m Ravi 👋. I've hired 100+ PMs, led product at Facebook, TripAdvisor, Tinder, and Microsoft, taught tens of thousands at Reforge, and advised some of the most recognizable names in tech. Thanks for being here.

His drip paintings had made him one of the most famous artists in America. Pollock had accomplished something extraordinarily rare: critical and commercial success achieved in his lifetime. (Later, we’ll examine why it’s so hard for an innovative artist to achieve commercial success in their lifetime.)

Then, Pollock changed direction.

He began making what became known as his Black Pourings. They were darker and more figurative than the colorful, chaotic paintings that had made him famous. Pollock confidently entered a new creative chapter, but his audience was l…

Read more

As teams climb the AI learning curve, they’re accelerating, but new failure modes are also emerging. AI lets anyone on a product team build almost anything. That doesn’t make the team obsolete. It makes the team more important.

Matthew learned this the hard way — in a room with fifteen people.

He was helping a large nonprofit replace its membership and fundraising platform. In two days, with help from AI, he had produced a North Star document and a rough wireframe. Eighteen months earlier, the same work would have taken a designer and at least a week.

The sp…

Read more

(Years later, in another case of magical serendipity, I ended up working for J Allard — creator of that Lemonade Stand game and head of the initiative to launch the first Xbox.)

So other than justifying my gray hair, what’s my point? Though I never ended up writing code professionally, my technical experience has always been helpful as a product builder. It helped me bridge two worlds.

Today, like so many others, I’ve been experiencing a newfound joy in making software. For the first time, AI coding tools enable anyone to …

Read more

Do I still have a job?

Here’s my answer, the one I’d give any product builder reading this:

AI didn’t take the PM job. It exposed the one we should have been doing all along.

The hard part of product management was never the paperwork. It was understanding what customers actually want, craf…

Read more

Around the same time, the manosphere’s obsession with male beauty made looksmaxxing the word of the day.

Thus, “tokenmaxxing” was born — and it’s become the AI skeptic’s shorthand for “I told you so.” The party line: productivity gains aren’t showing up in the macro numbers, yet companies are burning millions on AI spend. Business Insider reported that Uber blew through its entire annual AI budget in ju…

Read more

Teams that hadn’t touched AI in early 2024 now use it every day to generate ideas, write PRDs, analyze research, and build working prototypes. I see it in my own work. I went from using AI a few times a day to running three or four threads in parallel, all day long.

Output is up. Velocity is up. Everything looks faster.

And yet, when I sit with product teams — startups, scale-ups, and a few household names — I keep seeing the same picture. Clogged GitHub repos. Stacks of unread AI-generated PRDs. Prototypes in various states of completion. Features abandoned by ambitious individuals who never got the buy-in to get them across the finish line.

We gained something powerful. We also lost something important.

AI has turned the most ambitious people on every team into 10x versions of themselves. But it has also made it harder than ever for them to play together.

Everyone’s doing context engineering in their own silo — generating work that’s overlapping, repetiti…

Read more

AI-powered prototyping has rewritten how we build. The old product development lifecycle has given way to one where working software shows up at every stage of discovery. Teams move faster. Ideas get tested earlier. Engineers stop building features no one wants.

But prototyping is not a cure-all. As teams adopt it, two new failure modes are emerging — both undermining the very promise prototyping was supposed to deliver:

1. The polishing trap: teams spend an inordinate amount of time perfecting prototypes, trying to close the gap between what they’re prototyping and the production software they’ll eventually put in front of customers. They agonize over pixel-perfect spacing. They iterate on details no customer…

Read more

On Artificial Analysis’s intelligence ranking, OpenAI’s frontier models still beat Claude. They’re ahead by the benchmarks that have defined this industry for three years.

On Ramp’s AI Index for May 2026, Anthropic just overtook OpenAI in enterprise spending.

Read more

We’ve all been in some version of this meeting. A 60-minute UX review is running late. The team is poring over different approaches to the same problem. Each approach is plausible. None are provable. The meeting ends in frustration, without a decision.

In a previous post, You might be doing user research wrong, I argued that user research questions come in three flavors:

• Recall questions: What did you do?

• Imagination questions: What would you do?

• Narration questions: What are you doing?

User research is trying to predict the future: what will customers do when we put our shiny new product in front of them? The temptation is to just ask them — what would you do? But imagination questions are the least reliable of the three. Users predict their own behavior about as poorly as we predict it for them.

Good product sense is one solution. It’s a kind of precognition that draws on pattern recognition from years of watching real users. But precognition has a failure mode. When the question is hard — no clear right answer, no obvious precedent, no behavior to recall — product sense devolves into guessing.

I had this type of question recently while working with a startup building an AI-powered news reader. The company has a cold start problem: they can generate great recommendations once they know what users care about — but they need to learn that during onboarding.

They had a taxonomy of over fifty topics across eight categories, and we were caught in a classic debate. Should we collapse topics into categories that users drill into, or show one long scrolling list? Both approaches were defensible. Static wireframes couldn’t tell us which would feel right. We were stuck in our own version of Minority Report — competing visions of the future, no way to verify which would play out.

In the past, we’d have disagreed, tossed a coin, and committed. That’s a guess in disguise. Now, in minutes, we can build prototypes of multiple variants. We can test them ourselves. We can put them in front of customers.

Dazl is one of my favorite new tools for exactly this. It’s purpose-built for product managers — designed to be a teammate across the full product lifecycle, from a first prompt to a handoff-ready prototype. Instead of bouncing between separate tools for PRDs, design, and prototyping, you stay in one place and keep everything in sync.

I gave Dazl a short prompt. Its plan mode generated an editable PRD — feature spec, layout, structure — that I could iterate on before any building started. Within minutes, both versions of the onboarding flow were live: a collapsible topic tree and a long scrolling list. The conversation leveled up from guessing to a discussion grounded in working software — software we could put in front of anyone on the team, or in front of customers.

Suddenly we weren’t guessing; we were validating.

That first prototype was just a starting point. As soon as we wanted something more sophisticated — a real design system, a brand voice, a second variant to compare against — the prototype needed more context than a single prompt could carry. This is where Dazl’s Documents feature earns its keep. You can bring in PRDs, brand guides, design systems, even competitor screenshots as first-class context the AI references while it builds.

In our case, the PRD already lived in Notion. Rather than copy-paste it into a prompt, I connected Dazl to Notion through its MCP integration and pulled the spec in live, so Dazl was working from the actual source of truth, not a stale snapshot. One instruction — update the prototype to match this spec — was enough for Dazl to reconcile what we’d built with what the PRD called for. The second variant, the brand’s tone of voice, and the full design system all landed in a single pass. The prototype stopped looking like a generic AI-generated screen and started looking like the product.

Skills are the other lever that matters as prototypes grow. They’re reusable mini-tools you define once and apply across the whole prototype. The brand guide called for witty, on-brand copy, so instead of hand-editing every headline and button label, we built a witty copy skill once and ran it across all the topics and categories in a single prompt. Once a skill exists, you can pull it whenever you need it instead of re-prompting the same intent over and over.

And then something better happened. While clicking through both variants on mobile, someone noticed neither was using horizontal space well. They suggested a third option: pills. Compact, tappable tags grouped under each category. We added it. Three variants, side by side.

Nobody had wireframed the pill version. It hadn’t appeared in the spec. It emerged from interacting with the first two. The act of building generated an option that no amount of arguing would have surfaced.

This is what painters have always known. They don’t compose in their heads. They sketch — fast, cheap, disposable — to find what works through doing rather than imagining. Sketching is how composition reveals itself.

Product builders haven’t had this. We’ve had specs, which are abstract. We’ve had static designs, which miss interaction. We’ve had MVPs, which are often neither minimal nor viable. So we’ve defaulted to talking (guessing) about what we’d build instead of building to find out.

AI has changed the math. AI prototyping lets us sketch with software. Building is finally cheap enough to use as a thinking tool.

One more thing made the whole loop feel sustainable: Dazl runs in both directions. Once the PRD was loaded as a Document, I could also ask Dazl to update the spec to match the prototype — pulling the new pills variant, the updated copy, and the latest UX details back into the PRD. The spec stopped being a snapshot from week one and started behaving like a living document that tracked what we were actually building.

The newsreader team picked the collapsible version. Sketching told us what we couldn’t have known otherwise: the expanded list felt overwhelming. The pill version was clever on desktop but no better than the long list on mobile. The exercise took less time than the debate would have. And because the variants were real working software, we could publish them and put them in front of users to measure which UI people preferred, which led to more topics selected, and which felt least overwhelming — turning a UX debate into a test we could actually run.

If you’ve prototyped before, you’ve felt this shift. If you haven’t, here’s the move: next time your team is locked in a UX debate, stop arguing and build both. Dazl is a great tool for this. Most AI tools work outside your process, making it difficult to keep everything aligned. Dazl is spec-driven, so as your PRD evolves the prototype stays true to it, and as the prototype evolves the PRD can be brought back in line. Its planning mode will feel familiar to any PM who’s written a PRD, Documents keep your real artifacts in the loop, and Skills let you turn one-off prompts into reusable levers. Engineers will appreciate the underlying code quality too — a clean component hierarchy and stable structure as the prototype grows make the eventual handoff to production smoother.

The goal isn’t a shippable prototype. It’s a better way to decide — turning guesswork into validation.

We used to build to deliver. Now we can build to discover, too.

Thanks to Dazl for sponsoring this post. Try Dazl the next time your team is locked in a UX debate.

And if you want to go deeper, my AI Prototyping course with Reforge starts April 24th.

Read more

Over my career consulting with dozens of companies on product strategy, I’ve found that the focus on differentiation is more destructive to clear strategic thinking than any other concept. The problem isn’t that differentiation is wrong — it’s that it’s incomplete. To understand why, we need to go back to first principles.

The commodity-monopoly spectrum

The concept of strategic differentiation comes from a first principle about pricing power.

Consider two types of products:

1. A complete commodity — like bananas. Every product is identical. Customers don’t care which one they choose. The market sets the price, not the company.

2. A complete monopoly — like the NFL. The product is the only one of its kind. The company has complete control over price & supply.

These two extremes behave very differently. Commodity sellers have to match the market price or lose share to a cheaper provider selling the same thing. Monopolies can lower prices to increase demand or raise prices to pad profits. They’re in control. And we know from NFL ticket prices which option monopoly companies choose — they’re much more in the business of maximizing profits than maximizing demand.

Most companies don’t exist at either extreme. In a capitalist economy, total monopolies get regulated or assailed by competition that steals away their monopoly power. And commodity sellers band together to reclaim pricing control — this is why OPEC exists.

How “differentiation” becomes a trap

So competitive differentiation comes from this fundamental strategic principle: commodity products are all the same as other products in the market; monopoly products are unique. As shorthand, we use terms like “competitive differentiation” or “unique selling proposition” to highlight that there’s value in being unique.

But here’s the nuance that gets lost: being unique only matters if customers in your market want the unique thing you’re selling. Uniqueness on its own is not a virtue. In fact, uniqueness for the sake of uniqueness can undermine your entire strategy because it conflates being different with being better.

On the flip side, sameness can be a virtue. A product that closely resembles another product with strong product-market fit benefits from selling into a market that already wants what it has. In a pre-product-market-fit company, the similarity of your product to others carries a lot more weight than differences customers may not want.

That doesn’t mean your product can be identical to the competition. All things being equal, customers choose the product they’ve heard of, the product their friends use, the product from an established company with a track record.

So you need something to break through the noise. But what? Let’s look at two markets that tell very different stories about what that “something” actually is.

Two markets, two lessons

Uber vs. Lyft: Advantage through network effects

In the ride-sharing market, Uber and Lyft are nearly identical products. Uber won not because it was simply different, but because it had inherent advantages. As the network of drivers grew, that created a compounding advantage: better prices and faster service. Yes, you could call better prices and faster service “different” — but the important point is that those differences confer an advantage — one that compounds over time, making it harder and harder for anyone to compete.

Tidal vs. Spotify: Different ≠ better

In the early days of music streaming, Tidal had genuinely interesting strategic differences. Founded by music industry veterans, it offered a library of music unavailable on Spotify and the ability to stream CD-quality audio. Tidal was meaningfully different.

But Spotify had an advantage. With its smaller library and less focus on audio fidelity, Spotify could do a better job actually streaming songs to customers. Songs started faster. Fewer cutouts. Fewer buffering issues. It worked on connections of varying quality.

On paper, Spotify was subpar compared to Tidal — a smaller library, lower audio quality. But they had an advantage: more reliable music streaming. At the end of the day, listeners want to enjoy music uninterrupted more than they care about exclusive tracks they may never search for.

From differentiation to advantage

The next time you’re in a heated strategic conversation, pay attention.

If “competitive differentiation” or “unique selling proposition” are taking up a lot of airtime, notice where the focus lands. These terms pull your attention toward what’s different — not what’s better.

Instead, spotlight the term competitive advantage. Ask:

• What advantages do we have relative to others in the market?

• How can we turn those advantages into a product that’s better for customers?

When you focus on advantages instead of differences, you realize the goal isn’t uniqueness. It’s competitiveness.

The most successful companies — the ones that are effectively monopolies or near-monopolies — didn’t get there because they were different from everyone else. They got there because they had the biggest advantage, and that advantage compounded over time.

Read more

We took a three-step checkout flow for a weight loss medication program and replaced it with a twenty-five-step intake. Medical history. Lifestyle questions. Weight loss goals. Personalized projections. The works.

Conversion jumped 40%.

Not despite the added steps. Because of them.

The step-to-step completion rate is north of 99%. Each step fosters their confidence. By the time they reach checkout, they are ready. Confident. The decision feels right.

This flies in the face of conventional wisdom. We’ve been trained to believe that every form field is friction, every additional screen is a drop-off risk. Remove steps. Reduce friction. Get out of the user’s way.

But that advice is incomplete. And following it blindly can cost y…

Read more

Tim invited me to read an early copy, and I was struck by how clearly he’s distilled years of hard-won lessons into a coherent framework. His Progress Wheel is the best unified theory I’ve found for how all the pieces fit together—defining the right strategy, setting meaningful goals, and reducing uncertainty through discovery. It captures what I’ve seen work with high-performing teams: ruthless focus on what matters, not just what looks impressive. If you’re tired of roadmaps that are really just to-do lists, check out Real Progress.

Check out Real Progress by Tim Herbig

Read more

The prototype we’ll build: a music discovery timeline showing how genres evolved from their earliest days. It has good typography, actual album information, real cover art from Spotify, and smooth animations. The kind of prototype you’d put in front of customers, not a wireframe you’d apologize for.

That used to require days or weeks with a full team. Now it takes 30 minutes and a little bit of design thinking.

We’ll cover three things: how to rapidly wireframe your ideas, how to generate realistic data that brings those ideas to life, and how Figma Make combines them into something that feels real.

This post is brought to you by Figma Make.

Figma Make transforms your ideas into interactive prototypes in minutes—no coding required. Start from your existing Figma designs, bring in realistic data, and iterate through conversation. Try Figma Make free and see how fast you can go from blank canvas to customer-ready prototype.

Would you hire an architect who couldn’t draw blueprints?

Imagine you’re about to remodel your house. Your architect has been working diligently and she’s ready to share her plans. You sit down, and she hands you… a Word doc?!

“Trust me, it’s going to be great.”

Would you write the check? Of course not. Architecture is a visual medium. You need to see the structure, the proportions, how spaces connect. Words aren’t enough. You need blueprints.

Digital products work the same way. They’re visual and interactive. You can’t fully communicate a product idea through written specs alone.

For years, I’ve encouraged every PM I’ve worked with to learn wireframing. User experience design is an essential PM competency, not just the designer’s job. As I wrote in How To Become a Peak Product Manager:

The best PMs don’t just describe customer needs, they work with designers to translate those needs into easy-to-use experiences.

Here’s why this matters. When you write “the user taps the album cover and sees track details,” everyone pictures something different. Does a drawer slide up? Does the whole screen transition to a new view? The right answer depends on the user’s intent and the workflow you’re building.

You can’t leave those decisions to chance.

Instead, when you show the interaction visually, everyone sees the same thing. That’s what blueprints do.

Wireframes → a better way to prompt

Most people prompt AI design tools with words. But AI has the same problem your team does: words aren’t specific enough. Software is visual. Visual prompts work better.

Wireframes aren’t just a bridge between product and design anymore. They’re the blueprints that guide your whole team—humans and AI.

From blank canvas to beautiful prototype

Here’s exactly how I went from blank Figma page to working prototype. The process is surprisingly simple once you understand the pieces.

👋 Watch the video to follow along as I go through every step.

1. Start with the Simple Design System

I know, I know. The blank page is intimidating. What font will I use? Does that font size look nice? Should I bold the headlines? How do I create a button? Where do I find nice looking icons?

A few months ago, Figma introduced Simple Design System—available in every new file. Over 400 components, typography presets, colors, icons, and even full layouts.

To get started, I drop an iPhone 16 frame onto the page—again, an easy Figma preset that moves decisions off my plate.

2. Auto-layout everything

My next simplification: use Figma’s auto layout feature for everything. No manual positioning—Figma arranges things vertically or horizontally automatically. I even turn it on for the main iPhone 16 frame since mobile UI is just a vertical stack.

Using auto layout, I add some margins as well. I set 24 pixels for top and bottom margins, 16 pixels on the sides.

Pro tip: use multiples of 4 or 8 for spacing. It keeps everything aligned to a grid even if you don’t know design theory.

3. Rough out your first elements

Let’s design a feature to explore a genre’s history through a timeline of seminal albums.

I want a cover photo at the top. So I add a gray square as a placeholder. Figma Make will fill this in with a real image later.

Name the layer “cover photo.” That naming matters—you’ll see why.

I add a title: “Downtempo.” We’ll build our wireframe around this genre, then use Claude to generate real data—artist names, album titles, descriptions—to make the prototype feel authentic.

The default text looks terrible. Wrong size, wrong font. But this is where Figma’s Simple Design System saves us. It has pre-built typography options. I choose “Title Page” and suddenly the text looks professional. I didn’t make any design decisions—I just picked from styles that already work together.

I add a description below the title, and set the text to the “Body Base” style. It fits in seamlessly.

Next, I add tags for the genre’s most important artists using Figma’s Tag component. Set horizontal auto layout, enable wrapping. Done.

After about 10 minutes, I have a wireframe that looks pretty clean. But it’s still just boxes and placeholder copy.

4. Mix in realistic data

Great wireframes need great copy. The shapes show layout. The words explain the experience.

So far, the copy in my wireframe is “FPO”—for position only (fancy designer term!). I could spend hours researching Downtempo music—writing genre overviews, compiling artist lists, finding album details.

Or I could use AI, which excels at this kind of content generation. Here’s the prompt I gave Claude:

I’m interested in the history of downtempo music. Generate a JSON file that includes the genre name, a description, and an array of 15-20 milestone albums. For each album include: name, release date, artist, a 1-2 sentence description of why it was a milestone, and relevant tags.

Minutes later, I have what I need. Real artist names. Actual album titles. Release years. Well-written descriptions: “Mezzanine by Massive Attack (1998) - This dark, brooding album pushed trip-hop into more experimental territory with its heavy use of guitar samples and collaborative approach with vocalists like Horace Andy.”

This isn’t Lorem Ipsum. This is data that tells a story.

I asked for JSON because structured data is easier for AI tools to parse—important when we build our Figma Make prototype later.

But I’m missing something: album covers. I want real album art, not placeholder images. This is a little tricker for AI.

Claude won’t able to reliably look up album covers without a little help from a friend. I built an MCP server that fetches album covers from Spotify and Deezer. Took about 30 minutes in Claude Code (maybe a future post?). Now Claude can grab the real artwork for any album.

I ask Claude:

Add album covers to this dataset using the album-cover MCP server.

This will take some time. Let’s go back to Figma while Claude does its thing.

5. Finish the wireframe

I want each year to show its important albums. I layout the album UI: cover art, artist name, album name, description, and tags.

Every element is from the Simple Design System and auto layout makes it easy to get the UI laid out nicely. As needed, I pull over some copy from the JSON we generated to get a feeling for how it will look with real data.

In less than 20 minutes, the wireframe is done:

6. Send to Figma Make

Now, we’re ready to build the prototype. Right-click the design and select “Send to Figma Make.”

My prompt is dead simple:

Based on the attached design, build a feature that shows the timeline of a music genre. Use this data to build the prototype:

I paste in the JSON.

Figma Make reads my wireframe—the structure, the layer names, the semantic organization—and generates a working prototype. Real album covers appear in the right places. Artist tags populate at the top. The timeline structures itself by year with albums underneath.

Figma Make understands that the wireframe provides structure and the JSON provides content. It even replaces my placeholder hero image with an actual photo.

No code written. No manual placement of 20 album covers. Just a wireframe, a data file, and AI doing the rest.

7. Iterate with taste

The first version works, but I want to refine it:

Make the cover images larger and add a play button for each album.

Figma Make updates the prototype. Bigger album covers. Play buttons appear on hover with a nice animation.

Let’s change to a dark theme with full rounded buttons. Use this green as the primary color: #1ed760. Use dark gray for the cards #1f1f1f and even darker gray for the background.

The entire design transforms. It starts looking like Spotify. Professional. Intentional.

Add a cool animation to the year as a user scrolls down.

As I scroll down the timeline, each year animates in with a subtle effect. The albums fade in as they enter the viewport.

Each time, Figma Make doesn’t just do what I ask—it adds taste. Hover animations. Subtle fades. Professional polish.

Making the most of Figma Make

Most AI design tools ask you to describe what you want in words. Figma Make flips this: start with a visual, then AI builds from it.

After building this prototype, a few things stood out:

1. First pixel to working prototype in one tool. You wireframe in Figma, generate the prototype in Figma, iterate in Figma. No export/import dance. The entire workflow stays in the canvas where you’re already thinking spatially.

2. Simple Design System removes guesswork. You focus on visual thinking—layout, hierarchy, user flow—not all the details. The components have proper padding, correct spacing grids, typography that scales. You snap together pieces that work.

3. Semantic understanding beats screenshots. Sure, you can paste screenshots into any AI prototyping tool. Figma Make reads your actual layers, components, and structure. Screenshot tools see pixels. Figma Make sees meaning.

4. Built-in taste. Good spacing defaults. Typography that looks right. Animations that feel smooth. You don’t need design expertise to ship something professional.

The result? I went from idea to customer-ready prototype in just 30 minutes.

Better prototypes = better signal

Design-driven prototyping enables teams to accelerate the time from initial hypothesis to initial test. More importantly, it makes that test more reliable by helping teams create better prototypes.

Bad prototypes break the “suspension of disbelief.” Customers have to imagine what the product will eventually look like when it’s “real.” Users act like they’re using the product instead of actually using it. That creates noise.

Great prototypes maintain the suspension of disbelief. They feel real, so users forget they’re testing. That creates signal.

Over to you…

You don’t need years of design training to create something worthwhile.

Next time you have a product idea, don’t write a spec. Open Figma. Drop in a frame. Add simple components. Sketch the structure—what goes where, how it flows.

Then send it to Figma Make and watch it transform into a working prototype. Put it in front of customers. That’s real signal—signal that helps you make better decisions.

With AI, visual thinking is your new superpower.

This post is brought to you by Figma Make.

Figma Make transforms your ideas into interactive prototypes in minutes—no coding required. Start from your existing Figma designs, bring in realistic data, and iterate through conversation. Try Figma Make free and see how fast you can go from blank canvas to customer-ready prototype.

Read more

In “Founder mode for the rest of us”, I discussed the idea that founder mode isn’t reserved for founders. Every great leader I’ve worked with operates with the level of ownership, speed, decisiveness, and attention to detail that defines a good founder. Which means you’ll encounter these leaders throughout your career… and working with them requires a completely different approach.

High-performance leaders demand more than the standard playbook for “managing up”—they move faster, dive deeper into details, and expect you to operate with the same level of ownership they do. I…

Read more