Naive question here. I have always run as a small org or just me, on one or two self-contained products. But isn't there a standard view on separately logging two VERY different things? I.e. tracking of customer reported problems, vs. tracking of potential solution work?
#1. Customer reported problems/desires, with a focus on a particular customer's pain, their viewpoint on solutions, etc.
A long back log of #1 customer pain points makes sense to me, especially if you can link new ones to related old ones, and review them in order of urgency, recency, magnitude of customer pain and number of related incidents.
Groups of related pain points could even be triaged as rationale's for potential new adjacent products, as apposed to potential feature work. Without getting into any design work.
#2. Feature work tickets, filled out with rich info on what wide-spread or critical customer problem has been selected to be solved. How it fits into the business plan, product plan, development schedule and design plan etc.
This seems like a list that should be kept relatively small. A backlog of #2 feature to-do's suggest a lot of wasted initial/pre design work, on problems that never reached a critical level or product fit. Also designs without serious development plans quickly turn into useless busy work.
This separation also allows list #1 to be managed by customer relationship roles, and list #2 by product planning roles. With coordination as problems get prioritized for product planning treatment.
--
Spit balling and looking for feedback! I have not encountered this problem before, but am scaling up staff for a product suite with many more potential directions than we could built out without ruthlessly organized prioritization.
#1. Customer reported problems/desires, with a focus on a particular customer's pain, their viewpoint on solutions, etc.
A long back log of #1 customer pain points makes sense to me, especially if you can link new ones to related old ones, and review them in order of urgency, recency, magnitude of customer pain and number of related incidents.
Groups of related pain points could even be triaged as rationale's for potential new adjacent products, as apposed to potential feature work. Without getting into any design work.
#2. Feature work tickets, filled out with rich info on what wide-spread or critical customer problem has been selected to be solved. How it fits into the business plan, product plan, development schedule and design plan etc.
This seems like a list that should be kept relatively small. A backlog of #2 feature to-do's suggest a lot of wasted initial/pre design work, on problems that never reached a critical level or product fit. Also designs without serious development plans quickly turn into useless busy work.
This separation also allows list #1 to be managed by customer relationship roles, and list #2 by product planning roles. With coordination as problems get prioritized for product planning treatment.
--
Spit balling and looking for feedback! I have not encountered this problem before, but am scaling up staff for a product suite with many more potential directions than we could built out without ruthlessly organized prioritization.