feedback should not be an echo chamber
DESCRIPTION
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.TRANSCRIPT
© 2011 Forrester Research, Inc. Reproduction Prohibited1 © 2009 Forrester Research, Inc. Reproduction Prohibited
Feedback Should Not Be An Echo Chamber
Tom Grant, Senior Analyst, Forrester Research
Silicon Valley Product Camp 2011
© 2011 Forrester Research, Inc. Reproduction Prohibited2
CUSTOMERS FOR
THE TECHNOLOGY
THE DEV TEAM
REAL CUSTOMER
VALUE
MANAGE WITHIN EXTEND BEYOND
Who’s ensuring that the overall process works?
PRODUCT MANAGERS
How can we adapt and
deliver quickly?
AGILE
Do our ideas translate into customer value?
INNOVATION
How can we make better decisions?
SERIOUS GAMES
What should we be delivering?
PRODUCTS
What’s the best timeline for delivering?
ROADMAPS
Isn’t software part of every product?
“DIGITAL PRODUCTS”
My research agenda
How do we understand what the customer
values?
SOCIAL MEDIA,REQUIREMENTS
© 2011 Forrester Research, Inc. Reproduction Prohibited3
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
© 2011 Forrester Research, Inc. Reproduction Prohibited4
WHAT ASPECTS OF REQS. MATTER
Source
Type
Audience
Outcome
Accuracy
© 2011 Forrester Research, Inc. Reproduction Prohibited5
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
© 2011 Forrester Research, Inc. Reproduction Prohibited6
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?
© 2011 Forrester Research, Inc. Reproduction Prohibited7
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?
© 2011 Forrester Research, Inc. Reproduction Prohibited8
AUDIENCE
For whom is this information intended?
What data model works for them?
Is it possible to standardize the information?
© 2011 Forrester Research, Inc. Reproduction Prohibited9
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?
© 2011 Forrester Research, Inc. Reproduction Prohibited10
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?
© 2009 Forrester Research, Inc. Reproduction Prohibited
Thank you
Tom Grant650.581.3846
Blogs.forrester.com/tom_grant
@TomGrantForr
www.forrester.com