This chapter is from the book
This chapter is from the book
This chapter is from the book
Harnessing Feedback
Marketects typically use the following formal and informal, external and internal feedback loops to ensure that they receive the data they need to make sound decisions:
-
Organizing and/or attending user conferences (their own and competitors)
-
Reviewing first- and second-line technical or product support logs
-
Reviewing feature requests generated by customers
-
Interviewing salespeople for features they believe would significantly improve the salability of the product (often referred to as a "win/loss analysis")
-
Meeting with key customers or advisory groups
-
Meeting with industry or market analysts
Tarchitects employ similar feedback loops to stay abreast of technological trends. Conferences, magazines, mailing lists, home computers, and insatiable curiosity all provide them with data.
Drawing from different data sources results in divergence between the tarchitecture and marketecture maps described in the previous section.
Fortunately, the creation and ongoing maintenance (e.g., quarterly updates) of these maps are the best ways to prevent divergence and to share data. Other helpful techniques include making the raw data that informs these maps available to both marketects and tarchitects. For example, marketects usually obtain primary market data via user conferences or focus groups. Inviting marketects to these events is a great way of reaching consensus on key issues. Marketects, in turn, should be open to reading the key technical articles that are shaping their industry or tarchitecture, and the tarchitect is a key source for such articles. Note that my goal isn't to change the naturally different information-seeking and -processing methods of marketects and tarchitects but to make certain that the subset of data used as a source for key decisions are available to everyone on the project.
What if They Say Something They Shouldn't?
One simple and effective strategy for leveraging primary feedback is to ask your developers to work directly with customers. Several of my clients have been Silicon Valley startups. One created a marketplace for intellectual property licensing and for several years ran a user conference to actively seek feedback from customers on current and proposed product offerings. What made this conference unique was that nearly the entire development staff was present to make presentations, conduct demos, and work with key customers. This direct involvement was a key element of the company's ability to build products that its customers truly wanted.
Of course, you might be thinking, "I'm not going to let my developers talk with customers. What if they say something they shouldn't?" This fear may be real—sometimes developers do say things that they shouldn't—but in practice it isn't that big a risk. If you're really concerned, give your developers the following guidelines:
-
Don't make any promises on priorities.
-
Don't make any commitments.
-
Don't talk negatively about our product or our competitors' products.
-
Don't say, "That should be easy." It sets expectations too high and can kill any negotiation to have the customer pay for the modification.
-
Don't say, "That's too hard." It can prematurely stop conversation about what the customer really wants and ways to achieve this.
-
Listen nonjudgmentally. They are your customers, and they're not stupid. They might be ignorant, but they're not lazy. They might have priorities you don't know about. They're neither your fan nor your adversary.