Founder Operations
Esta Collection mantiene el trabajo del founder organizado, acumulativo y revisable.
Workflow Management
Organizar el trabajo semanal del equipo founder.
Ritmo de founder
Habilidad: Establecer una cadencia de trabajo y revisión que mantiene el venture avanzando de forma sostenida
¿Por qué importa esta habilidad?
Sin un ritmo estructurado, los founders reaccionan constantemente a lo urgente y nunca trabajan en lo importante. Un ciclo semanal predecible — revisar métricas, definir prioridades, cerrar tareas — crea momentum y evita que el venture se estanque o dé vueltas en círculo. Los mejores founders no son más talentosos; son más consistentes.
Qué se ve como un buen resultado
El founder tiene un ritual semanal definido: día y hora fijos para revisar el tablero de métricas, actualizar el log de hipótesis, definir los 3 objetivos de la semana y revisar los Artifacts pendientes. Este ritmo se mantiene incluso en semanas difíciles o de alta actividad.
Errores comunes
- Trabajar sin agenda semanal y decidir en el momento qué hacer cada día
- Saltarse la revisión semanal cuando hay "mucho trabajo" — precisamente cuando más se necesita
- Confundir actividad intensa con progreso real (muchas reuniones ≠ venture avanzando)
- No registrar qué pasó la semana anterior y repetir los mismos errores
- Tener ritmo de trabajo pero no de reflexión — ejecutar sin aprender
Preguntas que el startup debe responder
- ¿Cuándo exactamente, cada semana, revisas tus métricas clave?
- ¿Qué tres cosas deben ocurrir esta semana para que el venture avance?
- ¿Cómo sabes al final de cada semana si fue una buena semana o no?
- ¿Tienes un espacio reservado para reflexionar — no solo ejecutar?
- ¿Qué tan predecible es tu semana de trabajo para tu equipo y mentores?
Artifact requerido
📄 Protocolo de Semana del Founder
Propósito: Documentar y comprometerse con una cadencia semanal de trabajo, revisión y reflexión que mantenga el venture avanzando de forma sostenida durante el programa
Elementos requeridos:
- Día y hora fijos para revisión semanal de métricas (bloque en calendario)
- Lista de 3 preguntas estándar que el founder se hace cada semana
- Proceso para definir las 3 prioridades de la semana siguiente
- Checklist de cierre de semana (¿qué logré? ¿qué aprendí? ¿qué cambio?)
- Registro de las últimas 4 semanas completadas con observaciones
- Compromiso firmado de mantener el ritmo durante el programa
- Nota de cómo se ajusta el ritmo en semanas excepcionales (viajes, demos, etc.)
Formato sugerido: Documento de 1–2 páginas con la estructura del protocolo + tabla de registro de semanas
Señales de calidad: El protocolo es específico (días y horas reales, no genéricos), realista para el contexto del founder, y tiene evidencia de haberse usado al menos 3 semanas seguidas
Errores fatales: Protocolo genérico copiado de una plantilla sin adaptación personal; sin evidencia de uso real; solo aspiracional sin implementación
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El founder tiene un protocolo semanal documentado con días y horas específicos
- El protocolo ha sido seguido al menos 3 semanas consecutivas
- Hay registro de al menos 4 semanas con observaciones de aprendizaje
- El founder puede articular qué cambió en su venture gracias al ritmo sostenido
- El protocolo está integrado con el Log de Decisiones y el tablero de métricas
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | Sin protocolo; el founder trabaja reactivamente sin cadencia definida |
| En progreso | El founder tiene intención de crear un ritmo pero no lo ha documentado ni practicado |
| Completo | Protocolo documentado y usado al menos 1 semana; estructura básica presente |
| Revisado | Protocolo seguido 3+ semanas con registro; ajustes realizados basados en experiencia |
| Cumple estándar | Cadencia sostenida y conectada con métricas, hipótesis y prioridades del venture |
| Fuerte/Sobresaliente | El ritmo del founder es un activo del venture; visible en el progreso acelerado y en la calidad de decisiones |
Cards relacionadas / siguiente paso
- Priorización de trabajo — el ritmo semanal define cuándo priorizas
- Log de decisiones — el cierre de semana es el momento de actualizar el log
- Estado de Artifacts — la revisión semanal incluye revisar avance de entregables
- Validación de hipótesis — el ritmo sostiene el ciclo Build-Measure-Learn
Priorización de trabajo
Habilidad: Decidir cada semana en qué enfocarse para avanzar el venture, rechazando todo lo que no contribuye a los objetivos del momento
¿Por qué importa esta habilidad?
Los founders tienen demanda infinita de atención y tiempo limitado. Sin un proceso claro de priorización, terminan haciendo lo que parece urgente en vez de lo que mueve la aguja. La capacidad de decir "no" a actividades atractivas pero irrelevantes — conferencias, features nuevos, reuniones sin propósito — es lo que separa a los ventures que avanzan de los que se diluyen.
Qué se ve como un buen resultado
Cada semana el founder puede nombrar sus 3 prioridades máximas con justificación explícita de por qué esas tres y no otras. Hay coherencia entre las prioridades declaradas y en qué se invirtió el tiempo real. El founder puede articular qué sacrificó esta semana y por qué valió la pena.
Errores comunes
- Tener más de 5 "prioridades" — si todo es prioridad, nada lo es
- Priorizar por urgencia emocional en vez de por impacto en el venture
- Decir que algo es prioridad pero no asignarle bloques de tiempo en el calendario
- Nunca revisar si las prioridades de la semana anterior se completaron
- Priorizar actividades de apariencia (crear slide decks, ir a eventos) sobre trabajo de fondo (hablar con clientes, iterar producto)
Preguntas que el startup debe responder
- ¿Cuáles son tus 3 prioridades esta semana y por qué exactamente esas tres?
- ¿Qué hipótesis crítica estás tratando de validar o invalidar esta semana?
- ¿Hay algo que estás haciendo que no debería estar en tu lista esta semana?
- ¿Cuántas horas de trabajo profundo tienes bloqueadas para tus prioridades principales?
- ¿Cómo conectan tus prioridades de esta semana con el objetivo del mes?
Artifact requerido
📄 Registro Semanal de Prioridades
Propósito: Documentar el proceso de priorización semanal, creando un historial que muestre coherencia entre lo que el founder declara importante y lo que realmente hace
Elementos requeridos:
- Objetivo principal del mes actual (contexto para la semana)
- Las 3 prioridades de la semana con justificación de 1–2 oraciones cada una
- Hipótesis o pregunta crítica que se intenta responder esta semana
- Lista de cosas activamente rechazadas esta semana con razón breve
- Resultado de las prioridades de la semana anterior (% completado, aprendizaje)
- Registro de al menos 4 semanas consecutivas completadas
- Reflexión mensual: ¿el patrón de prioridades está llevando al venture hacia adelante?
Formato sugerido: Tabla semanal acumulativa (puede ser en Notion, Google Sheets o documento compartido con mentor)
Señales de calidad: Las prioridades son específicas y medibles, la justificación conecta con el estado actual del venture, y hay evidencia de que las prioridades declaradas se tradujeron en acciones reales
Errores fatales: Prioridades genéricas sin justificación; sin registro histórico; sin evidencia de que el proceso se usa semanalmente
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El founder tiene un proceso documentado de priorización semanal
- Hay registro de al menos 4 semanas con las 3 prioridades y sus resultados
- Las prioridades declaran conexión explícita con hipótesis o métricas del venture
- El founder puede mostrar coherencia entre tiempo invertido y prioridades declaradas
- El registro ha sido revisado por un mentor o facilitador al menos una vez
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | Sin proceso de priorización; el founder trabaja en lo que surge cada día |
| En progreso | El founder piensa en prioridades pero no las documenta ni las revisa sistemáticamente |
| Completo | Registro de 1–2 semanas con prioridades documentadas; proceso básico establecido |
| Revisado | 4+ semanas de registro; patrón visible entre prioridades y avance del venture |
| Cumple estándar | Priorización conectada con hipótesis y métricas; coherencia demostrable entre declarado y ejecutado |
| Fuerte/Sobresaliente | El historial de priorización muestra un founder que aprende y se adapta; visible impacto en velocidad y calidad del venture |
Cards relacionadas / siguiente paso
- Ritmo de founder — el proceso de priorización ocurre dentro del ritual semanal
- Log de decisiones — las decisiones de priorización se registran como decisiones del venture
- Validación de hipótesis — las prioridades deben conectar con hipótesis activas
- Tableau de métricas — las prioridades deben moverse hacia las métricas objetivo
Decision Tracking
Registrar cambios relevantes en el venture.
Log de decisiones
Habilidad: Documentar las decisiones clave del venture con su contexto, razonamiento y resultado esperado para crear memoria institucional
¿Por qué importa esta habilidad?
Los ventures toman cientos de decisiones. Sin documentación, el equipo olvida por qué decidió algo, repite debates resueltos, y no puede aprender de decisiones pasadas. Un log de decisiones convierte la experiencia del founder en capital del venture — disponible para reflexión, para nuevos miembros del equipo, para mentores, y para auditoría propia cuando algo sale mal.
Qué se ve como un buen resultado
El founder mantiene un log actualizado donde cada decisión significativa tiene: qué se decidió, por qué, qué información se tenía en ese momento, qué se esperaba que pasara, y qué ocurrió realmente. El log muestra un patrón de aprendizaje: decisiones revisadas, hipótesis actualizadas, modelos mentales mejorados.
Errores comunes
- Documentar solo las decisiones exitosas y omitir las que resultaron mal
- Registrar qué se decidió sin registrar por qué — pierde el valor de aprendizaje
- Actualizar el log solo cuando hay tiempo libre (nunca) en vez de inmediatamente
- Confundir el log de decisiones con un diario personal — debe ser accesible para mentores y equipo
- No revisar el log periódicamente para extraer patrones de aprendizaje
Preguntas que el startup debe responder
- ¿Cuáles han sido las 5 decisiones más importantes del venture en las últimas 4 semanas?
- ¿Hay decisiones que tomaste por intuición que ahora quisiste haber documentado mejor?
- ¿Cuándo fue la última vez que una decisión pasada te causó confusión o debate con tu equipo?
- ¿Tienes alguna decisión importante pendiente esta semana? ¿Cómo la vas a registrar?
- ¿Qué patrón notas en tus últimas 10 decisiones? ¿En qué tipo de decisiones tiendes a equivocarte?
Artifact requerido
📄 Log de Decisiones del Venture
Propósito: Crear un registro vivo de las decisiones significativas del venture que funcione como memoria institucional, fuente de aprendizaje, y herramienta de rendición de cuentas
Elementos requeridos:
- Fecha y contexto de la decisión (etapa del venture, semana del programa)
- Descripción clara de la decisión tomada (1–3 oraciones)
- Opciones consideradas y descartadas con razón breve
- Información y evidencia que fundamentó la decisión
- Resultado esperado: qué se esperaba que ocurriera
- Resultado real: qué ocurrió (actualizado cuando se dispone de datos)
- Aprendizaje extraído (una oración que empiece con "Aprendí que..." o "Confirmo que...")
Formato sugerido: Tabla cronológica en Notion o Google Sheets, accesible para el equipo y mentores; mínimo 10 entradas durante el programa
Señales de calidad: El log tiene entradas para decisiones de diferente tipo (producto, cliente, equipo, estrategia); los resultados reales están actualizados; hay evidencia de aprendizaje usado en decisiones posteriores
Errores fatales: Log vacío o con solo 1–2 entradas superficiales; sin resultados reales registrados; solo decisiones exitosas
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El log tiene al menos 10 entradas de decisiones reales del venture
- Cada entrada tiene contexto, razonamiento, resultado esperado y (cuando aplica) resultado real
- El log cubre decisiones de al menos 3 dominios diferentes (producto, cliente, equipo, financiero, estratégico)
- El founder puede señalar al menos 2 casos donde el log informó una decisión posterior
- El log está accesible para mentores y ha sido revisado en al menos una sesión de mentoría
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | Sin log; el founder toma decisiones sin documentar ni aprender sistemáticamente de ellas |
| En progreso | El founder entiende el valor del log pero tiene menos de 5 entradas incompletas |
| Completo | 10+ entradas con contexto y razonamiento; estructura consistente; algunas con resultados reales |
| Revisado | Log activo con entradas en múltiples dominios; evidencia de revisión y actualización periódica |
| Cumple estándar | Log completo y usado como herramienta activa de aprendizaje; decisiones posteriores informadas por entradas previas |
| Fuerte/Sobresaliente | El log es un activo del venture citado en estrategia y pitch; el founder puede articular su evolución como tomador de decisiones |
Cards relacionadas / siguiente paso
- Cambios de hipótesis — las decisiones de pivotar o perseverar se registran en ambos logs
- Ritmo de founder — el cierre de semana incluye actualizar el log
- Priorización de trabajo — las decisiones de prioridad también pertenecen al log
- Validación de hipótesis — cada ciclo de validación genera decisiones documentables
Cambios de hipótesis
Habilidad: Registrar formalmente cómo y por qué cambia el venture al aprender, creando un historial de evolución estratégica
¿Por qué importa esta habilidad?
Los ventures exitosos no son los que tenían razón desde el principio — son los que aprendieron más rápido y cambiaron cuando la evidencia lo requería. Documentar los cambios de hipótesis convierte cada pivote o ajuste en un activo de aprendizaje. También demuestra a mentores e inversores que el founder tiene el sistema nervioso apropiado: actualiza creencias ante evidencia, no ante presión social.
Qué se ve como un buen resultado
El founder tiene un registro de cómo han evolucionado sus hipótesis principales durante el programa. Cada cambio está justificado por evidencia específica, no por intuición o presión externa. El historial muestra un founder que aprende: hipótesis que se confirman, se invalidan, se refinan — y un venture que evoluciona en respuesta real al aprendizaje.
Errores comunes
- Cambiar hipótesis sin documentar la razón — el equipo no puede aprender ni alinearse
- Registrar cambios de hipótesis solo cuando son grandes pivotes, ignorando ajustes pequeños pero importantes
- Confundir cambio de hipótesis con cambio de opinión sin evidencia
- No distinguir entre una hipótesis invalidada (señal de aprendizaje) y una hipótesis abandonada (rendición)
- Usar el registro solo retrospectivamente en vez de en tiempo real cuando ocurre el cambio
Preguntas que el startup debe responder
- ¿Cuál es la hipótesis más importante que ha cambiado en tu venture en las últimas 6 semanas?
- ¿Qué evidencia concreta te hizo cambiar esa hipótesis?
- ¿Hay hipótesis que mantienes iguales a pesar de evidencia débil? ¿Por qué?
- ¿Cómo comunicaste el cambio de hipótesis a tu equipo o co-founder?
- ¿Cuándo fue la última vez que cambiaste una hipótesis por evidencia, no por presión o comodidad?
Artifact requerido
📄 Registro de Evolución de Hipótesis
Propósito: Documentar la evolución de las hipótesis críticas del venture durante el programa, mostrando un historial de aprendizaje basado en evidencia y toma de decisiones estratégicas informadas
Elementos requeridos:
- Hipótesis original (tal como fue formulada al inicio o al comenzar a probarla)
- Fecha y contexto en que se identificó el cambio necesario
- Evidencia específica que motivó el cambio (qué se observó, midió, o aprendió)
- Nueva versión de la hipótesis (más precisa, acotada, o diferente)
- Implicación del cambio para el venture (qué cambia en estrategia, producto, cliente)
- Tipo de cambio: refinamiento / pivote parcial / pivote completo / confirmación
- Próximo experimento diseñado para probar la nueva hipótesis
Formato sugerido: Tabla cronológica o árbol de hipótesis visual; mínimo 6 entradas de cambio durante el programa, cubiendo al menos 3 hipótesis diferentes
Señales de calidad: Cada cambio está anclado en evidencia específica y citable; el registro muestra un patrón de aprendizaje coherente, no cambios erráticos; los cambios han impactado la dirección del venture
Errores fatales: Registro vacío o retroactivo inventado; cambios sin evidencia real; el venture no ha cambiado nada durante el programa
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El registro tiene al menos 6 entradas de cambios de hipótesis reales
- Cada cambio está justificado por evidencia específica (entrevista, experimento, dato)
- El registro cubre al menos 3 hipótesis diferentes (cliente, problema, solución, mercado, modelo)
- El founder puede articular cómo los cambios de hipótesis modificaron la dirección del venture
- El registro conecta con el Log de Decisiones y los resultados de experimentos
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | Sin registro; el venture "evoluciona" sin documentación de qué cambió y por qué |
| En progreso | El founder recuerda cambios de hipótesis pero tiene menos de 3 registrados formalmente |
| Completo | 6+ entradas con evidencia y nueva versión de hipótesis; estructura consistente |
| Revisado | Registro activo cubriendo múltiples hipótesis; conexión clara entre evidencia y cambio |
| Cumple estándar | El registro muestra un patrón de aprendizaje: el venture mejora porque el founder actualiza hipótesis sistemáticamente |
| Fuerte/Sobresaliente | El historial de hipótesis es una narrativa coherente del journey del venture; usable directamente en el pitch como evidencia de aprendizaje |
Cards relacionadas / siguiente paso
- Log de decisiones — cambios de hipótesis generan entradas en el log de decisiones
- Validación de hipótesis — los experimentos producen la evidencia que cambia hipótesis
- Narrativa del venture — la historia del pitch se construye con la evolución de hipótesis
- Estructura de evidencia — el banco de evidencia fundamenta los cambios de hipótesis
Evidence Management
Consolidar los outputs del startup como evidencia acumulada.
Estructura de evidencia
Habilidad: Organizar todos los Artifacts del startup en un sistema accesible que muestre el progreso del venture de forma clara y verificable
¿Por qué importa esta habilidad?
Al final del programa, los Artifacts son la evidencia tangible de lo que el venture construyó y aprendió. Sin organización, el trabajo existe pero no puede comunicarse — ni a mentores, ni a jueces, ni a inversores. Un sistema de evidencia bien estructurado convierte los entregables individuales en un portafolio coherente que cuenta la historia del venture y demuestra su madurez.
Qué se ve como un buen resultado
El founder tiene un repositorio centralizado donde todos los Artifacts del venture están organizados por colección, con links directos, fecha de última actualización, y estado de completitud. Cualquier mentor puede encontrar en menos de 2 minutos la evidencia de cualquier área del venture. El repositorio está vivo: se actualiza semanalmente.
Errores comunes
- Tener los Artifacts dispersos en múltiples carpetas, drives y herramientas sin índice central
- Guardar versiones viejas sin claridad sobre cuál es la más reciente
- Crear el repositorio al final del programa en vez de mantenerlo durante todo el proceso
- Organizar los Artifacts por herramienta (docs, slides, etc.) en vez de por área del venture
- Tener un índice que lista los Artifacts pero sin links funcionales o con acceso restringido
Preguntas que el startup debe responder
- ¿Dónde están todos los Artifacts de tu venture ahora mismo?
- ¿Puede un mentor externo encontrar tu Business Model Canvas en menos de 60 segundos?
- ¿Cuántos Artifacts tienes completados versus pendientes según el plan del programa?
- ¿Cómo organizas las versiones anteriores de tus Artifacts para que no contaminen los actuales?
- ¿Qué tan fácil es para tu co-founder o equipo encontrar cualquier entregable sin preguntarte a ti?
Artifact requerido
📄 Repositorio Central de Evidencia del Venture
Propósito: Crear un sistema centralizado y accesible que organice todos los Artifacts del venture, mostrando el progreso completo del trabajo y facilitando revisión por mentores, facilitadores e inversores
Elementos requeridos:
- Página o documento índice con todos los Artifacts organizados por colección del programa
- Para cada Artifact: nombre, link directo, fecha de creación, fecha de última actualización
- Estado de cada Artifact: No iniciado / En progreso / Completo / Revisado
- Sección de Artifacts destacados (los 5 más importantes del venture)
- Historial de versiones para los 3 Artifacts más críticos (BMC, propuesta de valor, modelo financiero)
- Nota de acceso: confirmar que todos los links funcionan y son accesibles para el rol de Viewer
- Última fecha de revisión completa del repositorio
Formato sugerido: Página en Notion o Google Sites con tabla maestra de Artifacts; organizada por las 11 colecciones del programa; revisada y actualizada cada semana
Señales de calidad: Todos los links funcionan; el estado de cada Artifact es preciso; se puede navegar el repositorio completo en menos de 5 minutos; un externo puede entender el estado del venture solo revisando el índice
Errores fatales: Repositorio vacío o con menos del 50% de los Artifacts; links rotos; Artifacts solo mencionados sin acceso real al documento
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El repositorio incluye el 100% de los Artifacts completados hasta la fecha
- Todos los links son funcionales y accesibles para el rol de Viewer
- El estado de cada Artifact es preciso y está actualizado en la última semana
- Un evaluador externo puede navegar y entender el repositorio sin instrucciones adicionales
- El repositorio ha sido compartido con el facilitador del programa para revisión
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | Sin repositorio; los Artifacts existen en diferentes lugares sin organización central |
| En progreso | Existe una carpeta o intento de organización pero incompleto, con links rotos o acceso restringido |
| Completo | Repositorio con 80%+ de Artifacts indexados, links funcionales, estado indicado |
| Revisado | Repositorio completo, actualizado en la última semana, accesible y navegable por externos |
| Cumple estándar | Repositorio completo, organizado por colección, con historial de versiones para Artifacts críticos |
| Fuerte/Sobresaliente | El repositorio es un activo del pitch: profesional, completo, actualizado, y cuenta la historia del venture a través de sus entregables |
Cards relacionadas / siguiente paso
- Estado de Artifacts — el repositorio es el lugar donde se gestiona el estado de cada entregable
- Ritmo de founder — la revisión semanal incluye actualizar el repositorio
- Preparación del pitch final — el repositorio es la base de evidencia para el pitch
- Log de decisiones — los Artifacts son evidencia que fundamenta decisiones
Estado de Artifacts
Habilidad: Dar seguimiento activo al avance de todos los entregables requeridos del programa, identificando brechas y cerrando pendientes a tiempo
¿Por qué importa esta habilidad?
Muchos founders llegan al final del programa con grandes ideas pero sin los entregables que demuestran que construyeron algo real. El seguimiento activo del estado de Artifacts no es burocracia — es la diferencia entre un venture que tiene evidencia de su trabajo y uno que solo tiene conversaciones. Saber exactamente qué está completo, qué está en progreso, y qué está atrasado permite actuar antes de que sea tarde.
Qué se ve como un buen resultado
El founder sabe en cualquier momento el estado exacto de todos los Artifacts del programa. Hay un plan para completar los pendientes con fechas y responsables. Las brechas se identifican con anticipación, no en la semana de la presentación final. El cierre de cada Artifact es un evento registrado, no una tarea olvidada.
Errores comunes
- No llevar registro del estado de Artifacts y "asumir" que están todos completos
- Considerar un Artifact "completo" porque existe un borrador — sin revisión ni aprobación
- Dejar todos los Artifacts para la última semana del programa
- No distinguir entre Artifacts requeridos (obligatorios) y Artifacts opcionales
- Perder el track de cuál versión de un Artifact es la final y aprobada
Preguntas que el startup debe responder
- ¿Cuántos Artifacts del programa están marcados como "Completo" en este momento?
- ¿Cuáles son los 3 Artifacts más atrasados y cuál es tu plan para cerrarlos?
- ¿Hay algún Artifact que técnicamente existe pero en realidad necesita trabajo significativo?
- ¿Qué Artifact te genera más ansiedad cuando piensas en la presentación final?
- ¿Qué tan alineado está tu estado de Artifacts con la evaluación de tu facilitador?
Artifact requerido
📄 Dashboard de Estado de Artifacts
Propósito: Crear un panel de control visual del avance de todos los Artifacts requeridos del programa, que permita identificar brechas, priorizar cierres, y demostrar progreso al equipo y mentores
Elementos requeridos:
- Lista completa de los Artifacts requeridos del programa (todos los 92)
- Estado actual de cada uno: No iniciado / En progreso / Completo / Revisado / Aprobado
- Responsable asignado para cada Artifact pendiente
- Fecha objetivo de completitud para Artifacts en progreso
- Semáforo de prioridad: rojo (atrasado o crítico), amarillo (en riesgo), verde (en tiempo)
- Resumen ejecutivo: % completado por colección y total del programa
- Plan de cierre para los 5 Artifacts más críticos pendientes
Formato sugerido: Dashboard visual en Notion, Google Sheets o Airtable; actualizado al menos semanalmente; compartido con facilitador del programa
Señales de calidad: El dashboard refleja el estado real (no optimista) de cada Artifact; el plan de cierre es específico y realista; el facilitador ha confirmado que el estado es preciso
Errores fatales: Dashboard que solo lista Artifacts sin estados reales; estado "completo" para Artifacts que no existen o están incompletos; no compartido con facilitador
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El dashboard incluye todos los Artifacts requeridos del programa con estado actualizado
- Los estados reflejan la evaluación real (confirmada con facilitador), no la percepción del founder
- Hay un plan de cierre con fechas para todos los Artifacts no completados
- El dashboard muestra al menos el 70% de los Artifacts del programa como Completos o superiores
- El dashboard fue revisado y validado por el facilitador en la última semana del programa
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | Sin dashboard; el founder no sabe con certeza cuántos Artifacts están completos |
| En progreso | Lista parcial de Artifacts con estados aproximados; sin plan de cierre ni responsables |
| Completo | Dashboard completo con todos los Artifacts y estados; plan de cierre para pendientes |
| Revisado | Dashboard validado con facilitador; estados precisos; plan de cierre con fechas reales |
| Cumple estándar | 70%+ de Artifacts completos; dashboard activo como herramienta de gestión semanal |
| Fuerte/Sobresaliente | 90%+ de Artifacts completos y revisados; el dashboard es un instrumento de orgullo del venture, no solo de cumplimiento |
Cards relacionadas / siguiente paso
- Estructura de evidencia — el dashboard se conecta con el repositorio central
- Ritmo de founder — la revisión semanal incluye actualizar el dashboard
- Preparación del pitch final — el estado de Artifacts define la solidez del pitch
- Rúbrica general del programa — el dashboard anticipa la evaluación final del facilitador
Portada — Founder Operations
⚙️ Founder Operations
Mantiene el ritmo de trabajo, la trazabilidad de decisiones y la evidencia acumulada del equipo.