Product research + analytics · Survey + SQL

Reliability is the signal.

A 1,257-response survey and 50 interviews I designed and led, analyzed to answer one question: is satisfaction driven by new features, or by whether the product simply works.

Role
Designed and led the research + analysis
Method
Survey n=1,257 · 50 interviews
Stack
PostgreSQL · SQL · Python · Tableau
Verdict
Reliability should lead the roadmap

The question

Teams default to shipping features. The data disagreed.

The instinct when satisfaction slips is to add content. Before accepting that, I tested whether satisfaction tracks features at all, or whether it tracks something more basic: how often the product fails under the user.

The finding

Satisfaction collapses with error frequency.

Joining survey responses to reported error frequency showed a clean, steep relationship. The experience is not rated on what is added. It is rated on what breaks.

Satisfaction by error frequency

10-point scale · survey n=1,257

No server errors6.8 / 10
Near-daily errors3.7 / 10

Satisfaction nearly halves as errors move from none to near-daily, a larger swing than any feature preference in the survey.

The priorities

When users rank what to fix, reliability takes the top three.

Top priority, ranked by respondents

count of respondents · n=1,257

Server stability1,188
Bug fixes1,100
Performance1,079
New content227
New maps195

The top three priorities are all reliability. New content and new maps sit far below, despite being where roadmaps usually spend.

The call

Recommendation

Reliability, not feature expansion, should lead the roadmap. Satisfaction is tied to error frequency, and users rank stability, bug fixes, and performance above anything new. Protecting retention starts there.

How I'd measure it

Tie the roadmap to the number it moves.

North Star
Satisfaction, tracked against error frequency and 30-day retention.
If reliability work is real, error frequency falls, satisfaction rises, and retention follows. If it does not, the thesis is wrong.
Reliability
Error rate and crash-free sessions per user.
Perception
Longitudinal satisfaction, not a one-time read.
Outcome
Retention among previously affected users.

Limits and next steps

What I would validate before over-investing.

01

Self-report bias

Cross-check reported error frequency against telemetry so the driver is measured, not just recalled.

02

Ceiling on reliability

Once errors are rare, confirm features re-enter as the next driver rather than assuming reliability scales forever.

03

Segment differences

Check whether heavy users weight reliability differently from casual ones before a blanket roadmap call.

04

Causality

Use the reliability work itself as the test: fix, then watch satisfaction and retention move.

Falsification. If error frequency drops and satisfaction does not follow, reliability was not the driver, and the roadmap should return to features.