Choose the account before assuming the person
A finance director can be a plausible persona at an unsuitable company. Conversely, a strong-fit account can require engineering, security and finance to participate. Keep account qualification separate from stakeholder coverage so a contact title does not stand in for a complete buying case.
Personas should describe work and decision relevance, not fictional biographies. Ask what the role owns, what evidence matters to it and how it affects adoption or approval. When those responsibilities differ across companies, record the uncertainty and validate it in discovery.
| Decision | Evidence to use | What changes next |
|---|---|---|
| ICP | Organization-level problem, fit and disqualifiers | Decides which accounts deserve research and selling time |
| Persona | Role-level responsibilities and decision relevance | Shapes a useful question and stakeholder plan |
| Buying committee | Actual participants and influence at this account | Replaces generic assumptions with a real decision map |
Work through the decision
Illustrative product: entitlement infrastructure. The ICP is a platform with access complexity and feasible integration. The engineering persona may care about reliability and development effort; finance may care about scope and commercial justification. Those are starting questions, not proven preferences of every individual.
If discovery reveals product leadership owns the project and security can block adoption, update the committee. Do not keep addressing the original finance contact as the sole buyer simply because the persona deck said so.
A persona is written like a fictional customer biography
Invented motivations, ages and personal habits can distract from the work the product changes. Ground the persona in role responsibilities and actual buyer evidence. Where knowledge is missing, write a discovery question instead of a narrative detail.
A concrete next step
Take one target account and write its ICP fit in two sentences. Then map three possible roles and the distinct question each could answer; mark which roles remain unverified.
Sources and research notes
- GitLab Command PlanCompany operating handbook
- Schematic product documentationCompany product description
Primary sources reviewed October 6, 2026. The operating recommendations and worked scenarios are Daavid’s analysis. Illustrative numbers are assumptions, not measured client results. Company marks identify sources and prior experience; they do not imply a customer relationship or endorsement.
Schematic