Feedback Should Not Be An Echo Chamber
•Download as PPTX, PDF•
3 likes•1,333 views
Product teams are prone to the same tendencies in every organization, to increasingly turn conversations with customers about what they want into an echo chamber of what the product team wants to hear. This session explores some of the sources of the echo chamber, and through informal discussion, identifies some techniques to overcome it. The goal is to show the strengths and weaknesses of different sources of ideas and requirements, and chart a strategy for building an overall requirements strategy.
Recommended
Recommended
More Related Content
What's hot
What's hot (15)
Viewers also liked
Viewers also liked (17)
Similar to Feedback Should Not Be An Echo Chamber
Similar to Feedback Should Not Be An Echo Chamber (20)
More from Tom Grant
More from Tom Grant (8)
Feedback Should Not Be An Echo Chamber
- 1. Feedback Should Not Be An Echo Chamber Tom Grant, Senior Analyst, Forrester Research Silicon Valley Product Camp 2011
- 2. My research agenda Do our ideas translate into customer value? INNOVATION CUSTOMERS FOR THE TECHNOLOGY What should we be delivering? PRODUCTS How can we adapt and deliver quickly? AGILE REAL CUSTOMER VALUE How do we understand what the customer values? SOCIAL MEDIA,REQUIREMENTS THE DEV TEAM Isn’t software part of every product? “DIGITAL PRODUCTS” Who’s ensuring that the overall process works? PRODUCT MANAGERS What’s the best timeline for delivering? ROADMAPS How can we make better decisions? SERIOUS GAMES MANAGE WITHIN EXTEND BEYOND
- 3. The echo chamber Preference for own ideas Internal politics within a team Unrepresentative internal betas Leading questions Customers who are not 100% honest Lack of context for a request Wrong language for explaining request
- 4. WHAT ASPECTS OF REQS. MATTER Source Type Audience Outcome Accuracy
- 5. OUR SCENARIO Internet and intranet collaboration tool Add-on to MSFT SharePoint Designed for cross-functional teams Shipped version 1.1 Considering an add-on for MSFT Office Live Also considering support for Google Docs, Zoho First adopters = professional services companies In particular, 5 big customers Strong opinions in the development team
- 6. SOURCE What are the plausible sources of requirements? How do you collect this information? How reliable is the information? How much work is required for a sufficient level of reliable information?
- 7. TYPE Is this information about you or the customer? How much depth does this information provide? How can you ensure that the information is representative? What sort of impact does this information have?
- 8. AUDIENCE For whom is this information intended? What data model works for them? Is it possible to standardize the information?
- 9. OUTCOME What are the decisions or actions in which this information will be used? When do you know that this information had a successful impact? How might you need to adjust the information, over time?
- 10. ACCURACY How many sources of requirements do you need? Which information do you need to build over time? Which information do you need to update regularly? How do you do retrospectives on this information? How can requirements shake up comfortable assumptions?
- 11. Thank you Tom Grant 650.581.3846 tgrant@forrester.com Blogs.forrester.com/tom_grant @TomGrantForr www.forrester.com
Editor's Notes
- Delete second Name/Title if not needed, but be sure to keep the Month Day, Year information. For a teleconference, after the date, add a period and “Call in at XX:55 p.m. Eastern time” (change the time to five minutes prior to the start of the teleconference).