La petición de función que de verdad deberías construir (y cómo saberlo)

No todas las peticiones de funciones valen lo mismo. Algunas harán mejor tu app. Algunas te harán famoso. Algunas te distraerán para siempre. Esto es cómo detectar las que de verdad importan.

Ya sabes decir que no a las malas peticiones de funciones. Aprendiste a distinguir el scope creep de las funciones centrales. Estás protegiendo los límites de tu producto.

Pero ahora estás en otro aprieto: tienes una docena de peticiones que pasan todas la prueba. Todas son para tu app. Todas son razonables. Todas son cosas que tus usuarios de verdad quieren. Pero solo puedes construir tres de ellas.

¿Cuáles tres?

Aquí es donde la mayoría de las decisiones de producto se tuercen. Los fundadores eligen las que suenan más impresionantes, o las más rentables, o las que vinieron de su cliente más importante. A veces aciertan. Por lo general se equivocan.

Las señales que importan

Señal 1: Repetición no provocada

Si tres usuarios distintos piden lo mismo sin haber hablado entre ellos, eso es una señal. No se pusieron de acuerdo. A todos, simplemente, se les ocurrió. Si cinco usuarios lo piden, eso no es coincidencia —es una necesidad genuina.

Lo inverso es importante: si un usuario lo pide y nadie más, y tú lo construyes, ahora estás manteniendo una función que nadie más usa y con la que ese único usuario quizá tampoco quede contento (porque la construiste un poco mal).

Cuenta las peticiones antes de construir. No las del cliente más ruidoso ni las de tu cliente más grande —cuenta la repetición no provocada. Dos o tres usuarios independientes pidiendo lo mismo es una señal mucho más fuerte que un cliente importante pidiendo cinco cosas.

Señal 2: El apaño importa

Si tienes usuarios y se están quedando aunque la función falte, encontraron un apaño. Quizá lo están haciendo fuera de tu app. Quizá lo están haciendo a mano. Quizá están usando otra herramienta en paralelo.

Pero se están quedando, lo cual significa que no necesitan la función para usar tu app. La necesitan para usar tu app mejor. Eso es distinto de un obstáculo.

Las funciones que más importan son las que impiden que la gente use tu app del todo. Las funciones que son un agrado de tener son las que la gente resuelve con un apaño.

Pon atención a cuáles peticiones son obstáculos. Alguien que dice “no puedo usar esto hasta que hagas X” frente a alguien que dice “sería genial que tuvieras X”. Esa distinción es oro.

Señal 3: La función se empaqueta con un modelo de negocio

Algunas funciones desbloquean formas completamente nuevas de ganar dinero. “Facturar a mis clientes” desbloquea un modelo de negocio donde cobras por facturar. “Exportar a Salesforce” desbloquea ingresos por integración. “Marca blanca para revendedores” desbloquea un canal de socios.

Pero aquí está el truco: no sabes si esos modelos van a funcionar hasta que ya estás lanzando. No puedes planear alrededor de ellos. Solo puedes notarlos después de lanzar y ver si la gente de verdad los usa.

Las funciones que más éxito tienen son aquellas en las que lanzar la función revela un mercado que no sabías que existía. Construiste exportar. Resulta que las empresas quieren integrar tu exportación en su flujo de trabajo. Ahora tienes una historia de integración que no planeaste.

Construye funciones porque tus usuarios las necesitan. Luego observa para ver si tus usuarios las necesitan de una forma que crea un nuevo negocio. No predigas el modelo de negocio primero.

Señal 4: La petición de ayuda

Si un usuario te pide que construyas algo, eso es una petición. Si un usuario pregunta si podrías construir algo y se ofrece a ayudar a probarlo, eso es distinto.

La gente que se ofrece a ayudar a probar es gente que está comprometida con el resultado. Usarán la función con cuidado. Reportarán errores. Te dirán si de verdad resuelve su problema.

La gente que solo pide es gente que espera que mágicamente construyas lo que se está imaginando. A veces lo harás. A menudo no.

Construye primero con quienes prueban. Todo lo demás es secundario.

La tentación de construir la función de prestigio

Todo producto tiene una función que, si la lanzas, te hace sonar más impresionante. Para las apps de agendado, es integrar con Calendly. Para las apps de tareas, es integrar con Slack. Todos saben qué son. Todos las quieren.

Aquí está la cosa: todos las están consiguiendo también de alguien más. Si tu función no es la mejor y más fácil integración con Slack, solo le suma complejidad a tu app sin hacerte famoso.

Las funciones que te hacen famoso son aquellas que estás en una posición única para construir porque entiendes los problemas de tus usuarios específicos mejor que nadie. Esas no son las funciones de prestigio. Esas son las funciones aburridas que resuelven problemas reales para personas reales.

La integración con Slack es impresionante. Una herramienta que les permite a tus usuarios hacer una cosa específica mucho más rápido de lo que Slack jamás se imaginó es valiosa.

Cómo decidir de verdad

Cuando tengas un lote de peticiones de funciones que pasan todas la prueba de “¿esto está dentro del alcance?”, ordénalas por:

  1. ¿Cuántos usuarios lo pidieron (de forma independiente)? Más es mejor.
  2. ¿Esto es un obstáculo o un agrado de tener? Los obstáculos son más urgentes.
  3. ¿Tus usuarios pueden resolverlo con un apaño hoy? Si no, es más importante.
  4. ¿Alguien te va a ayudar a probarlo? Si sí, constrúyelo primero.
  5. ¿Esto revelará un nuevo mercado? Si quizá, eso es un extra, no una razón.

Luego construye en ese orden. No en el orden de lo que suena impresionante. No en el orden de tu cliente más grande. El orden de la señal real de la gente que usa tu app.

La función que no construirás (todavía)

Tendrás peticiones que no pasen el corte. No finjas que las construirás algún día. Dile al usuario: “No vamos a construir eso ahora. Aquí está el porqué. Aquí está lo que sí estamos construyendo. Aquí hay una alternativa que podría funcionarte”.

Esa honestidad importa más de lo que crees. Los usuarios prefieren saber que no lo vas a hacer a esperar seis meses con la esperanza.

Y a veces, una vez que dijiste que no, el usuario encuentra un apaño, u otra herramienta, o resuelve el problema de una forma distinta. Eso está bien. No puedes serlo todo para todos.

Los productos que ganan son los que hacen su trabajo bien y escuchan con atención lo que los usuarios de verdad necesitan, no los que tratan de serlo todo y terminan sin ser nada.