A product team, mid-decision. The part we wanted to keep.
“Nobody could remember why we’d said no the first time, so we said yes, and found out why.”
Before Because, we ran a small product team inside a much bigger company. In one planning cycle we rebuilt a feature we had deliberately killed eighteen months earlier. The person who killed it had moved teams. The thread explaining why was in a Slack workspace that no longer existed.
We found the reason the expensive way: by shipping it again and watching the same numbers fall.
Most companies have a version of that story. Decisions get made all day, in threads and on calls, and almost none of them get written down with the reasons attached. Writing them up by hand never sticks, because it’s extra work at exactly the moment everyone wants to move on.
So we built the thing that does the writing for you, and asks only for a nod.
What we hold ourselves to
Four rules that settle most product arguments here before they start.
Ask for a nod, not a form
If keeping a record takes more than one tap, people won’t do it. Every feature has to pass that test.
A person always decides
Because drafts and suggests. It never marks anything settled on its own, and it never will.
Forget by default
We read a lot so we can keep a little. Anything that isn’t a confirmed record is gone within seconds.
Reasons over rulings
A decision without its why is just a rule. We’d rather show three honest reasons than a confident summary.
We use it on ourselves.
A few records from our own log, about building Because. Our changelog is written the same way.
