Product Manager feedback tends to be unstructured & is often not easily actionable.
This had bugged me for years, until I starting applying this framework a few years ago.
Structuring feedback in these 5 categories forces more specificity & action-orientation.
It's a joint plan in which the manager is equally accountable.
How to start?
Managers: write up to 3 prioritized points per category
All others: share this framework with your manager🙂
There’s more to feedback of course (acknowledging past progress, specific examples, etc.)
The focus of this framework is on the plan aspect of feedback i.e. where do we go from here. In my experience, this part is what’s most deficient in current methods for PM feedback.
Most Execution problems are really 1) Strategy problems, or 2) Interpersonal problems, or 3) Culture problems
Good leaders execute well because they understand this. They fix the root problem.
Bad leaders struggle because they are always applying band-aids.
Of course, at times it is a real Execution problem.
Real Execution problems include:
A) Funding constraints
B) Team skill gaps
C) Tool issues
D) Org structure
E) Process problems
F) External dependencies
G) Technical complexity
H) Coordination complexity
In the majority of cases though, what is initially expressed as an Execution problem isn't an Execution problem at all.
It's more convenient to point a finger at these Execution problems when the root cause is actually a Strategy / Interpersonal / Culture problem.
-started by identifying the real goal
-decomposed vague concepts
-framed the right questions
-sought more data or experience
-listened to multiple perspectives
-assessed upsides & downsides
-examined your own biases
-acted like an owner
The frameworks & examples shared by @rahulvohra are superb
But perhaps even more important is the product philosophy: deeply understanding user motivations & psychology, and conceiving creative product solutions rather than the “safe” ones
If you want to check out the content right away, @chrishlad has created a nice thread summarizing this episode (but don't forget to also listen to the episode):
All else being equal, it’s often more prudent to prefer teams that tend to Over-Promise & Under-Deliver (OPUD) rather than teams that consistently Under-Promise & Over-Deliver (UPOD)
👇🏾
What I’ve observed in practice, within talented organizations:
OPUD teams tend to be ambitious for the user & the company. They aim high & might miss at times as a result.
UPOD teams tend to be ambitious for self first. They care more about survival & perception management.
"Over-Promise & Under-Deliver" teams might miss some of their promises, but they still usually end up with greater net productivity & impact than "Under-Promise & Over-Deliver" teams.