mauromendezg@gmail.com

Tipo A · Fintech · Claude Code · Claude Design · MCP

Portafolio de
inversiones para
jóvenes.

De brief de negocio a build navegable end-to-end en 1 mes. Workflow PM Builder.

Case studyCase study · Publicado abril 2026
TL;DR

Resumen

Tomé un brief de negocio típico: "construir recomendador de inversiones para jóvenes con bajo conocimiento financiero." Lo llevé desde discovery hasta prototipo navegable + plan de implementación en un mes.

Sin atajos

Sin saltarme etapas. Sin vibe coding. Sin teoría vacía. Lo que en banca tradicional toma 2-3 meses se puede acelerar a 1 mes si el PM construye con stack AI-native — y mantiene criterio de producto senior.

El problema

El brief de negocio

El negocio quiere ofrecer recomendaciones personalizadas de inversión a clientes que no tienen información ni experiencia financiera. Mucha regulación, perfiles de riesgo que deben ser muy bien analizados, equipos de cumplimiento involucrados.

Cómo lo simplifiqué

Para este caso lo simplifiqué: imaginé un "Tinder de decisiones financieras" donde el cliente arma su portafolio a partir de preferencias rápidas. Sin pretender que esté validado por reguladores — el foco es la metodología, no el producto. Esto es banca regulada hipotética. La metodología es la real.

Las 5 etapas que cubrí (y por qué importan)

1. Mapeo de stakeholders

Incluyendo cumplimiento y legal desde el día uno. La diferencia entre un proyecto que avanza y uno que se atasca: cuándo entran los equipos regulatorios.

2. Discovery

Con UX, lead técnico, cumplimiento, legal y negocio. Aquí se traduce la necesidad de negocio en experiencia y se define el problema detrás del requerimiento.

3. Documentación

Story map + historias de usuario con criterios de aceptación + reglas de negocio. Validación formal con cumplimiento y legal antes de construir nada.

4. Prototipado rápido con Claude Code

No para reemplazar el proceso — para acelerar la presentación a stakeholders y fallar rápido.

5. Plan de implementación para desarrollo

Capas de base de datos, seguridad, orden de construcción. Las primeras tres etapas se hacen igual que siempre. Las dos últimas son las que cambian con stack AI-native.

Story Map del viaje del cliente

El journey end-to-end

Construí el journey desde "el cliente abre la app" hasta "ejecuta su primera inversión." Cada paso con criterios de aceptación, manejo de estados y casos límite.

El call-to-action central

El momento donde el cliente sin inversiones previas hace su primera. Para el negocio, ese hito vale más que cualquier métrica de engagement.

Historias de usuario

6 historias principales

Desde "entender el mecanismo antes de empezar" hasta "ver mi portafolio recomendado."

Cada una con

  • Criterios de aceptación específicos
  • Reglas de negocio asociadas
  • Validaciones regulatorias requeridas
  • Estados de error y manejo
Build en Claude Code

El input estructurado

En Claude Code armé un markdown de especificaciones con todas las historias de usuario, el story map completo, y reglas de negocio + restricciones regulatorias.

La iteración

Le di la instrucción de construir la app. Iteramos varias veces — borrando, ajustando, refinando. El primer intento nunca queda. La conversación con el modelo es donde se construye.

El flujo navegable resultante

  • Define su objetivo de inversión (ej: "comprar un viaje en 2 años")
  • Indica horizonte temporal
  • Evalúa activos uno por uno (Apple sí, oro sí, Nvidia no...)
  • Recibe portafolio recomendado basado en sus preferencias
  • Ejecuta la primera inversión (call-to-action principal del negocio)

Detalle por tarjeta

Cada tarjeta de activo incluye: icono, performance del último año, resumen del activo, perfil de riesgo, y una frase de un inversor conocido relacionada al activo. Todo escrito en la historia de usuario, todo construido por Claude.

Plan de implementación

Lo que entrega

Claude generó un plan alineado al stack típico de un equipo de desarrollo. Roadmap de construcción, comunicación al equipo, control de alcance.

Lo que ES

  • Guía de construcción
  • Estimación inicial
  • Mapa de decisiones técnicas
  • Punto de referencia para el equipo

Lo que NO ES

  • El código (eso lo escribe ingeniería)
  • Promesa de fechas
  • Documento fijo (muta durante el desarrollo)
  • Reemplazo de las decisiones técnicas del equipo

Su rol

Bajar incertidumbre. Punto.

Lo que aprendí construyéndolo

1. Acelerar no es saltarse etapas

Las primeras tres etapas (mapeo de stakeholders, discovery, documentación con validación regulatoria) toman casi el mismo tiempo. Lo que se acelera es prototipado y plan de implementación.

2. Cumplimiento y legal desde el día uno cambian todo

Si entran al final, paran el proyecto. Si entran al principio, le dan velocidad. Los PMs senior que conozco que han trabajado en banca lo saben — los junior lo descubren tarde.

3. El prototipo rápido sirve para fallar rápido, no para impresionar

El valor de prototipar en horas en lugar de semanas es que puedes presentar a stakeholders 5 versiones antes de comprometer una a desarrollo.

Disclosure

Qué es real, qué es hipotético

Este case study es metodología real aplicada a un producto hipotético. El brief de negocio es inventado, los reguladores no validaron nada, y ningún cliente real está usando este recomendador.

El nivel de rigor

El rigor del proceso, el manejo de stakeholders regulatorios, y el nivel de documentación entregable son exactamente los que aplicaría en un producto en producción de banca regulada. Si construyes en fintech o banca regulada y quieres ver cómo adaptar este flujo a tu caso, escríbeme.