Technical Product Partner para Founders en Etapa Temprana
Un método de alcance fijo para probar una hipótesis riesgosa antes de decidir construir, iterar o detenerse.
Resumen
Los founders en etapa temprana suelen enfrentar una decisión de producto antes de contar con evidencia suficiente. Trabajo sobre una pregunta definida por vez. Identificamos la hipótesis con mayor capacidad de revertir la decisión, revisamos la evidencia disponible y diseñamos la prueba útil más pequeña. El resultado es una recomendación escrita para CONSTRUIR, ITERAR o DETENERSE, con la evidencia, los riesgos y los límites expresados con claridad.
Palabras clave: decisiones de producto; factibilidad técnica; sistemas de IA; founders; evidencia
- Para quién
- Founders en etapa temprana
- Resultado
- CONSTRUIR, ITERAR o DETENERSE
- Primer formato
- 75 minutos
- Precio beta
- USD 120
Enviar una pregunta de producto →
Definición del problema
Un prototipo pulido puede demostrar que una interfaz se puede construir. No demuestra que un usuario cambiará su conducta, que existen los datos necesarios, que un proveedor permite la integración o que el costo de entrega funciona.
El error caro no es programar lento. Es comprometer tiempo y dinero antes de nombrar la hipótesis capaz de invalidar el producto.
Intervención propuesta
El trabajo comienza con una decisión, no con una lista de funciones. La evidencia existente se separa de las opiniones. La arquitectura, los permisos, los costos y las restricciones operativas entran en la prueba solo cuando pueden cambiar esa decisión.
La prueba útil más pequeña puede ser un spike técnico, un flujo manual, un prototipo acotado, una revisión de evidencia o un modelo de costos. No es un MVP completo.
- Pregunta de producto
- Evidencia existente
- Hipótesis más riesgosa
- Prueba útil más pequeña
- Evidencia observada
Formatos de trabajo
El valor de la Product Decision Session se acredita a un Idea-to-Proof Sprint aceptado.
| Formato | Cuándo usarlo | Incluye | Duración | Precio beta |
|---|---|---|---|---|
| Product Decision Session | Existe una decisión concreta, pero todavía no está claro qué evidencia la resolvería. | Aproximadamente 10 minutos de pre-work, una sesión de 75 minutos y un Founder Decision Brief de una página dentro de las 24 horas. | 75 minutos | USD 120 para los primeros cinco clientes. Luego USD 180. |
| Idea-to-Proof Sprint | Hace falta una prueba funcional pequeña o un spike técnico antes de poder decidir. | Dos sesiones, una hipótesis riesgosa, una prueba de alcance fijo, feedback limitado, riesgos y un plan de 30 días. | 7 días | USD 550 para los primeros tres casos. Luego USD 850. |
Resultados
Cada trabajo termina con una decisión y su razonamiento. Los artefactos exactos dependen de la pregunta.
- Founder Decision Brief de una página
- Mapa de evidencia e hipótesis
- Spike técnico o prueba funcional acotada
- Nota de arquitectura y costos
- Riesgos y regla de decisión explícita
- Plan priorizado de 30 días
Evidencia técnica seleccionada
Estos son artefactos públicos, no resultados de clientes. Muestran trabajo implementado y razonamiento documentado. No demuestran adopción, escala ni resultados comerciales.
Sistema público
Study
El repositorio y la interfaz públicos muestran un flujo de documentos a notas y tarjetas. Para usar Resumen o Tarjetas, la persona debe aportar una API key de Google Gemini. Estos artefactos no establecen demanda ni rendimiento comercial.
Prototipo
Prototipo de file search con Gemini
El código inspeccionado del repositorio implementa interacciones del lado del cliente para store e importación de file search, contexto documental, imágenes adjuntas, streaming y metadata de fuentes. La nota enlazada documenta razonamiento de arquitectura y costos. No es evidencia de una aplicación desplegada ni de un sistema de producción.
Escritos seleccionados
Notas de infraestructura SRE y plataformas edge
Dos notas técnicas públicas nombran temas de infraestructura VPS y SRE y tradeoffs de IA y plataformas edge. Muestran razonamiento documentado, no implementación, medición, trabajo de clientes ni validación externa.
[Nota técnica][Nota de infraestructura SRE][Plataformas edge]
Alcance y limitaciones
- Cada trabajo aborda una pregunta principal de producto.
- El trabajo no garantiza product-market fit, inversión, ingresos, éxito técnico ni resultados comerciales.
- No reemplaza la investigación con usuarios cuando hace falta evidencia de usuarios.
- Un MVP completo, la implementación abierta y el soporte indefinido quedan fuera de alcance.
- Acepto un solo sprint activo por vez.
- No acepto logística, última milla, gestión de entregas, optimización de rutas, flota, dispatch, tracking de entregas ni trabajo competitivo adyacente.
Aplicación y procedimiento
No hay calendario público ni checkout público. La aplicación inicia una revisión de encaje y conflictos.
- 01Aplicación
- 02Revisión de encaje y conflictos
- 03Aceptación
- 04Pago
- 05Reserva privada
- 06Pre-work
- 07Sesión
- 08Founder Decision Brief
- 09Sprint opcional
Enviar una aplicación no crea una relación profesional, no reserva una reunión y no cobra un pago.
Nota del autor
Pablo Cardozo es AI Engineer y Technical Product Partner en Buenos Aires. Su trabajo público incluye interfaces de productos con IA, prototipos de retrieval y análisis documentados de infraestructura.
¿Tenés una pregunta de producto que valga la pena probar?
Describí el problema observado, la evidencia existente y la decisión que necesitás tomar.
Enviar una pregunta de producto →