The Rude FAQ

Overview

The Rude FAQ is the part of Working Backwards that most companies skip — and the part that makes the mechanism actually work.

Where the Customer FAQ is about clarity of value, and the Stakeholder FAQ is about feasibility and execution, the Rude FAQ is about brutally honest self-interrogation:

• What will break?
• Why will this fail?
• Where are the unseen risks?
• What is everyone afraid to say?
• What assumptions are wrong?
• What happens if we ship and nobody cares?

The Rude FAQ is not pessimism.
It is risk engineering.
It protects time, capital, and engineering bandwidth by forcing truth into the open before a single sprint begins.

Why the Rude FAQ Exists

Most product failures are not caused by:

• A technical limitation
• A lack of engineering talent
• Poor UX
• Bad pricing

They are caused by wishful thinking and cultural fear of calling out uncomfortable truths.

The Rude FAQ eliminates:

• Founder bias
• Confirmation bias
• Narrative-driven decision making
• Overconfidence
• Blind spots

If the Rude FAQ feels harsh, good.
That means it is doing its job.

How to Write a Rude FAQ

The Rude FAQ answers the questions we hope never get asked — but always do.

It should:

• Assume the product will be challenged
• Assume the competitive landscape is hostile
• Assume the constraints are real
• Assume the world doesn't care about our good intentions

It is written in direct language. Plain, factual, sharp.

It should include:

• Risks
• Unknowns
• Limitations
• Dependencies
• Worst-case scenarios

If a Rude FAQ feels polite or diplomatic, it is not a Rude FAQ.

Core Areas the Rude FAQ Covers

A proper Rude FAQ includes blunt questions across:

Reality & Assumptions

• Why might we be wrong about demand?
• What if customers don't care?
• What assumption has the highest uncertainty?

Competition

• What makes us think we can win here?
• Why won't incumbents copy or crush this?

Architecture & Execution

• What technical risks will slow us down?
• Where are the unknown unknowns?

Resourcing

• What if we can't hire the talent we need?
• What if the team doesn't have bandwidth?

Operational & Reliability Risk

• What happens when it fails in the real world?
• What are the biggest failure modes?

Adoption & GTM

• How will we sell this without over-promising?
• What are the switching and activation risks?

Culture & Behavior

• Where might we self-sabotage?
• What political or organizational risks exist?

The Rude FAQ exposes variables that could kill the product.

Common Rude FAQ Questions

Below are the most common question patterns to include:

Demand and Adoption

• What if users don't behave as we expect?
• What if nobody uses it?
• What needs to be true for adoption to happen?

Competition and Market Reality

• Why can't a competitor copy this in 3 months?
• What would cause us to lose?
• What alternatives exist that we are ignoring?

Architecture and Technical Risk

• What is the single hardest technical problem?
• What is the dependency that could derail us?
• What design choice could become a scaling nightmare?

Operational and Reliability Risk

• What is the mission-critical failure mode?
• What happens when this breaks in the real world?
• What is our worst-case scenario?

Team and Execution Risk

• What skillsets are missing?
• What organizational friction might kill speed?
• What do we need to stop doing or reprioritize?

Economic and Business Risk

• What if the economics don't work?
• What if the value doesn't justify cost?
• What if we get stuck in long sales cycles?

The Goal of the Rude FAQ

The goal is simple:

Kill bad ideas early and strengthen good ideas before we execute.

The Rude FAQ forces honesty about:

• Execution reality
• Competitive pressure
• External blockers
• Internal dependencies
• Cultural pitfalls

When these questions surface early, teams make better decisions later.

What a Great Rude FAQ Looks Like

A strong Rude FAQ:

• Makes the team uncomfortable
• Reveals architectural and operational risks
• Contains specific weaknesses
• Names real constraints and tradeoffs
• Highlights hidden requirements
• Calls out places we may be deluding ourselves

It's better to discover these concerns at the document stage than in production.

What a Poor Rude FAQ Looks Like

A weak Rude FAQ:

• Uses polite, vague language
• Repeats the Stakeholder FAQ
• Avoids naming tradeoffs
• Sanitizes risks
• Sounds like marketing
• Tries to sound optimistic

A weak FAQ is a signal that:
The team is not ready or not being honest.

How to Review a Rude FAQ

Ask:

• Does this make us uncomfortable?
• Does it challenge assumptions?
• Does it reveal what could kill the idea?

If the answer is no:
It is a weak FAQ and needs another pass.

Where It Fits in the Working Backwards System

The Rude FAQ is reviewed last because it has only two purposes:

1. Expose the unspoken risks
2. Force the team to defend their assumptions

This is the mechanism that transforms Working Backwards from a documentation exercise into a truth-seeking system.