- Un producto que se volvió complejo puede mejorar más mediante la eliminación de elementos innecesarios que con más explicaciones, y el caso de la calculadora de precios de Pinecone lo demuestra
- La calculadora de precios era un recurso para estimar de antemano los costos basados en uso, pero un pequeño error de entrada podía inflar el costo estimado hasta 1,000 veces y frenar el registro
- Internamente se intentó corregir el problema agregando explicaciones y valores predeterminados, pero cada ajuste generaba nueva confusión y se acumularon más de 550 mensajes en un canal dedicado de Slack
- En un A/B test en el que se eliminó la calculadora, los visitantes que no la vieron tuvieron 16% más probabilidad de registrarse y 90% más probabilidad de hacer una consulta, sin aumento en los tickets de soporte relacionados con precios
- Una vez que se agrega un elemento, tiende a permanecer aunque su valor disminuya; por eso conviene revisar conscientemente las decisiones de quitar bloques grandes de productos, proyectos y procesos
Caso de eliminación de la calculadora de precios de Pinecone
- Pinecone colocó una calculadora de costos en su página de precios porque, con un esquema de precios basado en uso, a los usuarios les resulta difícil saber con precisión de antemano cuál será el costo real
- Al hablar con usuarios potenciales, confirmaron que algunos estaban abandonando el registro tras ver estimaciones de costo muy altas en la calculadora
- Ese caso de uso era relativamente pequeño según los estándares de Pinecone
- La calculadora era mucho más confusa y sensible de lo esperado
- Un pequeño malentendido o un dato mal ingresado podía exagerar el costo estimado hasta 1,000 veces
- La calculadora les daba a los usuarios una falsa sensación de certeza, y ellos tomaban sus valores como si fueran el costo real, sin revisar la documentación, consultar al equipo ni validarlo mediante uso directo
- Como respuesta rápida, se agregaron explicaciones, disclaimers, detalles y valores predeterminados, pero el intento de reducir una confusión generaba otra
- La discusión interna también creció: en un canal dedicado de Slack se acumularon más de 550 mensajes, y se invirtió mucho tiempo en reuniones y documentación
- Una persona preguntó: “¿De verdad necesitamos la calculadora?”, pero al principio su pregunta quedó opacada por la opinión mayoritaria
- Luego realizaron un A/B test para verificar si al eliminar la calculadora y sus problemas también desaparecía su valor
- Los visitantes que no vieron la calculadora tuvieron 16% más probabilidad de registrarse que quienes sí la vieron
- Tuvieron 90% más probabilidad de hacer una consulta
- No hubo aumento en los tickets de soporte relacionados con precios
- En una encuesta interna, 7 de cada 10 personas de la compañía esperaban que la versión con calculadora fuera mejor, pero los resultados del test mostraron lo contrario
Por qué es difícil eliminar
- Muchas organizaciones, al resolver problemas, piensan primero en sumar antes que en restar
- Aunque eliminar algo pueda generar grandes beneficios, es difícil que se perciba como la opción intuitiva
- Se cita como investigación relacionada People systematically overlook subtractive changes
- Los sistemas de recompensas también suelen estar orientados a agregar cosas, y los incentivos para eliminar son poco frecuentes
- Como ejemplo de que eliminar también debería ser recompensado, se presenta Negative 2000 Lines Of Code
- A quien defendió con fuerza agregar un elemento le resulta difícil admitir que ese elemento no aporta valor
- Si se intenta eliminar algo que otra persona impulsó agregar, puede parecer un ataque a su criterio o a su trabajo, por lo que es más fácil dejarlo como está
- Muchas veces se asume que lo que ya existe está ahí por una buena razón y no se vuelve a evaluar
- Cuando nos acostumbramos al estado actual, tendemos a rechazar el cambio en sí antes de pensar lo suficiente en qué conviene eliminar
- Simplificar recortando con decisión elementos no esenciales puede traducirse en mejores tasas de respuesta de clientes, sistemas más confiables y un crecimiento e ingresos más rápidos
- Más que pequeños recortes, hace falta optar por eliminar bloques grandes de proyectos, productos y procesos; cuanto mayor sea la resistencia del equipo a una eliminación, mayor puede ser el beneficio oculto
1 comentarios
Opiniones de Hacker News
No sé si esa calculadora era buena o mala, pero la justificación, a simple vista, no tiene mucho sentido
Es obvio que si les ocultas a los usuarios que el costo del producto puede ser alto, aumentarán los registros. Que en realidad estén mejor o no depende de si más adelante reciben una factura desagradable, y eso no se puede saber con una breve prueba A/B en la página de registro
También se ven seguido casos del tipo: al quitar información de los snippets de resultados de búsqueda, subió la tasa de clics. Claro que suben los clics, porque ahora hay que hacer clic para ver la información que antes estaba en el snippet; pero se olvida cuál opción era realmente mejor
El dilema era “cómo corregir esos casos”, y la solución fue “eliminemos la calculadora desastrosa”. No ocultaron un costo 1000 veces mayor; evitaron perder usuarios por una estimación errónea 1000 veces mayor
Un ejemplo son los concesionarios de autos que dificultan consultar precios en línea y empujan a enviar un correo o visitar el local. Las calculadoras facilitan comparar antes de comprar, y a muchas empresas eso no les gusta. Sea consciente o no, es una motivación que hay que considerar
Si eres transparente con el usuario, inevitablemente lo vas a confundir más. Porque el criterio de comparación en sí trata al usuario como ganado tonto al que se puede conducir al matadero. Bajo ese criterio, cualquier función que trate al usuario como una persona pensante genera confusión y perjudica la conversión
Obviamente la página de precios quedó horrible, pero dejó de importar porque “los registros están aumentando”. En este caso, la calculadora podía resultar abrumadora para alguien que no estuviera familiarizado con los términos, pero la decisión intuitiva de “¿cómo la simplificamos?” debería haber venido primero. No me gusta la cultura de las pruebas A/B en la que todo tiene que analizarse y demostrarse estadísticamente
Si el usuario ni siquiera se queda desde el principio, ¿cómo puedes probar más adelante si está satisfecho o insatisfecho? Si cierras el ciclo y aumentas la participación, también crece la posibilidad de educar correctamente al cliente y satisfacerlo mediante interacciones posteriores
Lo recomendé porque quiero difundir la gran sabiduría del artículo, pero los límites pueden volverse difusos muy rápido
La mentalidad de “si quitamos esta parte, ¿desaparecerá algo valioso?” a veces me jugó en contra en proyectos tempranos. En especial porque es difícil estimar el valor futuro del código y los datos
Una vez, en un proyecto nuevo, hice un esquema SQL inicial con columnas de metadatos adicionales para etiquetas de publicaciones, y la semana siguiente un ingeniero senior las eliminó todas invocando el principio YAGNI. Como no estaban en la hoja de ruta de ese momento, técnicamente tenía razón, pero el trabajo original había tomado alrededor de una hora y el costo de mantener los datos era casi cero
Un año después, quien creó una funcionalidad que necesitaba esas columnas terminé siendo yo, y ahora tuve que rehacer lo mismo, incluyendo una migración de una base de datos de producción con usuarios. Por eso también hay que preguntarse lo contrario: “si quitamos esta parte, ¿aparecerá algo valioso?”. En este artículo la respuesta era clara, pero en mi caso no lo fue
Recuerdo que en SpaceX tienen una métrica que captura un concepto parecido: el porcentaje de funcionalidades eliminadas que se vuelven a agregar por segunda vez. Si todas las funcionalidades eliminadas se vuelven a agregar, tienes una tasa de reincidencia de funcionalidades del 100%, así que estás recortando demasiado seguido; 70% también es alto y 30% también es alto
Pero 0% también es malo. Si no intentas eliminar suficientes funcionalidades innecesarias, terminas con bloat. En etapas tempranas del producto parece razonable que esa tasa sea más alta, y que, a medida que madura, baje a un porcentaje bajo pero distinto de cero
Como no puedes saber en el presente el conjunto exacto de funcionalidades que necesita el mejor producto posible, está bien adoptar un enfoque probabilístico para recortar lo innecesario. Si hace falta, lo vuelves a agregar, y mientras eso no ocurra demasiado seguido, no hay razón para cuestionar la decisión inicial de eliminarlo
O, en vez de probar ambas opciones en la realidad y ver los resultados, también podríamos pasar seis meses en reuniones hablando de hipótesis y de métricas sustitutas de creencias previas no expresadas
Pasa a ser “¿se puede usar? ¿se puede borrar?”, y alguien recuerda a Knight Capital, que reutilizó un campo antiguo y terminó en un desastre enorme. Entonces dejar los campos existentes siempre se vuelve la opción más segura, y al final aparecen
metadataymetadata_1. Al año siguiente nadie sabe por qué hay dos campos de metadatos, y todo se vuelve aún más confusoEl peor codebase con el que me tocó trabajar estaba diseñado pensando en usos futuros complejos. Incluso en este ejemplo, el codebase recién necesitó la columna un año después. Por eso creo que sentar el precedente de eliminar todo fragmento de código que anticipe necesidades futuras es lo correcto. Incluso si al final vuelve a hacer falta
Para una persona es optimización prematura; para otra es “ya vi un patrón parecido antes y voy a agregar lo que entonces habría sido útil”. No parece haber una forma confiable de distinguir cuál de las dos tiene razón
La situación que describes tiene, a grandes rasgos, tres resultados. Primero, el campo resulta útil exactamente como se implementó al inicio. Segundo, la funcionalidad se implementa, pero con otro campo u otra implementación. Tercero, la funcionalidad nunca se implementa
Incluso si asignamos la misma probabilidad a las tres opciones, que haberlo creado desde el principio sea una victoria solo ocurre en un tercio de los casos. También hay que pensar cuánto costo cognitivo habría implicado, durante todo ese tiempo, verificar que las otras funcionalidades implementadas funcionaran correctamente con la columna de metadatos
En este caso, significa que tu juicio fue correcto y que tenías una gran comprensión del proyecto, pero si una decisión fue buena o no debe juzgarse con la información disponible en ese momento, no sabiendo todo lo que se supo después
El pasaje de que “en una votación interna de la empresa, 7 de cada 10 personas pensaron que la versión con calculadora sería mejor” es interesante y representa una dinámica típica.
En general fue un buen texto, pero este punto merecía más énfasis. Si el 30% de las personas involucradas ve mal la calculadora, aunque la mayoría la vea bien, es una señal de un problema potencialmente grande.
Aquí hay que tener cuidado con la política interna. La gente normalmente no quiere criticar a otros equipos si no obtiene ningún beneficio político. Por eso, si se le pregunta a la empresa “¿esto que hizo nuestro equipo tiene un efecto neto positivo?”, la respuesta por defecto tiende a ser “sí”, para no armar conflicto innecesariamente.
En esa situación, que un 30% haya señalado la posibilidad de destrucción de valor es mucho más importante de lo que parece. Hay que indagar bastante a fondo por qué lo vieron así. En este caso, en efecto fueron conscientes de ese punto y terminó bien, pero ese resultado de la votación era evidencia de un problema serio desde el principio.
Cuando se mezclan intereses, se vuelve más complicado. Ventas quiere activar todo tipo de patrones oscuros, y soporte al cliente puede estar harto de procesar reembolsos porque se agrega automáticamente una garantía extendida al carrito.
Me dio risa la parte del texto que decía que quitar la calculadora podría ser mejor para los usuarios porque se completarían más ventas. Tal vez la opción correcta era que el usuario recibiera el impacto adecuado del precio y se fuera, pero eso se ignoró.
Imagina que el código de la calculadora es un desastre comparado con el resto del proyecto, usa una biblioteca vieja, se rompe al actualizarla, puede tener vulnerabilidades de seguridad, consume una cantidad anormal de recursos y arruina el sistema de compilación. Nadie quiere lidiar con eso.
En esa situación, si preguntas si es una buena idea, la mayoría responderá “no” y querrá deshacerse de ese desastre. Entonces 70% es un número muy bueno. En cambio, si es una función en la que a la gente le gusta trabajar, 70% es un número realmente malo.
Claro que podrían haber pensado eso, pero es un salto bastante grande. Tal vez creían que no habría mucha diferencia, o suponían que el rendimiento era menor por los casos en que la calculadora daba respuestas incorrectas.
El mensaje general es interesante, pero esta parte me hizo detenerme un poco.
Cuando dice que “con apenas malentender algo o ingresar algo mal, la estimación puede exagerarse hasta 1000 veces”, ¿significa que en el uso real, si malentiendes o evalúas mal una métrica aunque sea un poco, terminarás pagando 1000 veces más de lo planeado?
En los sistemas de cobro en línea eso es totalmente realista. Una vez configuré mal un prototipo en GCP y pensé que costaría unos 2 o 3 dólares, pero después de no prestarle atención por unos días me llegó una factura de más de 100 dólares.
Si con mover un poco un slider el precio estimado aumenta de forma absurda, se entiende que los clientes abandonen. Quitar la herramienta ayudará con los registros, pero no ayudará a los clientes que más adelante se enfrenten a este tipo de problema.
Un usuario pensó que el número de consultas por segundo se calculaba como cantidad de búsquedas × el top-k de cada búsqueda. El top-k es la cantidad de resultados que quieres recibir. Si el top-k es 10, ingresas un valor 10 veces mayor que el real para consultas por segundo y ves una estimación unas 10 veces mayor que la factura real.
Otro usuario pensó que el número de vectores se calculaba como cantidad de embeddings × número de dimensiones del embedding. 1,536 es un número común de dimensiones, así que el valor ingresado terminó siendo literalmente 1,536 veces mayor. El uso real lo calcula correctamente Pinecone, así que no se cobra una cantidad tan alta.
El número de dimensiones de un vector es un concepto básico para ingenieros de IA y QPS es una métrica básica para administradores de bases de datos, pero Pinecone tiene muchos usuarios que son nuevos en IA, nuevos en administración de bases de datos, o ambas cosas.
El autor debería seguir su propio consejo. Debería quitar el “Psst... Get the next post in your inbox” que interrumpe a mitad del artículo, y también eliminar ese botón tonto que te sigue al hacer scroll.
Conté cinco formas de suscribirse solo en esa página. ¿De verdad hacen falta cinco? ¿Hace falta ponérselas enfrente a la gente en medio del contenido? ¿De verdad creen que van a conseguir más suscriptores interrumpiendo y molestando a las personas? ¿Ese es el tipo de suscriptor que quieren?
Quitar algo suele ser bastante claro. Basta con salir de esa mentalidad de pozo de “más, más, más; ganar dinero; atraer clientes” y pensar: “¿qué es lo correcto para respetar al usuario, y cómo podemos ayudarlo tratándolo como un ser humano y no como alguien a quien exprimirle la cartera?”.
Hay que recordar que la mayoría de los negocios existen para ganar dinero, no para hacerles agradable la experiencia a los lectores de HN.
Qué significa respetar al usuario es una pregunta distinta, aunque no completamente desconectada.
Que se haya creado un canal dedicado de Slack, que se hayan acumulado más de 550 mensajes con opiniones de toda la empresa, y que se hayan gastado decenas de horas en reuniones y miles de palabras sobre qué habría que agregar para arreglar la calculadora es un síntoma de contratación excesiva.
Cuando hay demasiada gente, se pierde la iniciativa. Si se olvidan de qué es realmente importante y sienten que tienen que llegar a un consenso por comité, entonces hay demasiada gente.
El diseño por comité también queda limitado dentro del comité.
¿No sería mejor eliminar directamente el esquema de precios, que es tan complejo que los clientes no pueden modelarlo de forma útil?
Es decir, si la opción A cuesta x dólares y la opción B cuesta 10x dólares, y la mayoría de los usuarios cree por error que necesita B, la calculadora se vuelve una herramienta que induce a confusión.
A mí me gusta bastante el enfoque de “consulta por precio”. Es molesto para los usuarios que quieren saber rápido un rango aproximado de precios, pero ayuda a identificar casos en los que se pueden negociar precios estándar o precios difíciles de explicar fácilmente en línea. También permite captar situaciones en las que el usuario simplemente habría seguido de largo. Por supuesto, no aplica para la mayoría de los casos de comercio electrónico.
En nuestra empresa hay unos 250 productos, y 5 de ellos generan el 80% de los ingresos.
Los equipos de desarrollo de esos 5 productos apenas alcanzan a seguir el ritmo de las correcciones de bugs, y les cuesta agregar funcionalidades nuevas e importantes. Meter cualquier cosa en el roadmap, sin importar quién lo pida, es una batalla imposible.
La empresa tiene miles de desarrolladores, pero la mayoría está asignada a productos que casi no contribuyen a los ingresos.
Parece claro que, para avanzar, lo correcto sería recortar la mayoría de los productos y reorganizar los equipos para impulsar los principales productos generadores de ingresos que queden. Pero eso no ocurrió, y no hay señales ni rumores de que vaya a ocurrir. La política interna de las empresas es realmente dura.
Tuve una experiencia parecida. En un sitio web con varios productos que parecían bastante similares, nos preocupaba que a la gente le costara decidir qué comprar y que por eso no comprara.
Así que creamos un applet de recomendación de productos que, después de que el usuario respondiera algunas preguntas, recomendaba uno o dos productos más adecuados. Costó algo de trabajo hacerlo bien, pero una vez terminado funcionaba bien.
Lo pusimos en el sitio y la tasa de conversión se desplomó. Hicimos una prueba A/B y quedó claro que perjudicaba la conversión. Todavía no sé por qué la perjudicaba, pero así fue. Entonces lo movimos de la página principal a la sección de FAQ, y casi nadie volvió a usarlo.
Quizá la gente estaba indecisa, y les ahorró el esfuerzo de probar distintas cosas por su cuenta para averiguarlo.
Si era un servicio, quizá una estrategia al estilo Amazon Prime, donde se registran primero aunque no estén seguros y luego se aprovecha la falacia del costo hundido, podría haber funcionado. O tal vez, sin el applet, se habrían registrado esperando que la versión más barata fuera suficiente, pero el applet les cortó esa esperanza de inmediato.
Si era un producto físico, quizá simplemente los ayudó a evitar una mala compra.
No esperaría que la gente lo buscara en las FAQ. Tal vez en el footer, pero no en las FAQ.
Es un caso de estudio interesante, pero soy escéptico sobre sus implicaciones más amplias. Pinecone es conocido por ser caro en comparación con otros servicios de bases de datos vectoriales. Si se hace una comparación horizontal de precios, hay varias opciones mejores en el mercado.
Quitar la calculadora no resuelve el problema central. Solo vuelve los costos más difusos y hace que al usuario le cueste más comparar opciones desde el principio. Desde mi punto de vista, al reducir el paso de comparación, podría hacer que más usuarios con poca información suban datos sin entender bien el impacto en el precio.
A veces simplificar tiene valor, pero en este caso parece beneficiar más a la empresa que al usuario. En lugar de eliminar la calculadora por completo, quizá habría sido mejor mejorar su precisión y usabilidad. La transparencia de precios es importante, especialmente en servicios B2B donde los costos pueden crecer rápidamente.