Key Concepts
Understand Atisbo's evidence-to-outcome product model
Key Concepts
Evidence and Snippets
A Snippet is the smallest citable unit of evidence: a complaint, observation, request, metric, or operational event with its original source and time. Evidence can be customer, internal, or operational. Atisbo preserves provenance so an agent can trace a requirement back to what actually happened.
Claims: product problems
A Claim is a product problem or pattern supported by one or more related Snippets. Atisbo groups related evidence, maintains a living summary, and exposes contradictory evidence rather than hiding it inside an average.
Humans validate ambiguous patterns and decide whether a problem belongs in active product work.
Evidence-weighted priority
Atisbo's current solution priority answers: “What deserves attention now, given the evidence and our strategy?”
The live base combines:
- urgency/severity judged from evidence;
- evidence volume and recency;
- strategic alignment.
The PM can set manual backlog order and apply an explicit priority boost. Manual order governs first. The base recomputes when evidence changes.
RICE is legacy record-keeping and effort-estimation data. Reach, Impact, Confidence, and rice_score do not determine current backlog order.
Solutions: decisions and work items
A Solution is both the chosen product response and the canonical backlog item. It preserves the problem it covers, the reasoning behind the decision, constraints, owner, conversation, implementation context, human review state, and outcome.
Atisbo owns this product-decision backlog. Jira, Linear, and GitHub may manage delivery details, but they do not replace the product problem, decision, or outcome stored in Atisbo.
Product Coverage
Before a PR is handed to a human, Atisbo can check whether the implementation declaration accounts for every covered Claim and Idea and acknowledges unresolved contradictory evidence. Product Coverage is traceability, not code review: tests, CI, security review, and human judgment remain separate.
Decisions and outcomes
Every meaningful product action produces a Decision record. After launch, an Outcome records whether the intervention succeeded, partially worked, missed, or produced an unexpected result, with optional before/after KPIs.
A merged PR or deployment is output. It becomes an outcome only after the team observes what changed.
Product Map
Maps organize the same Claims and Solutions through useful lenses such as product areas, journeys, systems, or KPIs. They do not create a separate backlog; they make pressure and relationships visible without breaking traceability.