We are the documenters... we ensure that the most important parts of how our application is supposed to work never gets forgotten.
Expectations / Description
Success:
- No one on the P&E team has to ask how new functionality is intended to work
- None of the direct stakeholder (enablement, product marketing, and customer support) has to ask how launched functionality is intended to work (can be measured with a decrease in tickets that could be solved by having documentation in place)
- Documentation is created, reviewed, and added to Zendesk Guide before the feature is launched and passed to Customer Support and Customer Experience prior to launch to create support articles
Note: The scope of this role is it is responsible for creating a manual that inspires the customer-facing and enablement documentation but is NOT responsible for writing customer-facing and enablement documentation
Details:
Here is lesson that outlines internal documentation on the P&E team
With every launch and every new feature, there are many details about the feature that we on the product have in our heads. These include:
- Overview of the feature
- How the feature works
- Screenshots
- Demo Video
- and more!
We have a goal to properly document the feature launching for both P&E and inter-departmental stakeholders.
Things you might deliver/do
- Create a story for creating documentation in each epic
- Create documentation and move it through the review process
- Add documentation for each feature to Zendesk Guide
- Maintain documentation in the now and future
- Share documentation easily with stakeholders via Zendesk Guide
- The Feature Documenters (at least one person from each squad) will get together to create a Feature Documenters Handbook where they will agree on how documentation will be written, organized, and styled in the internal knowledge-base (Zendesk Guide).
Here is an example of what success looks like
Requirements
- Feature Documenter's must have a position with the reach of 1.1 or higher
- Feature Documenter's are recommended to be milestone 1+,Stakeholder / Feedback Management
- Feature Documenter's must be milestone 1+,Business and Technical Translation
- Feature Documenter's must be milestone 1+,Copywriting
- Feature Documenter's must be milestone 1+,Product Knowledge
Configuration Health
- ✅ Has 4 Abilities
- ✅ Is a part of 6 Positions
- ✅ Has been referenced in 4 pieces of public recognition
- ℹ️ No one has reacted to this Assignment
- ℹ️ No one has an official rating on this Assignment
- ⛔️ Last updated: over 4 years ago
- ℹ️ Never conversed about
Examples / Observations
Observation created almost 5 years agoWe had to respond to an RFP (Request for Proposal).
There was a question about permissions, and I immediately knew that there is one person I definitely needed to bring in... THE HAMMER!!!
I asked Kim how she would respond to this RFP question, and a couple of short hours later, she knocked it out of the park! Here is the doc she wrote up.
Made me even more confident that Kim not only has my back, but she does nothing half assed.
Well done... we all appreciate you!
Observation created almost 6 years agoFeaturing:Raphael A.We put learners firstWe inspire others to do better workWe don't wait to be told what to do, we take initiativeWe put the team before ourselvesCopywritingFeature DocumenterDocumentation is vital for a software company. That is true for all aspects of our app but particularly user management. Lessonly cannot exist without learners, so the action of making it clear and easy to get users into Lessonly is important. Even though I know all of that creating documentation can be seen as the least fun aspect of software. It is more fun to build new stuff than to write in painstaking detail about the stuff you just built.
With all of that being said, it only makes what Raphael did more impressive. We recently wrapped up the development of SCIM for OneLogin. We were left with the documentation piece. I tried my best to get it started but we reached a point where we had to set the JSON user schema and I was lost. Raphael (who got involved late to the project) was able to familiarize himself with the code base and write some killer documentation (found here: https://docs.google.com/document/d/1zaEPLM1wtiDHBth9owIG29R2c-3oYWq04jPtxvH-5P0/edit#)
This is the definition of a team player. Hopping onto a project and helping out any way you can no matter what. Raphael has always been game for these sort of things but I was reminded again by this.
Official Feature Documenters
This section is for Lessonly folks only. Sign your team up to find your Gruuv!
Teams needing a Feature Documenter
This section is for Lessonly folks only. Sign your team up to find your Gruuv!
Positions that reference being a Feature Documenter
This section is for Lessonly folks only. Sign your team up to find your Gruuv!
Conversations about Feature Documenter
This section is for Lessonly folks only. Sign your team up to find your Gruuv!