Cómo convertir una tarea repetida de servicios en un producto mínimo, y el primer paso más pequeño para probarlo

Qué vas a aprender hoy

En la lección 2 viste que el modelo de servicios tiene un techo marcado por las horas facturables, y que convertir una tarea repetida en un producto es una forma de superar ese techo. Hoy vas a ver un marco concreto, con investigación detrás, para decidir qué tarea de las que repites tiene sentido convertir en producto, y qué significa realmente “el paso más pequeño” para probarlo sin construir nada completo todavía.

Conceptos base

Productización: el proceso de convertir una actividad de servicio (algo que haces manualmente, caso por caso, para cada cliente) en una oferta empaquetada, repetible y en parte automatizada.

Frecuencia de la tarea: cuántas veces repites una actividad concreta y cuánto se parece cada repetición a la anterior.

Complejidad cognitiva: cuánto juicio experto, criterio o decisión especializada exige esa tarea, frente a cuánto es mecánico o sigue un patrón predecible.

MVP (Minimum Viable Product, producto mínimo viable): según Eric Ries, “la versión de un producto nuevo que permite a un equipo recopilar la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo posible”. No es “la versión más pequeña posible del producto final”: es la versión más pequeña que responde a una pregunta concreta sobre si alguien lo quiere.

Desarrollo

No todas las tareas repetidas son buenas candidatas a producto

Es tentador pensar que cualquier tarea que repites es candidata a convertirse en producto. No es así, y hay un criterio con base empírica para distinguir cuáles sí. Mohanbir Sawhney, profesor de la Kellogg School of Management (Northwestern University), desarrolló un marco de cinco pasos para la productización de servicios profesionales, publicado en Harvard Business Review en 2016 (“Putting Products into Services”) y ampliado en MIT Sloan Management Review en 2024 (“How to Turn Professional Services Into Products”). El primer paso de ese marco consiste en evaluar cada actividad de servicio según dos dimensiones: frecuencia y complejidad cognitiva.

Sobre la frecuencia, la pregunta que plantea Sawhney es directa: “¿con qué frecuencia se realiza cada actividad? ¿Cuánto se repite esa actividad?”. Cuanto más frecuente y repetible, más datos y más oportunidades de pulir una versión estandarizada. Sobre la complejidad cognitiva, la pregunta es “¿cuánta habilidad cognitiva exige realizar esa actividad?”: las actividades menos complejas son más fáciles de convertir en algo automatizado o empaquetado, mientras que las decisiones que exigen criterio experto y especializado son mucho más difíciles de productizar sin perder calidad. (Sawhney, M. (2024), “How to Turn Professional Services Into Products”, MIT Sloan Management Review)

El ejemplo que pone el propio estudio es el de la tramitación de siniestros de seguros de auto: son actividades que “ocurren con una frecuencia muy alta, y muchas de las decisiones implicadas son directas”, lo que las convierte en una candidata ideal para la automatización, como demuestra el sistema de inteligencia artificial “AI Jim” de la aseguradora Lemonade. (Sawhney, 2024) El patrón general es: alta frecuencia y baja complejidad cognitiva es la combinación que mejor se presta a convertirse en producto. Alta frecuencia con alta complejidad cognitiva (una decisión que se repite mucho pero exige criterio experto cada vez) es mucho más difícil de productizar sin perder lo que hace valioso el servicio original, y baja frecuencia con cualquier nivel de complejidad rara vez justifica el esfuerzo de construir algo repetible, precisamente porque no hay suficientes repeticiones para amortizar esa inversión.

El propio marco de Sawhney, con sus cinco pasos completos (evaluar el potencial de producto, decidir el nivel óptimo de productización, definir el catálogo de oferta para distintos segmentos de cliente, construir las capacidades necesarias, y liderar la transformación de la organización), está pensado originalmente para empresas de servicios profesionales de cierto tamaño. Para una sola persona o un equipo pequeño, el primer paso —evaluar frecuencia y complejidad de cada tarea— sigue siendo aplicable tal cual; los pasos siguientes se simplifican mucho, porque no hace falta rediseñar una organización entera para probar si una tarea concreta tiene sentido como oferta empaquetada.

Aplicado a un desarrollador: qué buscar en tu propio trabajo repetido

Trasladado a una habilidad digital, esto da un criterio concreto para revisar las tareas que repites para distintos clientes o proyectos. No preguntes solo “¿lo hago a menudo?”: pregunta también “¿cuánto criterio experto exige cada vez, o sigue básicamente el mismo patrón?”. Configurar un entorno de desarrollo desde cero para cada cliente nuevo, generar un informe con el mismo formato cada mes, o revisar un mismo tipo de error de seguridad en distintos proyectos son ejemplos de alta frecuencia y baja-a-media complejidad: buenos candidatos. Diseñar la arquitectura completa de un sistema nuevo desde cero, en cambio, es una tarea de alta complejidad cognitiva que varía mucho de un proyecto a otro: mala candidata a productizar, al menos como primer paso.

Qué es (y qué no es) un MVP

Una vez identificada la tarea candidata, la pregunta siguiente es cómo probar si tiene sentido convertirla en producto sin invertir meses en construirlo. Aquí es donde entra el concepto de MVP, acuñado por Eric Ries en el movimiento Lean Startup. Ries insiste en una idea que se malinterpreta a menudo: pese al nombre, un MVP no consiste en construir la versión más pequeña posible del producto final. Es “la versión de un producto nuevo que permite a un equipo recopilar la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo posible”. (Ries, E., “What is an MVP?”, Lean Startup Co.)

La diferencia es importante: un MVP no se diseña para minimizar funcionalidades, se diseña para maximizar lo que aprendes sobre si alguien de verdad quiere pagar por esto, con el menor esfuerzo de construcción posible. Eso significa que, para muchas tareas repetidas de servicios, el primer MVP no necesita ser software: puede ser la misma tarea, hecha de la misma forma manual de siempre, pero empaquetada como una oferta concreta con un precio y un alcance definidos, ofrecida a un cliente nuevo o existente antes de automatizar nada. Si nadie paga por esa versión empaquetada manualmente, construir la versión automatizada habría sido esfuerzo desperdiciado; si sí pagan, ya tienes validación real antes de invertir en construir nada.

Ries también aclara qué pasa después de ese primer experimento: si los primeros clientes quedan satisfechos con la versión manual, es una señal de que seguir invirtiendo en construir la versión automatizada tiene sentido; si no quedan satisfechos, hace falta otra iteración del MVP antes de construir nada más grande, en vez de asumir que el problema es solo de ejecución y lanzarse directamente a automatizar una oferta que en realidad todavía no está validada.

Juntando los dos marcos

El proceso completo, combinando ambas piezas, queda así: primero, usa el criterio de Sawhney (frecuencia alta, complejidad cognitiva baja o media) para elegir qué tarea repetida merece la pena revisar. Segundo, en vez de saltar directamente a automatizarla o construir una herramienta, define el MVP de Ries para esa tarea: la versión más pequeña que te permita comprobar si alguien pagaría por ella como oferta concreta, aunque la ejecutes manualmente la primera vez. Solo después de esa validación tiene sentido invertir tiempo en automatizar, empaquetar o construir el producto completo que viste en la lección 2 como modelo de coste marginal cercano a cero.

Aplicación práctica

Con una hoja en blanco, haz este ejercicio de 15 minutos:

1. Lista tres o cuatro tareas que repites para distintos clientes o proyectos en tu trabajo actual.
2. Para cada una, puntúa la frecuencia (¿cuántas veces la has hecho en el último año, aproximadamente?) y la complejidad cognitiva (¿sigue básicamente el mismo patrón cada vez, o exige un criterio experto distinto en cada ocasión?).
3. Identifica la tarea con mayor frecuencia y menor complejidad cognitiva relativa. Esa es tu mejor candidata a productizar, según el criterio de Sawhney.
4. Define el MVP más pequeño para esa tarea, siguiendo la definición de Ries: no la versión mínima del producto final, sino la versión más pequeña que te permita comprobar si alguien pagaría por ella como oferta empaquetada, aunque la sigas ejecutando manualmente por ahora.
5. Decide a quién se lo ofrecerías primero (un cliente actual, alguien de tu red) y qué necesitarías ver en su respuesta para considerar que la validación fue positiva.

No hace falta ejecutar el quinto paso hoy mismo. El objetivo de este ejercicio es dejar la decisión lista por escrito, con el candidato elegido y el criterio de validación definido de antemano, para no improvisar esa parte cuando llegue el momento de ofrecerlo de verdad.

Errores comunes

Productizar la tarea más compleja en vez de la más repetida. La intuición suele ser automatizar lo que da más trabajo, pero el criterio de Sawhney señala justo lo contrario: alta frecuencia y baja complejidad cognitiva es la combinación que mejor se presta a convertirse en producto.

Confundir MVP con “versión incompleta del producto final”. Un MVP no es una versión recortada de lo que planeas construir: es el experimento más pequeño posible para aprender si el producto completo merece la pena construirse.

Construir la automatización antes de validar la demanda. Si nadie ha pagado todavía por la versión manual y empaquetada, automatizar antes de esa validación es esfuerzo que puede terminar sin usarse.

Intentar productizar una tarea que exige criterio experto variable en cada caso. Ese tipo de tareas pierde precisamente lo que las hace valiosas cuando se estandariza demasiado pronto.

Elegir una tarea de baja frecuencia porque “sería interesante” convertirla en producto. Sin suficientes repeticiones no hay forma de amortizar el esfuerzo de empaquetarla, por muy atractiva que parezca la idea en abstracto.

Interpretar un MVP fallido como un fallo de ejecución en vez de una señal sobre la demanda. Si los primeros clientes no quedan satisfechos, la respuesta correcta según Ries es iterar el MVP, no saltar directamente a construir una versión más grande con la esperanza de que eso resuelva el problema.

Fuentes

• Sawhney, Mohanbir (2016), “Putting Products into Services”, Harvard Business Review. hbr.org
• Sawhney, Mohanbir (2024), “How to Turn Professional Services Into Products”, MIT Sloan Management Review. sloanreview.mit.edu
• Ries, Eric, “What is an MVP?”, Lean Startup Co. leanstartup.co

Para la próxima lección

La próxima lección de esta pista tratará sobre cómo poner precio a un producto o servicio digital nuevo cuando no existe un precio de mercado claro con el que compararlo, y qué señales usar para no infravalorar tu trabajo por falta de referencia.

---

Este contenido es material educativo. No constituye asesoramiento financiero ni profesional, ni recomienda ninguna plataforma o herramienta concreta.