productcreator.ai
A competency playbook for the era of the product creator.
Abstract
The Product Creator Playbook defines 31 competencies across three layers that capture what it means to build products in the creator era. It provides a shared language for assessing individual capability, diagnosing organizational maturity, and charting the transformation from project teams to product teams to empowered creator teams. Each competency is measured on a six-level scale (0–5) that distinguishes doing the work well from helping others grow and from shaping organizational practice.
The product industry is in the middle of a transformation that most competency playbooks haven’t caught up to. For years, the dominant model was resources: people staffed onto projects, measured by output, managed through handoffs and Gantt charts. Then came the shift to teams— cross-functional squads with shared ownership, empowered to solve problems rather than execute specs.
Now we’re entering the era of the product creator. Marty Cagan and Bob Baxley at SVPG have articulated what this means: product managers, designers, and engineers who are individually strong enough and cross-disciplinarily fluent enough to co-create products that customers love. Not feature factories. Not ticket-takers. Creators.
Existing competency playbooks — whether they come from HR departments, PM tool vendors, or engineering career ladders — don’t capture what matters in this new era. They either focus on a single discipline, reduce competency to seniority, or list skills without a meaningful progression model. None of them ask the essential question: can this person operate as a product creator, not just a practitioner?
The Product Creator Playbook is built to answer that question. It draws heavily on the intellectual foundation laid by SVPG — particularly the concepts of empowered teams, continuous discovery, and the missionary vs. mercenary distinction — and extends it into a structured, measurable playbook that organizations can use for assessment, development, and transformation.
The playbook organizes 31 competencies into three layers. This structure is deliberate: it forces the creator-era question first, preserves discipline depth second, and separates people leadership from product creation entirely.
Layer 1
Creator Core
The competencies every product creator must have, regardless of discipline. Customer understanding, continuous discovery, product vision, strategy, craft, creative courage, AI fluency, enabling technology insight, cross-discipline fluency, and outcome accountability.
Layer 2
Discipline Depth
Product
4 competencies — value & viability
Design
5 competencies — usability & experience
Technology
5 competencies — feasibility & architecture
Layer 3
Leadership
For those leading product organizations. Empowerment, org design, people leadership, coaching, culture building, missionary alignment, and talent strategy.
Why this structure matters: Layer 1 forces the question that defines the creator era — can every member of the product team, regardless of discipline, operate as a genuine creator? Layer 2 preserves the reality that deep discipline expertise still matters. Layer 3 separates the distinct challenge of leading product organizations from the challenge of building products.
Every competency is measured on a six-level scale (0–5). The levels are not seniority bands — they describe a progression from no awareness to organizational impact.
Not Aware
Has not encountered this concept or practice. No exposure, no recognition of its importance in product work.
Understanding
You know what good looks like. You can recognize the competency in action and appreciate its value, even if you haven't practiced it yourself.
Learning
You're actively building the skill. You participate, experiment, and improve with guidance. You're developing the habit but not yet independent.
Applying
You practice the competency independently and effectively. Your work consistently reflects this capability. This is the level of a strong individual contributor.
Leading
You help others grow in this competency. You coach, mentor, establish team practices, and raise the bar. This is not "does it very well" — it's "makes others better at it."
Shaping
You define how the organization practices this competency. You establish standards, build programs, and shape culture at scale. This is not exceptional individual performance — it's organizational impact.
Critical distinctions
These 10 competencies apply to every product creator — product managers, designers, and engineers alike. They define what it means to operate as a creator rather than a practitioner.
Develops deep understanding of customers through direct exposure to their needs, behaviors, and context.
This is about going beyond second-hand reports and dashboards. Strong product creators talk to real customers regularly, observe them in their environment, and can describe their workflows, frustrations, and goals from memory. A designer who watches users struggle with a competitor, an engineer who joins a customer visit and sees the messy reality of how the product is used, a PM who knows their customers by name — all of these build the empathy that separates creators from feature factories.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Aware of the value of customer understanding; recognizes good practices.
You know that talking to customers matters, and you can tell when a team is making assumptions vs. working from real insight. You haven't yet run research yourself, but you appreciate its value and can point to examples of teams that do it well.
Learning
Participates in customer interactions; synthesizes input with help.
You've joined customer interviews, support calls, or usability sessions. You can take notes and identify themes with some guidance. You're building the habit of asking "how do we know this?" when the team discusses customer needs.
Applying
Leads or independently conducts customer research; extracts actionable insights.
You plan and run your own customer interviews, observation sessions, or research activities appropriate to your discipline. You synthesize findings into actionable insights and share them with the team. Your work is regularly informed by direct customer contact.
Leading
Embeds customer learning into team practice; mentors others in building customer empathy.
You've made customer contact a team habit, not just your own. Everyone on the team — engineers, designers, PMs — participates in customer conversations. You coach others on research techniques and ensure customer insights drive decisions, not just validate them.
Shaping
Creates scalable programs for customer engagement across the organization.
You've built customer advisory boards, research panels, or feedback loops that work across multiple teams. You influence how the entire organization thinks about customers and ensure customer voice is embedded in strategic decisions at every level.
Validates customer problems and potential solutions early using structured discovery techniques — interviews, experiments, prototypes, and opportunity-solution trees.
Discovery is the discipline of reducing risk before committing significant effort. It applies to every creator: a PM testing whether customers actually have the problem, a designer prototyping three approaches to see which one clicks, an engineer spiking a technical solution to see if it can perform at scale. Good discovery uses lightweight experiments and structured playbooks to make better bets. The key is making it continuous — not a phase that happens before "real work," but an ongoing practice woven into every week.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Aware of discovery tools and playbooks; recognizes when ideas are unvalidated.
You know what discovery is and why it matters. You can spot when a team is jumping straight to building without validating assumptions. You've read about playbooks like opportunity-solution trees or design sprints but haven't applied them yet.
Learning
Supports discovery work; helps structure assumptions and tests.
You've participated in discovery activities — helping design a prototype test, writing interview scripts, or running a technical spike to test feasibility. With guidance, you can frame a hypothesis and identify what you'd need to learn before committing to a solution.
Applying
Plans and leads discovery activities; iterates based on learnings.
You independently plan discovery work within your discipline: identifying assumptions, designing experiments, running tests, and synthesizing learnings. You know when to use which technique — when a quick conversation is enough vs. when you need a prototype test vs. when you need data analysis — and you iterate based on what you learn rather than plowing ahead.
Leading
Coaches the team on continuous discovery; establishes it as a weekly habit.
You've made discovery a continuous practice, not a phase. Your team runs weekly experiments, interviews, or spikes as a habit. You coach others on how to frame hypotheses, design lean tests, and know when they've learned enough to move forward. Engineers and designers on your team contribute to discovery, not just PMs.
Shaping
Defines org-wide discovery practices; challenges build-first culture.
You've changed how the organization approaches new ideas. Teams across the company use discovery practices. You've challenged the "just build it" culture and replaced it with a structured approach to de-risking ideas before committing resources. Discovery is muscle memory, not overhead.
Shapes and communicates a compelling long-term direction for the product that inspires the team and filters decisions.
Vision is the north star that keeps everyone rowing in the same direction. It answers: where are we going and why does it matter? A strong product vision is aspirational yet grounded, inspiring the team while providing a practical filter for what to build and what to say no to. Every creator contributes to vision — engineers who see technical possibilities, designers who imagine future experiences, PMs who connect market opportunity to customer need. The best visions emerge from the intersection of all three perspectives.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows what product vision is and how it guides decisions.
You can articulate what a product vision is and why teams need one. You understand the difference between vision, strategy, and roadmap. You can recognize when a team lacks direction due to a missing or unclear vision.
Learning
Connects team work to the broader vision; starts developing a point of view.
You reference the product vision when explaining priorities. You're starting to develop your own point of view about where your area of the product should go and can articulate it in discussions. You contribute insights from your discipline that sharpen the vision.
Applying
Develops vision for a product or domain; rallies others around it.
You've created a compelling vision for your product or domain that the team buys into. You use it to guide decisions and communicate direction to stakeholders. People on your team can explain the vision and how their work connects to it.
Leading
Aligns multiple teams to a shared vision; inspires genuine commitment.
You shape vision across multiple teams or a product area. You bring people together around a shared direction, resolve competing priorities through the lens of the vision, and inspire genuine commitment — not just compliance. Your vision integrates technical possibility, design ambition, and market opportunity.
Shaping
Defines vision across product lines; shapes company direction.
You define product vision at the company level, connecting multiple product lines into a coherent narrative. Your vision influences company strategy, investor communication, and organizational structure. You shape how the company thinks about its future.
Generates strategic insight from the intersection of enabling technology, customer pain, and market dynamics — then focuses and sequences the critical problems to solve.
Strategy is not a translation exercise that turns vision into a roadmap. It is the act of seeing something others miss: a technology that just crossed from "interesting" to "enabling," a customer pain point that incumbents have normalized, a market shift that creates a window of opportunity. Good strategy then requires the discipline of focus — choosing the one or two problems that matter most right now and sequencing them so each win creates leverage for the next. This is where Uber-like insights come from: someone saw that GPS + smartphones + payments made ride-hailing possible and focused relentlessly on solving the supply problem first. Strategy is the hardest competency because it requires both creative insight and ruthless prioritization.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands that strategy involves choices and tradeoffs, not just plans.
You grasp the difference between strategy and a feature list. You understand that strategy requires saying no to good ideas in order to focus on great ones. You can follow how strategic priorities translate into what the team works on.
Learning
Identifies strategic inputs; starts connecting technology trends to customer problems.
You actively scan for strategic inputs: new technologies, competitive moves, emerging customer behaviors. You're learning to connect these dots — seeing how a technology shift might create a new product opportunity or how a market change might make an existing approach obsolete. You participate in strategy discussions with useful observations.
Applying
Develops focused strategy for a product area; sequences problems to create leverage.
You own a clear strategy for your area that reflects genuine insight, not just incremental improvement. You can articulate what you're betting on and why, what you're deliberately not doing, and how your sequence of moves creates compounding advantage. Your strategy connects enabling technology, customer need, and business model in a way that feels obvious in hindsight but wasn't before you articulated it.
Leading
Generates strategic insight across multiple domains; aligns a portfolio of bets.
You see strategic opportunities that span multiple teams or product areas. You help the organization focus its portfolio of bets, kill initiatives that no longer make strategic sense, and double down on ones showing signal. You connect technology platform investments to product-level differentiation and market timing.
Shaping
Drives company-level strategic shifts; identifies and acts on enabling technology inflections.
You identify strategic inflection points — technologies, market shifts, or regulatory changes — that create opportunities for transformative moves. You've driven company-level strategic pivots or expansions based on these insights. Your strategic thinking shapes board-level decisions and competitive positioning. You see the enabling technology and imagine the product that doesn't exist yet.
Obsesses over the quality of the customer experience — the details that separate products people tolerate from products people love.
Product craft is the relentless attention to what the customer actually experiences. For a designer, it's the micro-interaction that makes an action feel satisfying. For an engineer, it's the loading time that drops from 3 seconds to 300 milliseconds. For a PM, it's the onboarding flow that makes a new user productive in minutes instead of hours. Craft means caring about edge cases, error states, empty states, and the countless small moments that add up to a product experience. It's not about internal specs being clean — it's about the customer feeling like someone at this company actually gives a damn.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Recognizes well-crafted products and can articulate why they feel different.
You can tell when a product experience is well-crafted — and when it isn't. You notice details like confusing flows, slow responses, missing error states, or inconsistent behavior. You appreciate good craft but don't yet consistently apply that eye to your own work.
Learning
Starts applying craft to own work; learns to consider the full customer journey.
You're developing the habit of thinking beyond the happy path. You consider error states, loading states, and edge cases in your work. You're learning what "good enough" actually means in different contexts — when polish matters and when shipping fast matters more.
Applying
Drives quality through obsessive attention to the customer experience.
Your work consistently reflects care for the customer experience. You think about the full journey — not just the feature you're building, but how it connects to everything else the customer does. You catch quality issues early and you're the person on the team who says "wait, what happens when..." before it's too late.
Leading
Raises the craft bar for the team; establishes quality standards.
You've raised the quality bar for your team. You review work through the lens of customer experience, share patterns and anti-patterns, and have established standards that the team follows. Products your team ships are noticeably better-crafted than the industry average.
Shaping
Defines and evangelizes craft standards that become organizational culture.
You've defined product quality standards that are used across the organization — design principles, quality checklists, review processes, or experience benchmarks. You've elevated the craft level of the entire product organization. People join the company partly because of the craft culture you've built.
Willingness to pursue non-obvious, transformative ideas rather than consensus-safe choices.
Most product work gravitates toward the safe center: incremental improvements, features competitors already have, ideas that survive committee review because nobody objects. Creative courage is the willingness to champion an idea that makes people uncomfortable precisely because it challenges conventional thinking. It's not about being contrarian for its own sake — it's about having the conviction to pursue a genuinely better approach when the evidence supports it, even when the organization resists. The designer who proposes removing half the interface instead of adding to it. The engineer who argues for rewriting the system when everyone else wants to patch. The PM who kills a popular feature because it distracts from what matters. These are acts of creative courage.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Recognizes the difference between consensus-safe and genuinely bold product choices.
You can identify when a team is converging on a safe-but-mediocre option because nobody wants to argue. You understand that breakthrough products come from non-obvious bets, and you appreciate examples of creative courage even if you haven't practiced it yourself.
Learning
Voices unconventional ideas in team settings; starts developing conviction in the face of skepticism.
You're learning to push back when the team settles for "good enough" too quickly. You propose ideas that go beyond the obvious, even when they make you uncomfortable. You sometimes back down too fast when challenged, but you're building the muscle of holding a position and explaining why.
Applying
Champions non-obvious approaches; demonstrates the courage to kill safe-but-mediocre work.
You regularly advocate for approaches that break from convention when you believe they're better for the customer. You've killed or significantly redirected your own work when you realized a bolder approach was right. You frame unconventional ideas with evidence and invite productive debate rather than just asserting opinions.
Leading
Creates safety for others to take creative risks; protects bold ideas from organizational antibodies.
You actively protect non-obvious ideas from being killed by organizational inertia or politics. You've created an environment where team members feel safe proposing radical approaches. You recognize and celebrate creative courage in others. When a bold bet fails, you ensure the team learns from it rather than punishing the risk-taker.
Shaping
Builds organizational capacity for creative risk-taking; has a track record of transformative bets.
You've driven multiple non-obvious product decisions that created significant value — bets that most people initially questioned. You've established norms and structures that encourage creative risk-taking across the organization: innovation time, bet-sizing playbooks, retrospectives on missed opportunities. The organization's tolerance for creative risk is measurably higher because of your influence.
Understands AI capabilities and limitations deeply enough to design products that leverage AI as a fundamental building block, not just a feature.
AI fluency is not about being able to train models — it's about understanding what AI can and cannot do well enough to design products around it. This means knowing the difference between what LLMs are reliable at vs. where they hallucinate, understanding when a deterministic algorithm is better than a probabilistic model, and grasping concepts like prompt engineering, embeddings, fine-tuning, and retrieval-augmented generation at a product level. AI-native product thinking goes further: it's about imagining products that couldn't exist without AI, not just adding an AI chatbot to an existing product. A product creator with AI fluency looks at a customer workflow and asks "what if AI handled the 80% that's routine so humans could focus on the 20% that requires judgment?"
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows the basics of what AI can do; can distinguish hype from substance.
You understand core AI concepts at a high level — machine learning, LLMs, computer vision, etc. You can tell the difference between realistic AI applications and marketing hype. You know that AI outputs are probabilistic, not deterministic, and you understand why that matters for product design.
Learning
Uses AI tools in daily work; starts identifying AI-leveraged product opportunities.
You actively use AI tools (coding assistants, design tools, research tools) and understand their strengths and failure modes from direct experience. You're starting to identify opportunities where AI could fundamentally change a customer workflow, not just automate a small step. You can have useful conversations with ML engineers about feasibility.
Applying
Designs AI-leveraged features with appropriate guardrails; understands tradeoffs between AI approaches.
You design product features that leverage AI thoughtfully — with appropriate confidence thresholds, fallback behaviors, and human-in-the-loop patterns. You understand tradeoffs between approaches (rules vs. ML, fine-tuned vs. prompted, on-device vs. cloud) and make informed choices. You can write product specs for AI features that account for edge cases, bias risks, and graceful degradation.
Leading
Shapes AI product strategy for a product area; builds team capability in AI-native design.
You define how AI should be integrated across a product area — not as scattered features but as a coherent strategy. You help the team develop AI product intuition: when to use AI, when not to, how to evaluate AI feature performance, and how to design for the unique UX challenges of probabilistic systems. You stay current with AI capabilities and translate advances into product opportunities.
Shaping
Envisions AI-native products that couldn't exist without AI; reshapes how the organization thinks about AI.
You conceive products or product categories that are fundamentally AI-native — not existing products with AI bolted on, but new approaches to customer problems that only become possible with AI. You've shifted the organization from "where can we add AI?" to "what becomes possible now that AI can do X?" Your understanding of AI capabilities directly shapes company strategy and investment priorities.
Identifies when a technology crosses from "interesting" to "enabling" — seeing the iPhone and imagining Uber.
Every transformative product was built on a technology that most people dismissed, misunderstood, or hadn't noticed. Enabling Technology Insight is the ability to look at a new technology — a sensor, a protocol, an API, a cost curve crossing a threshold — and see the product it makes possible. This isn't about tracking every tech trend; it's about deeply understanding what technologies actually enable in terms of customer experience. When GPS moved from military to consumer devices, most people saw maps. Some people saw ride-hailing, fitness tracking, and location-based gaming. That's the difference. This competency matters for every creator: engineers see what's newly feasible, designers see what's newly experienceable, PMs see what's newly viable.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Follows technology trends; understands that technology shifts create product opportunities.
You keep up with technology news and can identify major trends. You understand the concept that new technologies enable new products, though you tend to evaluate technologies in isolation rather than imagining their product implications.
Learning
Connects specific technology changes to potential customer impact.
You're developing the habit of asking "what does this make possible?" when you encounter a new technology. You can identify a few examples of technology-enabled products and explain the connection. You're starting to evaluate technologies through the lens of customer problems, not just technical novelty.
Applying
Identifies enabling technologies for your product area; proposes products or features they unlock.
You actively scan for technologies that are crossing the "enabling" threshold for your domain. You've proposed features or product directions based on a technology becoming newly feasible, affordable, or reliable. For example, you saw that edge ML inference became fast enough to enable real-time on-device personalization and shaped your roadmap around it.
Leading
Connects technology inflections to strategic product moves; builds the team's tech-scanning capability.
You systematically track technology maturity curves relevant to your product area and connect inflection points to strategic opportunities. You help the team develop "enabling technology instinct" — the pattern recognition needed to see a technology shift and immediately imagine the product it enables. You've driven multiple product decisions based on this capability.
Shaping
Sees enabling technologies before peers; has driven company-level bets based on technology-product insight.
You've correctly identified one or more enabling technology shifts early and translated them into products or features that created significant value. Your insight shaped company strategy. You've built a systematic practice of technology scanning and product imagination that the organization relies on for strategic planning. People look to you to answer "what becomes possible next?"
Operates competently outside your primary discipline — a designer who reads code, an engineer who interviews customers, a PM who sketches interfaces.
The creator model collapses the walls between disciplines. This doesn't mean everyone does everything — specialization still matters. But the best product creators are fluent enough in adjacent disciplines to collaborate at a higher level, spot opportunities others miss, and fill gaps when needed. An engineer who understands design principles catches UX issues during code review, not after launch. A designer who can read code prototypes interactions instead of just drawing them. A PM who understands system architecture makes better tradeoff decisions. Cross-discipline fluency is the difference between throwing work over the wall and truly co-creating.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Appreciates what other disciplines contribute; aware of own knowledge gaps.
You understand what designers, engineers, and PMs each bring to the product process. You respect their expertise and recognize the limits of your own. You can follow conversations in other disciplines at a basic level but rarely contribute to them.
Learning
Actively learning fundamentals of adjacent disciplines; starts contributing outside primary role.
You're investing in learning beyond your discipline — a designer learning basic code concepts, an engineer reading about UX research methods, a PM understanding design principles. You occasionally contribute useful observations outside your primary area, and your cross-discipline curiosity makes you a better collaborator.
Applying
Contributes meaningfully in adjacent disciplines; fills gaps when the team needs it.
You're genuinely useful outside your primary discipline. You can sketch a wireframe if you're an engineer, write a basic query if you're a designer, or evaluate a system architecture diagram if you're a PM. You fill gaps when the team needs it and your cross-discipline contributions regularly improve the product.
Leading
Bridges disciplines fluently; enables higher-quality collaboration across the team.
You operate fluidly across discipline boundaries. You translate between technical, design, and business languages effortlessly. You spot opportunities for cross-discipline synergy that others miss and help the team collaborate at a level that wouldn't be possible without your bridging role. You encourage and model cross-discipline fluency in others.
Shaping
Embodies the creator model; builds organizational capability for cross-discipline work.
You're a role model for what cross-discipline fluency looks like. You've built training programs, pairing practices, or team structures that develop cross-discipline capability across the organization. Your work has measurably improved how disciplines collaborate, reducing handoff waste and increasing the quality of co-created solutions.
Defines, measures, and is accountable for outcomes throughout the product lifecycle — emphasizing speed of validated learning, not project management.
Outcome accountability merges the old concepts of "execution" and "delivery" into something more fundamental: taking ownership of results, not just activities. It's not about Gantt charts and status reports — it's about defining what success looks like before you build, measuring whether you achieved it after you ship, and learning as fast as possible in between. A product creator with strong outcome accountability ships an MVP in a week to learn, not a fully-specced feature in a quarter to check a box. They kill features that don't move metrics, even popular ones. They celebrate learning velocity, not lines of code or screens designed.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands that shipping is not the finish line and that outcomes matter more than output.
You know that launching a feature doesn't mean the job is done. You understand that real accountability means the thing you shipped actually solved the problem and moved the needle. You can distinguish between output metrics (features shipped) and outcome metrics (customer behavior changed).
Learning
Starts defining success criteria; tracks progress toward outcomes with guidance.
You're building the habit of defining what success looks like before starting work. You help set KPIs or success criteria, and you're learning to use lightweight methods to ship and learn quickly rather than over-planning. You track your velocity of validated learning, not just your velocity of delivery.
Applying
Owns outcomes end-to-end; ships fast to learn, iterates based on evidence.
You consistently define success metrics before building and review them after shipping. When something doesn't deliver expected impact, you investigate, iterate, or kill it. You optimize for learning speed — choosing the smallest thing you can ship that will teach you the most. Your team ships reliably and stakeholders trust your judgment on timelines and scope.
Leading
Holds the team accountable to outcomes; builds a culture of learning velocity.
You've created a team culture where outcomes matter more than output. The team celebrates learning — even from failures — and moves fast to validate or invalidate hypotheses. You coach others to define success criteria, ship lean, and kill work that isn't delivering. You stop low-impact work before it drains resources.
Shaping
Shifts the organization from output-focused to outcome-driven; defines how success is measured.
You've transformed how the organization thinks about accountability. Teams across the company measure success by customer and business outcomes, not by features shipped. You've influenced how leadership evaluates product teams, how incentives are structured, and how the organization balances speed-of-learning with quality-of-execution.
Four competencies for creators focused on value and viability risks. These define the depth expected of product managers and product leaders operating as creators.
Understands how the product fits into the broader business model, market dynamics, and unit economics.
Products exist within a business context. Business acumen means understanding revenue models, unit economics, competitive landscape, and how your product decisions affect the bottom line. It's not about being a finance expert — it's about making product decisions that are commercially sound and understanding the financial impact of your choices. A product creator with business acumen knows why a 2% improvement in activation is worth more than a new feature, and can explain it in terms the CFO respects.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Can describe how the business makes money and the basic market dynamics.
You understand your company's business model at a basic level — who pays, how pricing works, what the main revenue drivers are. You know enough to avoid product decisions that obviously conflict with business goals.
Learning
Connects product decisions to business impact; starts modeling tradeoffs.
You consider business implications when making product decisions. You're learning to think about unit economics, customer acquisition costs, and lifetime value. You can participate in business discussions and ask relevant questions about revenue impact and market positioning.
Applying
Makes tradeoffs with clear business context; models business cases for product decisions.
You factor business impact into every significant product decision. You understand your product's P&L contribution, can model the business case for new features or investments, and make tradeoffs between user experience and commercial goals thoughtfully. You speak the language of the business with credibility.
Leading
Shapes pricing, monetization, or growth strategies for the product area.
You actively shape the business model — proposing pricing changes, identifying monetization opportunities, or defining growth strategies. You work closely with finance and business teams as a peer, and your commercial instincts are trusted by leadership.
Shaping
Drives business model innovation; identifies new revenue streams or market expansions.
You've driven significant business model changes — new revenue streams, pricing innovations, or market expansions. You influence company-level financial strategy and are recognized as someone who bridges product and business thinking at the highest level.
Earns trust through evidence and demonstrated competence — evangelizes the product direction rather than managing expectations.
The old model of "stakeholder management" treated internal relationships as something to be managed — expectations set, updates sent, conflicts contained. The creator model demands something different: earning trust through evidence and demonstrated competence, then using that trust to evangelize bold product directions. You don't manage stakeholders — you convert them into believers by showing them compelling evidence, inviting them into discovery, and building a track record of being right about what customers need. When you say "we should do X," people listen not because you managed their expectations, but because you've earned credibility through repeated demonstration of good judgment.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows who key stakeholders are; understands the importance of credibility and trust.
You can identify who your stakeholders are and understand that trust is earned, not assumed. You know that surprises are bad and that different people need different types of evidence to be convinced.
Learning
Builds credibility through transparency and follow-through; starts sharing evidence proactively.
You share evidence of what you're learning — customer quotes, experiment results, usage data — rather than just presenting conclusions. You follow through on commitments and are building a reputation as someone who's reliable, transparent, and genuinely curious about what's true.
Applying
Evangelizes product direction with compelling evidence; converts skeptics through demonstrated results.
You anticipate concerns and address them with evidence. You invite stakeholders into discovery activities rather than presenting finished strategies. When you advocate for a direction, people find your argument compelling because it's grounded in customer evidence and business reasoning. You've earned enough trust that people give you the benefit of the doubt on close calls.
Leading
Builds coalitions of believers across the organization; influences executive decisions through evidence.
You navigate complex organizational landscapes by building genuine belief in the product direction. Senior leaders seek your input not because you "manage up" well, but because you consistently bring insight they can't get elsewhere. You resolve conflicts by returning to evidence and shared goals rather than political maneuvering.
Shaping
Sets the standard for evidence-based leadership; shapes how the organization builds trust and makes decisions.
You've established a culture where product decisions are evangelized through evidence, not sold through politics. You've improved how the organization handles alignment, built rituals for evidence-sharing, and created an environment where the best argument wins regardless of the seniority of the person making it.
Designs experiments, applies causal reasoning, and knows when quantitative vs. qualitative evidence is the right tool.
This goes beyond being comfortable with dashboards. Evidence-based decision making is about knowing how to generate the right evidence for the decision at hand. Sometimes that's an A/B test with statistical rigor. Sometimes it's five customer interviews. Sometimes it's a napkin-math estimate that's good enough. The key skills are: designing experiments that actually test what you think they test, understanding causation vs. correlation, knowing when you have enough evidence to decide, and being honest when the evidence contradicts your hypothesis. It also means understanding the limits of data — knowing when a metric is being gamed, when survivorship bias is distorting your analysis, or when the thing that matters most simply can't be measured.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands key product metrics and the difference between correlation and causation.
You know what common product metrics mean (retention, conversion, NPS) and can read dashboards. You understand that correlation doesn't imply causation, even if you don't yet design experiments to test for it. You rely on analysts or more experienced peers to interpret data.
Learning
Pulls basic data; starts designing simple experiments; developing judgment about evidence quality.
You can pull basic data yourself and participate in evidence-based discussions. You're learning to design simple experiments and to ask "what would change our mind?" before making decisions. You're developing judgment about when quantitative evidence is needed vs. when a few conversations with customers would be more valuable.
Applying
Designs rigorous experiments; applies causal reasoning; chooses the right evidence type for each decision.
You regularly use evidence to inform decisions and can defend your choices. You design experiments that actually test your hypotheses (not just confirm your biases), understand statistical significance at a practical level, and know when qualitative insight is more appropriate than quantitative data. You're honest when the evidence doesn't support your preferred direction.
Leading
Builds evidence-based culture in the team; establishes experimentation practices.
You've made evidence-based decision making a team norm. You help others design experiments, challenge cherry-picked data, and build metric playbooks. You ensure the team doesn't over-index on easily measured metrics while ignoring harder-to-measure but more important outcomes. You've established experimentation practices that produce reliable results.
Shaping
Drives organization-wide evidence culture; shapes experimentation infrastructure and practices.
You've influenced the organization's evidence infrastructure, tooling, and culture. You've helped define company-wide metrics playbooks, improved data accessibility, established experimentation platforms, or changed how decisions are made at the executive level. The organization makes measurably better decisions because of practices you've put in place.
Evaluates and prioritizes ideas, MVPs, and solutions with clarity, taste, and critical thinking.
Product judgment is the taste and intuition you develop over time — the ability to look at a feature, a design, or a strategy and know whether it's right. It's built through experience, pattern recognition, and constantly comparing your predictions against reality. Strong judgment means knowing what "good enough" looks like for this context, when to push for more, and when to kill a beloved idea because the evidence says it's not working. It's also knowing which battles to fight — spending your credibility on the decisions that truly matter.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands what makes a product idea promising; developing an eye for quality.
You can articulate basic criteria for evaluating product ideas: Does it solve a real problem? Is there a market? Can we build it? You're developing your eye for what works but still rely heavily on others' judgment for important calls.
Learning
Practices prioritization with reasoning; starts developing product instinct.
You use prioritization playbooks and can rank ideas with reasoning. You're learning to separate "interesting" from "impactful" and starting to develop your own instinct for what will work. You compare your predictions against outcomes to calibrate your judgment.
Applying
Makes tradeoffs with confidence; reliably distinguishes strong ideas from weak ones.
Your product instincts are reliable. You can evaluate an MVP and know if it's too thin or too bloated. You push back on ideas that don't meet the bar with clear reasoning. You compare alternatives thoughtfully and your calls are right more often than not. You know which decisions are reversible and which aren't.
Leading
Raises the quality bar; mentors others in developing judgment.
You raise the quality bar for the team and organization. You can diplomatically challenge ideas from senior stakeholders when needed. You help others develop their judgment by sharing playbooks and walking through your reasoning on tough calls. Your judgment is trusted across the organization.
Shaping
Defines prioritization principles; influences product quality culture across the organization.
You've shaped how the organization evaluates and prioritizes ideas. Your principles and playbooks are widely adopted. You've influenced the culture to be more rigorous about product quality and more willing to kill ideas that don't meet the bar, even popular ones.
Five competencies for creators focused on usability and experience risks. These define the depth expected of designers operating as creators.
Designs intuitive, efficient user flows and interactions that solve real problems.
Interaction design is about shaping how users accomplish their goals through your product. It spans information architecture, navigation, micro-interactions, error handling, and progressive disclosure. Great interaction designers balance simplicity with power, making common tasks effortless while keeping advanced capabilities accessible. The best interaction design is invisible — users don't notice it because everything just works the way they expected.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Recognizes good and poor interaction patterns in products.
You can identify when an interface is confusing or delightful. You understand basic concepts like affordances, feedback, and consistency, but you rely on established patterns rather than creating new ones.
Learning
Designs basic flows with guidance; learning to consider edge cases and error states.
You create wireframes and flows for straightforward tasks. You're learning to think about error states, empty states, and edge cases. Your designs improve with feedback from more experienced designers.
Applying
Designs complete, well-considered interaction flows independently.
You design full user journeys considering happy paths, error states, loading states, and edge cases. You make thoughtful decisions about navigation, information hierarchy, and micro-interactions. Users find your designs intuitive without needing instructions.
Leading
Raises interaction quality across the team; establishes reusable patterns.
You define interaction patterns that others follow. You catch interaction issues in design reviews and help the team think more carefully about how users experience the product end-to-end. Your patterns become part of the design system.
Shaping
Defines interaction design standards and pushes innovation across the organization.
You shape how the organization approaches interaction design — establishing principles, evolving the design system's interaction patterns, and pushing for innovation in how users engage with the product. Your design language influences the entire product portfolio.
Creates visually compelling, consistent, and accessible interfaces that communicate clearly.
Visual design goes beyond making things look good — it's about using color, typography, spacing, and hierarchy to communicate clearly, guide attention, and build brand trust. Strong visual designers create systems, not just screens, ensuring consistency and accessibility across the product. They understand that visual design is a communication tool: every color choice, font weight, and spacing decision either helps or hinders the user's understanding.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Recognizes visual quality and basic design principles.
You have an eye for visual quality and can identify inconsistencies. You understand basic principles like contrast, alignment, and hierarchy, but you don't yet create visual designs independently.
Learning
Applies design system components; starts making informed visual decisions.
You use existing design system components effectively and are learning to make visual decisions about layout, spacing, and typography. Your designs are clean but may lack polish or personality.
Applying
Creates polished, on-brand visual designs; contributes to the design system.
You create visually polished interfaces that are consistent with the brand and design system. You contribute new components or patterns when needed and ensure accessibility standards are met. Your visual work communicates hierarchy and intent clearly.
Leading
Elevates visual quality across the team; evolves the design language.
You set the visual direction for your product area. You evolve the design language, ensure consistency across teams, and mentor others in visual craft. Your work raises the bar for the entire team.
Shaping
Defines brand and visual identity at the product or company level.
You shape the visual identity of the product or company. You lead design system evolution, establish visual standards, and ensure the product's visual language scales across platforms, products, and markets.
Plans and conducts user research to uncover needs, behaviors, and usability issues.
UX research is the foundation of evidence-based design. It includes qualitative methods (interviews, contextual inquiry, usability testing) and quantitative methods (surveys, analytics, A/B tests). Strong researchers know which method to use when, can synthesize findings into actionable insights, and ensure the team builds on real user understanding rather than assumptions. Research is not a phase — it's an ongoing input to every design decision.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows research methods exist and values user input in the design process.
You understand why UX research matters and can identify when decisions are based on assumptions. You've observed research sessions but haven't conducted them yourself.
Learning
Assists in research planning and note-taking; learning to identify patterns.
You help prepare research plans and take notes during sessions. You're learning to identify patterns in user behavior and can summarize findings with guidance from experienced researchers.
Applying
Plans and runs research independently; translates findings into design decisions.
You independently plan research studies, recruit participants, run sessions, and synthesize findings into actionable insights. Your design decisions are consistently informed by research evidence, and you know which method to use for which question.
Leading
Establishes research practices for the team; coaches others in research skills.
You've built a research practice within your team. Others come to you for research advice. You ensure research is continuous, not just a one-off activity, and you help PMs and engineers participate effectively in user research.
Shaping
Defines research strategy and operations across the organization.
You've established research operations, repositories, and standards that multiple teams use. You influence how the organization invests in research infrastructure and ensure user insights flow into strategic decisions at every level.
Builds prototypes at appropriate fidelity — from paper sketches to AI-assisted code prototypes — to validate ideas before committing to full builds.
Prototyping is about making ideas tangible quickly so you can learn from them before investing heavily. The modern prototyping toolkit has expanded far beyond Figma clickthroughs: it includes AI-assisted code generation to create functional prototypes in hours, no-code tools to build testable experiences, coded prototypes that exercise real APIs and data, and even hardware prototyping with off-the-shelf components. The key skill is choosing the right fidelity and tool for the question you're trying to answer. A paper sketch might be enough to test a concept. A coded prototype might be necessary to test whether a workflow actually feels fast enough with real data.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows what prototyping is and why testing ideas early is valuable.
You understand that prototypes help validate ideas before building. You can distinguish between different fidelity levels but haven't created many prototypes yourself. You know the difference between a prototype and a spec.
Learning
Creates basic prototypes in design tools; learning to match fidelity to the question.
You create simple prototypes using tools like Figma. You're learning when to use low-fi vs. high-fi prototypes and how to use them in usability testing. You're beginning to explore AI-assisted prototyping tools and code-based prototyping.
Applying
Builds prototypes across fidelities and tools — Figma, code, AI-assisted, no-code — matched to the question at hand.
You create prototypes at the right fidelity for the decision at hand. You use Figma for interaction design, AI-assisted tools or code for functional prototypes, and no-code platforms when you need something testable quickly. Your prototypes effectively answer specific questions — "will users understand this flow?" or "does this feel fast enough with real data?"
Leading
Uses advanced prototyping to de-risk the hardest product questions; coaches others in prototype-driven development.
You use prototyping strategically to de-risk the most uncertain aspects of a product. You push the team beyond traditional design-tool prototypes to use code, AI tools, and real data when the question demands it. You coach others on matching prototype fidelity to the learning goal.
Shaping
Establishes prototyping culture and tooling across the organization; makes prototype-driven development the norm.
You've shaped how the organization prototypes — standardizing tools, establishing practices for testing with prototypes, and integrating rapid prototyping (including AI-assisted and code-based) into the product development workflow. Teams reach for prototypes before specs as a matter of habit.
Designs and builds products that are usable by people with diverse abilities.
Accessibility is about ensuring your product works for everyone — including people with visual, motor, cognitive, and hearing differences. It's both a moral imperative and often a legal requirement. Strong accessibility practitioners go beyond compliance checklists to genuinely inclusive design that improves the experience for all users. Curb cuts help everyone, not just wheelchair users — the same principle applies to accessible product design.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Aware of accessibility importance and basic standards (WCAG).
You know that accessibility matters and are aware of guidelines like WCAG. You can identify obvious accessibility issues (missing alt text, poor contrast) but don't yet design with accessibility as a primary consideration.
Learning
Applies basic accessibility practices; learning to audit designs and implementations.
You consider accessibility during design — checking contrast ratios, labeling inputs, ensuring keyboard navigation. You're learning to use screen readers and audit tools to test your work and catch issues before they reach users.
Applying
Designs accessibly by default; catches issues in reviews.
Accessibility is a natural part of your design process. You consider diverse users from the start, test with assistive technologies, and catch accessibility issues in your own and others' work. Your designs meet WCAG AA standards and you think about inclusive design as good design, not a constraint.
Leading
Champions accessibility practices across the team; ensures it's tested before shipping.
You've embedded accessibility into your team's workflow — design reviews include accessibility checks, and engineers understand implementation requirements. You mentor others and ensure accessibility is tested before shipping. You advocate for accessibility improvements in existing products.
Shaping
Defines accessibility strategy and standards across the organization.
You've established organization-wide accessibility standards, testing processes, and training. You influence product strategy to prioritize inclusive design and ensure the company meets or exceeds accessibility requirements. You've built the infrastructure (tools, guidelines, audits) that makes accessible products the default.
Five competencies for creators focused on feasibility and architecture risks. These define the depth expected of engineers operating as creators.
Designs scalable, maintainable system architectures that serve product needs and enable rapid iteration.
Architecture is about making structural decisions that are hard to change later — and making them in service of the product, not in service of technical elegance. It spans system decomposition, API design, data modeling, infrastructure choices, and scalability planning. Great architects balance technical quality with pragmatism, making the right tradeoffs for the product's current stage and future direction. They know when to build for scale and when to take a shortcut that lets the team learn faster.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands basic architectural concepts, patterns, and their tradeoffs.
You know what microservices, monoliths, APIs, and databases are. You can read architecture diagrams and follow discussions about system design, but you don't yet make architectural decisions independently.
Learning
Contributes to design discussions; makes sound component-level decisions.
You participate in architecture discussions and make design decisions within your component. You're learning to consider scalability, maintainability, and how your choices affect the broader system and the team's ability to iterate.
Applying
Designs system components independently with clear tradeoffs and product-awareness.
You design system components and services with clear API contracts, appropriate data models, and sensible tradeoffs. You anticipate scaling challenges and technical debt implications. Importantly, your architecture decisions are informed by product needs — you build for the iteration speed the product requires.
Leading
Defines architecture for multi-team systems; guides others in making product-aware technical choices.
You design architectures that span multiple teams and services. You make decisions about technology choices, integration patterns, and migration strategies. You ensure architectural decisions enable product agility, not just technical correctness. Others look to you for guidance on complex system design challenges.
Shaping
Sets architectural direction and technical strategy across the organization.
You define the architectural vision for the organization — platform strategy, technology radar, and technical standards. Your decisions shape how the entire engineering organization builds and scales systems, always in service of the product's ability to serve customers.
Drives code quality, testing practices, and engineering standards that enable sustainable velocity.
Engineering excellence is about building software that's reliable, maintainable, and well-tested — not as an end in itself, but because it's the foundation of sustainable speed. Sloppy engineering feels fast for a sprint and slow for a year. Excellent engineering feels deliberate for a sprint and fast for a year. This covers code review practices, testing strategies (unit, integration, e2e), CI/CD, monitoring, and incident response. Strong technology creators build environments where quality is a habit, not a tax.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows software quality practices and their importance for sustainable velocity.
You understand why testing, code review, and CI/CD matter. You follow established practices but don't yet define or improve them. You can articulate why cutting corners on quality eventually slows the team down.
Learning
Writes well-tested code; participates constructively in code reviews.
You write tests for your code, participate actively in code reviews, and follow the team's quality standards. You're learning to identify technical debt and suggest improvements to testing and deployment practices.
Applying
Drives quality practices for the team; improves test coverage and CI/CD pipelines.
You champion testing practices, improve CI/CD pipelines, and ensure the team maintains high code quality. You identify and address technical debt proactively. Your code reviews are thorough, constructive, and focused on both correctness and maintainability.
Leading
Establishes engineering standards; mentors others in building reliable systems.
You define engineering standards for your area — testing strategies, code review guidelines, deployment practices, monitoring and alerting. You mentor engineers in writing better code and building more reliable systems. Your standards measurably improve both quality and velocity.
Shaping
Defines engineering culture and quality standards across the organization.
You shape engineering culture across the organization — establishing standards, introducing new practices, and ensuring quality scales with team growth. Your standards are adopted widely and measurably improve reliability, developer experience, and delivery speed.
Identifies, communicates, and strategically manages technical debt to protect the team's ability to iterate.
Technical debt is inevitable, but unmanaged debt kills velocity and morale. This competency is about recognizing debt, quantifying its impact in terms that non-technical stakeholders understand, and making strategic decisions about when to pay it down vs. when to accept it. The best technology creators treat tech debt like financial debt: sometimes borrowing is smart (shipping faster to learn), but you always need to know your balance and have a repayment plan. They communicate debt impact in product terms — "this debt costs us 2 days per feature" — not in technical jargon.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Recognizes technical debt and its effects on team velocity.
You can identify technical debt in code you work with and understand how it slows the team down. You know that some debt is strategic (taken on deliberately to ship faster) and some is accidental (accumulated through neglect).
Learning
Documents debt; starts quantifying impact in terms stakeholders understand.
You actively document technical debt and raise it in planning discussions. You're learning to quantify its impact in terms stakeholders understand — velocity cost, reliability risk, hiring impact — rather than just saying "the code is messy."
Applying
Manages debt strategically; balances paydown with feature work; prevents unnecessary new debt.
You make strategic decisions about tech debt — knowing when to pay it down, when to live with it, and how to prevent new unnecessary debt. You negotiate tech debt work into the roadmap and deliver it alongside feature work. You articulate the business case for each debt investment.
Leading
Creates debt management practices for the team; builds shared understanding with product partners.
You've established processes for tracking, prioritizing, and paying down technical debt. You help PMs and stakeholders understand the business case for tech investments and build a shared playbook for deciding when to invest in debt reduction vs. feature work. Team velocity stays healthy over time.
Shaping
Drives org-wide technical investment strategy; influences how the company balances speed and sustainability.
You influence how the organization thinks about technical investment — balancing feature development, platform work, and debt reduction at a portfolio level. You ensure long-term technical health is part of strategic planning, and you've built the playbooks and metrics that make this sustainable.
Identifies opportunities for shared platforms and reusable capabilities that multiply engineering impact.
Platform thinking is about recognizing when individual team solutions should become shared capabilities. It involves building APIs, services, and tools that multiply the impact of engineering investment. Great platform thinkers balance the leverage of shared solutions against the coordination cost and the risk of premature abstraction. They know that the best platforms are extracted from successful products, not designed in a vacuum — and that a platform nobody uses is worse than no platform at all.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands the value of shared platforms and reusable infrastructure.
You know what platforms are and why reusable infrastructure matters. You can use shared services and APIs but don't yet think about when to create them or how to evaluate the investment.
Learning
Identifies duplication across teams; starts proposing shared solutions.
You notice when multiple teams are solving the same problem and suggest consolidation. You're learning to think about API design, developer experience, and how to make your code reusable without over-abstracting too early.
Applying
Builds reusable services and tools that other teams adopt and value.
You build shared services, libraries, or tools that other teams actually use (not just ones that exist in theory). You think about developer experience, documentation, versioning, and backward compatibility. Your platform work measurably reduces duplication and increases velocity across teams.
Leading
Defines platform strategy for the product area; balances leverage against coordination cost.
You identify platform opportunities strategically and build the business case for investment. You design platforms that balance flexibility with simplicity and ensure adoption through great developer experience. You know when not to build a platform — when the coordination cost exceeds the benefit.
Shaping
Drives platform vision and strategy across the organization.
You define the company's platform strategy — what to build internally, what to buy, and how platform investments connect to business outcomes. You shape how the engineering organization thinks about leverage, reuse, and the build-vs-buy decision at a strategic level.
Personally creates functional prototypes using code, AI tools, or no-code platforms in hours — not weeks.
In the creator era, the ability to go from idea to working prototype in hours is a superpower. This isn't about building production systems quickly — it's about creating something real enough to test with customers, demonstrate to stakeholders, or prove feasibility before the team commits. A technology creator with this skill reaches for code, AI coding assistants, or no-code tools the way a designer reaches for a sketchpad. They build functional prototypes that handle real data, connect to real APIs, and can be put in front of real users — not polished, not production-ready, but real enough to learn from. This skill separates engineers who wait for specs from creators who generate momentum.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows that rapid prototyping is valuable; aware of tools beyond traditional development.
You understand the value of building something quickly to learn from it. You're aware that AI coding tools, no-code platforms, and other rapid development approaches exist, though you mostly default to your standard development workflow even for exploratory work.
Learning
Uses AI tools and shortcuts to build simple prototypes faster than traditional development.
You're experimenting with AI coding assistants, no-code tools, or rapid development playbooks to build things faster. You can create a simple functional prototype in a day that would have taken a week with your traditional approach. You're learning to separate "prototype quality" from "production quality" in your head.
Applying
Builds functional prototypes in hours that are real enough to test with users and inform product decisions.
You can go from idea to functional prototype in hours. Your prototypes connect to real APIs, handle real data, and are good enough to put in front of customers or stakeholders. You use AI tools, code generators, and no-code platforms fluently, choosing the fastest path to something testable. Your prototypes have directly influenced product decisions multiple times.
Leading
Establishes rapid prototyping as a team capability; teaches others to build fast.
You've made rapid prototyping a standard practice on your team. Engineers ship prototypes before writing specs. You've taught others to use AI tools and rapid development techniques effectively. You maintain a toolkit of templates, starters, and patterns that let the team go from idea to prototype faster than competitors go from idea to spec.
Shaping
Builds organizational capability for prototype-driven development; shapes how the company validates ideas.
You've changed how the organization builds products. Teams across the company prototype before committing to full builds. You've established the tooling, templates, and cultural norms that make rapid prototyping the default. You've influenced how the company validates ideas — through working software, not slide decks. The organization's speed of validated learning is measurably faster because of your work.
Seven competencies for those leading product organizations. These separate the distinct challenge of building and leading teams from the challenge of building products.
Creates an environment where teams feel genuine ownership, autonomy, and responsibility for outcomes.
Empowered teams deliver better outcomes than feature factories. This competency measures whether you give your team real ownership over problems (not just tasks), provide the context they need to make good decisions, and trust them to find the right solutions. It's about leading through context, not control. The test is simple: when a decision needs to be made and you're not in the room, does the team have the confidence, context, and competence to make a good one?
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands why empowered teams outperform feature-factory teams.
You understand intellectually that empowered teams perform better. You know the difference between giving a team a problem to solve vs. handing them a spec to implement. You may not yet practice this consistently in your own leadership.
Learning
Supports empowerment by sharing context generously and framing problems, not solutions.
You share business context and customer insights so the team can make informed decisions. You're learning to frame work as problems to solve rather than solutions to build, though you sometimes slip back into prescriptive mode when under pressure.
Applying
Delegates decision-making genuinely; trusts the team to find better solutions than you would.
Your team feels genuine ownership over their work. You provide clear goals and context, then trust the team to figure out how to get there. You resist the urge to micromanage and celebrate when the team finds a better solution than what you had in mind. You let them fail safely when the learning is worth it.
Leading
Coaches teams to operate with ownership and confidence; develops decision-making capability.
You actively develop the team's ability to operate autonomously. You coach creators to think about customer problems and business impact, not just their discipline. When decisions need to be made, the team doesn't always look to you — they have the confidence and context to decide themselves.
Shaping
Creates organizational structures and leadership models that make empowerment the default.
You've built organizational structures — team topologies, decision-making playbooks, information-sharing practices — that make empowerment the default across many teams. Leaders across the organization follow principles you've helped establish. Empowerment is structural, not just attitudinal.
Designs team structures and topologies that enable effective product creation.
Org design is about shaping how teams are structured, scoped, and interact. It includes team topology decisions (stream-aligned, platform, enabling teams), defining team boundaries and interfaces, and ensuring the org structure supports the product architecture. Conway's Law works both ways — the best leaders use it intentionally. Bad org design creates coordination overhead, ownership gaps, and misaligned incentives that no amount of individual talent can overcome.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands how team structure affects product outcomes and velocity.
You know that team structure matters and affects what the organization can build. You understand concepts like Conway's Law and team topologies but haven't made org design decisions yourself.
Learning
Identifies misalignments between team structure and product architecture.
You participate in org design conversations and can spot when team boundaries create friction. You're learning how to think about cognitive load, ownership boundaries, and communication patterns in the context of team effectiveness.
Applying
Designs team structures for a product area; manages boundaries and dependencies.
You make deliberate decisions about how teams are structured, scoped, and interact. You've reorganized teams to better align with product architecture, reduced coordination overhead, and improved ownership clarity.
Leading
Shapes team topology across multiple product areas; manages organizational evolution.
You design team structures across a larger organization, considering dependencies, platform needs, and growth. You create enabling teams, manage the evolution from one topology to another, and ensure teams have the right autonomy, scope, and cross-discipline composition.
Shaping
Defines organizational design principles and practices for the company.
You influence how the entire company thinks about team structure. You've established principles for when to split, merge, or restructure teams, and your approach to org design — including cross-discipline team composition — is a competitive advantage in building great products.
Hires, develops, and retains strong product creators; manages performance with honesty and care.
People leadership is about building a team of exceptional creators and helping them do the best work of their careers. It covers the full talent lifecycle: hiring, onboarding, development, feedback, promotion, and sometimes difficult conversations about performance. Great people leaders create environments where talented people thrive and grow — and they have the courage to make hard calls when someone isn't working out, rather than letting the whole team suffer from avoidance.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Understands the importance of talent and team health for product outcomes.
You know that great products come from great teams. You appreciate the importance of hiring, development, and retention, but you haven't been directly responsible for these activities beyond occasional interviewing.
Learning
Participates in hiring; gives feedback; starting to manage people directly.
You help with interviewing and onboarding. You give regular feedback to teammates and are learning how to have difficult conversations. You may be managing one or two people and discovering what it takes to help someone grow.
Applying
Manages a team effectively; hires well; develops people through feedback and stretch assignments.
You manage a team with regular 1:1s, clear expectations, and constructive feedback. You run effective hiring processes and make good hiring decisions. Your direct reports grow visibly under your leadership. You address performance issues directly rather than avoiding them.
Leading
Builds and leads a high-performing product team or group.
You lead a group of product creators across disciplines. You've built a strong hiring bar, created development playbooks, and managed out underperformers when needed. Your team has a reputation for excellence and people want to join it.
Shaping
Defines talent strategy and leadership development for the product organization.
You shape the company's approach to product talent — career ladders, development programs, hiring standards, and leadership pipeline. You've built an organization that consistently attracts, develops, and retains exceptional product creators across all disciplines.
Grows product creators through feedback, pairing, stretch assignments, and structured development.
Coaching is about helping others build their own capabilities rather than doing the work for them. It involves asking powerful questions, providing actionable feedback, creating growth opportunities, and knowing when to step in vs. let someone struggle and learn. Great coaches multiply their impact through the people they develop. They don't create dependence — they build confidence and competence that persists after the coaching relationship ends.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows that coaching differs from managing or directing.
You understand the difference between telling someone what to do and helping them figure it out. You value coaching but haven't yet developed a structured coaching practice.
Learning
Gives constructive feedback; starts pairing with less experienced creators.
You provide regular feedback and spend time helping less experienced colleagues. You're learning to ask questions instead of giving answers and to create safe spaces for learning and experimentation.
Applying
Coaches individuals with clear development plans, stretch assignments, and regular feedback.
You have a structured approach to coaching — you create development plans, provide regular feedback, and design stretch assignments that build specific competencies. Your coachees show measurable growth. You adapt your coaching style to different people and situations.
Leading
Builds a coaching culture where senior creators develop junior ones.
You've made coaching a team norm, not just your personal practice. Senior creators coach junior ones, peer feedback is regular and constructive, and people actively seek growth opportunities. You develop other coaches, multiplying your impact.
Shaping
Establishes coaching and development programs across the organization.
You've built organization-wide coaching programs, mentorship structures, and development playbooks. You've trained other leaders to be effective coaches and created a culture where continuous growth is expected, supported, and visible in people's career trajectories.
Shapes product culture — the norms, values, and behaviors that determine how work actually gets done.
Culture is how work actually gets done when nobody's watching — the norms, values, and behaviors that shape everyday decisions. Product culture determines whether teams are empowered or controlled, whether they optimize for learning or output, whether they collaborate or compete, and whether they take creative risks or play it safe. Leaders shape culture through their actions, decisions, and — critically — what they celebrate and what they tolerate. You get the culture you tolerate, not the culture you describe in a slide deck.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Recognizes the impact of culture on product outcomes.
You can identify cultural patterns — whether a team values learning vs. output, collaboration vs. competition. You understand that culture is shaped by leadership behavior, not just stated values. You can describe the culture you're in, even if you can't yet change it.
Learning
Models desired cultural behaviors; starts influencing team norms through example.
You consciously model the behaviors you want to see — transparency, experimentation, customer focus, creative courage. You're starting to influence team norms through your actions and the conversations you initiate.
Applying
Actively shapes team culture through rituals, feedback, and intentional example.
You've established rituals and practices that reinforce the culture you want — retrospectives, demo days, customer visit programs, learning celebrations. Your team's culture is noticeably different and stronger because of your influence.
Leading
Builds a strong product culture across multiple teams while allowing team-level variation.
You shape culture across a larger group — ensuring consistent values and practices while allowing team-level variation. You address toxic behaviors, celebrate the right things (learning, outcomes, creative courage), and your cultural influence extends beyond your direct reports.
Shaping
Defines and evolves product culture at the company level.
You shape the company's product culture — from how teams are run to how success is measured. You influence hiring for cultural contribution, establish cross-company rituals, and ensure the culture scales as the company grows. People cite the culture as a reason they joined and stayed.
Builds genuine belief in the product mission — creating missionary teams, not mercenary ones.
The difference between a missionary team and a mercenary team is the difference between a product that changes the world and one that ships features. Missionaries believe in the mission. They care about the customer problem. They do the hard work not because it's on the roadmap but because it matters. Building missionary alignment is not about charisma or motivational speeches — it's about connecting every person's daily work to the impact it has on real customers. It's about being honest about why the work matters, removing bullshit that obscures purpose, and ensuring that the team understands and believes in the problem they're solving. When someone asks "why are we building this?", the answer is never "because the stakeholder requested it" — it's "because these customers are struggling with X, and we can fix it."
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Recognizes the difference between missionary and mercenary teams.
You can identify teams that are just executing tasks vs. teams that genuinely care about the outcome. You understand that motivation and purpose affect product quality, but you haven't yet deliberately built missionary alignment in a team.
Learning
Connects team work to customer impact; starts making the "why" visible and compelling.
You actively connect daily work to customer impact. You share customer stories, bring the team into contact with the people they're building for, and explain why each piece of work matters. You're learning how to make the mission feel real and personal rather than abstract.
Applying
Builds genuine missionary alignment in a team; people do hard work because they believe in the mission.
Your team genuinely cares about the customer problem they're solving. They volunteer for hard problems, push for quality beyond what's required, and feel personal ownership of outcomes. You've achieved this not through speeches but through consistent connection of work to impact: customer visits, impact metrics on the wall, and honest conversations about why the work matters.
Leading
Creates missionary alignment across multiple teams; helps other leaders connect their teams to purpose.
You build missionary teams at scale. You help other leaders find and articulate the mission for their areas. You remove organizational noise that obscures purpose — unnecessary process, disconnected metrics, political priorities. People across your organization can articulate who they're building for and why it matters.
Shaping
Shapes company-wide mission and ensures every team can see their connection to it.
You shape the company's product mission and ensure it's not just a poster on the wall but a living reality that every team connects to their daily work. You've built the structures — customer contact programs, impact visibility, narrative practices — that sustain missionary alignment as the company grows. People join the company because of the mission and stay because they can see their impact.
Identifies, attracts, develops, and retains exceptional product creators — building the team that can build the product.
Talent strategy goes beyond hiring processes and interview loops. It's about understanding what kind of people you need (not just what roles to fill), identifying potential creators who might not have the traditional resume, developing talent from within, and creating an environment where exceptional people choose to stay and grow. It includes building talent pipelines, creating career paths that keep top performers engaged, and making your organization a place where the best product creators in the industry want to work. One exceptional hire changes a team. A great talent strategy changes an organization.
Not Aware
Has not encountered this concept or practice.
No exposure to this area. Has not recognized its importance in product work and has not seen it practiced.
Understanding
Knows what good hiring looks like and why talent quality is the highest-leverage investment.
You understand that hiring is crucial and can distinguish between strong and weak interview practices. You appreciate that talent quality is the single highest-leverage activity for a product leader, but you haven't owned a talent strategy yourself.
Learning
Conducts effective interviews; starts developing an eye for identifying creator potential.
You conduct structured interviews and provide useful written feedback. You're learning to evaluate beyond surface-level skills — assessing judgment, creative courage, cross-discipline fluency, and growth potential. You're starting to identify people who have creator instincts even if they don't have traditional backgrounds.
Applying
Owns talent strategy for a team; builds strong pipelines; makes excellent hiring decisions.
You own end-to-end talent strategy for your team. You write compelling job descriptions that attract creators (not just practitioners), design interview loops that assess the competencies that actually matter, and make strong hiring decisions. You also invest in developing existing team members and creating growth paths that retain top performers.
Leading
Builds talent systems at scale; creates career paths and development programs.
You've built talent practices that work at scale — interview training, assessment rubrics, career ladders, development programs, and retention strategies. You raise the hiring bar for other managers, identify high-potential creators early, and build succession plans. Your team has a reputation that attracts top talent.
Shaping
Defines talent strategy and employer brand for the product organization.
You shape how the company attracts, evaluates, develops, and retains product creators across all disciplines. You've built the employer brand, established relationships with talent sources (universities, communities, bootcamps), and created a talent development engine that is a genuine competitive advantage. The best creators in the industry know your organization and want to work there.
The playbook is designed for multiple modes of use, from individual self-reflection to organization-wide diagnostics.
Self-assessment
Rate yourself on each competency in your track. The result is a radar chart that shows your shape — where you’re strong, where you’re growing, and where you need to invest. Honest self-assessment is the starting point for intentional development.
Manager assessment
Invite your manager to rate you on the same competencies. Comparing your self-assessment with your manager’s perspective reveals blind spots and alignment gaps. The most valuable conversations happen where the two ratings diverge.
AI assessment
Let AI interview you with behavioral questions tailored to each competency. Instead of picking a number, you describe real situations from your work. The AI evaluates your responses against the level definitions, producing an evidence-based assessment that’s harder to game than self-reporting.
Org diagnostic
Aggregate individual assessments across your product organization to see the company-level picture. Where are your collective strengths? Where are the gaps? Which teams are operating as creators and which are stuck in project mode?
The transformation arc
Aggregate scores map to the transformation arc: averages of 1.0–2.5 indicate project-mode teams (resources executing tasks), 2.5–3.8 indicate product teams (empowered but still developing), and 3.8–5.0 indicate creator teams (the full realization of the empowered product model). This gives leadership a clear, measurable picture of where the organization stands and what needs to change.
The Product Creator Playbook was built by Jirka Helmich, former CPO at Mews, where he led the transformation of a product organization from project mode to empowered product teams.
This playbook carries an intellectual debt to Marty Cagan and Bob Baxley at SVPG, whose work on empowered product teams and the product creator concept provides the conceptual foundation. Teresa Torres’s work on continuous discovery habits deeply influenced the discovery competencies. The broader SVPG body of work — on product vision, strategy, empowerment, and missionary teams — is woven throughout.
The playbook is the intellectual core of productcreator.ai, a tool for assessing product team capability, diagnosing organizational maturity, and charting the path from project to product to creator.
We use cookies for analytics to understand how the site is used. No tracking without your consent. Privacy policy