A couple of weeks ago I launched an update to the Product Competency Toolkit, a system of 12 competencies that empower product managers, product leaders, engineers, designers, founders, and builders of all kinds to create remarkable products.
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.
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.
Super helpful!
Thanks Ravi. One thing that helps with "too much context" -> keeping an explicit "not decided yet" list next to the prototype, so the agent doesn't fill the gaps with confident guesses.
Do you have something like that in your product definition template?