I stumbled across a post about better decision making for product managers. It encourages to pose three questions for each decision with larger (expected) impact:
- Imagine that the option you’re currently leaning toward simply vanished as a feasible alternative. What else could you do?
- Imagine that the alternative you are currently considering will actually turn out to be a terrible decision. Where could you go looking for the proof of that right now?
- Six months from now, what evidence would make you change your mind about the choice you’ve made? What would make you double-down?
Read the explanations in the full post “How to avoid the curse of knowledge“.
Addendum: I have created a resource stash for all things related to Software Product Management!
Last week, I linked a very good post about how to say NO to a feature request. But then, when should you say YES to a feature request? There are a couple of questions to answer:
- Does it fit your vision?
- Will it still matter in 5 years?
- Will everyone benefit from it?
- Will it improve, complement or innovate on the existing workflow?
- Does it grow the business?
- Will it generate new meaningful engagement?
- If it succeeds, can we support & afford it?
- Can we design it so that reward is greater than effort?
- Can we do it well?
- Can we scope it well?
I especially like to way to look on long-term cost.
Obviously, it is not feasible to develop every single feature request people have. There are various reasons to say NO most of the time, and this article give good advice on how to argue with requesters. I highly recommend it.
Decision making is one of a product manager’s core activity. Read this wonderful list and decision-making techniques to be prepared for every scenario there might be.