From One Department to a Network

Expand an existing account through a deliberate rhythm of adoption, boundaries, and shared capability.

The success of one delivery is only a seed. Expansion means turning a validated approach into organizational capability through cadence, boundaries, and a network. Reviewing the Palantir-style playbook, a16z gives advice pointing the same way: exhaust every option to get the first three to five customers running in production before you talk about scale a16z-palantirization.

After reading, you should be able to answer:

• What signal says this customer is ready for a second department, and what signal says it is not
• Which one sentence you must be able to answer before crossing to a department with different workflows
• Why “how many departments we covered” is not an expansion metric

Expansion cadence

Let health and adoption drive the next field, not the next sales opportunity. If the current department has not reached a stable usage and renewal signal, opening another front only multiplies uncertainty. Deepening an existing customer is often more reliable than adding a new department.

Copy within boundaries

Start with departments whose workflows are similar. Before entering a different context, ask which parts of the playbook will fail there. Repair those parts first; do not mistake a successful pattern for a universal template.

From department to network

After enough departments, one-off integrations become the bottleneck again. Move shared data connections, evaluation rules, and tools into a platform. The FDE’s radius grows from one department to the whole network.

Expansion is not the number of departments covered. It is whether department N gets started faster than department N-1.