Reflect actual usage
Describe actual tasks, attempts, outcomes, and constraints. Separate observed patterns from inferred motivations.
Product strategy / Discussion draft 02
00 — The proposal
Real behavior.
Better personas.
Sharper decisions.
Use customer behavior to build personas that better represent real users, then bring that context into DataDisco Feedback and QA.
Explore the proposal10 chapters · Read, discuss, then decide
Not a digital copy of a person.
An
evidence-backed representation of a behavioral group, with
explicit unknowns.
The opportunity
01 / 09
Not just a plausible persona.
A perspective grounded in use.
A persona becomes more useful when we know what its users actually do: the paths they take, the features they rely on, the constraints they encounter, and how their behavior changes over time.
Represent meaningful differences
Distinguish occasional and habitual use, individual and team workflows, and different levels of product exposure without inventing personalities.
Make every run more relevant
Give Feedback realistic starting conditions and give QA evidence-informed scenarios. Evaluate both against real users and observable product behavior.
MirrorBall supplies the behavioral grounding.
Personas make it
usable across research, Feedback, and QA.
How mirroring works / Proposed model
02 / 09
From event history
to a behavioral representation.
Mirror the patterns supported by the data, not an imagined inner life. CSV and PostHog are inputs to the same process, not different kinds of personas.
01 / Understand
Give the data meaning
Map events to tasks, feature exposure, success, failure, and return activity. Establish identity, account context, and observation windows.
Input: Timestamped events plus deliberately selected properties. A click is not automatically intent; a missing event is not automatically abandonment.
02 / Characterize
Find meaningful patterns
Compare paths, frequency, sequence, time to completion, feature breadth, repeated errors, and recovery. Include successful and routine use, not just struggles.
Output: Distinct behavioral groups with supporting metrics and variation. Keep differences visible rather than flattening everyone into an average user.
03 / Represent
Ground a reviewed persona
Turn each relevant profile into task context, prior product exposure, typical workflows, and evidenced constraints that downstream runs can use.
Boundary: Preserve source and uncertainty. Do not turn event counts into unsupported claims about personality, expertise, or willingness to pay.
A user can fit multiple patterns and change over time. A persona represents a group in a defined context, not a permanent label attached to an individual.
The DataDisco connection
03 / 09
One evidence loop.
Four distinct jobs.
Proposed product workflow. The components exist in the architecture; the end-to-end behavior below is a direction to validate, not a claim that every connection is shipped.
Observe
What is happening, and to whom?
Turn CSV or connected analytics into behavioral groups, supporting evidence, and unanswered questions.
Evidence + profilesRepresent
Whose perspective should we explore?
Review and link a behavioral profile to a persona. Keep research-led context distinct from analytics-derived claims.
Grounded perspectiveInvestigate
Where might this experience fail them?
Explore a prototype with a relevant task and supported constraints. Produce page-grounded findings and hypotheses.
Experience findingsVerify
Does the important journey work?
Propose reproducible checks with test data and expected behavior. Verify fixes and watch for regressions.
Checks + findings
Close the loop ← Collect real-user feedback and
post-change analytics. Refine the profile and the next
investigation.
Feedback is not a customer interview.
Synthetic feedback can reveal interface friction; it cannot
confirm what real customers believe.
QA is not a conversion forecast.
A passing
test confirms the tested behavior, not that users will adopt the
product or pay.
What an analytics-driven persona contains
04 / 09
A persona with a history.
Not just a biography.
Keep the human-readable persona, but ground its product behavior in a reviewed profile. Research and analytics complement each other without becoming interchangeable evidence.
-
Tasks and working context
Which workflows are observed? Which goals are customer-provided or inferred? Keep those origins explicit.
-
Prior exposure and usage patterns
What has this group used before? Preserve cadence, common paths, and variation rather than assigning a vague “power user” personality.
-
Constraints and starting conditions
Carry supported plan limits, permissions, device context, and product state where available. Missing context stays unknown.
-
Research-backed human context
Link interviews and customer-provided roles or goals through review. Analytics alone does not establish demographics, attitudes, or intent.
-
Evidence and version
Retain the population, time window, metrics, uncertainty, and reviewed profile version. New evidence can refine the persona without silently rewriting earlier runs.
Better data, not just more data
05 / 09
Recommend the next thing
worth learning.
When the evidence cannot distinguish explanations, MirrorBall should propose a specific event, property, or question, and explain the decision it enables.
| Uncertainty | Collect or ask | Decision enabled |
|---|---|---|
| Unfamiliar or simply not interested? | Feature exposure and task attempts. Ask: “What were you trying to accomplish?” | Give the persona an evidenced starting point instead of assuming lack of awareness or intent. |
| Individual or team workflow? | Account-level collaboration events and permissions. Ask who uses the output. | Represent the task’s actual audience and propose relevant collaboration scenarios. |
| Completion or real value? | After success: “Did this accomplish what you came here to do?” | Ground the persona’s goal in reported value, not just a technically completed action. |
CSV and PostHog, one evidence model
Timestamped events support journeys. User-summary CSVs support comparisons but less sequence detail. Aggregate exports cannot reconstruct individual paths. Show these capability limits before analysis.
Collect deliberately
Check existing tracking first. Recommend minimal, allowlisted properties and pseudonymous identity. Avoid raw files, form contents, and sensitive data. Customers approve collection and prompts.
For B2B, resolve the unit of analysis: the person using the product may not be the account buying it. Identity, event coverage, and observation windows come before a confident narrative.
What makes the system credible
06 / 09
Learn from reality.
Not from our own generated answers.
Keep a visible distinction between what happened, what someone reported, what the model inferred, and what we recommend testing.
Evidence stays attached
Every profile retains its source, population, time window, and supporting metrics. Hypotheses remain labeled. Evidence-quality scores are not accuracy probabilities.
Compare like with like
Use relevant successful-user comparisons, complete observation windows, and account for plan, acquisition source, and product changes where available.
Check against customers
Use interviews, surveys, replay, and held-out outcomes. Reported reasons can be biased; generated persona responses never become customer evidence.
Update without rewriting history
Record explanations as supported, contradicted, or unresolved. Review profile changes. Measure interventions rather than assuming correlations are causal.
The test: does this produce more accurate, actionable findings than analytics alone or a generic persona?
How grounding changes the output
07 / 09
Same product.
Better Feedback. Better QA.
The persona should change the task, starting state, and constraints of a run, not just the tone of its answers. These are proposed applications to validate.
Represent the audience
Build or enrich personas from distinct behavioral groups. Preserve both routine successes and difficulties; avoid one generic “average user.”
For the report builder: Carry the saved-report workflow and repeat-use context. Do not assume a profession or dislike of collaboration.
Explore from the right context
Give the agent a grounded task and prior exposure. Findings still need captured page evidence, not persona-driven speculation.
For the report builder: Reopen saved work, adjust a filter, and export. Explore whether a redesign disrupts that established path.
Prioritize realistic scenarios
Translate important journeys into safe fixtures and explicit expected behavior. Check permissions, state, errors, and recovery.
For the report builder: Verify saved filters persist and exported results match the selection. Keep broader regression coverage too.
Other example questionsWhere do new users struggle? Why do some stop returning? What
blocks an upgrade? These are applications of the model, not its
boundaries or a fixed roadmap.
Prioritize by reach and consequence, not frequency alone. Rare permission failures or destructive-action bugs matter even when they do not define a large persona group.
For the cofounder conversation
08 / 09
What should we agree
before more implementation?
A proposed direction, not a committed roadmap.
What do we mean by “mirror”?
Recommendation: represent observed workflows, usage patterns, and constraints. Do not promise a copy of someone’s mind or unvalidated response predictions.
How should data enrich Personas?
Recommendation: reviewed behavioral grounding alongside research-led context. Support new personas and reviewed links to existing ones, without blending evidence types.
What should flow into Feedback and QA?
Recommendation: tasks, starting states, constraints, and evidence references. Review proposed scenarios, tracking changes, and user prompts before execution.
How do we prove better representation?
Recommendation: compare grounded personas against generic personas and analytics alone. Assess real-user agreement, useful Feedback findings, and confirmed QA issues on held-out workflows.
What is our first real dataset?
Choose an authorized product dataset covering varied workflows and access to real users or research. Prove the data-to-persona-to-run connection before expanding automation.
Better evidence → better representation.
Better representation
→ more relevant Feedback and QA.
Research notes
09 / 09
Grounded direction.
Not a market-wide verdict.
These sources support behavioral analysis and its boundaries. The proposed data-to-persona-to-run model is our product synthesis, not a capability or effectiveness claim established by these sources.
-
PostHog: finding an activation metric ↗Defines candidate activation behaviors through their association with later retention. Correlation is not proof that encouraging the action will cause retention.
-
Amplitude: digital product benchmarks ↗Organizes acquisition, activation, engagement, and retention across 2,600+ companies. Broad digital-product coverage, not exclusively self-serve SaaS.
-
ChartMogul: SaaS retention report ↗Analyzes 2,100+ SaaS businesses and variation by stage and account revenue. Useful structural context, not a current benchmark target.
-
Stripe: revenue recovery ↗Distinguishes failed-payment recovery from voluntary cancellation. Supports separating operational billing loss from user motivation.
-
PostHog: funnels ↗ · Retention ↗Supports explicit funnel steps, conversion windows, return events, and cohort definitions rather than universal churn rules.
-
DataDisco project documentationBased on ingestion, behavioral evidence, persona portfolios, and architectural primitives. This presentation is not a runtime audit. No private customer data is included.
Research scope: directly inspected public sources; broad web search was unavailable. Priorities and product recommendations are our synthesis. All worked examples are illustrative.