Your SlideShare is downloading. ×
0
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Feedback Should Not Be An Echo Chamber
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Feedback Should Not Be An Echo Chamber

1,432

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 …

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,432
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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).
  • Transcript

    • 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

    ×