Signals vs dashboards: which do you actually need?

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

A dashboard is pull: it holds the truth, but only helps you the moment you remember to open it. A signal is push: it reaches you the moment something happens, whether you were looking or not. A founder with one product can usually get away with pull alone; a founder running several products can't, because the thing that breaks first isn't the data — it's your attention.

SoleOS published this.

The core difference: pull versus push

A dashboard is a room you have to walk into. Nothing changes if you don't visit — the churned customer from Tuesday sits there quietly on Friday, waiting for you to scroll past it. That's fine when checking the room costs nothing, which is roughly true with one product and one habit of glancing at it over coffee.

A signal is the opposite contract: it comes to you. You don't decide to look; it decides to interrupt. That's a stronger promise, and it should be reserved for things actually worth an interruption — not everything that moves.

Neither model is "better" in the abstract. A dashboard is cheap to build, cheap to ignore, and gives you range — compare, filter, go back in time. A signal is expensive to design well (get it wrong and it's noise), but it's the only mechanism that reaches you when you weren't planning to check anything at all.

Why running several products breaks the dashboard model

One dashboard, checked daily, is a habit. Three or four dashboards, each needing its own daily visit, is a part-time job — and it's the first thing that slips when you're heads-down shipping. The math doesn't change because you're more disciplined; it changes because attention doesn't scale with the number of things you're watching.

This is the specific failure mode of running multiple products at once: not that you stop caring about product B, but that product A had a launch this week, so product B's dashboard didn't get opened for eleven days. Nothing was necessarily wrong with product B's numbers — you just genuinely don't know, because pull only works if someone pulls. If this sounds familiar, a breakdown of what actually goes wrong when you split attention across several side projects covers the dashboard gap in more detail.

The fix isn't "check dashboards more often." It's recognizing that some events shouldn't wait in a dashboard for you to find them — they should find you.

What deserves a real-time signal

Not everything. A signal earns its interruption by meeting a simple bar: would you want to know within the hour, regardless of what else you're doing? A short list of things that usually clear that bar:

• A purchase or new subscriber — especially the first on a new product, or the first after a change you shipped. You want to know it converted, not read about it in an aggregate count three days later.
• A churn or cancellation — particularly a high-value customer, or an early pattern (two cancellations in a day where you'd normally see none).
• A milestone — crossing a revenue threshold, hitting a user count, a review landing. These are morale events as much as business events, and their value comes partly from timing.
• An anomaly, a spike or a drop — a sudden jump in signups, a sudden drop in activations, a payment failure rate that jumped. Anomalies are time-sensitive: the earlier you catch a regression, the cheaper it is to fix.

These share a shape: discrete events with a clear "when," where acting sooner is meaningfully better than acting later. That's the test for whether something belongs in the push layer at all.

What belongs in the weekly review instead

Almost everything else. Trend lines, week-over-week comparisons, "is product C's retention creeping down," "should I raise the price on the Maker plan," "which of my four products deserves next month's dev time" — none of these need to interrupt your Tuesday afternoon. They need a recurring block of time where you look at all your products side by side and make a decision with context, not a notification with none.

This is what a dashboard, paired with a scheduled review habit, is actually good at: aggregation, comparison, trend-spotting, prioritization across a portfolio. If you don't already have a fixed slot for this, a structured weekly portfolio review ritual is the natural place to put it — one sitting, one lens across everything, instead of N separate dashboard visits that may or may not happen.

A useful rule of thumb: if a metric only matters in comparison to last week or last month, it's a review-time metric. If it matters the moment it happens, it's a signal candidate.

The failure mode of signal overload

Push has a failure mode too, and it's worse than a dashboard going unchecked: too many alerts and you stop reading any of them. The first week of a new signal, you open every one. By week three, if half are noise — a $0.99 trial that was always going to churn, a "spike" that's just Tuesday's normal traffic — you start swiping them away unread. At that point the signal is dead weight, and worse, the one alert that mattered gets swiped along with the rest.

The fix is scope and threshold, not volume:

• Set a floor. Don't alert on every purchase once you have meaningful daily volume — alert on the first of the day, on purchases above a certain value, or on anomalies relative to your own baseline.
• Separate channels by urgency. A churn on your highest-tier plan and a routine daily summary can't look identical in your inbox, or you'll triage them the same way.
• Review the alert list periodically. If you've ignored a category of signal for a month, either it's mis-scoped or it isn't worth sending — fix the threshold or turn it off.
• Match scope to product stage. A brand-new product might deserve an alert on every purchase, because there are three a week; a mature one with steady volume needs alerts on anomalies, not business-as-usual.

For a concrete number to tune against instead of a gut feeling, track your own alert-open rate over a couple of weeks — what fraction of pushes you actually act on versus dismiss. That tells you whether a given signal is scoped correctly, and it's yours to measure, not a benchmark anyone else can hand you.

The honest answer: you need both

Push tells you when. Pull tells you why, and what to do about it. A signal without a review habit turns into isolated events you react to but never contextualize — you know a customer churned, but not whether churn is trending up across the portfolio. A dashboard without signals turns into the thing you meant to check, on the day it would have mattered most.

If you run one product, this tension mostly evaporates: a single dashboard you already glance at daily is a fine system, and a push layer on top is optional polish, not a requirement. The split earns its keep specifically once you're running enough products that pull alone starts silently dropping things.

SoleOS is built around holding both ends: real-time signals for the handful of events per product that deserve one, and a portfolio dashboard for the weekly comparison work signals were never meant to do. If you want to see what that looks like before deciding whether it fits how you run things, there's a live demo you can click through, and the setup guides walk through scoping your first signals so they don't turn into noise on day one.

Frequently asked questions

How many signals is too many?

There's no universal number — it depends on your volume and how many products you run. The practical test is behavioral: track how often you actually open and act on an alert versus dismiss it unread. A category you're consistently ignoring is either mis-scoped (raise the threshold, narrow the condition) or doesn't deserve to be a push at all — move it to the weekly review instead.

Can a single-product founder skip signals entirely and just use a dashboard?

Yes, reasonably. If you check one dashboard daily and rarely miss a day, you're already getting most of what push would give you, just with a slight delay. Signals start earning their keep once you can't reliably check everything yourself — usually when a second or third product enters the picture, or a specific event (a big customer's payment failing) is costly enough that even a one-day delay is a problem.

What's the difference between an anomaly signal and a milestone signal?

A milestone is expected and positive — you know roughly when you're approaching a revenue threshold or user count, and the alert marks the moment it happened. An anomaly is unexpected in either direction — a spike or a drop relative to your own recent baseline — and its value is entirely in the surprise: it tells you something changed that you didn't already know to look for.

Should churn alerts fire for every cancellation?

Not necessarily, especially at meaningful subscriber volume — at that point routine churn is a review-time trend, not an individual event. It's usually worth keeping a real-time signal for cancellations on your higher-value plans or a cluster of churns in a short window, since either can indicate something worth same-day attention (a billing bug, a bad release) rather than ordinary attrition.