Feedback Should Not Be An Echo Chamber

1,663 views

Published on

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.

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,663
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
16
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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).
  • Feedback Should Not Be An Echo Chamber

    1. 1. Feedback Should Not Be An Echo Chamber<br />Tom Grant, Senior Analyst, Forrester Research<br />Silicon Valley Product Camp 2011<br />
    2. 2. My research agenda<br />Do our ideas translate into customer value?<br />INNOVATION<br />CUSTOMERS FOR<br />THE TECHNOLOGY<br />What should we be delivering?<br />PRODUCTS<br />How can we adapt and deliver quickly?<br />AGILE<br />REAL CUSTOMER VALUE<br />How do we understand what the customer values?<br />SOCIAL MEDIA,REQUIREMENTS<br />THE DEV TEAM<br />Isn’t software part of every product?<br />“DIGITAL PRODUCTS”<br />Who’s ensuring that the overall process works?<br />PRODUCT MANAGERS<br />What’s the best timeline for delivering?<br />ROADMAPS<br />How can we make better decisions?<br />SERIOUS GAMES<br />MANAGE WITHIN<br />EXTEND BEYOND<br />
    3. 3. The echo chamber<br />Preference for own ideas<br />Internal politics within a team<br />Unrepresentative internal betas<br />Leading questions<br />Customers who are not 100% honest<br />Lack of context for a request<br />Wrong language for explaining request<br />
    4. 4. WHAT ASPECTS OF REQS. MATTER<br />Source<br />Type<br />Audience<br />Outcome<br />Accuracy<br />
    5. 5. OUR SCENARIO<br />Internet and intranet collaboration tool<br />Add-on to MSFT SharePoint<br />Designed for cross-functional teams<br />Shipped version 1.1<br />Considering an add-on for MSFT Office Live<br />Also considering support for Google Docs, Zoho<br />First adopters = professional services companies<br />In particular, 5 big customers<br />Strong opinions in the development team<br />
    6. 6. SOURCE<br />What are the plausible sources of requirements?<br />How do you collect this information?<br />How reliable is the information?<br />How much work is required for a sufficient level of reliable information?<br />
    7. 7. TYPE<br />Is this information about you or the customer?<br />How much depth does this information provide?<br />How can you ensure that the information is representative?<br />What sort of impact does this information have?<br />
    8. 8. AUDIENCE<br />For whom is this information intended?<br />What data model works for them?<br />Is it possible to standardize the information?<br />
    9. 9. OUTCOME<br />What are the decisions or actions in which this information will be used?<br />When do you know that this information had a successful impact?<br />How might you need to adjust the information, over time?<br />
    10. 10. ACCURACY<br />How many sources of requirements do you need?<br />Which information do you need to build over time?<br />Which information do you need to update regularly?<br />How do you do retrospectives on this information?<br />How can requirements shake up comfortable assumptions?<br />
    11. 11. Thank you<br />Tom Grant<br />650.581.3846<br />tgrant@forrester.com<br />Blogs.forrester.com/tom_grant<br />@TomGrantForr<br />www.forrester.com<br />

    ×