3 ms·

Product planning should always be done in a tree structure. The top nodes are business objectives, then under them are products, then under them are customer pr

Product planning should always be done in a tree structure. The top nodes are business objectives, then under them are products, then under them are customer problems, then under them are backlog items. Saying you have too many backlog items typically means you don't have the proper structure set up, and probably also don't have a prioritized list of business objectives to work from. "Talking to customers" is great for understanding customer problems, but know your business objectives first. Else you'll waste time gather feedback in areas you won't work on anyways.

mason55 3y ago
A good search term for this is "opportunity-solution tree". Basically what you said, first you identify a business opportunity, then you customer-facing outcomes that would help you achieve the business opportunity, and THEN you identify solutions that help deliver those customer outcomes. E.g. You discover a business opportunity to build a simpler confabulator. Step one is to identify the different possible outcomes for customers that would indicate you had successfully built something simpler. Identifying what that means is actually hard. Maybe lots of people say they want something simpler, but to some people that means "less data to manually input" and to other people it means "better guidance in the configuration process". So there's value in this step on its own - it helps clarify your thinking and gives you ways to know if you're successful. And THEN you can identify solutions to help achieve those customer outcomes. Maybe for the "better guidance" one you have possible solutions of improving the UI or integrating an LLM to answer questions. But since you've tied it to a real outcome for customers, you can do a better job evaluating those options. It's hard work but the process does a much better job leading to coherent solutions vs. "bucket of features".

mason55 3y ago

A good search term for this is "opportunity-solution tree". Basically what you said, first you identify a business opportunity, then you customer-facing outcomes that would help you achieve the business opportunity, and THEN you identify solutions that help deliver those customer outcomes. E.g. You discover a business opportunity to build a simpler confabulator. Step one is to identify the different possible outcomes for customers that would indicate you had successfully built something simpler. Identifying what that means is actually hard. Maybe lots of people say they want something simpler, but to some people that means "less data to manually input" and to other people it means "better guidance in the configuration process". So there's value in this step on its own - it helps clarify your thinking and gives you ways to know if you're successful. And THEN you can identify solutions to help achieve those customer outcomes. Maybe for the "better guidance" one you have possible solutions of improving the UI or integrating an LLM to answer questions. But since you've tied it to a real outcome for customers, you can do a better job evaluating those options. It's hard work but the process does a much better job leading to coherent solutions vs. "bucket of features".