Product Execution
Specs, delivery, quality, and my 10-50-90 framework, the work of shipping.
Product Execution: Define, build, and launch exceptional products.
This is the first of the four competency areas in The PM Competency Model, and I put it first on purpose. Execution is the foundation the rest of the PM career sits on. Strategy, vision, and influence stay theoretical until something ships and moves a number. I have watched brilliant strategists wash out because they could not get anything across the line, and I have watched relentless executors get promoted right past them. The order here is not an accident.
#My point of view: execution is the one thing a PM can never be bad at
You can be spiky everywhere else, and you should be. The competency model is explicit about it. Nobody is great at all twelve competencies, and chasing a flat profile is how you end up mediocre at everything (The T-Shaped PM and Knowing Your Shape). Execution is the one exception I will fight for. A PM who cannot define a clear spec, ship to plan, and hold a quality bar is not a junior PM. They are someone who is not yet doing the job. Everything else multiplies a base of can this person reliably get good product out the door. If the base is zero, the multiplier does not matter.
That is also why execution dominates the early ladder. At the APM and PM levels you are largely judged on execution: can you spec a feature, work with engineering, and ship it without it falling over. Strategy and influence are where careers mature (The Product Career Ladder), but they get built on top of an execution reputation you earn in years one through four.
#The three competencies
This area breaks into three competencies, each with its own note and its own named behaviors from my model.
| Competency | What it covers | The behaviors |
|---|---|---|
| Feature Specification | Turning a problem into shared, buildable understanding | Outcome Oriented · Comprehensive Documentation · Clarity |
| Product Delivery | Working with the team to actually ship | Team Coordination & Alignment · Communication · Delivery to Plan |
| Product Quality | Holding the bar on decisions and risk | Sound Product Decision Making · Risk Identification & Mitigation |
#The supporting notes
The competencies are the what you are measured on. The rest of this domain is the how I actually do it, the craft and frameworks and beliefs underneath.
| Note | Why it's here |
|---|---|
| Writing PRDs and Specs | The craft of the spec: formats, the one-pager, over-spec vs under-spec |
| Agile Delivery and Team Cadence | Sprints, standups, and the PM's real role (you are not the scrum master) |
| The 10-50-90 Execution Framework | My core execution operating system: phases, confidence, and roles |
| RACI and Decision Rights | Who actually decides; Owner/Partner/Consulted; disagree-and-commit |
| Sound Product Decision-Making | Reversible vs irreversible doors, decisiveness, owning the call |
| Risk Identification and Mitigation | Classify by impact × likelihood, contingency, transparent comms |
| Shipping and Launch | Rollout strategy, phased and dark launch, launch readiness, measurement |
| Outcomes Over Outputs | My core belief: measure what changed, not what shipped |
#Where execution connects
Execution does not live in a vacuum. Good specs are downstream of good discovery, because you cannot define what to build until you understand the problem and the four big risks. What you choose to execute on is a prioritization decision. And the whole point of shipping is to move a business outcome, which is why Outcomes Over Outputs sits at the end of this domain rather than the start of the strategy one.
Senior PMs often try to "graduate" out of execution into pure strategy. The best leaders I have worked with never do. They stop writing the spec themselves and start raising the team's execution bar with better processes, better reviews, and fewer surprises. The work changes altitude. It never stops being your responsibility.
#Continue Reading
- Feature Specification for the first competency: turning a problem into shared, buildable understanding.
- The 10-50-90 Execution Framework for the operating system I use to run any non-trivial piece of work.
- Outcomes Over Outputs for why a feature factory is the failure mode this whole area exists to prevent.
- The PM Competency Model for how this area fits with the other three and the full ladder.
- Foundations of the Craft for the concepts execution sits on top of.