Gran parte de la escritura sobre producto sigue partiendo de que las mejores lecciones provienen de la escala, la financiación y los equipos con abundantes recursos.

No creo que eso sea cierto.

Algunas de las lecciones de producto más útiles que he aprendido surgieron de construir con muy poco margen de error: presupuestos ajustados, plazos cambiantes, procesos manuales por todas partes y consecuencias que aparecían rápido cuando la secuencia era incorrecta.

Ese fue el entorno en el que trabajé en una plataforma de gestión universitaria en Nigeria.

No se trataba de un producto en el que una prioridad mal resuelta significara un trimestre ligeramente más débil o una función retrasada. Si las admisiones no se gestionaban a tiempo, los estudiantes podían perder su lugar. Si la recaudación de pagos no estaba diseñada con precisión, los ingresos se filtraban por las grietas. Si los reportes se añadían después, la dirección quedaba tomando decisiones con visibilidad parcial.

Y cuando COVID interrumpió las operaciones presenciales, la verdadera prueba no era si la plataforma era elegante. Era si podía expandirse lo bastante rápido para mantener a la institución en funcionamiento.

Esa experiencia dio lugar al modelo CAPE: priorización centrada en la crisis, arquitectura como incentivo, infraestructura de datos paralela y extensibilidad por diseño.

No es un método universal ni una fórmula perfecta. CAPE es un enfoque práctico para equipos que trabajan bajo presión, donde tomar decisiones en el orden correcto importa más que tener un plan perfecto.

C – Priorización centrada en la crisis

La mayoría de los equipos afirma priorizar en función del valor y el esfuerzo, lo que funciona hasta cierto punto. Pero esa lógica empieza a fallar cuando una sola falla sin resolver puede volver irrelevante todo lo demás.

Esa era la realidad con admisiones.

En aquel entonces, la incorporación de nuevos estudiantes era en su mayoría manual. Los estudiantes debían pasar por admisiones y registro usando formularios en papel, verificaciones dispersas y ayuda del personal en casi cada etapa. Algunos viajaban largas distancias y muchos enfrentaban plazos muy ajustados. Si el sistema no podía soportar la presión, los estudiantes quedaban fuera. Así que la incorporación fue lo primero.

No porque fuera la parte más innovadora de la plataforma. No porque se viera mejor en una hoja de ruta. Sino porque era el punto de máxima falla. Si ese proceso se rompía, el resto de la plataforma no importaba.

Este es el primer principio de CAPE: no empezar por la mayor oportunidad. Empezar por la falla que causaría más daño si no se corrigiera de inmediato.

Suena simple. Rara vez se siente simple cuando uno está dentro de la situación. Los equipos suelen verse tentados a repartir el esfuerzo entre varias necesidades visibles, sobre todo cuando los actores involucrados empujan en direcciones distintas. Pero bajo restricciones, dispersar la atención puede convertirse en una forma disfrazada de evasión. Parece equilibrado. Por lo general, debilita la entrega.

La restricción obligó a formular una pregunta más incómoda: si solo resolvemos una cosa bien primero, ¿cuál debe ser?

Esa pregunta sigue siendo importante incluso en entornos mejor financiados. Los equipos que la responden con honestidad suelen construir primeras versiones más sólidas. Los que no lo hacen, por lo general terminan con hojas de ruta más amplias y bases más frágiles.

Si la primera versión no estabiliza la falla de mayor costo, probablemente sea la primera versión equivocada.

A – Arquitectura como incentivo

Uno de los problemas más persistentes de la universidad era el incumplimiento de pagos, que constituía un defecto importante de diseño.

En lugar de tratar el pago como una tarea administrativa al lado del recorrido académico, lo volvimos estructural. El pago desbloqueaba el registro. El registro desbloqueaba la elegibilidad para exámenes. Sin pago, no hay avance.

Simple. Pero estructuralmente crítico.

Esa decisión cambió la lógica de la plataforma. El foco pasó de pedir a las personas que cumplieran a la lógica de flujo del sistema. Esa distinción importa más de lo que muchos equipos creen.

Muchas decisiones de producto sobre el comportamiento todavía se abordan como problemas de comunicación. Pero cuando el comportamiento es crítico para el negocio, la arquitectura suele hacer más que cualquier persuasión.

Eso es lo que quiero decir con arquitectura como incentivo. Diseñar el sistema para que el comportamiento correcto quede incorporado en la secuencia.

El cumplimiento de pagos mejoró significativamente una vez que esa dependencia quedó integrada en la plataforma. Pero la lección más importante fue que, si un producto depende de cierto comportamiento, la arquitectura debe asumir parte de esa carga.

Cuando el comportamiento importa, eliminen la opcionalidad antes de añadir recordatorios.

P – Infraestructura de datos paralela

Aquí es donde muchos productos fallan frente a la dirección. El flujo funciona, los usuarios completan sus tareas y las transacciones se procesan. Pero la institución sigue sin ver qué está ocurriendo realmente.

Ese era el caso aquí. Las partes interesadas no tenían una visión unificada de todo el proceso.

Bajo presión de entrega, es fácil lanzar primero el flujo de trabajo y dejar los reportes para después. Parece eficiente. No lo es. Los puntos ciegos que genera cuestan más que el tiempo que supuestamente ahorró.

Así que construimos los reportes junto con los flujos de trabajo.

Eso cambió la toma de decisiones. La dirección pudo ver con más claridad la posición de ingresos. Pudo ver las inscripciones por programa y nivel. Pudo ver dónde estaban cambiando los patrones de pago y de matrícula antes de que esos cambios se consolidaran en problemas operativos.

Este es el tercer principio de CAPE: si un flujo de trabajo es importante desde lo operativo, también debe serlo desde lo analítico al mismo tiempo.

Un producto que no puede observarse correctamente mientras está en ejecución crea un riesgo de segundo orden. Las decisiones empiezan a tomarse con base en supuestos rezagados en lugar de evidencia actual. Luego los equipos pasan meses compensando una visibilidad que debieron diseñar desde el principio.

Un flujo de trabajo sin instrumentación está operativo, pero estratégicamente ciego.

Construyan el flujo de trabajo y el modelo de visibilidad al mismo tiempo. No le pidan a la dirección que conduzca a ciegas y prometan el tablero para después.

E – Extensibilidad por diseño

A medida que pasó el tiempo, seguimos construyendo la plataforma con una funcionalidad sólida, hasta dejarla preparada para gestionar tareas clave de la universidad como admisiones, pagos de matrícula, registro, exámenes y certificados.

Entonces llegó COVID.

Casi de un día para otro, todo cambió. Las preocupaciones sobre registro, exámenes, pagos y procesos relacionados pasaron a un segundo plano, porque si los estudiantes no estaban aprendiendo, entonces no necesitaban esas funcionalidades. Nuestro foco pasó a ser si la plataforma podía adaptarse lo suficientemente rápido para mantener todo en marcha cuando las clases y las operaciones presenciales se detuvieron.

La plataforma soportaba admisiones, pagos de matrícula, exámenes y certificados, pero no tenía capacidad de aprendizaje. Esa brecha se convirtió en nuestro punto central. La pregunta era inmediata: ¿construir la capacidad de aprendizaje desde cero o integrar un LMS lo bastante rápido como para mantener a la universidad en funcionamiento?

Los estudiantes estaban en casa. La enseñanza se había detenido. Los ingresos habían caído. La institución no necesitaba la respuesta perfecta. Necesitaba la más rápida viable.

Elegimos la integración por una decisión arquitectónica previa: habíamos construido con suficiente modularidad para absorber nueva capacidad sin rehacerlo todo. No flexibilidad infinita. Solo la apertura suficiente para hacer posible el siguiente movimiento.

Eso es lo que significa extensibilidad en la práctica.

No significa construir para cada futuro posible; eso conduce a un sobre-diseño. La extensibilidad por diseño consiste en dejar suficiente espacio para el próximo cambio real, sin tener que rehacer el núcleo cada vez que cambian las cosas.

Esto importa porque los equipos de producto suelen tratar la extensibilidad como algo opcional hasta el día en que se vuelve urgente. Para entonces, resulta costosa.

La integración del LMS se entregó en cuatro meses. La continuidad académica se reanudó. Los ingresos se recuperaron de manera material dentro del mismo ciclo. Pero la lección más importante fue arquitectónica: los sistemas que sobreviven a choques externos no son siempre los que los predijeron. Son los que no fueron construidos con tanta rigidez que impidiera responder.

Construyan para el próximo desafío real, no para cada escenario posible.

CAPE no es valioso porque suene ordenado. Es valioso porque la secuencia se sostiene.

Todo producto de crecimiento rápido se enfrenta a su propia versión de admisiones: un punto de falla que hunde la hoja de ruta si no se resuelve primero, y todo lo demás es negociable en comparación. Todo producto con un comportamiento crítico para los ingresos se enfrenta a su propia versión de la puerta de pago: algo de lo que el negocio depende y que o bien se incorpora a la arquitectura o bien se persigue para siempre con recordatorios.

Todo equipo se enfrenta a su propia versión del problema de los reportes: la dirección volando a ciegas porque la visibilidad se pospuso en favor de sacar el flujo de trabajo. Y todo producto termina encontrándose con su propio COVID: el choque que nadie planeó y que pone a prueba si lo construido puede doblarse o si se rompe.

Por eso CAPE es transferible. La restricción no se trata realmente del presupuesto. Se trata de la proporción entre lo que debe ser cierto y lo que uno puede permitirse hacer mal. Esa proporción aparece con una ronda de financiación ajustada, una fecha límite regulatoria estricta, un equipo interno reducido de herramientas o una startup funcionando con seis meses de margen. Distinta presión. Misma disciplina requerida.

Si soy honesto, el principio más difícil de aplicar en la práctica es Arquitectura como incentivo. La priorización centrada en la crisis es una decisión que se toma una vez, al inicio. La extensibilidad es un hábito que puede incorporarse a los estándares con el tiempo. Arquitectura como incentivo exige algo más difícil: suficiente convicción para volver un comportamiento no negociable dentro del propio producto, en lugar de resolverlo aguas abajo con un aviso o una campaña.

Es una conversación difícil de tener con partes interesadas a las que les resulta más fácil pedirle amablemente a los usuarios que hacerlo obligatorio. También es el principio con más probabilidades de diluirse en una revisión de diseño, porque “agreguemos solo un recordatorio” siempre suena como la opción más cómoda. Rara vez es la correcta.

Si ya están construyendo con austeridad, en Lagos, en África Occidental, en un mercado donde “no teníamos presupuesto para hacerlo de otra manera” no es una frase de presentación sino un martes cualquiera, no les estoy diciendo que la restricción sea buena para ustedes. Ya lo saben.

Lo que estoy argumentando es más acotado, y creo que más útil. La restricción por sí sola no produce disciplina. Produce presión. Lo que uno hace con esa presión es otra cuestión, y es totalmente posible construir bajo restricciones reales y aun así equivocarse en la secuencia, porque la mayor parte del consejo disponible para equipos austeros no fue escrito para equipos austeros. Fue escrito por personas con colchón, para personas con colchón.

“Lanza rápido, añade cumplimiento después” no es un mal consejo. Es un consejo para alguien que puede pagar lo que costará después. Aplíquenlo con la misma decisión cuando no haya una nueva ronda esperando detrás, y “después” suele significar nunca, o significa una emergencia que cuesta diez veces lo que habría costado la decisión la primera vez.

Toda decisión diferida en este texto —tratar el pago como opcional, construir los reportes después, omitir la modularidad necesaria para la extensibilidad— es exactamente ese tipo de consejo prestado. Suena eficiente hasta que ya no existe presupuesto posterior para absorber el costo de posponerla.

CAPE es mi intento de nombrar, de manera deliberada, lo que la mayoría de nosotros aprende por accidente bajo presión de plazos. No es una afirmación de que la restricción forme carácter. Es una forma de comprobar, antes de lanzar, si hemos tomado prestada en silencio una decisión de secuencia que solo tiene sentido para la contabilidad de otra persona.

Esa disciplina vale la pena conservar incluso cuando la restricción se afloja. La mayoría no intenta escapar de la restricción para por fin dejar de pensar así. Si llega la financiación, el objetivo no es perder los instintos que nos trajeron hasta aquí.

Leer también: FUTA honra a un exalumno convertido en emprendedor de ciberseguridad mientras la universidad acoge una conferencia internacional histórica sobre informática