Start with the outcome
I write product manager goals around the change we want to create, not the number of tickets we expect to close. “Ship five features” is an output. “Help new users reach a first useful result with less confusion” gives the team a problem to understand and a result to learn about.
Four goal areas
I use customer and product outcomes, business contribution, decision and discovery quality, and team effectiveness. Depending on context, signals might include task success, retention, cost, risk reduction, a validated assumption, or clearer ownership. I do not force every team into the same metric.
For each goal, I write the audience, baseline when known, signals, dependencies, risks, and next review point. If we do not have a baseline, I say so and make measurement the first step rather than inventing precision.
Avoid common traps
I avoid goals that reward shipping regardless of value, goals wholly controlled by another team, and goals too broad to guide a choice. A roadmap is not a goal list; the roadmap can change while accountability to the outcome remains.
The best PM goals make it easier to say no, choose a next step, and learn honestly. I use them as a conversation tool—not a false promise that product work can be reduced to one score.
A practical check
I review goals with the team, not only at a formal performance checkpoint. That gives us a chance to update the approach while the outcome remains stable. If a goal no longer reflects the product strategy, I change it openly and record why.
My bottom line
I use this framework to make the work explicit, not to create ceremony for its own sake. Start with the decision, show the evidence, make ownership visible, and revisit the approach when the product or context changes.
If you are building the fundamentals behind this kind of work, the Product HQ product management certification is a useful next step. I also share practical lessons in the Product HQ newsletter.