Today we’ll consider responses to two more questions from the Global Study of Product Team Performance. How do your organization’s practices compare to the findings shared by survey participants?
Question: How do you track, review, and develop ideas from your employees, customers, and suppliers? (Check one.)
|We have no formal processes and systems in place to track, develop, and manage ideas. It’s mainly done through emails, spreadsheets, and occasional brainstorming sessions.||48.2%|
|We use our CRM tool to store and manage ideas from our employees and customers.||14.2%|
|We have developed our own in-house solution using a portal and document management system.||15.4%|
|We use an off-the-shelf, cloud-based (or on premises) idea management system.||18.6%|
What Responses Tell Us
Nearly half of all respondents (48.2%) indicated that their organizations have no formal system for tracking, developing, and managing ideas. Other responses were more equally distributed including use of a CRM tool (14.2%), reliance on an in-house solution (15.4%), and use of an off-the shelf cloud or premises-based system.
Question: What criteria do you use to prioritize requirements? (Check all that apply.)
Criteria to Prioritize Requirements
|Everything is a priority (nothing is a priority)||10.7%|
|Thumb in the wind||11.5%|
|Size/influence of customer||59.9%|
|Technical (architecture, stability, scalability)||46.8%|
|Risk (technical risk, market risk, product risk)||44.4%|
|Key internal stakeholder influence||38.9%|
A Closer Look at Responses
Nearly 60% of respondents indicated that the size/influence of a customer is a primary way their organizations prioritize requirements. Respondents also highly rated development cost (54.0%), revenue (50%), technical criteria (46.8%), risk (44.4%), profitability (42.1%), and key internal stakeholder influence (38.9%). It is reassuring that thumb in the wind and treating everything as a priority ranked much lower as criteria for prioritizing requirements. These two earned just 11.5% and 10.7% responses respectively.
Next week we’ll take a closer look at team product backlog. We’ll also consider which product development requirement format makes on-boarding new employees easier.