SaaS
Lanzas versiones cada quince días y escribes sobre ello dos veces al año
A los equipos de software no les faltan cosas que contar. Les falta la persona que las cuenta, porque escribir siempre es la tarea que se pospone cuando el lanzamiento se retrasa, y se pospone todas las veces, hasta que la entrada más reciente del blog tiene once meses y dice "presentamos".
El fallo es estructural, no editorial
Cada equipo sabe que debería escribir más. Los ingenieros saben escribir; el fundador sabe escribir; normalmente a alguien le gusta. El problema es que escribir no tiene fecha límite propia, y todo lo que no tiene fecha límite pierde contra todo lo que la tiene, cada quince días, para siempre.
Un plan aporta la fecha límite que falta. Una casilla con fecha, un tema y un redactor asignado es un compromiso tomado en una semana tranquila y aplicado en una semana que no lo es, y el borrador aparece lo recuerde o no nadie. Aprobarlo lleva minutos; escribirlo desde cero lleva una tarde que nunca llega.
Ese es todo el argumento. No es que un modelo escriba mejor que tu equipo, porque no lo hace. Es que un borrador que editas el martes existe, y una entrada que tenías intención de escribir no.
Una hoja de ruta es un plan que ya escribiste
La mayor parte de los seis meses ya está decidida. Sabes más o menos qué se lanza en los próximos dos trimestres, qué partes del producto se malinterpretan, qué integraciones te piden constantemente y qué preguntas llegan a soporte todas las semanas.
Cada una de esas cosas es un tema. La hoja de ruta aporta la cadencia —un lanzamiento se convierte en una serie de casillas en lugar de una sola entrada en el registro de cambios— y soporte aporta la mitad perenne, porque una pregunta que se hace veinte veces al mes es un texto que vale la pena escribir una vez y enlazar para siempre.
Deja huecos. Los lanzamientos se retrasan, y un plan sin casillas vacías convierte un lanzamiento retrasado en tres entradas sobre algo que todavía no existe. Dejar abierta una cuarta parte de las casillas no es holgura; es la parte del plan que sobrevive al contacto con tu calendario real.
- 1BlogQué se lanzó y por qué existe. Primero el problema, después la función.
- 2Facebook / InstagramLa versión en una frase, para quienes nunca abrirán un registro de cambios.
- 3BlogCómo lo usó alguien de verdad. Concreto, con las partes incómodas incluidas.
- ·Si se retrasaLas franjas se mueven con el lanzamiento. Nada anuncia algo que no existe.
- 4BlogLa pregunta de soporte que esta versión por fin responde, escrita una sola vez.
La hoja de ruta marca el ritmoSoporte marca los temas
Tu registro de cambios no es contenido. Es un recibo.
Dos redactores, a veces tres
El que explica el producto, y el que habla de la empresa
Son voces genuinamente distintas, y fusionarlas produce esa insipidez tan característica de los blogs de software: una entrada que no es ni una explicación técnica ni un relato humano de nada.
El redactor técnico
Explica qué hace una cosa, con precisión y sin adjetivos. Sabe para qué sirve tu producto y para qué no, y tiene permiso para decirlo. Es el redactor cuyas entradas se enlazan desde los tickets de soporte.
La voz de la empresa
Escribe sobre decisiones, equilibrios y hacia dónde estáis construyendo. Útil de una forma difícil de medir y evidente en la contratación, en las llamadas de ventas y en la razón por la que alguien elige a un proveedor pequeño antes que a uno grande.
El que responde
Gestiona los comentarios bajo tu política. Responde lo que puede, señala lo que no puede y nunca especula sobre la hoja de ruta. Todo lo que se parezca a una incidencia de soporte pasa de inmediato a una persona.
Aquí la puerta de aprobación hace un trabajo real
Para una panadería, una entrada sin aprobar es un pequeño bochorno. Para una empresa de software es una carga de soporte, una objeción de venta o un compromiso que nadie aceptó. Un borrador que describe un límite ligeramente mal te lo citará de vuelta un cliente, y un borrador que insinúa una fecha se tomará como una promesa.
Así que este es el caso donde el piloto automático merece más cautela. Un acuerdo razonable es piloto automático en las franjas sociales cortas que repiten algo ya publicado, y aprobación en todo lo que haga una afirmación sobre el producto. Cualquier cosa sobre precios, capacidad o fechas debería leerla una persona de forma permanente, y vale la pena escribirlo en las reglas del redactor para que los borradores de ese tipo se retengan y se marquen en lugar de encolarse.
Lo que el informe le dice a un equipo pequeño
Planificado frente a publicado es la cifra que importa, y para un equipo de software suele ser incómoda el primer trimestre. También es la única medida honesta de si la escritura ha dejado de perder de nuevo contra el lanzamiento.
La acogida importa menos de lo que parece. Un artículo técnico encuentra a su público en meses, no en días, y juzgarlo en la segunda semana te hará retirar las piezas que iban a funcionar. El equilibrio de temas es más útil al principio: muestra si solo escribes sobre lo que se ha lanzado, que es el modo de fallo estándar y la razón de que tantos blogs de software se lean como un registro de cambios con párrafos.
La parte honesta: si tu producto es genuinamente técnico, las piezas más profundas siguen necesitando a un ingeniero durante una tarde. Lo que cambia con un plan es que esas tardes se programan y el otro ochenta por ciento de la escritura deja de competir con ellas.