20 Questions from New Scrum Master to Product Owner

What should a new Scrum Master ask the Product Manager? Here are some suggestions that also provide a view on the product manager’s duties. I do not agree with all questions and all proposed answers, but it is definitely inspiring.

 

Addendum: I have created a resource stash for all things related to Software Product Management!

Better decision making

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:

  1. Imagine that the option you’re currently leaning toward simply vanished as a feasible alternative. What else could you do?
  2. 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?
  3. 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!

When to say YES to a Feature Request

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.

Killing a Feature

Killing a feature is a hard task for a product manager, because you can be sure that someone will complain, and that you break someone’s workflow.

But in order to build a great, focused product, you need to sunset a feature when it does not fit anymore.

Here is a guide on how to kill features properly:

  1. Confirm the condition is terminal
  2. Stop offering it to new sign-ups
  3. Divide users into two camps
  4. Announce end of life to remaining folks

Think in order of magnitudes

This has been a topic for some times: Google wants its employees to think in order of magnitude, not in percentages. They want people to grow the business/product by 10x, not 10%.

The calculations and business model behind this theme are irrelevant to my mind: The concept is all about mental attitude rather than money. People need to think big to build big things. So I have to agree.

Does software estimation make sense?

Richard Clayton wrote an post on why software estimation is useless which has received mixed responses.

He correctly points out the advantages and disadvantages of software estimates. While he concludes that estimation is useless, I conclude that it is useful despite the disadvantages. His only proposal to do better is to work until the budget is spent. (That makes sense when a story is indeed inestimable for some reason).

I believe that his approach may possibly work for paid project, but not for standard software development.

Ruthless prioritization

Maybe “Laws of Software Engineering” is a bit too high-aimed, but the logic is certainly true:

  • Your development team will never be big enough. You will always have more ideas than space for development
  • Therefore, you need to prioritize ruthlessly.

prioritization makes every single item on your backlog more important than one other and less important than one other. No two items have the same priority. Since you will never have sufficient resources to develop everything, you need to prioritize. Simple.