Equipos de producto que necesitan ordenar lo que ya construyeron

La consultoría está pensada para startups y áreas internas de producto en Argentina y Latinoamérica que ya tienen algo funcionando y sienten que la interfaz creció más rápido que las decisiones. Flujos de onboarding, formularios y componentes que se fueron sumando sin un criterio común. El trabajo se adapta a equipos chicos o a áreas internas que necesitan documentar patrones y decidir qué corregir primero, revisando flujos reales y no escenarios de laboratorio.

Para quién tiene sentido este trabajo

La consultoría está pensada para equipos que ya tienen producto en marcha y sienten que la interfaz creció más rápido que sus reglas. Startups en etapa temprana y áreas internas de producto en Argentina y Latinoamérica suelen llegar con el mismo síntoma: onboarding que nadie terminó de definir, formularios largos y componentes que cada persona resuelve a su manera. Si eso te suena familiar, esta página y las siguientes lecturas te van a servir como punto de partida.

Startups con producto vivo

Equipos chicos donde diseño, producto e ingeniería comparten las mismas decisiones. Revisamos flujos reales de registro, alta y configuración para detectar dónde se pierde la gente y qué se puede corregir sin rehacer todo.

Ver reseñas de equipos

Áreas internas de producto

Departamentos que heredaron una interfaz con años de capas y necesitan documentar patrones antes de seguir sumando pantallas. El trabajo se adapta al ritmo del equipo y a lo que ya está en producción.

Leer la auditoría de onboarding

Equipos que ordenan su sistema

Cuando los componentes se repiten con variaciones mínimas y nadie sabe cuál es el correcto, conviene una guía viva antes que otra ronda de parches. Se prioriza por impacto en la tarea del usuario, no por estética.

Cómo ordenar la arquitectura

Antes de arrancar conviene dejar por escrito qué entra en una auditoría, qué no, y con qué tipo de equipo funciona mejor. Estas son las aclaraciones que suelo repetir en la primera conversación.

Qué sí y qué no

Con quién se trabaja

Startups en etapa temprana y áreas internas de producto en Argentina y Latinoamérica. En general son equipos que ya tienen algo en producción: un onboarding, formularios, un panel, componentes que se fueron sumando sin un criterio común. No hace falta que tengan un equipo de diseño armado. Sí hace falta que alguien del lado del producto pueda tomar decisiones y sostenerlas durante los sprints de corrección.

Qué se revisa

Flujos reales, no escenarios hipotéticos. Se trabaja sobre lo que hoy está publicado o en staging: el recorrido de registro, la navegación principal, los formularios que la gente abandona, los patrones de componentes que se repiten con variaciones. Si no hay acceso a un flujo concreto, no hay auditoría posible, solo opiniones.

Qué queda fuera

No se trabaja con inversiones, ganancias, finanzas, apuestas, casino, trading, tokens ni contenido para adultos. Tampoco con productos que todavía no existen: si no hay interfaz construida, no hay nada que auditar. Y no se entregan decks inflados ni presentaciones de tendencias sin relación con el producto del equipo.

Cómo se comunica

De forma sobria y directa. Los hallazgos se priorizan por impacto real en la tarea del usuario, no por lo vistoso del cambio. Si algo funciona, se dice que funciona y se deja quieto. El estudio es independiente y dirigido por Kyungmin Lee, así que las recomendaciones no dependen de un proveedor ni de una herramienta puntual.

Qué se necesita del equipo

Acceso a las pantallas o a un entorno de prueba, una persona de referencia que conozca el producto y cierta disponibilidad para revisar hallazgos intermedios. No se pide documentación perfecta ni un sistema de diseño previo: justamente, muchas veces el problema es que ese sistema no existe o quedó desactualizado.

Alcance y expectativas

Una auditoría no reemplaza al equipo de producto ni resuelve todo de una vez. Entrega un mapa de problemas, un orden de corrección por sprints y criterios para que el equipo pueda seguir solo. Si después de leer los hallazgos el equipo decide no avanzar, el trabajo igual sirve como diagnóstico. No hay promesas de métricas ni resultados garantizados.