Identify your Stakeholders
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.
- 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 Services. 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 login? Internal versus external? File format? Code snippets? KB?)
- Include boilerplate elements such as Known issues and pain points.
What if you do not know where to start?
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 that node, and what tertiary effects a choice would have.
Perhaps create a list of a writing’s utility. How would these people be affected by your decision?