Work Understanding: Documentation
Objective. Use the in-app documentation to confirm how a term, metric or screen is defined before quoting it, and treat it as the reference that settles interpretation disputes - while verifying version currency.
Documentation holds the definitions and guidance for the app's terms, metrics and screens. It answers 'what does this actually mean and how is it meant to be used?' - the reference a CSM checks before interpreting, not a feature to demo.
See it in the demo
What this screen answers
The customer question is: what does this metric or term precisely mean, and how is this screen meant to be read? Documentation is the reference layer. Sales people use it to answer a definition question accurately rather than guessing; CSMs use it to settle an interpretation dispute with a customer by pointing to a shared, written definition.
The value is consistency: when a metric's meaning is written down and agreed, two people stop arguing past each other. The whole honesty spine of these modules depends on everyone using the same definition of opportunity, released time, confidence and coverage.
The task
- Open the documentation from the overview.
- Before quoting a metric or term to a customer, find its definition here and confirm you are reading it the way the product intends.
- Use it to resolve ambiguity - denominator, scope, modelled versus measured - rather than improvising an interpretation.
- Check the documentation is current for the version in use, and treat a gap between documented and observed behaviour as something to confirm with product, not to resolve by assumption.
Describe documentation by its role as the definition reference, not invented page titles or exact wording.
How to read it
Read documentation as the authority on meaning, bounded by its version. The classic misread is assuming the docs are complete and current and quoting a definition that has drifted from the deployed behaviour. Documentation can lag the product, and a demo's docs may not match a customer's version.
Use it to anchor the definitions that matter most for honesty - that opportunity is modelled and released time is measured, that a finding carries confidence, that coverage can be partial. Where documentation and a screen disagree, the gap is a question for product, not a licence to pick the convenient reading.
Honest limits
This screen does not guarantee that every definition is current or that documented behaviour matches a customer's deployment. The demo's documentation is illustrative.
Confirm with product when a definition is load-bearing for a customer decision and when documentation may have lagged a release. Position documentation as the shared reference that keeps interpretation consistent - the thing you point to instead of asserting - while verifying currency for anything a customer will act on.
Interpretation check
Documentation is the authority on what a term or metric means, but bounded by its version; it can lag the deployed behaviour, so verify currency before quoting a load-bearing definition and escalate any doc-versus-screen gap to product.
In the field
In a KnackGlobal QBR, pointing to the written definition of 'measured released time' versus 'modelled opportunity' is what stops a finance stakeholder reading a projection as a booked saving.
Practical task
On the demo documentation screen, look up the definition of one load-bearing term - for example opportunity versus released time - and write it in your own words, noting what you would verify with product before quoting it to a customer.
Self-check
Why check documentation before quoting a metric to a customer?
To confirm you are reading the metric the way the product intends - the denominator, scope, and whether it is modelled or measured - rather than improvising a definition that may be wrong or disputed.
Documentation and a screen seem to disagree. What do you do?
Treat the gap as a question for product, not a licence to pick the convenient reading. Documentation can lag a release, so confirm before acting on either.
What definitions are most important to anchor here?
The honesty-critical ones: opportunity is modelled, released time is measured, findings carry confidence, coverage can be partial. Shared definitions are what stop two people arguing past each other.
Can the demo's documentation be assumed to match a customer's deployment?
No. It is illustrative and may differ by version. Verify currency with product for anything a customer will act on.
Verified vs demo. Screen is live in the demo at /#/docs; exact content and definitions are SME-validation-pending and illustrative, and whether documentation is current for a customer's version must be confirmed with product.