Requirements that you didn't know were there (Write the Docs Europe 2017)

Requirements that
you didn’t know
were there
Lesia Zasadna, InfoDev – ELEKS Ltd.
Write the Docs Europe 2017

My talk is basically about
closing the gap between
what our customers say
they want now…
Requirements that you didn’t know were there, by Lesia Zasadna
e.g.,
…and what they may
ultimately want.
eternal
glory
API docs

Why should customer’s heartaches matter to us?
Isn’t it enough just to be doing our job well
and delivering good quality docs?

Recently, our documentation
team got decreased from 3 to 2
people because of budgeting
shortages.
The customer was satisfied
with our services, but we
weren’t a critical piece
of the puzzle. And so, the
first to be let go.
Bye!

We did our job well. Our docs
were accessible, scannable,
accurate, complete, user-friendly.
But for some reason, it wasn’t
enough. We still got cut down.
We started searching for ways to
make documentation
indispensable in a way that really
mattered to our customer.

We assumed that what mattered to their business
was revenue and decided to make our docs
generate more income for the customer.
So, we gathered info, collected analytics, improved
our docs, and got more profitable. It was a success.
But surprisingly, this did not change the attitude
to docs as much as we expected.

So, we adapted. By that time, we
knew our documentation’s short-
term benefits and revenue
targets (e.g., API docs could cut
the time for onboarding new
front-end developers).
We went on and analyzed if our
documentation fit into the long-
term goals – bigger strategies like
knowledge sustenance or
content digitalization.

We adapted, again. And again, this helped, but
only by a small margin.
Looks like no matter what we did, we couldn’t
change documentation status quo that much.
It still remained on the outskirts of the big picture.
Thankfully, a case of one very stubborn PO,
and a bit of artfulness helped us figure out
what we were missing.

One of our doc projects was
a help system for
a complex web-based TMS.
The product was super-
complicated, but the new
product owner didn’t want
to invest into UX or
documentation.
Our arguments were in vain.
It only takes
60 clicks and
4 UI forms
to complete
a workflow…

We needed another way to
get that product owner
on our side.
One day we found out that
he was a huge Apple fan (and
suddenly realized why a
Windows product was
packed with Apple-style
features. Duh.)
Don’t you like
my dock?

So, during our last help system
update, we tweaked the
appearance of new topics to be
more minimalistic and
Apple-style.
This didn’t do miracles. But at
least the product owner was
somehow less opposed to us
and gave us more time to get
proof of help system usage.
Dock looks good
on helps too

We came to realize that no matter how well you
do your job, not everything is down to business
value or to your expertise.
It’s also very important to relate to your
customers on a personal, emotional level.

This is often taught in sales and marketing,
but we as technical communicators are
rarely trained to “read” our customers.

They might actually
explain why.
And what they want to
achieve with this.
Totally valid, right?
Here’s an example.
Imagine your customer wants
you to create a figurative chair
with 1 leg.
1 leg, you ask?
1 leg, they say.
Exactly like this.

But what they usually don’t tell
us is what’s their personal gain
in requesting documentation.
Do they lose a job if it doesn’t
work out?
Do they get a promotion if it
does?
Or is it a part of some bigger
scheme altogether?

Make your documentation
deliver personal as well as
business benefits.
Who knows, they might even
forgive you small sins like
typos or bad screenshots.
These hiccups won’t matter
because of that metaphorical
crown that you put on your
customer’s head.
I did ask for
a bigger chair…

This is that hidden requirement from this
presentation’s title, and it goes like this:
ensure that your document helps the customer
not only succeed in business as an official
customer figure, but also achieve their personal
goals, whatever those may be.

So, how do you deal with requirements that
your customers will never talk about but
subconsciously always expect?
Let me share how we tried to capture the
underlying interest of our new customer.

At first, all we knew was that our
customer is a logistics company
that needs to extend their IT department.

12
There were close to 100 people distributed across
12 subprojects concerned with web portals, mobile
apps, back-end infrastructure, really, all kinds of things.
It was our job to figure out which doc services would
be best for each subproject.

100 people can be really overwhelming,
especially at the beginning of the project.
Out of all these people, we tried to identify
the key customer personas.

12
Type 1 – immediate contact: controls requirements,
handles day-to-day tech issues & operations.
Type 2 – decision maker: concerned with high-level
progress, controls the budget, knows the business,
has the power to close down the project.

24 people is easier than 100, right?
About everyone of them, we asked these
4 questions:
#1
Which of their
colleagues are
their allies &
competitors?
Are they the
actual decision-
maker?
What’s their
personality
type?
What are their
drivers and
motives?
#2 #3 #4

Are they the actual decision-maker?
#1

There was a case of API
documentation for a mobile app.
When talking our PO through this
idea, we paid much attention to
tech implementation. Because our
POs are tech-savvy people.
He said OK, I like it, we can do it.
Just let me handle this further.
Seemed our job was done.
suggested a great
solution for quicker
onboarding of new
front-end developers
focused on showing
the value to the techy
Product Owner

What we didn’t think about was
that our PO needed to convince
his manager who was in control
of the budget.
We didn’t give our PO any
specific financial data, like by
how much the cost would be cut.
The API documentation was
approved eventually, but with a
much smaller scope.
didn’t think about
who was the actual
decision maker
if we provided arguments
that resonated with that
decision maker, and if he
saw more value, he would
grant us more budget

Which of their colleagues are their allies &
competitors?
#2

source: PoT Wiki
We usually see our customers as an organized
group of individuals heading to the same goal
with the same unified approach.

source: PoT Wiki
But in reality, it’s a group of individual players
who got stuck with each other and are each
tangled up in their own schemes.

There was another subproject that
needed API documentation too.
We prepared a good technical
specification and very convincing
financial data for the PO.
We also mentioned that we had
already done the API documentation
for another subproject, and how that
other PO had been very satisfied.
We were bound to succeed… but no(
attempt #2: same doc,
different subproject &
different PO
learned on our mistakes:
provided both tech and
profits info; added
bonus: good feedback
from another PO

Turned out those POs hated
each other big time – they
wanted the same promotion.
PO #2 wanted to be different,
cooler than PO #1, she didn’t
want to follow in his steps. We
found out only months later.
Who would have thought that
documentation could end up in
the middle of a political game?
didn’t take into account
the relationships within
the customer’s team
if POs were allies, good
feedback about us from
one to another would be
our advantage, but they
were competitors

What’s their personality type?
#3

From the very start, when you get to know your
PO, try and understand their personality traits
that may impact your work.
For example, how they react under stress.
Are they likely to present their mismanagement
as your low productivity? Are they more for
themselves or a team player?
There are several ways to get insight on this.

Limit the email/messenger usage
for notifications or yes/no inquiries.
When you have open questions and
discussions, use verbal
communication channels.
This gives you a chance to ask why
your customer is making that
decision and hope that they will
share some insight.
talk through open-
ended questions to
underdstand the
customer’s motives
maybe, they will
share their motives?

When you have this verbal
communication, try to ask
indirect questions, drop hints,
use your sense of humor.
Mix personal information in
the conversation.
They are likely to respond
with their own stories,
moods, and views.
try to personalize
the conversation
and hope that they
respond in the same
manner

Pay attention to how people
phrase things.
For example, when talking
about policy change, would
they use a passive or active
attitude?
This could tell you how they
feel about authorities.
do they say “we
were told to” or
“we decided to”?
phrasing and specific
word usage can
contain a lot of cues

Socialize with third parties.
It’s a good idea to take the
time to talk with people who
are not directly involved
in your project from the
customer’s side.
They are generally more
relaxed toward you, not so
much guarded about
everything they say.
talk to people who you
don’t have to talk to
they are not afraid to
tell you what others keep
to themselves

And the last one, this is a hard
job for 1 person.
Start creating a knowledge base
with all that info you have and
ask other team members to
contribute.
Together, you can get a very
good picture. The only risk here
is that people may not always
use this information wisely.
don’t let the info get
lost – create a knowledge
base, encourage your
teammates to use it and
contribute
but beware of situations
when the customer hears
from someone else what
they told you privately

What are their drivers and motives?
#4

One of the apps our team created
was a mobile CRM for the
customer’s sales teams.
We also had to make a promo video
for this mobile CRM.
Most of the customer’s sales people
are men. Because of this, and also
trying to adapt to local culture, we
made the main character in the
video a man. Seemed a legit choice,
much encouraged by our PO.
created a promo video
for sales people
tried local targeting
with video character

Product owner loved it, but
the his manager told us to
rework it and include more
globally varied characters.
It’s kind of a case of
overtrying on our side –
sometimes, you have to
discard personal preferences
of your customers in favor of
their corporate policy.
could have questioned the
decisions of our PO and
done more investigation
after all, not everything
is down to personal
preferences…

To sum up, these are the 4 types of things you
should investigate about your customer.
Then, try to align your work with your
customer’s ultimate goals and ambitions.

The bottom line is, focus on people as much as
you focus on tasks.
And then you’ll be sure to not miss any of the
requirements. Even the supersecret ones.

THANKS!
Skype: rrroady || Email: lesia.zasadna@eleks.com || Facebook: Lesia Zasadna

Requirements that you didn't know were there (Write the Docs Europe 2017)

Recommended

Recommended

More Related Content

Similar to Requirements that you didn't know were there (Write the Docs Europe 2017)

Similar to Requirements that you didn't know were there (Write the Docs Europe 2017) (20)

Recently uploaded

Recently uploaded (20)

Requirements that you didn't know were there (Write the Docs Europe 2017)