Preguntas de entrevista para Responsable de Producto

Respuesta modelo

Partimos de la métrica norte del equipo, que era proyectos completados por cuenta y mes, y de su árbol de palancas: activación, frecuencia de uso y retención. El trimestre anterior habíamos empujado la frecuencia sin apenas resultado, así que miré dónde estaba la fuga mayor y la encontré arriba del todo: el 62 % de las altas nuevas no llegaba a crear su primer proyecto. Hice dieciocho entrevistas en tres semanas, la mitad con cuentas que se habían quedado por el camino, y crucé lo que oí con el embudo en Amplitude. Salieron dos puntos de fricción claros: la importación de datos y la falta de una plantilla inicial. Dirección pedía un rediseño completo del onboarding, que eran unos cuatro meses; propuse atacar solo esos dos pasos, seis semanas, con un test A/B al 50 % del tráfico y un criterio de decisión acordado de antemano. La activación a siete días pasó del 31 % al 46 %, unas 1.900 cuentas activadas más por trimestre. Lo que dejamos fuera lo documenté con su motivo, y eso evitó que la discusión se reabriera en cada comité.

Respuesta modelo

El plan de medición lo cierro antes de construir, no después, porque si lo dejo para el final siempre aparece la métrica que hace quedar bien al equipo. Defino tres cosas: la métrica principal que debería moverse, dos métricas de guardia que no deben empeorar —normalmente latencia, tickets de soporte y churn— y el umbral a partir del cual consideramos que ha funcionado. En el rediseño del cambio de plan, por ejemplo, la principal era la tasa de finalización del flujo, las de guardia eran los tickets de facturación y las bajas en los siete días siguientes, y el umbral era cinco puntos. Mido por cohortes, nunca comparando el antes y el después en bruto, porque la estacionalidad de nuestro negocio en agosto y en enero se come cualquier efecto. Y me obligo a revisar a los treinta días: muchas funcionalidades tienen un pico de novedad que desaparece en dos semanas y llamar éxito a ese pico es la forma más rápida de perder credibilidad con ingeniería.

Respuesta modelo

El director comercial quería un módulo de informes a medida para un cliente grande que estaba renegociando el contrato. Lo primero que hice fue no discutir en la reunión: pedí dos días. Estimé el trabajo con la tech lead —siete semanas, más un mantenimiento recurrente porque nos apartaba del modelo de datos común— y revisé cuántas cuentas más habían pedido algo parecido: cuatro de trescientas cuarenta. Luego llamé al cliente con el comercial delante y descubrimos que lo que necesitaba no era el módulo, sino exportar tres informes concretos cada lunes. Propuse una exportación programada, dos semanas de trabajo, y dejé por escrito qué haría cambiar mi decisión: si en un trimestre lo pedían más de veinte cuentas, entraba en el roadmap. El cliente renovó, el director comercial se sintió acompañado y no perdimos siete semanas. La clave no fue el no, fue llegar con una alternativa y con el dato el mismo día.

Respuesta modelo

Con constancia más que con recursos, que es la situación normal en la mayoría de empresas españolas de tamaño medio. Tengo un ritmo fijo de tres entrevistas semanales que no se negocia: una con un cliente activo, una con alguien que acaba de darse de baja y una con una cuenta que se quedó a medias en el alta. Los participantes salen de Zendesk y de un formulario de Typeform, y agradezco su tiempo con algo simbólico, no con dinero. Guardo las notas en Dovetail etiquetadas por oportunidad, y cada quince días reviso el mapa de oportunidades con diseño y con la tech lead: eso es lo que evita que las entrevistas se conviertan en una colección de anécdotas. Cuando necesito volumen, lanzo una encuesta corta o un fake door; el año pasado dos funcionalidades murieron ahí, con un 1,2 % de interés real, y nos ahorramos unos tres meses de trabajo. Y algo que cuesta poco y rinde mucho: escuchar grabaciones de soporte y sentarme media jornada al trimestre con el equipo de atención al cliente.

Respuesta modelo

Lo primero es no tratar la estimación como una negociación de bazar, porque presionar sobre la fecha solo genera trabajo mal hecho y desconfianza. Me siento con la tech lead a abrir los tres meses: casi siempre hay una parte que es el problema real y otra que es generalidad, migración o casos límite. En el último caso, de doce semanas, ocho eran un motor de reglas configurable y cuatro resolvían el 80 % de las peticiones con tres reglas fijas. Volví a negocio con dos opciones sobre la mesa: la versión de cuatro semanas ahora, medida, y la decisión de invertir en el motor solo si el uso lo justificaba. También pregunté qué había detrás de las tres semanas, porque a veces es una feria del sector o una renovación concreta y basta con tener lista una parte. Si aun así no cabe, digo qué sale del trimestre a cambio: la conversación deja de ser sobre plazos y pasa a ser sobre prioridades, que es donde debe estar.

Respuesta modelo

Lanzamos un panel de estadísticas avanzadas para el plan superior porque cinco cuentas grandes lo pedían con insistencia y el equipo comercial lo consideraba imprescindible para cerrar operaciones. No hice discovery real: di por buena la petición porque venía de cuentas importantes. Nueve semanas de trabajo y, a los tres meses, lo usaba el 6 % de las cuentas con acceso y no cambió ni una renovación. Al revisarlo con las entrevistas que debí hacer antes, el problema real no era la falta de datos, sino que nadie confiaba en las cifras porque la definición de cuenta activa variaba entre pantallas. Retiramos el panel, unificamos las definiciones y publicamos un glosario dentro del producto; los tickets sobre datos incoherentes cayeron un 40 %. Me llevé dos reglas: una petición repetida no es evidencia, es una hipótesis, y antes de construir hay que ser capaz de decir en una frase qué debería ocurrir si acertamos.

Respuesta modelo

Trabajo en trío de producto: la diseñadora, la tech lead y yo definimos juntos el problema y la métrica antes de que exista ninguna solución. Yo no llego con pantallas dibujadas; llego con el problema, la evidencia y las restricciones. Las tres participamos en las entrevistas, aunque sea una cada dos semanas, porque la conversación posterior es completamente distinta cuando el equipo ha oído al cliente en lugar de leer mi resumen. Ingeniería entra pronto, en la fase en la que aún se puede cambiar el enfoque: muchas veces la solución más barata surge de ahí. Yo me encargo del contexto, del porqué, de la priorización y de defender el alcance ante el resto de la empresa; diseño se encarga de la solución y de la validación con usuarios; ingeniería, del cómo y de la viabilidad. Y protejo dos cosas con firmeza: que el equipo no reciba peticiones directas por canales paralelos y que haya un presupuesto fijo de capacidad para fiabilidad y deuda técnica.

Respuesta modelo

Llevo tres años en la misma línea de producto y he pasado de un equipo a dos, pero el techo está claro: la estrategia se decide fuera y mi margen se ha reducido a optimizar lo que ya existe. Busco un puesto con responsabilidad sobre un resultado de negocio completo y no solo sobre un conjunto de funcionalidades. De esta posición me interesan tres cosas concretas: que el equipo trabaje con descubrimiento continuo y no por lista de peticiones, que exista cultura de medición —he visto en su blog cómo publican los resultados de sus experimentos, incluidos los negativos— y que el producto tenga un componente de monetización, que es donde más he aprendido y donde más disfruto. Y quiero preguntarle algo por mi parte: ¿quién decide hoy qué entra en el roadmap y con qué criterio?

RICE puntúa cada iniciativa multiplicando alcance (cuántas personas afecta en un periodo), impacto (cuánto mueve la métrica, en una escala acordada), confianza (qué evidencia respalda las dos cifras anteriores) y dividiendo por el esfuerzo en semanas-persona. Su valor real no está en el número, sino en obligar al equipo a explicitar los supuestos y en hacer comparables peticiones que llegan de sitios muy distintos. Falla en tres puntos. Primero, es muy sensible al esfuerzo: basta que ingeniería estime dos semanas en lugar de cuatro para que una iniciativa suba a lo alto de la lista. Segundo, el impacto se puntúa a ojo y quien defiende la iniciativa tiende a inflarlo, así que conviene puntuar entre varias personas o dejar que lo haga alguien sin interés en el resultado. Y tercero, penaliza las apuestas estratégicas: nada que sea grande, incierto y a doce meses sobrevive a una división por esfuerzo. Por eso lo uso solo para ordenar mejoras dentro de un objetivo ya elegido, y reservo aparte entre un 20 % y un 30 % de la capacidad para apuestas y para deuda técnica, que se deciden con otro criterio.

Antes de proponer nada, necesito saber qué considera esta empresa activación, porque la cifra no significa lo mismo si es «crear una cuenta» o «llegar al momento en que el producto aporta valor». Después construiría el árbol: activación es el producto de la tasa de finalización de cada paso del alta, así que la trocearía por pasos, por origen de tráfico, por dispositivo y por tipo de cuenta. Casi siempre hay un paso que se lleva la mitad de la fuga y un segmento con un comportamiento muy distinto del resto. Con eso miraría dos fuentes: la cuantitativa, para saber dónde y cuánto se pierde, y la cualitativa —diez o doce entrevistas con altas recientes que no llegaron, más grabaciones de sesión—, para saber por qué. La experiencia dice que las causas suelen repartirse entre fricción real (formularios largos, importación de datos, verificación), expectativa equivocada creada por el marketing y ausencia de un primer valor claro en los diez primeros minutos. A partir de ahí elegiría dos hipótesis, no diez, y las probaría con test A/B con el criterio de decisión fijado de antemano. Y fijaría una métrica de guardia: subir la activación aflojando el alta puede llenar el producto de cuentas que se irán en tres semanas y empeorar la retención a noventa días.

La retención mide qué porcentaje de una cohorte sigue obteniendo valor pasado un tiempo; el churn es su reverso contable, la proporción que se marcha en un periodo, y suele aplicarse a cuentas o a ingresos. No son intercambiables: en un producto B2B se puede perder un 3 % de cuentas y ganar ingresos si las que se van son las pequeñas, y de ahí que convenga mirar el churn de ingresos junto al de cuentas. La curva por cohortes se lee en tres tramos. La caída inicial de las primeras semanas habla de un problema de activación o de expectativa equivocada, no de retención. La pendiente intermedia indica si el producto se integra en la rutina del usuario. Y lo importante de verdad es si la curva se aplana: una curva que se estabiliza en el 40 % significa que hay un grupo que ha encontrado su sitio y que el negocio puede crecer; una curva que sigue bajando hasta cero significa que no hay producto, por mucha adquisición que se compre. Comparo siempre cohortes mensuales del mismo tamaño y con la misma definición de uso activo, porque cambiar esa definición a mitad de año es la manera más común de contarse un cuento.

Antes de lanzarlo fijo cuatro cosas: la métrica principal, el efecto mínimo que me interesa detectar, la potencia y el nivel de significación habituales, y con eso calculo el tamaño muestral y la duración. Si el cálculo me dice que necesito once semanas para detectar dos puntos, ya sé que ese test no es viable y tengo que decidir otra cosa: cambiar la métrica por una más frecuente y correlacionada, aumentar el efecto esperado con un cambio más ambicioso o asumir la decisión sin experimento. Fijo también el criterio de parada y no miro los resultados a diario para cortar en cuanto salga favorable, porque eso convierte cualquier ruido en un éxito. No haría un test en cuatro situaciones: cuando el volumen es insuficiente, algo muy común en B2B con cientos y no millones de cuentas; cuando el cambio es irreversible o afecta a una obligación legal, como un requisito de accesibilidad o de privacidad, que se hace y punto; cuando el coste de construir las dos variantes supera claramente el valor de la información; y cuando el resultado no cambiaría la decisión, que es la pregunta más útil de todas. En esos casos uso lanzamientos progresivos con banderas de funcionalidad, comparación entre grupos equivalentes o simplemente decido con la evidencia cualitativa y lo digo en voz alta.

El ARPU es el ingreso medio por usuario o por cuenta en un periodo, y su utilidad depende de con qué se acompañe: por sí solo puede subir simplemente porque se han ido los clientes pequeños, lo cual no es una buena noticia. Yo lo miro junto al número de cuentas, al churn de ingresos y al LTV frente al CAC. Sin tocar el precio de lista hay varias palancas. La primera es la estructura de planes: qué se incluye en cada nivel y cuál es el eje de crecimiento —usuarios, volumen, proyectos—; cambiar el límite del plan intermedio de usuarios a proyectos nos subió el ARPU de 18,40 € a 23,10 € mensuales sin aumentar el churn. La segunda es la expansión: avisos en el momento en que la cuenta roza el límite, con la ventaja explicada en términos de su uso real y no como un anuncio genérico. La tercera es la mezcla: empujar el plan anual con dos meses de descuento mejora la caja y la retención a la vez. La cuarta, muchas veces la más rentable, es reducir la fuga de ingresos: pagos fallidos que nadie reintenta, descuentos históricos que se arrastran años y bajas por fricción en la renovación. Y todo esto exige medir el efecto en cohortes nuevas, porque tocar precios a la base instalada tiene consecuencias que aparecen tres meses después.

No lo evalúo como una cuestión técnica, sino como una inversión con retorno, y para eso necesito que la conversación salga del terreno abstracto. Hago tres preguntas: qué nos está costando hoy esa deuda en algo medible —incidencias, tiempo de entrega, horas de guardia, retrabajo—, qué pasa si esperamos otro trimestre, y si hay una versión más pequeña que capture la mayor parte del beneficio. En el módulo de facturación, la respuesta a la primera pregunta fue clara: siete incidencias críticas al mes y un tiempo de entrega mediano de treinta y cuatro días para cualquier cambio. Con ese dato no hubo debate, y además cambié el planteamiento: en lugar de aprobar seis semanas de parón, acordamos un presupuesto fijo del 20 % de la capacidad de cada trimestre para fiabilidad y deuda. Las incidencias críticas bajaron de siete a dos al mes y el tiempo de entrega, a diecinueve días. Lo que no hago es pedir a ingeniería que me demuestre el detalle técnico: si me piden algo de forma insistente y con argumentos de coste, mi trabajo es traducirlo a impacto de negocio, no auditar su criterio.

Los trato como restricciones de diseño desde la fase de discovery, no como un trámite del final, porque llegar a la revisión legal con la funcionalidad terminada es la manera más cara de trabajar. En privacidad, las preguntas que llevo a la mesa desde el primer boceto son qué datos personales necesito de verdad, con qué base de licitud, cuánto tiempo los conservo y cómo permito ejercer los derechos; el principio de minimización suele simplificar el producto, no complicarlo. Trabajo con legal y, cuando hay tratamientos de riesgo, con la persona responsable de protección de datos, siguiendo los criterios de la AEPD, especialmente en consentimiento y en gestión de cookies, que en España se revisan con lupa. En accesibilidad, el marco europeo ya obliga a buena parte del comercio electrónico, la banca y el transporte, así que incluyo los criterios WCAG 2.1 AA y la norma EN 301 549 en la definición de terminado: contraste, navegación por teclado, etiquetado de formularios y compatibilidad con lectores de pantalla. En mi último puesto lo planificamos con seis meses de antelación reservando un 20 % de la capacidad; corregimos ciento cuarenta y dos incidencias, no bloqueamos ninguna operación comercial y ganamos dos concursos que exigían declaración de accesibilidad. Y con las funcionalidades de inteligencia artificial estamos aplicando la misma lógica anticipatoria por el reglamento europeo: clasificación del caso de uso, transparencia hacia el usuario y supervisión humana donde la decisión afecta a la persona.

Primero separo la amenaza de la necesidad. Pido una llamada con el cliente, junto con la persona responsable de la cuenta, para entender qué problema hay debajo de la petición; muy a menudo lo que se pide es una solución que el cliente ha imaginado, no lo que necesita. Después cuantifico tres cosas: cuánto pesa esa cuenta en los ingresos, cuánto cuesta la funcionalidad —incluido el mantenimiento futuro, que es la parte que siempre se olvida— y cuántas otras cuentas han pedido algo equivalente. Con eso preparo dos escenarios para dirección: hacerlo, diciendo con nombre y apellidos qué sale del trimestre a cambio, o resolver el 80 % de la necesidad con una alternativa más barata, que casi siempre existe. La decisión de sacrificar el trimestre por un cliente no es mía en solitario, es de negocio, pero mi responsabilidad es que se tome con el coste sobre la mesa y no en caliente. Y si se hace a medida, negocio dos condiciones: que sea configurable para otras cuentas o que tenga fecha de retirada, para no arrastrar durante años una funcionalidad de un solo cliente.

Lo digo el mismo día, y lo digo yo. Lo primero es comprobar que el hallazgo es sólido y no una impresión de una sola prueba de usabilidad: reviso el dato, hago dos o tres entrevistas más y hablo con soporte. Si se confirma, convoco al trío de producto y ponemos tres opciones sobre la mesa: lanzar a un grupo reducido para aprender con coste bajo, recortar hasta la parte que sí resuelve algo, o parar. Lo que nunca hago es lanzar igualmente porque el trabajo ya está hecho: el coste ya está gastado y añadir mantenimiento de algo inútil es tirar dinero dos veces. Después informo a los stakeholders con el mismo formato que uso siempre: qué esperábamos, qué hemos aprendido, qué proponemos y cuánto cuesta cada opción. En un caso así optamos por lanzar al 10 % con una bandera de funcionalidad; a las tres semanas confirmamos que no había uso y lo retiramos sin haber prometido nada a nadie. Y la parte más importante llega luego: revisar en qué momento del proceso debimos detectarlo, que en aquel caso fue una validación que nos saltamos por prisa.

No lo resuelvo en privado con cada uno, porque así se acaba prometiendo lo mismo dos veces. Los siento juntos con los datos delante: cuántas operaciones se están perdiendo por lo que pide comercial, con qué importe, y cuántos tickets y horas cuesta lo que pide soporte, con qué efecto en las bajas. Traduzco ambas peticiones a la misma unidad, normalmente ingresos en riesgo a doce meses, y las coloco en el mismo marco de priorización que el resto. Muchas veces aparece una tercera opción que satisface parcialmente a los dos, y cuando no aparece, la decisión se toma contra el objetivo del trimestre, que es el árbitro: si el objetivo es retención, gana soporte; si es crecimiento de cuentas nuevas, gana comercial. Lo que sí garantizo a quien pierde es dos cosas: una explicación con el criterio, no con una excusa, y una fecha concreta de revisión. La transparencia del criterio es lo que hace que la siguiente vez ambos vengan con datos en lugar de con presión.

Reconociéndolo primero, porque si el equipo lo ha vivido y yo lo minimizo, la conversación se acaba ahí. Después miro los datos de los tres trimestres: cuántos cambios hubo, de dónde vinieron y cuáles resultaron justificados. En mi caso, siete de nueve cambios venían del mismo canal, peticiones directas de dirección comercial que entraban sin pasar por ningún filtro. Con eso propuse tres medidas concretas: un único canal de entrada para las peticiones, con un formato mínimo de problema y de impacto; un compromiso trimestral más pequeño, con un 25 % de la capacidad deliberadamente sin asignar para absorber lo imprevisto; y una revisión quincenal en la que cualquier cambio implica decir en voz alta qué sale a cambio. Lo importante es que la confianza no vuelve con un discurso, vuelve cumpliendo dos trimestres seguidos. Y publiqué el resultado: cumplimiento del 84 % frente al 55 % anterior, con los cambios que sí hubo explicados uno a uno.

Distingo entre lo que el experimento dice y lo que no dice. Un resultado plano puede significar que no hay efecto o que no teníamos potencia suficiente para detectarlo, y esa diferencia hay que explicarla sin tecnicismos: con nuestro volumen, solo habríamos detectado un efecto superior a cuatro puntos, así que lo que sabemos es que no hay una mejora grande, no que no haya ninguna. A partir de ahí, la pregunta que planteo es cuánto cuesta lanzarlo: si el coste de mantenimiento es bajo, no empeora ninguna métrica de guardia y hay un argumento razonable de coherencia o de marca, lanzarlo es una decisión legítima y no me opongo. Lo que pido es que se llame por su nombre: es una decisión de criterio, no un resultado del experimento, y así queda escrita en la nota de decisión. Si además empeorase alguna métrica de guardia, ahí sí me planto y lo digo con el dato delante. Mi trabajo no es ganar la discusión, es evitar que dentro de seis meses se recuerde como una mejora demostrada algo que nunca lo fue.