Yesterday, I wrote that product managers should not rely on SMEs as their primary source for requirements. I will now go further and state that, to the extent that a company hires a product manager or business analyst to interact primarily with SMEs, the role names "product manager" and "business analyst" are misnomers.
I see this problem often in companies. They believe they already know the requirements (often confused with design); they are just looking for someone to document them so that developers can get to work. They call the person who does this documenting a "product manager" or "business analyst", but this person in fact has only a small - and very tactical - subset of the responsibilities that these roles entail.
In my opinion, this problem is largely responsible for the misconception that SMEs are primary sources for requirements.
The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos
Comments