Documentation
Docs in progress.
Full docs are in progress. The AI Product Playbook currently documents product and engineering workflows, including context, steps, outputs and review gates. It is interim workflow documentation. The product page explains the Brain lifecycle, current capabilities and target gaps.
Simply explained.
Every AI generates more. Teklens shows what still applies. The Company Brain is the company's shared memory: everything people and AI agents decide and learn is kept, connected and compounding with every conversation.
- Ingestion and agent access
- Provider APIs, synchronisation and webhooks keep sources current. Outward MCP tools expose the Company Brain and its evidence. Secure access to more than 1,500 apps runs through one connectivity layer with rules and permissions per agent.
- Approvals and permissions
- Topic owners approve changes to the Company Brain. Source drafts follow the review and write permissions of the source. Projects can be restricted to named people; legal, finance and HR stay private.
- Write-back and result
- Every approved change is written back per target and confirmed. What cannot be done automatically stays visible as open work with an owner. No universal transaction, no automatic deletion.
Source change → contradiction found → proposal as a diff → approval → write-back to the source → result visible per target. Nothing goes live without approval.
Enterprise Context Management · The productEvery Activity as a how-to
Each Activity explains briefly what it achieves – the detail page shows context, steps, output and quality gate.
01
Discover
- How to write OKRsTranslate strategy into a few measurable outcomes; do not disguise task lists as key results.
- How to define and use KPIsChoose a few standing product-health indicators, then establish a repeatable evidence-led review distinct from quarterly OKRs.
- Define product positioningBuild a supported value story for a defined audience and preserve claim meaning across short variants.
- User interviews — planning & prepPrepare behaviour-based interviews that could disprove the hypothesis, with realistic recruitment and consent planning.
- User interviews — running the sessionListen to recent lived behaviour rather than selling the product; keep raw observations intact for later synthesis.
- User interviews — synthesis & distributionSynthesise across participants without counting repeated mentions as independent evidence; communicate decisions with their support.
- How to map a customer journeyMap the customer’s experience, keeping observed current behaviour distinct from proposed future improvements.
- How to map an opportunity solution treeKeep the tree rooted in one outcome and evidence-backed opportunities; solutions remain alternatives until tested.
- How to map and test assumptionsPrioritise consequential weak beliefs and predefine what evidence would change the decision.
- How to use the Kano modelDistinguish customer-derived satisfaction categories from provisional team hypotheses; reassess categories as expectations evolve.
- How to prioritise using jobs-to-be-donePrioritise important underserved jobs before mapping solutions; preserve the difference between customer evidence and team guesses.
- How to write a feature briefAnswer whether the opportunity deserves exploration without prematurely prescribing requirements or implementation.
- How to prioritise against your objectivesPrioritise by objective contribution without forcing essential maintenance into an invented strategic link.
- How to build a weighted scoring modelAgree strategic criteria before scoring; use the ranking to expose trade-offs rather than automatically selecting work.
- How to prioritise with a 2×2 matrixUse shared relative placement to surface assumptions; the matrix is not a precision ranking.
- How to run effective product meetingsFirst decide whether live discussion is necessary; preserve preparation and resume with the actual meeting outcomes.
- How to share product updates on SlackLead with evidence of completed work and user value; draft for a confirmed audience without automatically posting.
- Coordinate a go-to-market launchCoordinate product availability and market readiness with clear dependencies; distinguish launch approval from publishing or deployment.
- How to run a retrospectiveBegin with prior commitments and finish with a few owned improvement experiments; do not turn the reflection into blame.
02
Define
- How to define success metricsDefine success before requirements by combining one primary outcome, diagnostic usage and a counter-metric.
- Success metrics with Discover, Use, RelyConnect awareness, successful use and continued reliance into distinct measurable stages with shared functional ownership.
- How to use RICEScore independently before discussion and preserve legitimate reasons to choose out of score order.
- How to prioritise with ICE scoringUse ICE for a quick relative comparison with consistent anchors and honest confidence.
- How to prioritise with MoSCoWUse the conversation to separate essential delivery from negotiable scope; Won’t means this time, not forever.
- How to write a PRDDescribe what users must be able to do, explicitly bound scope, and avoid substituting design or architecture for requirements.
- How to write a good ticketMake the item understandable and testable while respecting the engineers’ agreed working format.
- How to run backlog refinementPrepare and refine a PM-agreed subset of upcoming stories; preserve partial meeting coverage, per-story discussion and confirmation, and resume the same Activity without overwriting approved sources.
- How to record an architecture decisionRecord one decision with its real consequences; supersede earlier decisions visibly instead of erasing their rationale.
- How to define and review service level objectivesChoose reliability targets to support user-centred trade-offs, then review whether the indicators actually represent the experience.
- How to run a design critiqueFacilitate critique against goals rather than personal taste; critique informs design judgement and is not user validation.
- How to test a prototype with usersEvaluate observed task behaviour without teaching the intended answer; evidence determines whether another round is necessary.
- Design onboarding to first valueOptimise for the first useful outcome rather than completion of setup or a tour of every feature.
- How to write error messagesWrite error copy together with the recovery behaviour, never promising an action the product cannot perform.
- Run an adoption experimentPredefine the experiment and protect its interpretation from contamination, insufficient evidence and outcome-driven metric changes.
- How to run exploratory testingExplore adaptively within a bounded question; document what was actually exercised and what remains unknown.
03
Build
- How to review a code changeReview actual change scope and system effects, separating substantiated issues from optional preferences.
- How to log a bugProduce one factual reproducible report; search for a matching report before proposing a new ticket.
- How to plan a canary rolloutPlan limited exposure with pre-agreed evaluation; an approved plan alone never executes a production rollout.
04
Operate
- How to write release notesTranslate shipped changes into user value and never equate a merged change with general availability.
- Enable sales and support for a releasePrepare customer-facing teams with truthful role-specific material and feed actual questions back into the reference set.
- How to write user messages for downtimeCommunicate known impact promptly without inventing a recovery time; maintain a clear update and all-clear sequence.
- How to run a blameless incident postmortemLearn from system conditions and information available at the time, preserving uncertainty and avoiding personal blame.
- Plan product deprecation and retirementSeparate discouraging new use from actual removal and preserve users’ ability to complete their work through the transition.