forked from San-Francisco-Write-The-Docs/lone-writers-guide
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathIdentifyYourStakeholders.rst
54 lines (37 loc) · 2.3 KB
/
IdentifyYourStakeholders.rst
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<!-- https://docs.google.com/document/d/1etQPWjN2QjYzhxkyILahw4eAkUgYktfpM41eTS4PhCU/edit# -->
**************************
Identify your Stakeholders
**************************
=================================================================
How to swim in the deep water - A lone writer’s guide to survival
=================================================================
Starting notes:
---------------
* Finding the key stakeholders. Which internal stakeholders can be your ally? These are not necessarily people in product development, but might be in the leadership, marketing, sales.
Hack-a-thon content:
--------------------
Why this is important:
* The stakeholders know the customers well; they know the business goals. They can help you prioritize.
* If you design something without taking into account what the stakeholders find to be important, the time will come they’ll kill it
* You can’t necessarily go by job titles, especially in a young org. YMMV
* not necessarily the dev group
* not necessarily your best reviewers
How do you figure this out? (stakeholders for the doc)
* Find out who cares
* Talk to people who’ve been there a long time
* Spread around groups: PM, QA, Mktg, UX, Support, DevX, Professional Svces, etc. Cast your net widely. Listen for who’s got contact with customers; who’s got visibility into the direction of the product.
* Who writes the specs?
* Outside the company: who’s making purchase decisions?
What questions do you ask?
* What’s your biggest pain point that docs can help with?
* What’s the most important goal the company has this year?
* What do you mean when you say “docs”? (e.g., behind signin? Internal versus external? File format? Code snippets? KB?)
* Boilerplate elements: Known issues, pain points,
_____________________________________
What if you do not know where to start?
Doodle! :D :
Create nodes for everyone involved within the company (especially if the company is small)
Draw connections (from prior experience) to see who often interacts with who
Understand which nodes would be directly affected by your project.
Ask yourself how the changes would impact not only that node, but the tertiary effects that a choice would have.
Perhaps create a list of a writing's utility. How would these people be affected by your decision?