Skill oficial · Principios de pensadores de negocios

Plan de lanzamiento que no escala, estilo Graham

Convierte una idea de producto en un plan para sus primeros usuarios a partir del ensayo de Paul Graham Do Things that Don't Scale: un inicio estrecho, usuarios conseguidos a mano, pasos manuales, sin gran lanzamiento y con crecimiento semanal.

Not affiliated with or endorsed by Paul Graham or their companies. About these principles: Paul Graham's ideas, explained.

Funciona en Claude, ChatGPT y agentes de programación. En Team y Business, la skill oficial de tu pod se actualiza sola cuando la mejoramos.

Cuándo usarla

Qué le das

Qué obtienes

La idea como vector, un grupo inicial estrecho, una lista de usuarios a conseguir a mano, la experiencia de los primeros usuarios, pasos manuales con su disparador para automatizar, recortes y una medida semanal.

Cómo funciona

  1. Escribe el vector (principio 10) Primer componente: lo que construyes. Segundo componente: lo que harás a mano para arrancar. Si el segundo componente está vacío, para y dilo claramente; es la señal de alarma del ensayo.
  2. Elige el fuego contenido (principio 6) Nombra el grupo más estrecho donde podrías llegar rápido a una masa crítica, cuántas personas lo forman y por qué sentirían que el producto es para ellas. Prefiere el grupo que se apunta más rápido al que más paga, salvo que el caso del usuario diga lo contrario.
  3. Enumera a quién conseguir a mano (principio 2) De diez a treinta lugares o personas con nombre (comunidades, eventos, antiguos clientes, colegas) y la primera acción exacta para cada uno: una visita, una llamada, una sesión de configuración. Sustituye “enviar un enlace” por “darles de alta juntos”.
  4. Diseña la experiencia de los primeros usuarios (principios 4 y 5) Lo que cada usuario nuevo recibe de los fundadores y que una gran empresa no podría darle: una puesta en marcha personal, una línea directa, una nota, un arreglo publicado el mismo día. Nombra quién lo hace y cuánto tiempo lleva por usuario.
  5. Elige un usuario para el que construir (principio 7) En B2B, el usuario a cuyas necesidades te vas a ajustar de cerca, y lo que aprenderás usando el producto en su nombre.
  6. Marca lo que sigue siendo manual (principio 8) Cada paso que harás a mano ahora, su tiempo por usuario y el número de usuarios u horas por semana a partir del cual lo automatizarás.
  7. Recorta las grandes apuestas (principio 9) Enumera cualquier gran lanzamiento, campaña de prensa o alianza del plan, y qué hacer en su lugar con ese tiempo.
  8. Fija la medida semanal (principio 3) Una cifra (ingresos si los hay; si no, usuarios activos), su valor actual, un objetivo de crecimiento semanal que el equipo crea que puede alcanzar y una revisión semanal.

El SKILL.md

El archivo completo, tal como lo lee tu IA. Descargarlo

---
name: paul-graham-style-unscalable-plan
description: Convierte una idea de producto o de negocio en un plan para sus primeros usuarios con los consejos del ensayo de Paul Graham “Do Things that Don't Scale” (julio de 2013; en traducción nuestra, “Haz cosas que no escalan”). Trata la idea como un par formado por lo que construyes y las cosas que no escalan que haces para arrancar, consigue usuarios a mano, empieza en un mercado deliberadamente estrecho donde puedas llegar a una masa crítica, haz que la experiencia de ser uno de los primeros usuarios sea extraordinaria, trabaja de cerca con un usuario como si construyeras solo para él, haz a mano lo que automatizarás después, olvida el gran lanzamiento y la gran alianza, y mide el crecimiento semanal. Úsala cuando un fundador o un equipo está a punto de lanzar, tiene un producto pero pocos usuarios, espera a que los usuarios lleguen solos, planea un gran lanzamiento o una alianza para arrancar el crecimiento, o pregunta cómo conseguir los primeros clientes o qué hacer que no escale.
---

# Plan de lanzamiento que no escala al estilo de Paul Graham

Estos son principios que Paul Graham ha expuesto públicamente en sus ensayos, sobre todo “Do Things that Don't Scale” (julio de 2013; en traducción nuestra, “Haz cosas que no escalan”) y “Startup = Growth” (septiembre de 2012; “Startup = crecimiento”). Sin afiliación con Paul Graham ni con sus empresas, y sin su respaldo. La skill revisa el plan de lanzamiento del usuario frente a los consejos del ensayo y lo convierte en un plan concreto para los primeros usuarios: quiénes, cómo se les encuentra, qué se hace a mano y cómo se mide el crecimiento semana a semana.

## Reglas básicas

- No atribuyas a Paul Graham citas ni opiniones más allá de las fuentes citadas.
- No hagas un juego de rol, no lo imites ni escribas con la voz de Paul Graham; revisa el material del usuario frente a los principios de abajo.
- Usa las cifras del propio usuario. Nunca inventes número de usuarios, tasas de crecimiento ni tasas de conversión; marca los huecos con “[comprobar: ...]”.
- El ensayo está escrito para startups que aspiran a crecer rápido. Para un negocio que no busca crecer rápido (un estudio, una tienda de barrio), di qué principios siguen encajando y cuáles no.
- Hacer cosas a mano tiene que ser honesto con los usuarios: nunca propongas engañar a nadie sobre lo que está pagando, y respeta la privacidad y el consentimiento al contactar con la gente.
- Los ejemplos de empresas del ensayo (Stripe, Airbnb, Facebook y otras) son del ensayo; no añadas afirmaciones sobre esas empresas que vayan más allá.

## Los principios

1. **Las startups despegan porque los fundadores las empujan.** Pocas crecen solas; el ensayo compara el empujón inicial con la manivela de los primeros motores de coche. Fuente: “Do Things that Don't Scale”, julio de 2013, sección inicial.
2. **Consigue usuarios a mano.** Lo que más hacen los fundadores al principio sin que escale es conseguir usuarios a mano en lugar de esperarlos; el ensayo describe a fundadores que dan de alta a la gente en el momento en lugar de enviarles un enlace. Encuentra el grupo más prometedor observando qué primeros usuarios muestran más entusiasmo y busca a más como ellos. Fuente: el mismo ensayo, secciones “Recruit” y “Fragile”.
3. **Los números pequeños se acumulan; mide el crecimiento semanal.** Los fundadores descartan conseguir usuarios a mano porque las cifras absolutas parecen pequeñas, y subestiman el crecimiento compuesto; el ensayo anima a medir el avance por la tasa de crecimiento semanal. “Startup = Growth” explica por qué Y Combinator mide el crecimiento por semana y, en su sección “Compass”, aconseja elegir una tasa de crecimiento que creas que puedes alcanzar e intentar alcanzarla cada semana. Fuente: el mismo ensayo, “Recruit”; “Startup = Growth”, septiembre de 2012.
4. **Encanta a los primeros usuarios.** Toma medidas extraordinarias para que los primeros usuarios estén contentos; ser pequeño te permite dar un nivel de atención que ninguna gran empresa puede dar. El ejemplo del ensayo es una empresa que enviaba a cada usuario nuevo una nota de agradecimiento escrita a mano. Fuente: el mismo ensayo, “Delight”.
5. **La experiencia, no solo el producto.** En una startup nueva, lo que debe ser extraordinario es la experiencia de ser usuario, y la atención puede compensar un producto temprano e incompleto. Tratar directamente con los primeros usuarios forma parte del ciclo de retroalimentación que hace bueno el producto. Fuente: el mismo ensayo, “Experience”.
6. **Empieza con un fuego contenido.** A veces lo correcto es un mercado deliberadamente estrecho donde puedas llegar rápido a una masa crítica, y luego ampliar. Al elegir entre el grupo que se apunta más rápido y el que más paga, el ensayo dice que lo mejor suele ser el primero. Fuente: el mismo ensayo, “Fire” y nota 8.
7. **Trabaja para un usuario como un consultor.** En B2B, elige un solo usuario y construye algo solo para él; el primer usuario es el molde, y lo que le encaja a él a menudo les encaja a otros. No cobres por horas por ello. Usar tu propio software en nombre de los usuarios te enseña cómo lo viven ellos. Fuente: el mismo ensayo, “Consult”.
8. **Sé el software y luego automatiza los cuellos de botella.** Con pocos usuarios, haz a mano lo que piensas automatizar y luego automatiza poco a poco; sabrás qué construir porque lo hiciste tú. Fuente: el mismo ensayo, “Manual”.
9. **Ni gran lanzamiento ni gran alianza.** De un lanzamiento solo necesitas un núcleo inicial de usuarios; cómo te vaya meses después depende más de lo contentos que los hayas dejado. Las alianzas con grandes empresas no suelen poner en marcha el crecimiento. Fuente: el mismo ensayo, “Big”.
10. **Una idea es un vector.** Piensa en una idea como un par: lo que vas a construir, más las cosas que no escalan que harás al principio para arrancar, normalmente conseguir usuarios a mano y darles una experiencia extraordinaria. Una idea cuya segunda parte está vacía, porque no hay forma de encontrar usuarios a los que conseguir a mano, probablemente es una mala idea, al menos para esos fundadores. Fuente: el mismo ensayo, “Vector” y nota 12.

## Cuándo usarla

- Antes de un lanzamiento, para sustituir “lanzar y ver qué pasa” por un plan para los primeros usuarios.
- Un producto que funciona pero tiene pocos usuarios, y un equipo esperando a que lleguen.
- Un plan que depende de un gran día de lanzamiento, de la prensa o de un gran socio.
- Para decidir con qué grupo estrecho empezar.
- No sirve para el programa de crecimiento de un producto maduro (usa experiment-plan o positioning-statement), ni para la economía unitaria (usa unit-economics-check).

## Qué necesitas

- Lo que estás construyendo, en una frase, y para quién.
- Los usuarios o clientes actuales, si los hay, y cómo te encontró cada uno.
- El plan de lanzamiento actual.
- Dónde se reúnen tus probables primeros usuarios, en internet o en persona, y si puedes llegar a ellos tú mismo.
- Qué parte del producto se podría hacer a mano por ahora.
- Las cifras semanales que tengas (registros, usuarios activos, ingresos).

## Pasos

1. **Escribe el vector (principio 10).** Primer componente: lo que construyes. Segundo componente: lo que harás a mano para arrancar. Si el segundo componente está vacío, para y dilo claramente; es la señal de alarma del ensayo.
2. **Elige el fuego contenido (principio 6).** Nombra el grupo más estrecho donde podrías llegar rápido a una masa crítica, cuántas personas lo forman y por qué sentirían que el producto es para ellas. Prefiere el grupo que se apunta más rápido al que más paga, salvo que el caso del usuario diga lo contrario.
3. **Enumera a quién conseguir a mano (principio 2).** De diez a treinta lugares o personas con nombre (comunidades, eventos, antiguos clientes, colegas) y la primera acción exacta para cada uno: una visita, una llamada, una sesión de configuración. Sustituye “enviar un enlace” por “darles de alta juntos”.
4. **Diseña la experiencia de los primeros usuarios (principios 4 y 5).** Lo que cada usuario nuevo recibe de los fundadores y que una gran empresa no podría darle: una puesta en marcha personal, una línea directa, una nota, un arreglo publicado el mismo día. Nombra quién lo hace y cuánto tiempo lleva por usuario.
5. **Elige un usuario para el que construir (principio 7).** En B2B, el usuario a cuyas necesidades te vas a ajustar de cerca, y lo que aprenderás usando el producto en su nombre.
6. **Marca lo que sigue siendo manual (principio 8).** Cada paso que harás a mano ahora, su tiempo por usuario y el número de usuarios u horas por semana a partir del cual lo automatizarás.
7. **Recorta las grandes apuestas (principio 9).** Enumera cualquier gran lanzamiento, campaña de prensa o alianza del plan, y qué hacer en su lugar con ese tiempo.
8. **Fija la medida semanal (principio 3).** Una cifra (ingresos si los hay; si no, usuarios activos), su valor actual, un objetivo de crecimiento semanal que el equipo crea que puede alcanzar y una revisión semanal.

## Formato de salida

```markdown
# Plan de lanzamiento que no escala: [producto]
Estos son principios que Paul Graham ha expuesto públicamente en “Do Things that Don't Scale” (julio de 2013) y “Startup = Growth” (septiembre de 2012). Sin afiliación con Paul Graham ni con sus empresas, y sin su respaldo.

## El vector
Construir: [qué]. Hacer a mano: [qué]. [Aviso si la segunda parte está vacía]

## Fuego contenido
[Grupo], unas [n] personas [o comprobar], porque [por qué es para ellas].

## Conseguir usuarios a mano
| Dónde / quién | Primera acción | Quién del equipo | Para cuándo |
|---|---|---|---|

## Experiencia de los primeros usuarios
| Qué recibe cada usuario nuevo | Quién lo hace | Tiempo por usuario |
|---|---|---|

## Un usuario para el que construir
[Quién, a qué te ajustarás, qué aprenderás]

## Manual ahora, automatizar después
| Paso hecho a mano | Tiempo por usuario | Automatizar cuando |
|---|---|---|

## Recortar o aplazar
[Gran lanzamiento / alianzas y qué los sustituye]

## Medida semanal
[Cifra], ahora [x], objetivo semanal [y], revisión los [día].

## Principios usados
[Numerados, con ensayo y sección]
```

## Ejemplo

**Entrada:** “Hemos creado una herramienta de reservas y recordatorios para peluquerías independientes. La usan 4 peluquerías, todas de amigos de mi cofundador. Plan: lanzar en un gran directorio de productos el mes que viene e intentar una alianza con una cadena de suministros para peluquerías. Nuestra puesta en marcha es un formulario de registro; nuestro código envía los recordatorios, pero configurar los servicios de la peluquería les lleva una hora y la mayoría abandona”.

**Salida (fragmento):**

```markdown
Estos son principios que Paul Graham ha expuesto públicamente en “Do Things that Don't Scale” (julio de 2013) y “Startup = Growth” (septiembre de 2012). Sin afiliación con Paul Graham ni con sus empresas, y sin su respaldo.

## El vector
Construir: reservas y recordatorios para peluquerías independientes. Hacer a mano: configurar nosotros mismos, en la peluquería, los servicios y el personal de cada una, y hacer un seguimiento semanal.

## Fuego contenido
Peluquerías independientes de un barrio de una ciudad [comprobar: cuántas], donde los dueños se conocen y pueden ver la herramienta funcionando en la peluquería de un amigo.

## Conseguir usuarios a mano
| Dónde / quién | Primera acción | Quién del equipo | Para cuándo |
|---|---|---|---|
| Dueños que conocen las 4 peluquerías actuales | Pedir a cada dueño actual dos presentaciones | Cofundador | Esta semana |
| Peluquerías de la calle principal del barrio | Visitarlas en persona una mañana tranquila entre semana y configurarlo en el momento si dicen que sí | Los dos fundadores | Las próximas dos semanas |

## Manual ahora, automatizar después
| Paso hecho a mano | Tiempo por usuario | Automatizar cuando |
|---|---|---|
| Introducir servicios, precios y personal | Alrededor de 1 hora [según la entrada] | Cuando las configuraciones lleven más de [comprobar: horas] a la semana |

## Recortar o aplazar
El lanzamiento en el directorio y la alianza con la cadena de suministros. El ensayo dice que un lanzamiento solo tiene que traer un núcleo inicial de usuarios y que las grandes alianzas no suelen poner en marcha el crecimiento; dedica ese mes al barrio.

## Medida semanal
Peluquerías activas, ahora 4, objetivo semanal [lo fija el equipo], revisión todos los lunes.
```

## Comprobaciones antes de enviar

- [ ] Las líneas de atribución y de no afiliación están en la salida.
- [ ] El vector tiene sus dos partes, o el plan dice claramente que la segunda está vacía.
- [ ] El grupo inicial es estrecho y tiene nombre, con un motivo por el que el producto es para él.
- [ ] Los usuarios se consiguen a mano, con lugares o personas con nombre y primeras acciones.
- [ ] Cada paso manual tiene un disparador de “automatizar cuando”.
- [ ] Cualquier gran lanzamiento o alianza se cuestiona, con el motivo del ensayo.
- [ ] Una cifra semanal con su valor actual; ninguna cifra inventada.

## Errores comunes

- Tomar “haz cosas que no escalan” como permiso para seguir haciéndolo todo a mano para siempre; el ensayo dice que hay que automatizar los cuellos de botella poco a poco.
- Elegir un mercado amplio porque parece más grande, en lugar de un grupo que pueda llegar a una masa crítica.
- Contar el total de registros en lugar del crecimiento semanal.
- Copiar como tácticas las historias de empresas del ensayo sin comprobar si encajan en el mercado del usuario.

Compártela con tu equipo

Agrégala a un AI Skill Pod y todo el equipo, colaboradores externos incluidos, usa la misma versión desde su propia IA. Lee las mejores formas de compartir skills de IA con un equipo

Agregar al pod de mi equipo

Historial de cambios

Fuentes

  1. Do Things that Don't Scale, Paul Graham, July 2013 (leída el 2026-11-04)
  2. Startup = Growth, Paul Graham, September 2012 (leída el 2026-11-04)