Notas sobre construir un producto discreto

Mole para Mac superó un pequeño hito de ventas unas tres semanas después del lanzamiento. En lugar de escribir sobre los números, quiero anotar algunas decisiones que tomé por el camino, porque la mayoría van a contracorriente de los instintos de un ingeniero en activo, y son las que defendería primero. Si estás construyendo tu propio producto, tal vez algo de esto te ahorre un desvío.

Respondo cada correo yo mismo

Desde el lanzamiento, cada pieza de soporte la he manejado a mano: reembolsos, reinicios de activación, devolver la diferencia de precio tras un descuento, preguntas cotidianas. El volumen es pequeño, bastante menos del uno por ciento de los usuarios escribe alguna vez, y podría haber montado un agente para manejarlo en media hora. Elegí no hacerlo, por dos razones.

Primero, el soporte es donde el producto te dice la verdad. Una solicitud de reembolso te dice por qué el producto decepcionó a alguien. Una pregunta incómoda te dice qué parte de la app no se explica sola. Unos cuantos correos de ida y vuelta sacan a la luz lo que el usuario realmente quería, que a menudo no es lo que pidió al principio. Filtra eso con automatización desde el día uno y pierdes la señal justo cuando más la necesitas.

Segundo, atender cada caso te hace fluido. Después de suficientes rondas conoces la mejor respuesta a cada clase de problema, y sabes qué problemas debería absorber el producto para que la pregunta nunca vuelva a plantearse. Cuando el volumen crezca y traiga automatización, codificará esa fluidez en lugar de conjeturas.

Mi umbral para automatizar no es un conteo de tickets. Quiero que la pregunta se repita, que la respuesta se mantenga estable y que las excepciones se comprendan. Hasta entonces, la conversación desordenada es la investigación. Después de ese punto, la automatización puede manejar el camino conocido y facilitar que un caso inusual llegue a una persona.

Hasta ahora el enfoque se sostiene: no he gastado nada en marketing, el crecimiento es de boca en boca y la tasa de reembolso está por debajo del 0,8 por ciento.

El andamiaje puede esperar

La misma lógica aplica a la infraestructura. No monté un sistema de tickets, un help desk ni una base de conocimiento antes del lanzamiento. A los ingenieros les encanta construir primero la maquinaria de apoyo porque es la parte que saben construir, y la IA la ha convertido en un trabajo de medio día, lo que la hace más tentadora y igual de fácil de optimizar demasiado pronto. El medio día es real; también lo es el costo continuo de cuidar un sistema que aún no necesitabas. Yo añadiría el sistema cuando la ausencia empiece a perder solicitudes, a ocultar el tiempo de respuesta o a hacer inconsistente la misma respuesta. Antes de eso, la bandeja de entrada es más simple y más informativa.

Decidir qué no construir

La diferencia entre un buen producto y uno mediocre está sobre todo en las cosas que se niega a hacer. Qué funciones pertenecen a cada versión, qué peticiones son necesidades reales y cuáles solo lo parecen, qué ideas genuinamente buenas aún no pertenecen a este producto. Me he disculpado con usuarios que sugirieron funciones buenas por sí solas, porque un Mac tiene un montón de trucos bonitos que Mole no debería hacer. Di sí a todo y obtienes un guiso, y un guiso es difícil de mantener y más difícil de confiar cuando se trata de borrar archivos.

Mantengo en la cabeza más o menos medio año del camino del producto: qué añade cada versión, qué se queda fuera y dónde aterrizan las cosas para que un usuario de primera vez las encuentre sin instrucciones. Si la primera tarea común necesita un manual, la interfaz ha fallado a las personas a las que más quiero llegar. La documentación sigue importando para la profundidad, los casos límite y la confianza, pero no debería rescatar la forma básica del producto. La navaja vieja lo dice mejor: no añadas una entidad a menos que sea necesaria.

Ahora uso tres vetos antes de que una función llegue al roadmap. No debería añadir un timer siempre activo, un listener ni un costo de muestreo a menos que el usuario haya entrado en la función. No debería ampliar el helper privilegiado ni pedir un permiso nuevo solo para hacer posible una pequeña comodidad. Y no debería añadir un ajuste cuando un valor predeterminado sereno puede decidir por todos. No son reglas universales para el software. Son un presupuesto para este producto: el trabajo residente, el privilegio y la configuración son formas de superficie que los usuarios tienen que confiar para siempre.

La posición

La posición de Mole es una frase: un cuidador silencioso para tu Mac. Limpia, desinstala, optimiza, analiza y vigila, y por lo demás se mantiene al margen. La ambición es simple de enunciar: si uno de cada cien usuarios de Mac se queda con Mole, habrá resultado genuinamente útil. Hace poco algunos usuarios con discapacidad visual empezaron a usarlo y se toparon con aristas, así que las mejoras de accesibilidad se adelantaron a las funciones nuevas. Tengo ganas de ver cómo se siente la app para ellos; un cuidador silencioso debería ser silencioso para todos.

Mantener los productos humanos en la era de la IA

La IA hizo posible gran parte de este producto. No sustituyó hablar con las personas que lo usan, y no creo que deba hacerlo. La eficiencia es fácil de comprar ahora; el sentimiento y la confianza entre un desarrollador y sus usuarios todavía hay que ganarlos conversación a conversación. Tal vez así es como los productos construidos con IA conservan su calor humano: el código se puede generar, la relación no.

Este es mi primer producto de pago, y algunas de estas decisiones pueden terminar siendo equivocadas. Si has recorrido este camino más tiempo que yo y me ves haciendo algo tonto, me gustaría saberlo. Cómo llegó Mole hasta aquí en primer lugar es una historia más larga, contada en De un script de shell de 500 líneas a una app para Mac.