|
SIGDOC Newsletter
March 2006
:: Volume 7, Number 1
Features
"Meeting Your Audience and Gaining Customer
Insight, Part II by Rob Pierce Meeting Your Audience and Gaining Customer
Insight, Part II
By Rob Pierce
robertp@us.ibm.com
The first part of this paper presented the benefits of seeking out customer
input and some ideas on how to create opportunities to visit customers.
It included some of the challenges to initiating opportunities for direct
customer feedback along with some suggestions on how to overcome those
apparent obstacles.
This next installment describes some preparation requirements for setting
up customer meetings. It includes how you might establish appropriate
goals that will be interesting enough to the customer and useful for
you and your organization to ensure a successful meeting or information-gathering
session. The goals can also apply to getting indirect customer input
rather than having a face-to-face meeting. It also describes how the
goals might best be presented to the different contacts or stakeholders.
Part III will include some sample scenarios of customer visits and
a summary.
Establishing Goals
If the ultimate goal for information developers is to gain audience
awareness by receiving direct customer input, then that goal must be
further articulated
if it is to attract the time and attention from those who are already
busy doing their jobs and may not have much time or interest to provide
such input. While this is a blunt statement, it is a true one, both from
the point of view of the customer and of the account representatives
in your own organization.
The intent of the visits from a documentation perspective might be
to follow a game plan such as meeting customers of a given product, learning
how they use the product, presenting to them how we use the product
ourselves
in our organization, describing the documentation that supports the
product, possibly adding how we are redesigning the documentation as
role-based
Help, and asking for feedback on issues the customer may have using
the product, such as performing a particular user task, following a documented
procedure or finding information. While you may want to focus only
on
the documentation, the customer likely is only interested in the documentation
within the context of actual workflow or user tasks.
A simple, generic statement such as “the goal is to gather feedback
and input from customers to help enhance the documentation for future
releases in part by learning how some of the customers use our products
and the accompanying documentation,” will need a description with
a deeper level of granularity and a broader spectrum of topics to attract
a customer development team that uses the products for which you provide
documentation. Customer development representatives are not likely to
be interested in discussing the pros and cons of a Help system for two
hours.
Once you identify who the contacts are in a certain geographic or industry-specific
area, you’ll need to provide a list of what you hope to cover in
an actual meeting if your proposal is to gain traction.
For an upcoming release if you were restructuring your documentation
to a new information model such as a role-based Help system, or a use
case (or user task) information architecture, there will be potentially
large changes to the user experience when searching for information.
Even though the changes may be significant enhancements, the changes
must still be managed and presented in an appropriate manner. This information
to be presented and the feedback you would hope to gain would not only
be of value from a customer perspective but would also be of great value
from your own colleagues who work with customers as technical specialists
and account representatives. The technical specialists themselves may
provide prime examples of people playing the roles defined in your Help
system, even though the system was designed with the external customer
more in mind than the internal consumer (your colleague). Since the field
specialists may help design or implement customer solutions, they are
usually able to assess what information developers see as fitting into
each role's "bucket" of topics to see if it is logical or intuitive,
clear and consistent.
For example, if you were working on providing the Help topics for a
Developer role it would be beneficial to gather customer feedback and
input on
this new and enhanced restructuring. When meeting with customers, you
might be able to demonstrate a prototype of the newly designed Help system
and gather feedback on how the new solution is received. Gathering input
on how the field specialists use the product and also how the customer
uses it can be invaluable and of great benefit to improving what you
deliver and make it more usable for the customer.
In scoping out and planning for specific customer visits, I hoped to
meet with customers to discuss our product documentation and focus on
Help for schema developers and API reference Help. I also wanted to describe
and present, possibly as an actual product demonstration, the newly restructured
documentation and provide customers and field representatives the opportunity
to look at a “beta version” and test the searchability of
the technical information by searching for user tasks or reference topics
that might be of interest to them.
I planned to use as an example a change request submitted by a customer,
in fact, one of the customers I hoped to visit. I hoped to demonstrate
how I used our own product and the process by which we used it to ensure
that customer change requests, including documentation change requests,
were identified and acted on. In our workflow model, email notification
enabled me to see the request and fix it in less than 24 hours from the
time it was submitted by a Support person based on a customer call. In
our state transition model for this change request system, I performed
the following tasks: assigned the change request (CR) to myself, added
a note, reviewed existing information, activated the CR by changing the
state with an action such as “Work On,” checked out the relevant
documentation source file, which is a versioned object in a database,
updated it, checked the updated file version back in to the database,
resolved the CR by changing the state of the CR to “Resolve” (with
a status of “fixed, not validated,” since the fix still needed
to be included in an updated build of the actual product deliverable – in
this case the Help -- and then verified by a quality engineer). A Support
person receives an email notification for each state change so that she
can automatically see the current status of the CR, and when it is resolved
she can inform the customer of the fix.
I wanted to present this information to customers to see if they were
as impressed as I seemed to be. I also hoped to elaborate on this work
model and describe the workflow process use case of an integration with
some of our own tools to better synchronize the information and communication
in order to help facilitate the information flow between the Support,
Development, and Documentation organizations and the technical content
that is generated from these groups in the form of white papers, Support
technical notes, and product documentation deliverables.
It would also be beneficial to meet customers in order to demonstrate
new enhancements to the information we provide (that in part is based
on
new tooling we were using) that were intended to help aid the usability
of our product, and gather input from them so they can feel that they
have a direct connection to some of the development taking place in our
organization.
I hoped to make contact with customers that might provide great examples
of companies that:
- Had several organizations or business units or development groups
at distributed sites. These companies may be looking for a solution
provided by your company or they may want to create it themselves.
In addition
to buying a product, the customer may also be thinking in terms of
design, implementation of the product including not just its features
and functionality
but also its installation, configuration, performance, authentication
and authorization (based on user privileges). These are only some of
the examples of what a customer audience is contemplating as part of
the product and the information that needs to support the product.
- May be quite large but have a relatively small number of developers
whose work consolidates all development activities that are then rolled
out to the actual users of the solution for which your product was
purchased. Such companies typically offer an additional layer of documentation
for
their form of your products that describes their implementation and
user tasks for the product.
As a final opportunity in each meeting, I wanted to provide customers
with the opportunity to share their relevant user tasks, review what
is proposed, and to let them voice any requests, concerns, complaints,
or other insights. For example, they might have concerns about...
- Authentication and authorization support and documentation
- Programmatic
(API or Web Services) support for the product
- Performance issues,
considerations, and concerns
- Information on the product working in
a distributed environment
- “Beta release" version feedback
of documentation
As stated before, gaining input from the customer representatives
for these same items would also be extremely valuable.
Restructuring documentation by roles, such as a User role, an Administrator
role, and a Developer Role, each as a component in a Help system,
is an example that would certainly benefit by customer input both
before
the new information architecture is designed and implemented and
after it's been tested, delivered and used by customers for future
enhancements.
A specific person working for a company that is your customer may
have a job that aligns with more than one defined role in a given
Help system.
For example, a consultant who helps implement customer solutions
may take on both the Administrator and Developer roles to complete
a solution.
I also hoped to gather customer feedback and input on the new and
enhanced restructuring/packaging, when meeting with customers. Part
of what
I wanted to demo for them and to gather feedback on was the new solution
we provide for the Developer role (in addition to the reference information,
code examples, and code details, if they want that level of technical
detail). Gathering input on how the field reps use the product and
how
the customer uses it would be of great benefit to improving what
we deliver and help to make it more usable for the customer in future
releases.
Roles do not necessarily translate to different people, however and
because the product is highly customizable and thus open-ended for
information
to provide, it was not entirely clear what would be the most beneficial
list of user tasks to document and how open-ended or specific they
should be.. For example, if there are 15 ways to do something, how
many do you
describe? As in other information development projects, since 80%
of the user tasks map to 20% of the functionality or most common
user
tasks, it seemed reasonable to describe what we thought were the
primary user
tasks. Getting input from real customers would help validate our
design strategy and the primary user tasks identified.
I worked with a field specialist who had been a good reviewer of
technical content in the past and an account manager/ representative
who could
make contact with the appropriate customer personnel for meetings.
In this case, this meant trying to set up two or three customer meetings
to help demonstrate, promote, and gather feedback for the product
documentation for which I am responsible. I hoped to visit customers
or partners
along
with the field specialist or account representative who already had
a relationship with the customer to help enhance the customer user
experience
by enabling them to express, in their own terms, how they use the
product and what they need or would like to see. It would also be
an opportunity
for me to describe the new role-based Help that will be delivered
in the next full release for our software product.
I learned that some contacts to work with for setting up customer
visits included:
- Field representatives, who are technical specialists who work with
customers providing solutions with the products
- Technical Manager,
typically a manager of the field reps
- Account representatives, who
service specific customer accounts (for example, customer accounts
A and B in this article)
- Account Managers, who manage account reps.
for specific customer accounts (for example, customer account C in
this article)
- A Technical representative, who works with account
reps.
Before the meetings were ever scheduled or even proposed
to prospective customers, I was first asked by the account
and field
reps
and by the managers to state the goals or intentions of the meetings,
in order to enable the reps to present the information to the
customers. Meeting goals included:
- Demonstrating the new role-based Help in general and the schema
developer role in particular.
- Gathering customer feedback on existing product documentation
and user tasks (which may or may not be currently documented).
- Ensuring that what I am developing for upcoming deliveries/releases
meets the needs of the customers.
- Demonstrating and gathering
customer feedback on the effectiveness of the "searchability" or
usability of content - for finding what they might be looking for.
- Generating a list of future enhancement requests, based on the
customer feedback, for inclusion in future releases of product
documentation.
The email and telephone correspondence that occurred in order to communicate
these messages took place over a number of weeks. The response
was favorable
by both the account representative and the customer development
teams, so the strategy worked and three customer meetings
were set up (to
take place over a two-day period, in London). Each visit
was scheduled to
last two hours, and I would be accompanied by either a field
rep or account rep.
Overall, the goals of the trip would be to meet customers, learn
how they use our product, present to them how we use our product, how
we are redesigning the documentation to role-based Help, and get their
feedback on issues they have using the product, developing a schema,
and finding information. I would need to map out a game plan for the meetings.
Note that in this article, there is no mention of getting management
buy-in for the cost of conducting these meetings, including travel.
It is true that selling the concept to the on-site representatives
may not be as large an issue as getting buy-in to receive travel
expense funding, though this issue is beyond the scope of this article.
The final part of this three-part article will appear in the next
issue of this Newsletter and will describe the three customer visits.
back to top
|
