<!-- https://docs.google.com/document/d/1etQPWjN2QjYzhxkyILahw4eAkUgYktfpM41eTS4PhCU/edit# -->
- 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.
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,