The Art School Model of Product Enablement
what I learned building an Enterprise product practice for 80+ PMs
This is the longest piece I’ve written to date. I tried splitting it up, but the thread that connected the work kept getting lost. So I’m publishing it all together.
So stick with it, skim it, or skip parts. Hope you enjoy.
A few roles back, I became the product practice lead for more than eighty product managers. The problem, as it was handed to me, was blunt: “Our PMs aren’t curious.”
It sounded believable on its face. I myself had seen plenty of moments where PMs took answers at face value, or committed to handed down directives without asking any questions, or focused on their own team’s success without considering how their work impacts downstream teams. I could see the dotted line between these symptoms and a lack of curiosity, so I treated it like the thing to fix. If PMs were not asking better questions, my job was to build the scaffolds that would teach them.
But the more I talked to people and watched things flow, the less that explanation made sense. The working theory became more nuanced: maybe our PMs were not short on curiosity. Maybe they did not have time to be curious. Maybe we were setting them up to fail.
This was a much broader problem to fix, and looking back at my discovery journal from that period, I’m glad we didn’t ignore the early patterns. PMs were better at project management behaviors not due to lack of curiosity but because those were the skills being rewarded. They also felt overwhelmed by the number of priorities and the sheer time spent coordinating it all. I started to understand that the underlying problem was very different from “PMs are not curious.”
The organization had trained people toward delivery, responsiveness, and coordination, dumped cross-cutting priorities on them, then felt disappointed when those same people didn’t show the strategic product behaviors nobody had made room for.
I heard versions of this across different domains with different leaders, engineers, designers, stakeholders, and unique habits. Pretty much all PMs had strong delivery muscles and only a handful had strong product instincts. In every domain, they were still being rewarded for project management delivery work. When your calendar is full of status meetings and your credibility comes from being responsive, curiosity starts to feel like a luxury or a nice-to-have. It doesn’t disappear because people lack imagination, it gets crowded out by the job they are actually being asked to do.
On paper, everyone had roughly the same job. Same broad skills matrix. Same job description. In practice, every silo had a different definition of “good.” That inconsistency cost us. Past attempts to introduce skill frameworks or coaching were vague. I heard frustration that career conversations felt subjective. Output and delivery carried more weight than outcomes and growth. And team rotations were painful because a PM who looked strong in one environment could be completely out of their depth in another.
That was the first real challenge for me. There were so many ways to tackle this, the most common transformation tactic you read about are “Here’s another playbook,” or “attend this workshop series,” or “do this new process and learn these acronyms.” But I’ve seen these all fail before. If we were to succeed where everyone else had failed before I needed to figure out the harder question to answer: what actually needs to transform for PMs to get better, and what in the system keeps working against that?
My first couple months were pure discovery. I talked to people across departments, listened for how product work actually happened, and tried to understand the differences between domains before deciding anything. Some people were frustrated by the lack of visible action, but those first two or three months are why later bets had traction. The learnings kept forcing the problem to become more specific. It was not just curiosity. It was role ambiguity, incentives, calendars, decision rights, leader expectations, partner expectations, and the uneven ways each domain defined good product work
I decided not to build a standard training program. We were treating the practice work like product work: understand the users, understand the constraints, name the real problems, then decide where to intervene.
We explicitly were not trying to bring a prebuilt product practice from frameworks. Each domain clearly needed different things, so one answer for everyone was going to miss the boat. But first, there was something missing across the board: a shared way to see the craft.
Part I: Making Proficiency Visible
For weeks we interviewed PMs, product leaders, engineers, designers, and partners across the different domains. One early obstacle we needed to clear was that everyone had a different definition of what good product work looked likesSo the first bet we tried was spreading a visual competency model we called the PM Shape.
It was a spider chart adapted from Ravi Mehta’s Peak Product Manager framework, with other skills added for our specific blend of practices: Lean, XP, balanced teams, and comfort with uncertainty.
This gave everyone a shared picture of product aptitude that worked across subjectivity. We wanted leaders to see the problem in a way they had real authority to do something about.
The discovery work had already shown that vague complaints were not accurate enough. “Not curious” was unfair. “Needs to be more strategic” was too generic, and in many cases it conflicted with what PMs were actually being tasked with. Each leader expected different things, so each domain’s PM skill pattern was going to look different. We needed leaders to change the question from “are my people good?” to “where are they fluent, where are they compensating, and what kind of support would actually help in my domain?”
The theory behind the PM Shape was that it would help individuals have better feedback conversations but also make strengths and gaps visible as a pattern. When we turned the interviews into composite competency charts for each domain, leaders could finally understand. Domain E was clearly strong at delivery and execution, but weak at understanding users and delivering incrementally. Another domain had PMs fluent in data-analysis but weak in leadership skills to actually make that data usable for their team.
That changed the conversation. If the same pattern showed up across a whole domain, it was harder to blame individual PMs for lacking curiosity or strategic thinking. The chart made the system visible.
The point was not, “this PM is weak.” The point was, “this environment is producing a specific behaviors.” Once leaders could see that pattern, we believed they could stop treating every development gap as an individual coaching problem.
It also created an awkward dynamic. Managers kept trying to use the Shapes for performance evaluation. We had succeeded in getting them to think about fluency and support in a consistent way, but old habits were still there. The chart kept getting used as a “good versus bad” barometer instead of “what kind of help does this person need?” At least one manager used the Shape to justify a PiP.
That misuse taught us something too. Even a development tool will get pulled into the existing incentive system if you do not protect it. The artifact was not separate from the culture. The culture was going to use it however the culture already knew how.
Through the shapes we had also mapped the levels and skill sets of the full product portfolio. A couple of red flags stood out.
First, there was a huge clump of Senior Product Managers with wildly different skill patterns and proficiency levels. The title was doing too much smoothing. Two people could both be Sr PMs while playing very different roles.
Second, there was no IC promotion path past Sr PM. We worried this was where good IC PMs went to stagnate and stall out.
We dog-eared those risks for later. and put a pause on the PM Shapes. We didn’t want to shame anyone but we couldn’t improve a practice when every conversation stays anecdotal. We wanted leaders to look at their org and say, “This is why our PMs are struggling to influence engineering,” or “Here is why everyone says outcomes but still behaves like output.”
That was the first lesson: before you can scale product craft, you have to make the craft discussable.
Part II: Making the Craft Worth Practicing
The Problem With Competency Models
Competency models fail in boring ways. People don’t rally around them. Leaders might nod and HR might appreciate them, but they rarely create energy. Before long, they usually turn into another way to rank, calibrate, and justify.
Some benefits from the PM Shapes stuck though The visual itself was a lasting idea of product management competency that we could refer back to. In practice most people still saw the job as a checklist of activities to do, not a craft. This is where the art metaphor started doing work.
In every conversation, I framed our work with a specific story:
Anyone can pick up a pencil and draw something on paper. That does not make them an artist.
Artists learn how different tools behave. They learn pencil, charcoal, paint, clay, light, negative space. They learn technique, medium, composition, constraint, style, and philosophy. They study the history. They practice enough to understand why watercolor behaves differently on wax paper than it does on canvas. Over time, they develop taste. Eventually, the best artists understand the principles well enough to break the rules without violating the thing that matters underneath.
Product management is the same. A PM can fill out a template. They can run a standup or write a story. They can use tools, frameworks, and techniques. But fluency is knowing which tool fits the moment, and knowing how to adapt a framework because you understand the principle underneath it.
We treat PMs like box checkers when we should be calling them craftspeople.
Using that frame, we set the mission: help budding artists become Da Vinci PMs.
From PM Types to PM Help
The art metaphor became a guide for how to help different PMs. We started with two axes: passion and proficiency. Later, generosity became a third dimension because the health of the community depended on people who were willing to share what they knew.
The archetypes were easy to understand. Despite being playful, the model was not a gimmick. It helped us decide what kind of engagement or enablement to offer.
A budding artist is already passionate. They don’t need to be convinced that product craft matters. They need to learn techniques, be given opportunities to practice and enough attention to build confidence.
A doodler is different. They may know how to do the work, but the spark is missing. Maybe they have been burned by the organization. Maybe they learned that curiosity is not rewarded. They may need a better problem, a leader who creates room for judgment, or a community that makes the craft feel alive again.
Da Vincis were the north star, but good craft still needs care. They needed to be treated as multipliers, not just IC high performers. If someone is proficient, passionate, and generous, the worst thing you can do is leave all of that inside their immediate team with nowhere to go. They can coach, model, challenge stale assumptions, and help the rest of the organization see what good looks like without turning it into a rigid script.
This changed how we thought about enablement. The competency chart told us what skills might need attention. The art model told us what kind of help might work. Together, they kept us from treating PM growth like a content problem.
The Mission Had to Be Felt
There is a reason “Da Vinci PM” worked better than “product capability maturity model.”
The art metaphor gave us a vision people could buy into. We weren’t trying to manufacture uniform PMs. We were trying to build a community of product artists: people with enough principle-level understanding to adapt across contexts, make better decisions, and help each other improve.
This was another way of moving away from a trait story. We were not saying, “some PMs are curious and some are not.” We were saying craft develops when people have language, examples, practice, feedback, and permission.
In many enterprise environments, PMs are pushed toward being doers instead of thinkers. They are praised for being responsive, keeping the machine moving, and making everyone around them feel supported. Over time, the work becomes procedure. The PM tends to become the project manager person who owns intake, writes up the chore, attends the meeting, translates the stakeholder request, and keeps the roadmap looking respectable. Then leaders ask why product thinking feels weak.
It was at this point, the system dynamics started to become more visible. If the environment rewards PMs for acting like delivery coordinators, it should not be surprising when they become very good delivery coordinators. If the environment leaves them no slack to investigate, compare, doubt, wander, or ask the naive question, it should not be surprising when they look less curious.
Part of the practice work was helping leaders see the tradeoff they were creating. You cannot ask PMs to develop judgment while punishing the behaviors that reflect decision-making. Curiosity takes time. Saying no requires air cover. Challenging assumptions requires trust and psychological safety. Cross-functional influence requires escalation to not be the default decision path.
The spider charts helped leaders see where their people were struggling. The Da Vinci story helped them understand why the answer could not be another procedure.
If we wanted PMs to become more fluent, the environment had to let them practice.
Part III: Creating a Place for Curiosity
The most impactful and enduring thing we did was also the most informal. We launched a weekly Product Studio, open forum where PMs could bring ideas, questions, stakeholder challenges, or anything else they were trying to figure out. It was not a lecture series, a required training, or a recorded meeting. It was open space.
Once we saw curiosity as something the environment either made possible or crowded out, Studio made more sense. PMs did not just need more content. They needed a place where curiosity was normal. For many PMs, it was the first discipline-specific space they had ever had. They’d never been able to ask questions about their jobs without judgment before.
It was quickly obvious the effect having no product community had on our PMs. There was a glaring lack of connectedness in how things got done. If people needed information from another team, they spent hours searching Drive or scouring org charts instead of asking. There was not much shared understanding of upstream or downstream impact, which meant one team’s change could break work other teams depended on. If they needed to write something, they often started from decades-old templates instead of thinking about what could be better. Any cohesion within a group of PMs depended on the domain leader creating it themselves.
In that environment, autonomy was hard to feel or demonstrate. Local needs and hyper-specific domain knowledge had become a substitute for good practice. PMs believed their problems were unique to them and could not be helped by anyone else.
Studio gave those struggles somewhere to go. We opened a topic sign up form for anything the community wanted to share or learn about, and we kept a living Miro board so the topics could be revisited after the meeting. Each session was as collaborative as we could make it. The Da Vincis and budding artists ate it up.
Sometimes studio was broad and unstructured. Other times they were highly technical. We occasionally invited guest speakers to bring expertise on something the group cared about. The conversations did more than transfer knowledge. They normalized the day-to-day work everyone was doing and made it obvious we could do it together instead of alone. A training deck could never build community or shared purpose the same way.
Studio worked because it changed one condition around the work: PMs no longer had to practice judgment alone.
That was the point of Studio. It was a place where PMs could practice socially. They could finally understand how their job could be their craft.
Part IV: Matching Help to the Person
Enablement Needs Engagement
One of the bigger lessons from that period is that enablement and engagement are different loops. Either one can collapse without the other.
Enablement is the work of helping people get better: think coaching, playbooks, office hours, skill maps, and deliberate practice. Engagement is the work of making the practice feel worth showing up for.
Many transformation initiatives overbuild enablement and under-build engagement. They create a toolkit, announce the toolkit, maybe hold a workshop about the toolkit, and then sit back and wonder why nothing changes. The hidden assumption is that the problem is access to information. Sometimes it is but usually not.
As we gained traction on engagement, we learned that PMs are not short on content or curiosity. They are short on time, context, confidence, and permission. They needed more experience translating principles into their domain-specific mess. And they need to believe the company values the craftwork. They need leaders to stop sending contradictory signals. Studio was not only an engagement outlet. It started to become a learning platform too.
The Da Vinci coaches felt valued for the same reason. We recruited the PMs who already had proficiency, passion, and generosity, then Studio gave them ways to contribute without making it feel like extra invisible labor. They could facilitate, coach other PMs, help with onboarding, participate in interviews, build playbooks, support XP workshops, or help define what good product practice looked like.
This did two useful things at once. First, it meant spreading good practice did not depend on my team alone. Second, it made the change feel less like a mandate from “the transformation people” and more like PMs building something they wanted to be part of. That distinction was huge because people resist being transformed but will often participate in building something they believe in.
Cohorts Made the Learning Work
The same logic shaped the curriculum. If curiosity and craft require practice, then enablement had to be more than a deck. PMs needed repetitions on real work.
At the same time as Studio created community, pull, and curiosity, curriculum work was where enablement got deeper. We had a waitlist of PMs who wanted to learn and introduced a full curriculum, offering a space to deliberately practice specific skills, get feedback, and show meaningful improvement.
The first unit covered story writing and backlog flow. The material was built to help PMs create sustainable pace and deliver high-quality software by understanding why good stories work: context, user value, acceptance criteria, and how to balance different types of work.
We considered webinars and self-guided coursework, but landed on cohorts of up to 12 PMs because we believed they would bond more and learn better in groups. Enrollment was first come, first served, and we required signed agreements from both PMs and their managers. It felt like overkill, but learning time was historically deprioritized. We needed a concrete commitment to hold everyone accountable to.
Another important design choice was that the assignments came from their real backlogs. We did not give PMs fake classroom exercises, then send them back to a different reality for the rest of the week. They brought the work they were already thinking about to class, used that for exercises, and took it back to their teams after.
The first cohort was a bet to answer the question: can we upskill everyone to the same foundation? The answer was yes, but the first version took too long. Ten of twelve PMs improved their story writing. That was a strong signal, but it took three months to see changes.
So we shortened the curriculum and ran the next bet. Cohort 2 asked whether a shorter version could still work. It did: nine of twelve PMs improved story writing. Cohorts 3 and 4 asked whether graduates could become peer coaches and teach the material without the practice team owning every session. That worked too. Across the first four cohorts, thirty-one of thirty-six PMs observably improved their story writing, and 10 graduates agreed to coach future cohorts.
Once again, this expanded the role of the Da Vincis. They were no longer just examples of good craft. They became official teachers, and we kept the ratio to no more than three PMs per coach. They became more confident and more eager to share because they learned more just through teaching others.
At the end of each curriculum, we scheduled review sessions with every manager and shared specific guidance to support each PM’s ongoing growth. Through the cohort, my team learned each PM’s strengths and weaknesses. The report card helped leaders see how to look at a backlog, what warning signs to spot, how often to audit stories, and what they should expect to see.
We measured the impact in a few ways: weekly attendance, engagement in the sessions and Slack channels, before-and-after story scores, and the shift in our PM archetype mix over time. The data helped us keep asking the right question: are more PMs moving toward confident and consistent craft? By the end, we had increased the share of budding artists by roughly twenty percentage points while reducing doodlers and paint-by-numbers PMs.
The curriculum connected the whole system: clear principles, real work, peer coaching, leader visibility, and enough measurement to know whether the bet was working.
Part V: Changing the Conditions Around the PM
Treat the Practice Like a Product
You do not build a practice by blasting out information and expecting people to make it work. You build it by learning quickly, adapting to the problems that come up, and showing people that their feedback changes what happens next. Then you look for the next fork in the road based on how people actually use what you built.
One principle the practice team kept coming back to was pull matters more than push. Ideas we introduced without collaboration struggled. The things that gained momentum moved by showing a possible future, telling a story people could locate themselves inside, and giving PMs a concrete way to contribute.
Plenty of ideas seemed great from a practice-lead chair and fell apart as soon as we watched a PM try to fit them into an already crowded day. Monthly long form workshops flopped. Roadmap templates struggled. That was another reason Studio mattered. It was a built-in feedback loop that kept the practice work close to the community. If something didn’t resonate or make intuitive sense, it was probably adding friction to days that were already packed.
We learned that if the community only exists because you are pushing it, you don’t have a real community yet.
Expanding the Boundaries of Influence
The bets also expanded naturally beyond ICs. Once we had enough trust, my team could start shaping the conditions around individuals. Across domains we evaluated how GPMs spent their time, how leaders talked about customer value, and how teams connected their work to outcomes.
The Balanced Leadership bet was a good example. The problem was not that GPMs lacked strategy skills in some abstract way. It was that many were spending too much time in the weeds, doing tactical work, and losing the space they needed for product-group strategy and people leadership. We forced them to inspect their own calendars and ask a better question: is my time matching the job I am supposed to be doing?
Another example pushed on another part of the system: customer-centricity. Teams were making plenty of decisions, but the connection between product delivered to customer value was not always clear. So we started mapping value up and across: from team indicators to org-level value, from product work to customer experience, and from customer experience back to business outcomes.
That led towards the North Star Framework as a highly successful proof of concept, later becoming the foundation for outcomes and operative phrases approach.
Hiring Was Part of the Practice Too
Hiring was part of the same system. If we wanted a stronger product culture, we could not only develop PMs after they joined. We had to change what “good” meant before someone entered the org.
The old PM hiring process was five to six rounds of random conversations. My team helped reshape it into three purposeful stages. We were involved in every PM candidate loop and trained other PMs and designers to give the interviews. That transformed interviewing into another way to teach the craft. Interviewers had to learn what good looked like, how to listen for it, and how to separate polished product language from actual judgment. At the peak, we were interviewing three candidates per week.
The results were measurable too. Time to hire dropped by 10 days, and a higher percentage of candidates progressed from round one to round two.
The Leadership Work Underneath
It would be comforting to say the community was enough. It was not.
PMs were getting more language, more confidence, and more peer support. The signal that stuck with me most came secondhand from the CTO. A Marketing VP had challenged their team to “take ownership and be confident like the PMs. They know their stuff like the PMs do.” That one meant a lot to me. It was not a practice-team metric or a survey response. It was an outside leader noticing that PMs were showing up differently.
As Studio gained momentum, the faults in the surrounding environment became more obvious. Managing the community and the weekly curriculum took a lot of energy, and the practice team wasn’t spending enough time on leadership enablement strategy.
So while the PMs might be getting noticeably stronger, leaders still decided what got praised, what got funded, what got escalated, and how much tolerance there was for challenging questions.
That was one of the early discovery insights we kept circling back to. If PMs were practicing project management behaviors because that was rewarded, a practice lead could not solve the problem by teaching discovery harder. The leadership conversation had to include the conditions around the work.
Having the cohort data to overlay on top of the composite org charts helped because we could make leadership conversations specific. Instead of saying, “We need PMs who can be strategic,” we could say, “This team has a pattern of strong execution and weak discovery. Here are specific skills you can help this PM with and here are things you should protect them better from.”
That kind of conversation shifts responsibility. If an entire org has a recurring competency gap, the believable answer is no longer individual grit or curiosity. This is where practice leadership had to become more political. We were influencing what the organization valued and asking leaders to see their own role in the gaps they were frustrated by.
We kept trying to bring the conversation back to what PMs were actually being asked to practice.
How We Kept The Work Connected to The Value
Measurement mattered because it forced us to treat culture as something shaped by conditions, not vibes. If the system was changing, we should be able to see some signal of it.
As internal practice work, it would have been easy to do a survey and use only sentiment feedback but we did not want to be vague about impact. The team treated the internal practice and culture as the “product” itself so it was important to find ways to justify our value and connect what we did to measurable or observable criteria. Looking back, I found an old sticky note from that period: “if you manage products, you know navigating to value involves a constant cycle of learning and decisions. Transformation works the same way.”
We treated the practice like a product, which meant we needed relational criteria to share our learning.
Some signals told us whether people were showing up like consistent / growing weekly Studio attendance, office-hours usage, and Slack channel activity. Some told us whether people were improving like cohort completion and PM progression towards Da Vinci. Some told us whether the practice itself was getting healthier: our last Pulse survey reported “85% of PMs believe their craft is improving through Studio and observing other teams, with most citing professional growth and peer connection as the CoP’s greatest value.”
The impact map kept the measures as honest as possible. Product thinking was not the end goal by itself. The bet was that stronger product thinking would help Kohl’s capture more revenue opportunities, increase customer value, reduce time to value, and make technology teams more efficient by reducing avoidable toil and complexity. That gave the practice team a clearer causal chain from daily activities to business outcomes.
The archetype improvements were an imperfect but helpful practice-health signal. Over a short window, we could see fewer paint-by-numbers PMs, a slight increase in Da Vincis, and movement among the middle groups.
The cleanest numbers came from enablement curriculum. Cohort 1 improved story writing for 83% of participants and showed a backlog cycle-time drop from 150 hours to 55 hours. Cohort 2 kept the shorter curriculum effective at 75% improvement. Cohorts 3 and 4 showed the curriculum could be taught by peer coaches, with 90% of participants improving across the first four cohorts. In the 2024 review, the completed cohorts were showing a 79% improvement rate overall, with 36 PMs, about 43% of the PM org, expected to complete the story-writing curriculum that year.
The leading measures mattered too. Week over week, did people keep showing up? Were PMs bringing real work and actually engaging? Were Da Vincis volunteering to teach? Were leaders asking better questions after seeing the charts? We never had perfect measures, but the signals told us whether the practice was alive.
For a while, we really believed we were doing the thing most transformation efforts only claim to do. The practice was self-sustaining. PMs were showing up. Leaders were asking different questions. Curiosity was a defining quality of teams.
And Then the Ground Moved
And then we came to the end. It ended in the way you would expected. On the eve of our announcement to roll out the North Star Framework trees leaders changed. Priorities shifted. The team was reorganized. The practice work was still valuable, but what we were building lost its home.
That is part of the lesson too. A product practice is not a process, a curriculum, a meeting series, or a team. It’s an ecosystem. If the environment changes, the practice has to be protected, moved, or rebuilt. Otherwise the pieces can survive stand-alone while the living system fades.
I think in our heads we always knew we’d have to build the practice to survive without us. The encouraging part is that the PM community continued Product Studio for over a year after my team was officially disbanded. People still ask for the PM Shape and the interview guides. If there’s a silver lining it’s that the impact we had didn’t vanish.
Part VI: What I’d Keep, What I’d Handle Differently
What I Would Keep
If I were doing this again, I would keep the same basic architecture of starting with discovery: interviewing across the spectrum of PMs, leaders, engineers, designers, and partners. Creating the domain-level shapes proved useful again and again because they made it easier to see the gap between what leaders said they wanted and what the system actually rewarded.
I would still frame on shared competency language, but I would be more explicit about its boundaries. I would be more careful about how quickly a spider chart can become a performance tool.
I would still build the story. A mission that gives people a view of the future. “Da Vinci PMs” works because it captures the essence of product work: product management is craft-based, not task-based. You can provide tools and techniques, but the goal is lasting judgment that adapts.
I would use a similar operating model and flywheel of enablement > engagement > amplification. Some PMs need skill-building. Some need renewed curiosity. Some need a peer community. Some need leadership support. Some need recognition. We were in the middle of rewriting job reqs and adding a Principal PM role for ICs above Senior PM when the team was disbanded.
I would still rely on pull vs push. We had a lot of generous experts to engage and challenge. Every company has people who are already carrying the craft, often informally, without much recognition and at personal cost. If you can identify them, protect their time and give them a real role in the practice because they become the most credible teachers you have.
I would still create a Studio: a recurring space where people can build community around craft. That needs to develop through practice, feedback, conversation, imitation, disagreement, and reflection. A Studio is a better metaphor than a classroom.
What I Would Be Careful About
The biggest risk is that the artifacts become more interesting than the practice. The practice takes more commitment and patience than new processes and frameworks.
A spider chart is seductive because it looks interesting and highlights focus areas. A 2x2 is memorable because it simplifies ideas. A name like Da Vinci can spread because it is easy to repeat. In my case, all of that was intentional, but those were scaffolds, not the actual impact work.
Impact shows up as a second- or third-order effect, once principles settle into a new mindset.
Do we change what we reward? Do we ask clarifying questions before committing to an execution plan? Do our teams practice collaborative overlap instead of sticking to siloed roles? When the fluency shows up, the impact does too.
The second risk is over-romanticizing craft. Artistry is a useful metaphor because it honors judgment, taste, practice, and principle-level understanding. But product management is still organizational work. It is full of real constraints, competing incentives, shareholder expectations, legacy systems, and pressure to deliver.
Calling PMs artists does not mean telling them to follow their muse. It means expecting them to understand their medium, such as a business model or problem space, and be skilled at adapting their methods.
The Real Outcome
The lesson I took from leading product practice is that you do not make PMs more curious by handing them better templates. Curiosity was not something PMs lacked, it was something the system had made hard.
This story has a lot of seemingly separate but interconnected pieces. competency framing, the Da Vinci narrative, enablement strategy, Studio, coaching, leadership influence, incentives. Each one probably deserves its own post and analysis. But the compounding value only makes sense when the pieces are in one place.
In my view, the competency chart improved because the art metaphor made the goal human. The art metaphor worked better because the competency work made gaps visible. Studio gave the mission somewhere to live. Da Vincis mattered because the community needed generous experts. Leadership mattered because leaders recognized better craft and visibly rewarded it.
The pieces only really make sense together. The most important thing we built was a practice environment.
Up until the very end, I was the biggest believer in the change we were creating. I saw signs of developing fluency everywhere. We made product judgment visible enough to discuss, gave people a craft identity they could rally around, and created a room where the craft could be practiced in public. We found the people who could teach without turning the work into dogma. And we used the artifacts to help leaders see the gaps in their own orgs without blaming individual PMs.
I was convinced we were onto a transformation approach unlike anything before. I saw it as bottom-up but balanced, and all our efforts were focused on creating enduring habits and beliefs. Looking back, I have to confront myself. Was I naive? Too optimistic? Did I have too much hubris? Did people actually buy in? Did I push too hard or alienate people? Did we just not have enough time?
Then I look back at what good came of it that exists to this day. We hired 15 A-player PMs. We helped handfuls of product people get recognized and promoted. PMs ask better questions now and have a real community. Backlogs are more structured and we have a shared picture of what good looks like. When looking for information, people talk to each other instead of searching for documentation.
still believe the art school metaphor holds: anyone can pick up a pencil and draw something on paper. That does not make them an artist.
The job is not to hand PMs more pencils. It is to create the conditions where they can practice long enough to develop judgment.
I’ll never know what would have happened if the organization had stayed stable long enough for the work to mature. Regardless, we helped product managers become better artists.