How we decide what goes in the timeline

This is a sample post. The product, the team and every detail in it are invented to show how an article looks. Replace it with your own.

A timeline that shows everything is one more tool to check. So the hard part of our work is not collecting updates. It is leaving most of them out.

Three questions#

Before a kind of update is allowed into the feed, we ask:

1. Would someone on the team act on it, or at least want to know?
2. Can it be said in one line?
3. Does it still matter tomorrow morning?

An update that fails any of the three stays in the tool it came from. It is not lost. It is one click away for the person who needs it.

You choose, not us#

Each source has a short list of things you can follow, and each one can be switched off. An example for one workspace:

Metrics    Sign-ups, Revenue, Latency     on
Metrics    Raw events                     off
Support    Billing, Onboarding            on
Support    Feedback                       off
Deploys    Production, Staging            on
Deploys    Preview builds                 off

The names above are examples. Your own list will look different.

What we leave out on purpose#

• Anything that repeats every few minutes.
• Updates that only make sense inside the tool they came from.
• Numbers that did not move.

If an entry would not change what anyone does today, it does not belong in the feed.

Support queues arrive in the timeline with this week’s release. The same three questions shaped which conversations appear and how they are grouped.