Product Principle Decision Filter
Use one clear product identity to settle thousands of feature decisions.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 95%
The Product Principle Decision Filter turns a concise statement of product identity into a practical prioritization tool. At Slack, the principle was that Slack is a tool for work, even though it felt social and supported community use cases. That context made many small decisions immediate because workplace products carry obligations that social products do not. A request to let employees block one another, for example, could provide immediate relief but could also conceal harassment from HR or enable colleagues to exclude someone from essential work. The method is to define the product's primary context, derive its obligations, and evaluate both intended use and misuse against them. A strong principle does not decide by slogan alone; it supplies the context needed to expose second-order effects.
Origin
Grace credits Slack's early founding team with establishing that Slack was a tool for work, a principle that clarified thousands of small product decisions despite the product's social feel.
Core principles
- 01A clear product identity makes recurring tradeoffs faster.
- 02Similar-looking use cases may have different obligations and risks.
- 03Features should be judged in the product's operating context, not in isolation.
How to run it
- 1
Define the operating context
Write one sentence stating where the product primarily operates and what role it plays there.
Pro tip Make the sentence specific enough to exclude attractive adjacent use cases.
Watch out A statement broad enough to fit every user will not resolve tradeoffs.
- 2
Derive the obligations
Identify the safety, governance, workflow, and accountability requirements created by that context.
Watch out Do not import assumptions from a superficially similar consumer product.
- 3
Test intended value
Describe the immediate problem the proposed feature solves for the requesting user.
Pro tip Acknowledge the real benefit before evaluating the tradeoff.
- 4
Test misuse and displacement
Ask how the feature could be weaponized and whether it hides a problem that another function must address.
Pro tip Model effects on coworkers and administrators, not only the person pressing the button.
Watch out A local feeling of safety may coexist with a larger organizational risk.
- 5
Decide from the principle
Choose the option that best fits the product identity and its obligations, then document the reasoning for future debates.
In the wild
Some Slack employees wanted blocking because communities also used the product and blocking could help a person feel safer. Grace argued that a workplace tool must preserve organizational accountability: blocking might hide harassment from HR or allow coworkers to exclude someone from meetings and discussions. The work-tool principle exposed risks that a social-product analogy missed.
→ The debate shifted from whether blocking feels useful to whether it fits the responsibilities of a workplace platform.
Common mistakes
Following adjacent use cases
A vocal community can pull the roadmap away from the product's primary context and economic purpose.
Evaluating only intended use
A feature that protects one user may also enable exclusion, concealment, or other second-order harms.
Is it for you?
Best for
Product teams serving a clearly defined environment such as work, healthcare, education, or social interaction.
Not ideal for
Teams that have not yet chosen a primary customer and usage context.
From the episode
Merci Grace (ex-Head of Growth at Slack) on PLG, interviewing, storytelling, building a diverse team, hiring salespeople, building a growth team, and much more