Decision Log para Startups
Los startups toman cientos de decisiones a la semana. La mayoría se pierde en Slack. Así se construye un registro de decisiones que funciona.
By Ellis Keane · 2026-03-16
En 1986, el transbordador espacial Challenger se desintegró 73 segundos después del lanzamiento. La investigación posterior reveló que los ingenieros de Morton Thiokol habían expresado la noche anterior sus preocupaciones sobre los sellos de los aros en O, argumentando que el frío hacía el lanzamiento inseguro. La dirección los ignoró. La decisión se tomó en una teleconferencia y, aunque existían diagramas y testimonios, el razonamiento crítico detrás de la anulación estaba fragmentado entre los participantes y nunca llegó de forma fiable a la cadena de mando.
No estoy comparando las decisiones de producto de tu startup con un desastre del transbordador (bueno, no la mayoría de ellas). Pero el patrón de fallo subyacente es el mismo que veo desarrollarse en startups cada semana, solo que con menos consecuencias: se toma una decisión, el razonamiento detrás de ella vive en la cabeza de alguien o en un hilo de Slack que está a punto de desaparecer de la pantalla, y tres meses después nadie puede reconstruir por qué elegimos el enfoque A sobre el B. No porque la decisión fuera errónea – a veces fue estupenda –, sino porque el contexto que la hizo correcta se ha evaporado.
"Se toma una decisión, el razonamiento detrás de ella vive en la cabeza de alguien o en un hilo de Slack que está a punto de desaparecer de la pantalla, y tres meses después nadie puede reconstruir por qué elegimos el enfoque A sobre el B." – Ellis Keane
Un registro de decisiones para startups no es un ejercicio burocrático. Es la diferencia entre «intentamos eso y no funcionó» (útil) y «creo que hablamos de eso alguna vez» (inútil).
La anatomía de una decisión perdida
Permíteme rastrear una decisión concreta a lo largo de su ciclo de vida, porque la versión abstracta de este problema convence menos que la concreta.
Es un martes de febrero. Tu jefe de ingeniería y tu PM están en un hilo de Slack debatiendo si construir un sistema de notificaciones propio o usar un servicio de terceros. El hilo tiene 47 mensajes (lo sé, pero así funcionan las cosas), y en el mensaje 38 ya han optado por la opción externa porque la implementación propia llevaría tres sprints y la fecha de lanzamiento es en dos.
El PM crea un issue en Linear: «Integrar [Servicio X] para notificaciones.» Un ingeniero lo toma, empieza a desarrollar. El hilo de Slack sigue ahí, técnicamente, pero nadie lo marca como favorito ni lo enlaza desde el issue de Linear.
Avancemos a mayo. El servicio externo tiene un problema de fiabilidad. Alguien pregunta: «¿Por qué no lo construimos nosotros mismos?» El PM recuerda la conversación, pero no los detalles. El jefe de ingeniería está de baja parental. El hilo de Slack está en algún lugar del canal #engineering de febrero, pero nadie recuerda la fecha exacta, y la búsqueda en Slack devuelve 200 resultados para «notificación» – porque, claro, todos los equipos hablan constantemente de notificaciones.
El equipo pasa 45 minutos en una reunión reconstruyendo el razonamiento original. Al final llegan a la misma conclusión – la restricción de tiempo seguía vigente –, pero los 45 minutos se han ido y la duda persiste. Multiplica esto por las docenas de decisiones que un startup toma cada mes y tendrás un volumen significativo de tiempo invertido en volver a debatir decisiones que ya se tomaron con cuidado.
Por qué los startups son especialmente malos en esto
Las grandes empresas (con todos sus defectos, que son muchos) tienden a codificar la memoria institucional en procesos: registros de decisiones de arquitectura, RFCs, documentos de diseño que pasan por ciclos formales de revisión. Las decisiones pueden estar enterradas en Confluence, pero al menos están escritas en algún lugar accesible.
Los startups no tienen esa infraestructura, y construirla parece exactamente el tipo de sobrecarga que se supone que debes evitar cuando eres pequeño y ágil. Hay un argumento razonable que dice que «simplemente lo recordaremos» funciona con cuatro personas – y así es –, hasta que llega la persona número cinco y no tiene contexto de por qué las cosas son como son.
Lo que hace que el seguimiento de decisiones en startups sea especialmente difícil es la fragmentación de herramientas. Las decisiones ocurren en todas partes: hilos de Slack, llamadas de Zoom, comentarios de Notion, discusiones de Linear, revisiones de PR en GitHub y – cada vez más – en mensajes directos que nunca llegan a un canal compartido. Cada herramienta captura un fragmento de la decisión, pero ninguna captura el conjunto, y los vínculos entre ellas los mantiene la memoria humana, que – con todo el cariño del mundo – es la base de datos menos fiable a la que tenemos acceso.
Qué necesita realmente un registro de decisiones
Hay una tentación de complicar esto en exceso. He visto equipos construir elaboradas bases de datos en Notion con 15 propiedades por entrada – tipo de decisión, nivel de impacto, estado de revisión, partes interesadas, OKRs relacionados – y luego no usarlas nunca porque el esfuerzo de rellenar todos esos campos para cada decisión supera el valor percibido.
Un registro de decisiones para startups debe ser lo suficientemente ligero como para que la gente lo use realmente. Esto es lo que importa:
La decisión en sí. Una frase. «Usaremos el Servicio X para notificaciones en lugar de desarrollarlo nosotros.» No un párrafo – una frase.
Quién la tomó y cuándo. Nombre y fecha. Parece obvio, pero es la parte que más importa cuando alguien cuestiona la decisión seis meses después. No es una cuestión de culpa (bueno, casi nunca) – es saber a quién preguntar por el razonamiento original.
Qué alternativas se consideraron. Dos o tres viñetas. «Se consideró desarrollo propio (estimación de 3 sprints, plazo demasiado ajustado)» y «Se consideró el Servicio Y (el precio no escala más allá de 10.000 usuarios).» Esta es la parte que previene volver a debatir – si las alternativas y sus concesiones están documentadas, el equipo no necesita redescubrirlas.
Dónde ocurrió la discusión. Un enlace al hilo de Slack, al issue de Linear, al comentario de Notion – dondequiera que se produjera el debate real. Este es el campo más infravalorado. Sin él, la entrada del registro es una afirmación sin evidencia. Con él, cualquiera que quiera el contexto completo puede leer la conversación original.
Qué cambiaría la decisión. Esto es opcional pero increíblemente útil para startups donde el contexto cambia rápido. «Reconsideraríamos esto si la fecha de lanzamiento se desplaza más de cuatro semanas» o «Esto asume que nos mantenemos por debajo de las 10.000 notificaciones mensuales.» Convierte un registro estático en uno vivo.
El mejor registro de decisiones para startups es el que tu equipo realmente rellena. Cinco campos, una frase cada uno. Si tarda más de 90 segundos registrar una decisión, el sistema morirá en menos de un mes.
Dónde ubicarlo
He visto equipos probar tres enfoques, y todos tienen sus concesiones.
Una base de datos en Notion. Es el más común y funciona razonablemente bien. Crea una base de datos con los cinco campos anteriores, añade una plantilla para que rellenarla sea rápido, y enlaza cada entrada a la página de proyecto correspondiente. El inconveniente: Notion es donde viven las especificaciones, no donde se toman las decisiones, así que dependes de que alguien vaya a Notion después de que la decisión se haya tomado en otro lugar. Ese paso «después» es donde se produce el abandono.
Directamente en Slack. Algunos equipos usan un canal dedicado #decisiones y publican un mensaje formateado para cada decisión. Esto genera menos fricción (la decisión probablemente se tomó en Slack de todas formas), pero la búsqueda de Slack dificulta encontrar decisiones por proyecto o rango de fechas, y la falta de campos estructurados hace que la consistencia se deteriore con el tiempo.
Directamente en Linear. Si la decisión se relaciona con un flujo de trabajo específico, registrarla como comentario en el issue de Linear correspondiente mantiene la decisión cerca del trabajo que afecta. El inconveniente es que las decisiones que abarcan múltiples issues o proyectos no tienen un lugar natural.
Ninguno es ideal, siendo honesto. El problema fundamental es que las decisiones ocurren en múltiples herramientas, pero los registros viven en una sola, por lo que siempre hay un paso manual para tender el puente. Ese paso manual es el único punto de fallo en cada registro de decisiones que he visto.
Lo que estamos construyendo en Sugarbug
El enfoque que adoptamos con Sugarbug es detectar las decisiones a medida que ocurren a través de las herramientas, en lugar de pedirle a alguien que las registre manualmente.
Cuando un hilo de Slack llega a una conclusión («OK, vamos con el Servicio X»), cuando se resuelve una discusión en un issue de Linear, cuando una revisión de PR en GitHub termina con una aprobación – todas estas son señales de que se ha tomado una decisión. Sugarbug ingiere estas señales, las clasifica y las vincula con las tareas y personas relevantes en el grafo de conocimiento. El «registro de decisiones» no es una base de datos separada que alguien tenga que mantener – es una vista de las decisiones que ya están integradas en tus herramientas existentes.
Todavía estamos trabajando en la precisión de la clasificación (determinar la diferencia entre «una decisión» y «simplemente una conversación» es más difícil de lo que parece), pero la apuesta estratégica es que capturar las decisiones en la fuente, donde realmente ocurren, es más fiable que pedirle a las personas que las dupliquen en un sistema separado.
Si esto te interesa, sugarbug.ai tiene más detalles. Pero el sistema manual descrito arriba servirá bien a la mayoría de startups hasta que el equipo sea lo suficientemente grande como para que la tasa de abandono del registro manual se convierta en un problema real – en nuestra experiencia, generalmente en torno a las 8–12 personas.
Deja de perder decisiones en el scroll de Slack. Sugarbug las captura automáticamente desde las herramientas donde realmente ocurren.
Q: ¿Qué debe incluir el registro de decisiones de un startup? A: Como mínimo: la propia decisión (una frase), quién la tomó, cuándo, qué alternativas se consideraron y dónde tuvo lugar la discusión. El último campo es el más importante – sin un enlace a la conversación original, la entrada del registro se convierte en una afirmación sin evidencia, y cuando alguien la cuestione seis meses después volverás a reconstruirlo de memoria.
Q: ¿Sugarbug construye automáticamente un registro de decisiones a partir de las herramientas existentes? A: Esa es la dirección que estamos tomando. Sugarbug ingiere señales de Slack, Linear, GitHub, Notion y otras herramientas, clasificándolas en un grafo de conocimiento. Cuando detecta una decisión – un PR aprobado, una discusión de Linear resuelta, un hilo de Slack que termina con un paso siguiente claro –, vincula esa decisión automáticamente con la tarea y las personas relevantes. Seguimos refinando la clasificación (distinguir «decisión» de «conversación» es genuinamente complicado), pero la ingestión y vinculación de señales funcionan.
Q: ¿Con qué frecuencia debería actualizar un startup su registro de decisiones? A: Lo ideal es registrar las decisiones en el momento en que se toman, no de forma semanal. Para el viernes, el razonamiento detrás de la decisión del martes ya resulta difuso, y la probabilidad de que alguien rellene con precisión el campo «alternativas consideradas» cae rápidamente. Si el registro es manual, conviértelo en un hábito de 90 segundos inmediatamente después de la decisión. Si usas una herramienta como Sugarbug, el objetivo es la captura en tiempo real desde las herramientas donde las decisiones realmente ocurren.
Q: ¿Puede Sugarbug hacer seguimiento de decisiones en Slack, Linear y GitHub? A: Sugarbug se conecta con los tres (y con Notion y Figma) y mantiene un grafo de conocimiento de las relaciones entre conversaciones, tareas y cambios de código. Cuando una decisión surge en un hilo de Slack, conduce a un issue de Linear y genera un PR en GitHub, Sugarbug vincula toda la cadena para que puedas rastrear la decisión desde el origen hasta la implementación sin que nadie tenga que crear esos vínculos manualmente.
Q: ¿Cuál es la diferencia entre un registro de decisiones y un Architecture Decision Record (ADR)? A: Los ADR son típicamente documentos formales para decisiones técnicas significativas – «usamos PostgreSQL en lugar de MongoDB» – con secciones estructuradas para contexto, decisión y consecuencias. Un registro de decisiones para startups es más amplio y ligero: captura las decisiones operativas diarias (qué proveedor, qué plazo, qué funcionalidad recortar) que los ADR considerarían demasiado pequeñas para documentar. Ambos son valiosos; el registro de decisiones cubre el 95 % de las decisiones que no justifican un ADR formal pero que igualmente deben ser rastreables.