The outcome test
Here's a simple test we use for every workflow we build: Can you describe its value without mentioning a single piece of technology?
If the answer is no, you haven't found the outcome yet.
Two ways to describe the same thing
Technology-first
"It syncs your CRM with your email via REST API webhooks and OAuth tokens."
Outcome-first
"It handles your follow-ups after client calls."
The first description is accurate. It tells you exactly what happens technically. But it requires you to understand CRMs, APIs, webhooks, and OAuth. It puts the machinery front and center.
The second description is also accurate. But it describes what disappears from your life, not what gets added to your tech stack.
Why this matters
When you can only describe your product in technical terms, it usually means one of two things:
- You built something technically interesting that doesn't solve a real problem.
- You solved a real problem but haven't figured out how to talk about it yet.
The first case is common in engineering-driven companies. The technology was the goal, and the use case was retrofitted.
The second case is fixable. You just need to keep asking "so what?" until you get to something a non-technical person would care about.
The exercise
Take your product description. Remove every technical term. What's left?
If the answer is nothing meaningful, that's useful information. It means you're building a solution in search of a problem.
If there's something left — if you can describe a real change in someone's life — then you've found the outcome. Lead with that. The technology is just how you get there.
Map your next project by what disappears from your to-do list, not what gets added to your tech stack.
That's the outcome test.