Why Every Product Needs Success Metrics Before Features

Credex is a spend-audit app for engineering managers - you connect your SaaS subscriptions and it flags overlap and savings. One of the earliest requests was a 'share this report' feature. It came through a Slack message from a beta user who had copy-pasted their report into an email to their CFO and asked if we could make that easier. Three people in the thread said 'yes ship this.' I put it on the roadmap before I had a success metric.

That's the problem.

We were three days from starting when I noticed I couldn't answer 'how will we know if we should keep it?' Nobody in the conversation could. We were about to build something we couldn't evaluate.

Without a success metric, 'worked' gets defined by whoever needed the feature to have worked - usually me, three weeks later, defending the build.

I looked at the surface I actually cared about - reports created per active user - and asked what a share feature was supposed to move. Two candidate outcomes: more reports created by invited teammates, or higher return-visit rate for the original author. The two candidates were not the same product.

That was the moment the feature stopped being obvious. It had been carrying two contradictory jobs in the same name.

I picked outcome A - teammate-created reports - because it mapped to the North Star metric (audits completed per week). I wrote it into the spec as a two-column table: outcome metric on the left, guardrail on the right.

• Outcome: a meaningful increase in weekly reports created via share link, measured three weeks after launch.
• Guardrail: no drop in report completion rate - if people share half-finished audits and never come back, we've made the product feel worse.
• Kill decision: if outcome misses AND guardrail regresses, the feature comes out. No debate.

The guardrail was the one we argued about. An engineer thought 'no drop in completion rate' was too conservative. I didn't budge. Looking back, he was probably right to push and I was right to hold. Both things can be true.

The share feature shipped in a week. Reports created via share links rose, but not enough to call it a clear win. The guardrail held. We kept the feature and scoped a follow-up to fix where the loop was leaking - an invite state that let recipients start where the sharer left off.

The target wasn't hit. The framework still worked, because it turned a feel-good feature into a testable one and told us what to build next.

Defining a metric feels like tempting fate. If you don't name a number, nothing 'fails.' That comfort is exactly why teams under-ship on outcomes.

I still find the conversation uncomfortable when it's a feature I want to build. The two-column table doesn't fix that - it just makes the discomfort visible, which is a different thing. If I built Credex from scratch, the table would be the first block in every PRD, above the problem statement.