Desarrollo de producto / 03
Un MVP necesita un primer cliente, no una lista de deseos más corta.
La hoja tiene cuarenta funciones. Reducirla a veinte parece un avance, pero todavía no explica por qué alguien usará el producto mañana. Empieza por la tarea del primer cliente y el resultado que le hará volver.
Describe una transacción
En un producto de reservas ficticio: el cliente encuentra un horario, reserva, paga y recibe confirmación; el proveedor ve una reserva fiable. Esa frase explica más que «panel, IA, pagos y notificaciones».
¿Qué pondrá a prueba la idea? ¿Una primera reserva completada, una segunda visita pagada o un proveedor que quiera seguir? Elige una señal próxima al problema. Contar registros puede decir muy poco sobre él.
Hipótesis
¿Quién pagará y qué tarea necesita resolver?
Recorrido
Un camino desde la solicitud hasta el resultado.
Piloto
Usuarios reales; errores y ayuda manual visibles.
Decisión
Continuar, cambiar o detenerse según los datos.
Ejemplo de alcance para un servicio de reservas. En otro producto, cambiar primero la hipótesis y después las funciones.
Diferenciar prototipo, piloto y primer producto
Un prototipo sirve para comprobar si se entiende una idea o una interfaz. Puede utilizar datos simulados y prescindir de cuentas o pagos reales. Un piloto prueba un servicio limitado con participantes reales y soporte acordado. Un MVP debe completar la tarea principal en las condiciones prometidas. Son entregables diferentes. Llamarlos a todos MVP dificulta comparar presupuestos y definir qué debe aceptarse al terminar.
Escribe la decisión que debe aclarar la primera versión. ¿Pagará un proveedor por reducir trabajo de agenda? ¿Volverá un cliente a contratar otra sesión? Define participantes, forma de llegada y señales contrarias a la hipótesis. Muchas altas no son necesariamente una buena medida si las personas nunca necesitaron el servicio. Un grupo pequeño realizando una tarea relevante puede revelar problemas importantes. Mantén visibles los límites de esa muestra cuando decidas continuar; descubrir un fallo de uso no equivale a demostrar demanda en todo el mercado.
Dibujar el recorrido completo antes de enumerar pantallas
Sigue a una persona desde que conoce la oferta hasta que recibe el resultado. Incluye lo que ocurre entre interfaces: un correo tardío, una disponibilidad aprobada por el proveedor o un pago pendiente. Anota qué sabe el usuario y qué necesita saber la empresa para continuar. La lista «acceso, panel y pago» puede ocultar estados intermedios que afectan a la confianza aunque no requieran una pantalla adicional muy elaborada.
En un servicio de reservas, el lado del proveedor importa tanto como la confirmación del cliente. Debe ver sesión, contacto y estado de pago correctos. Limitar el primer lanzamiento a un proveedor y una prestación es una decisión de alcance válida. Omitir la recuperación de una reserva interrumpida afecta a la posibilidad de completar la promesa. Revisa el recorrido con ambas partes antes de aplazar funciones. Esa conversación suele aclarar mejor las prioridades que discutir un número máximo de pantallas sin relacionarlo con el trabajo real.
Planificar el trabajo manual del piloto
Una persona puede gestionar cambios excepcionales, revisar documentos inciertos o preparar el primer informe mientras se prueba la demanda. Hazlo visible: quién lo realiza, cómo recibe la tarea y qué estado ve el cliente. Una intervención explícita puede evitar construir demasiado pronto un sistema administrativo complejo. El trabajo oculto distorsiona costes, capacidad y la impresión de que el producto ya funciona por sí solo.
Mide frecuencia y duración. Si el fundador repara cada reserva habitual, el piloto está mostrando un problema del recorrido central. Si una petición especial es rara y rápida de resolver, automatizarla puede esperar. Mantén una estructura que permita sustituir ese paso después: estado, responsable e historial resultan más útiles que mensajes privados dispersos. Las operaciones forman parte del experimento. El objetivo es descubrir dónde invertir, no presentar una experiencia aparentemente autónoma gracias a horas de intervención que no aparecen en el balance ni en el presupuesto futuro.
Desliza horizontalmente para ver todas las columnas.
| Función | Decisión para el piloto | Criterio de aceptación |
|---|---|---|
| Elegir hora y reservar | Construir el recorrido completo | Dos usuarios no pueden ocupar el mismo hueco |
| Cambios de fecha poco habituales | Gestionarlos manualmente desde administración | La solicitud tiene responsable y estado visible |
| Pago, si hace falta para validar la demanda | Confirmar el pago en el servidor | Una notificación repetida no genera otra compra |
| Fidelización y recomendaciones | Esperar a validar la demanda principal | Hay datos que vinculan la función con compras recurrentes |
Elegir web o móvil a partir del uso
Una aplicación web adaptable puede bastar cuando el usuario sigue un enlace para una tarea ocasional. Una aplicación móvil dedicada tiene más sentido si el uso repetido, funciones del dispositivo o trabajo sin conexión cambian sustancialmente la experiencia. Enumera esas necesidades antes de elegir tecnología. Pedir una app puede significar simplemente querer un servicio cómodo en el teléfono, sin que ello implique mantener publicaciones independientes en distintas tiendas.
Compara también configuración de cuentas, revisión de versiones, dispositivos compatibles, actualizaciones y atención. Si se propone código compartido, pregunta qué sigue siendo específico de cada plataforma y cómo se prueba. Tampoco fuerces una solución de navegador cuando la capacidad esencial del dispositivo no pueda proporcionarse de forma fiable. Haz una prueba técnica limitada del punto incierto. Un comportamiento demostrado en el dispositivo objetivo suele aclarar la arquitectura mejor que una lista extensa de ventajas genéricas de frameworks populares sin conexión con la tarea.
Verificar dependencias antes de comprometer la fecha
Una interfaz pequeña puede depender de calendario, pagos, CRM y datos existentes. Comprueba acceso, operaciones necesarias, ejemplos y entorno de pruebas antes de dar las integraciones por resueltas. Un conector disponible quizá no permita la escritura exacta que necesita el recorrido. La estimación debe declarar esas hipótesis, sobre todo cuando una organización externa controla permisos o documentación y la agencia no puede garantizarlos por su cuenta.
Define qué sistema manda sobre cada estado y cómo se resuelven cambios contradictorios. Si una cita se cancela directamente en el calendario, ¿qué muestra el portal? Si la notificación de pago llega antes que la actualización de reserva, ¿cómo continúa el proceso? No hace falta construir un panel sofisticado para cada fallo imaginable. Sí hace falta un estado seguro y una recuperación visible para el recorrido principal. Acordarlo permite estimar mejor, porque las transiciones difíciles dejan de permanecer escondidas hasta la última semana de aceptación.
Probar acceso con dos cuentas normales
Crea dos usuarios ordinarios en el entorno de pruebas e intenta abrir registros de uno desde el otro. Revisa interfaz y respuesta del servidor. Ocultar un botón no establece permisos sobre los datos. Define roles según responsabilidades reales, por ejemplo cliente, proveedor y administración. El modelo inicial puede ser sencillo, pero las acciones importantes deben comprobarse donde se lee o modifica la información.
Incluye recuperación de cuenta, invitaciones y retirada de acceso. Alguien puede abandonar una empresa o recibir una invitación enviada a la dirección incorrecta. El producto necesita manejarlo sin exponer registros ajenos. Pregunta quién puede consultar datos para soporte y cómo se limita ese acceso. Son requisitos habituales, no extras reservados a una futura versión empresarial. Un producto con pocas funciones puede mantener fronteras claras entre personas y organizaciones. Reducir alcance no debería significar posponer las comprobaciones que sostienen la confianza básica en el servicio.
Confirmar pagos sin depender del navegador
Un cliente puede cerrar la pestaña, perder conexión o actualizar durante el procesamiento. La aplicación necesita un estado conciliable con el proveedor de pagos, además de una pantalla de éxito. Distingue pendiente, correcto y fallido para que el usuario entienda el siguiente paso. No ofrezcas otro pago a ciegas mientras el anterior sigue sin aclararse. El mensaje debe reflejar si hay que actuar o esperar una comprobación.
Utiliza las notificaciones documentadas del servidor y verifica su autenticidad. El procesamiento debe tolerar mensajes repetidos y un orden distinto al esperado. Comprueba los registros de compra y reserva, no solo la respuesta técnica del endpoint. Incluye un procedimiento para reembolsos o pagos que necesitan investigación, aunque una persona lo gestione durante el piloto. Una recuperación manual comprensible es preferible a un checkout vistoso que deja al equipo sin explicar lo que ocurrió con el cobro y con el servicio que debía recibir el cliente.
Evaluar IA cuando forme parte de la promesa
Si interpretar documentos o responder desde una base de conocimiento es la función central, la calidad de la IA debe entrar en la aceptación inicial. Reúne entradas representativas y define resultados válidos, rechazos y casos para revisión humana. Separa falta de información en la fuente, interpretación incorrecta y acción posterior errónea. Un ejemplo atractivo no demuestra que el servicio resuelva la tarea en las condiciones anunciadas.
Considera también el trabajo que genera la incertidumbre. ¿Quién revisa una respuesta dudosa? ¿Qué puede corregir el cliente? ¿Qué ocurre si el modelo no está disponible? Una solicitud en cola, una respuesta limitada o ayuda humana pueden ser soluciones adecuadas. Elige el comportamiento de manera deliberada. Si el asistente solo es un atajo opcional alrededor de una reserva ya completa, puede llegar después. La hipótesis del producto debe decidirlo, sin convertir la presencia de IA en una obligación independiente del problema y de la utilidad para la primera persona usuaria.
Comparar propuestas con la misma historia de aceptación
Entrega a cada posible proveedor el mismo recorrido, ejemplos de datos y resultados observables. Pide separar descubrimiento, diseño, implementación, integraciones, pruebas y entrega. Dependencias y exclusiones deben quedar claras. Dos importes no son comparables si uno incluye operación y recuperación, y el otro solo una demostración. Resolver esa diferencia suele ser más útil que negociar un porcentaje de descuento sobre un alcance que todavía admite interpretaciones incompatibles.
Acuerda quién responde preguntas de negocio, quién acepta entregables y cómo se documenta un cambio. Pide avances que demuestren partes del recorrido real, no únicamente pantallas terminadas. Una incertidumbre técnica puede justificar una investigación acotada antes de un precio cerrado. Relaciona la reserva presupuestaria con riesgos identificados y condiciones de uso. Así se puede hablar de dinero y plazos con claridad sin fingir que el desarrollo no tiene incógnitas ni dejar toda modificación posterior abierta a un coste imposible de valorar.
Medir la decisión posterior al lanzamiento
Registra pasos que indiquen tarea completada: solicitud válida, cita confirmada, pago correcto o repetición de uso según la hipótesis. Distingue intentos y resultados, evitando contar dos veces un evento. Examina abandonos junto con la experiencia que los rodea antes de concluir que falta una función. Una oferta confusa, un precio mal explicado o una confirmación que no llega puede explicar el comportamiento mejor que una nueva lista de mejoras.
Mantén la revisión ligada a los participantes y al planteamiento inicial. Una muestra pequeña puede descubrir fricción sin demostrar demanda general. Anota lo que sigue sin saberse y qué observación cambiaría la decisión. Añade una función grande cuando haya una razón vinculada al comportamiento o al coste operativo. Si la tarea principal no se valora, un programa de recomendaciones o más gráficos no aclarará necesariamente el motivo. El primer producto debería permitir decidir con mejores fundamentos qué merece la siguiente inversión y qué conviene replantear antes de seguir construyendo.
Recorta amplitud, conserva fiabilidad
Un tipo de cliente, un servicio, un recorrido. Una persona puede resolver las peticiones especiales manualmente si el procedimiento está claro. Los referidos, cinco tarifas y los informes automáticos pueden esperar.
Mantén validaciones, permisos, estado del pago y recuperación. Intenta abrir una reserva ajena desde otra cuenta. Actualiza durante el pago. Envía dos veces. Una demo que solo funciona con clics perfectos no permite aprender bien de clientes reales.
La aplicación móvil necesita una razón
Una aplicación web adaptable puede bastar cuando la tarea principal empieza con un enlace. iOS y Android tienen sentido si las capacidades del dispositivo o el uso frecuente cambian la experiencia. Escribe esas necesidades antes de decidir.
Lo mismo ocurre con la IA. Si el primer cliente solo necesita reservar, el asistente puede llegar después. Si interpretar documentos es el núcleo del producto, evaluar sus respuestas forma parte del primer lanzamiento.
Incluye la entrega en el alcance
Acuerda quién controla el dominio, repositorio, alojamiento y cuenta de pagos. Incluye exportación, copias de seguridad y un canal para incidencias. El lunes después del lanzamiento alguien debe saber operar el producto.
Describe la primera versión mediante una prueba breve con resultados observables. Guarda las ideas posteriores aparte. Los clientes mostrarán qué merece ampliarse.
Antes de empezar
- Identificar al primer cliente y la tarea completa que debe terminar.
- Probar permisos, pagos interrumpidos y envíos duplicados.
- Acordar acceso al código, las cuentas y la documentación.
Nota editorial. Los ejemplos explican una decisión o una prueba; no son resultados de clientes.