SIGDOC Newsletter
June 2006
:: Volume 7, Number 2
Features
"Meeting Your Audience and Gaining Customer
Insight, Part III" by Rob Pierce
Meeting Your Audience and Gaining Customer
Insight, Part III
By Rob Pierce
robertp@us.ibm.com
In the first part of this paper, the benefits of seeking customer input
and some ideas on how to create opportunities to visit customers were
presented. It included some of the challenges of initiating opportunities
for direct customer feedback along with some ideas on how to overcome
those apparent obstacles.
The second part of this paper covered some of the preparation requirements
for setting up customer meetings. It included how you might determine
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 instead of a face to face meeting. It also described how
the goals might best be presented to the different contacts.
This part describes details of actual customer meetings that we held.
The format for each meeting varied, depending to some extent on how satisfied
the customer was. Contrary to my expectations, more satisfied customers
had more requests for product or solution enhancements, while less satisfied
customers tended to want resolution of existing issues; they did not
take as long term a view. Both types of customers, however, were able
to focus in on existing deliverables and in fact, the less satisfied
customer gave more critical feedback on Help systems and searchability
of technical content - perhaps because they were looking for information
more urgently than the satisfied customers who had fewer technical issues.
The customer visits
I recently had the opportunity to meet customers and better understand
how they use some of our products and how they do their work (their process
using the tools) and what they want to accomplish. In this case, the
phrase "outside in development" translated for me to "getting
customer input and reviewing real use cases," to help provide better
solutions. I also was able to demonstrate new enhancements to the information
we provide that was designed to improve the usability of our product,
and gather input from the customers in part so they could feel that they
have a direct connection to the development and information development
activities within our organization.
In this particular instance, the products are software development
tools and middleware - the software that in essence is the monitor and
motor
that controls a system. The biggest audience of middleware documentation
may be the application development companies that create industry or
company-specific solutions but there is also a large audience within
the IT departments of companies that create software for their companies.
And while user documentation on how to use a product might apply to large
company’s user population, the number of developers who set up
the environment for those users might be relatively small though the
information they required was very technical and needed to be easily
located by the customers.
The goals of my trip were to gather feedback and input from customers
by first presenting to them how we use our product and the strategy of
our information deliverables described as roles and use cases, and determining
how the customer could find the information they were looking for as
well as obtain their input on the quality and completeness of that information.
The customers
- Customer A - A customer who wished to consolidate all development
activities using the tools and processes of our company products. This
was a newer
user of our products.
- Customer B – An existing customer using distributed tools
and processes that was very experienced with our products.
- Customer C – A customer about to roll out our products and
purchase a many new licenses, though they currently use the products
within a
smaller context in their organization and work with technical consultants
from our company
Other types of customers that I did not meet who would also be very
useful are internal customers or partners who provide solutions with
our products
which they then sell to their customers. For example, several consulting
firms build software or services for building composite applications
and solutions. These are commonly application development companies
that create industry-specific solutions, such as automotive or health
care
software applications. With three meetings scheduled over a two-day period, each set for two
hours in duration, I knew that a consistent game plan would help keep
the meetings focused and more productive than if there were no structure.
And since each customer was a user of the same products, I planned to
give a similar presentation and ask similar questions to each customer.
What I expected, and what the customer representatives let me know in
advance, was that there would be differing levels of customer satisfaction.
One customer was very happy with the products and service, another one
was pleased but was having some difficulties with deployment, and another
liked the product but was always pushing for more enhancements. All the
customers would likely discuss their use cases, pain points and requests
for enhancements.
The game plan
The game plan that I established for leading each meeting
was to:
- State the intention of the meeting and goals that I hope to achieve
- Describe how we use our own products to help address and resolve
customer requests in our Development organization.
- Describe our workflow process using our own product in our organization
- Describe a primary use case for how our organization uses our
own software product solution as part of our development process to
help
demonstrate,
to the customer, the use case, associated process and best practices.
For example, I planned to use an actual change request record from
our development database that was submitted by Support based on a customer
issue (in fact the first customer I was meeting) to show them how our
solution helped enable me to resolve the issue in less than 24 hours,
even though the request came from Europe and I was in the United States.
- Ask customers how they use our product and identify their primary
use cases and role and responsibilities.
- Listen to how the customer uses the product and pay attention
to what they do, what they need to do or are trying to do, and what
are
their
pain points, issues, requirements or requests for enhancements.
- Ask customers about performance issues or implementation pain
points and let our technical representative provide specific technical
details
of our company use of the product and deployment model for issues
faced when deploying across multiple locations over a widely distributed
area.
- Ask customers to assess the effectiveness of the documentation.
Customers would have the opportunity to offer input on current release
and newer beta versions of the documentation, including Reference and
role-based Help.
Each of the three meetings described below was extremely useful in
several ways. Listening to the customer describe how they used the product,
how
they wanted to use the product, and how they searched for information
was very interesting and helped my awareness of their needs when I develop
newer information in the future. Also, by listening to the ways and terms
they used to describe all aspects of their using the product and information,
and noting the terminology they used helped me to note additional points
of entry to information that I would try to use for future enhancements
for searching for information. For example, by noting the customer terminology,
I would be able to confirm existing, and create additional, index entries
and keywords in current documentation that would enhance future searching
capabilities.
Meeting 1, with Customer A
9:30 Met with account representative, and a technical field representative
to discuss the customer account including who we would be meeting, technical
details of the customer’s use of our products and some current
pain points or issues. We then went to the customer work site.
10:00-12 Met with the Tools and Development process team lead and manager
and two of his development team leads.
The customers first discussed:
- Their primary use cases
- Current integrations with other software products or services
- Goals and pain points
- Implementation and configuration details. They use our products
in a distributed environment but have some issues with database mastership
since they feel that mastership would need to constantly change for
their
distributed Development organization’s three different development
sites.
The customer first described some enhancements to the product that
they would like to see. Then they discussed the technical information
we provide
with our products and online. Because Customer A is interested but new
to much of our products, the need for more conceptual information, such
as that commonly found in white papers, was described as being important.
Meeting 2, with Customer B
8:30 Met with account manager, account representative, and a technical
field specialist to discuss the customer account including whom we would
be meeting, technical details of the customer’s use of our products
and some current pain points or issues. We then taxied to the Customer
work site.
10:00-12 Met with two chief developers who are also team leads who
design, develop, deploy, and maintain their company’s software
systems.
After discussing their current workflow using the product and
then describing
planned enhancements in their system, Customer B stated that they would
like:
- Online support that makes it easy to find information they are
looking for.
- A logical hierarchy of information for the packaging of bundled
product information.
- Customizable Help.
At the conclusion of the meeting one of the lead developers walked
us to his office and provided us with a demonstration of their software
system and how they use it. The opportunity to see an actual implementation
of what our product documentation describes how to do was very interesting
and of great benefit for future information development. When you can
see what the customer is actually trying to do, and hear how they describe
the tasks they do with the product, you gain invaluable customer insight.
And in fact, this particular customer had developed a software solution
with our product that was more innovative, creative, and certainly realistic
than I had imagined.
Meeting 3, with Customer C
12:15 Met with account technical field specialist who provides consultation
on their system solution from a software and performance perspective.
We discussed the customer’s system design and implementation. This
individual was an active reviewer of the existing documentation and provided
both ongoing input and made requests for development enhancements.
2-4 pm Met with the Account representative for this customer and also
the account manager for the region, as well as three developers from
Customer C, who used our products to help manage and develop creative
software solutions for their company’s work force.
These Customer C professionals designed and implemented, with the help
of consultants, software applications that were deployed across their
organization, which 1000 users then used in their daily work, in a
distributed environment around the world. I find it interesting that
for this customer,
the audience for our developer-role technical documentation for creating
a software application was two or three people in their organization,
while the user-role documentation for using that application would
be 1000 people.
The feedback from the developers was largely composed of a wish list
of improvements they would like to see in the product. For example,
they want:
- Capability for creating their own Help component that enables
them to make information customizable and self-indexing. Also, enable
the Help text to be extendable and customizable.
- Books rather than HTML Help.
- Better quality and searchability for technical content, particularly
for technical notes (which they look for and read). Release
notes they do not read, they said.
- Improved consistency for describing pieces of information that
may be covered in different repositories such as the documentation
set,
an online Web site, or in technical notes.
- Better information updates for changes in a product or service
related to versioning and licensing issues or requirements
from release to
release. Customer agreed that this type of information
could be provided as technical
notes rather than in the documentation set.
- More technical information on customizations and other
advanced concepts in the documentation.
Overall summary of documentation feedback
Customers raised similar issues about their particular
schema and deployment and some cited performance issues
or tradeoffs
that
were required to
implement a solution. However, considering tradeoffs
is always likely be the case with software development, since
time
to develop, cost
to deploy, and complexity to maintain and prevent conflicts
are usually not complementary variables in creating
a software application
and
system
solution. But all customers were highly articulate
and provided constructive feedback.
All customers agreed with the logic of re-planned role-based
Help and that Reference content should not be included
within any one
role but
should be placed at the same level as the roles,
in the information hierarchy or architecture. Customers
also
provided valuable
input on their primary
use cases and pain points in developing a schema
that worked for a diverse group of original database repositories
with
differing record
types,
fields, states, permission, and policies. All have
created their own schemas from the bottom up and
not based their
schemas on
something
out of the box.
Customers noted that the quality of the technical
content was rated much higher than the capability
to search
and find the
information.
They agreed
that better use case searchability would greatly
enhance the documentation deliverables.
Customers agreed on the defined primary use cases
for the role-based Help I was responsible for.
For example,
for
the schema developer
role, the primary use cases were:
- Customizing a schema
- Modifying a schema
- Testing changes
- Using hooks
- Working with forms
- Applying packages
For most of our customers the audience for our
Developer or Administrator role-based
Help is a relatively
small number of people who create,
customize, or maintain a software
application. Conversely, the less technical user-role
documentation for using the software
application (developed for the Users in the customer
organization) can be
quite large.
Sometimes,
customer
organizations develop their own
documentation as additional user-role information
for their version
of the applications
they develop.
The
additional content is developed
by contractors, consultants, or in-house technical
writers.
Customers search for and use technical
content that is available in
different repositories
such as online
information
on a
Web site, in
technical notes,
and in the documentation set.
However, the different repositories and
current search
capabilities across these repositories
makes it difficult
to searching effectively for
information.
As part of the overall customer
wish list for technical content,
they
want to be
able to:
- Have highly configurable
Help systems
- Export Favorites to send
collections of links
to team members
- Print a Help page from
a right click context
menu
- Print all subtopics
of a Help entry
- Email a current page
- Improve the search
and index capabilities
by storing
previous
searches
- Have quick performance
for all documentation
launches,
linking, and searches
- Have highly
linked
information between
all technical
content
and resources. If all the
documentation
is
consolidated
for all
products, provide a
selection
box to
restrict
the searched material
- Provide indexes
that
are not only alphabetic,
but
also
ordered by product
and usage
or role
or use case
(for example, user
administration,
managing
databases, managing
customizations,
upgrading
packages)
- Have links
to
the product user
groups,
online
Web pages and
other
product-related resources
- Have
links
to other articles
and
documents for a
given product
Conclusion
How do you take the information you’ve gathered and put it
to good use? You can start by sharing your findings with members
of other business
units or departments within your organization.
Sharing the information can help to improve both the product in general
and the information you provide for the product in particular. Possible "next
steps" for ensuring that there is follow-on action after the customer
meetings might include providing the following:
- Information to in-house developers who may talk with a customer
or resolve some customer issues in future releases
- Customer feedback to Documentation groups within the business
unit for future improvements to the documentation deliverables
- Information to management who want to see and are willing to support
improvements to the user experience
Customers feel that accurate and relevant use cases are
more important than defined roles or role-based Help since each person
does not strictly
wear one hat all the time, and often fills different roles. In addition,
not all use cases fit strictly into one defined role.
Industry-specific customers are similar in what they are trying to
accomplish with the product though they may have different scenarios
(states and
actions) based on different system design, workflows, and implementation
details for these customizable products.
Meeting actual customers who use the product and may be using it in
more innovative ways than you’ve imagined is very exciting and useful
for motivating you to always consider the user experience in what you
do.
back to top
|
