Why SRE thinking makes you a better product builder
I'm an SRE by day and indie hacker by night.
Noticed something: the mental models I use at work — SLOs, incident response runbooks, observability — apply directly to building and validating products.
Infrastructure has observability. Product decisions usually don't. "Why we built this feature" gets lost in 6 months.
Wrote up how I apply SRE concepts to product validation:
- SLOs → validation success criteria (define the bar before running experiments)
- Incident escalation rules → pivot decisions (stop making them emotionally)
- Runbooks → validation playbooks
Any other engineers who've brought technical thinking into product development?
love this framing. i'm basically running SRE on my sales pipeline without realizing it.
my outreach system has: monitoring (reply checker every 30min), alerting (telegram notifications on new replies), runbooks (response templates for different reply types), and SLOs (target: 3% reply rate, currently at ~2%).
the pivot decision framework is especially relevant. i spent 6 weeks building a social media automation system before looking at the metrics honestly and pivoting to cold email outreach. if i'd had incident escalation rules for product decisions, i would have pivoted 4 weeks sooner.
what's your validation SLO look like? curious what threshold you use for this idea is worth continuing vs time to pivot.
this is exactly what i mean — you've been doing this intuitively, which is actually the interesting part. the mental model transfers because the underlying problem is the same: you're operating a system under uncertainty, and you need to know when to act vs. when to wait for more signal.
your pivot story is the one i hear most often. "if i'd had the rule written down, i would have moved 4 weeks sooner." the rule existed — it just wasn't explicit. making it explicit is the whole point.
on validation SLOs: i use a two-layer approach.
problem SLO (before building): 4 out of 5 user interviews must independently describe the same pain without me prompting it. if i'm leading the witness to get there, it doesn't count. this is my "error budget" — i'll tolerate 1 miss, but 2 misses means i haven't found a real problem yet.
feature SLO (after shipping): week-4 retention on the specific feature must be >30%. if users try it once and don't come back, that's an incident. i don't wait for intuition — that number triggers a postmortem automatically.
the cold email pivot is a perfect example of the second layer. reply rate 2% vs target 3% isn't just a metric — that's an SLO breach. the question isn't "should i be worried?" it's "what's in my runbook for this?"
what does your runbook say for the 2% → 3% gap? curious whether you've defined the escalation path or if that's still intuition-based.