Construyendo, y todo lo demás

En los últimos dos años, 31,832 personas solicitaron ser Product Manager en Whatnot. Contratamos a una. Contratamos a una. Tienes el doble de probabilidades de hacer un hoyo en uno que de conseguir un trabajo simplemente postulándote.

Eso no es un fallo del proceso. He estado construyendo productos – y equipos de producto – durante más de una década, y uno de los factores más importantes para decidir venir a Whatnot hace ~3 años fue la cultura de producto muy deliberada. Nadie sabe lo que significa ser PM en el mundo de la IA, pero todo lo que veo indica que la industria se está moviendo hacia nosotros y hacia cómo construimos aquí, porque ninguna herramienta te hará útil si no estás haciendo el trabajo correcto.

Primero tenemos que reconocer: el PM promedio es profundamente promedio.

La función de producto surgió como respuesta a la escala – los equipos de ingeniería se volvieron demasiado grandes para que los CEOs o GMs los gestionaran directamente, por lo que se necesitó un conducto entre negocio y tecnología. Con el tiempo, generalizamos perezosamente el rol a "cada vez que contratas un Engineering Manager, contratas un PM". Pero donde un Director de Ingeniería gestionaba 30-40 personas a través de sus EMs, un Director de PM solo gestionaba cinco. Los incentivos gobiernan el mundo, así que el trabajo de esos directores se convirtió en "justificar el crecimiento del headcount de mis socios de ingeniería" para que ellos, a su vez, pudieran crecer y convertirse en VP. Lentamente, el rol de los PMs junior pasó de ser "CEOs del producto" a "niñeros de botones" y los ingenieros con mentalidad de producto se convirtieron en tomadores de órdenes infantilizados.

Luego llegó la COVID y la industria contrató la asombrosa cifra de 500,000 nuevos ingenieros de software en solo cuatro años, y se crearon ~80,000 nuevos PMs para igualar. Eso son 80,000 PMs enterrados en equipos gigantescos en FAANG, lejos de cualquier cliente, a 50 capas de la reunión donde ocurre lo importante, enseñados a hacer PM con plantillas en una escuela de producto, en una era de crecimiento de engagement no merecido donde todo parecía funcionar.

La probabilidad de que alguien surja de ahí con grandes instintos de producto, experiencia y experiencia y determinación parece menos probable que hacer un hoyo en uno.

Segundo: hicimos que nuestros mejores fueran peores.

Cuando tu trabajo es supervisar a cinco personas, lo único que puedes hacer con tu día es meterte en el trabajo de otros. Ellos lo detestan y lo etiquetan como microgestión en una encuesta anónima, así que te echas atrás. ¿Entonces cómo ocupas tu tiempo? Cuentas historias, guías las cosas a través de revisiones para que tus equipos 'tengan éxito', justificas recursos. Pero no sabes qué historia contar, así que creas un equipo de investigación de usuarios para que te diga los trabajos por qué trabajos por hacer, luego una función de PMM para contar esa historia a los clientes. La función que llegó a ser estratégicamente importante porque recopilaba contexto y difundía claridad se abstrajo a sí misma en torres de marfil cada vez más altas.

Pero la verdad real está en los modelos de datos de tus sistemas, en las llamadas de ventas, en los tickets de CX, en los análisis – no en el bonito 2x2 hecho para simplificarlo todo.

Todo el tiempo que pasas jugando a la gestión significa que tu comprensión innata de los problemas se está volviendo obsoleta, tus instintos para tu cliente se vuelven más torpes, la probabilidad de que tengas razón está cayendo.

Nuestro promedio de bateo como función cayó tanto porque el denominador se expandió COMO porque su expansión significó que todos los que eran buenos en producto hace siete años fueron promovidos fuera de hacer cualquier trabajo real (o se hicieron lo suficientemente ricos como para que el incentivo de quedarse y hacer política fuera bajo).

El Camino Whatnot

Desde sus inicios, el equipo de producto de Whatnot se ha construido sobre una premisa algo simple: lamentamos que exista la gestión de producto. Ventas e ingeniería se llevaban bien antes de que nos contrataran, así que donde puedan, deberían enviar sin trabas procesales ni papeleo sin sentido. El producto es un oficio, no una calificación. Cualquiera que lo haga bien aprendió haciendo y estando cerca de grandes personas que lo hacen.

Recientemente estuve en una entrevista donde alguien me dijo que Whatnot se sentía como si Twitch y eBay hubieran tenido un bebé – culturalmente no podría estar más equivocado, pero en términos del alcance del producto es una comparación decente. Una estimación conservadora dice que esas dos organizaciones combinadas tienen >400 PMs. Nosotros tenemos 20. 20 PMs para más de 1200 empleados totales.

Nuestros PMs están asignados a problemas, no a EMs. Esos dos a menudo se superponen, pero no son lo mismo. Si estás construyendo un nuevo formato de venta para vendedores de moda, vas a estar bastante mano a mano con los EMs que manejan cómo funcionan los listados y el inventario, pero igualmente con los EMs de logística y pagos.

Tener que trabajar a través de múltiples stacks y sopesar impactos en diferentes clientes no es fácil – requiere un contexto amplio del negocio, la capacidad de prever impactos aguas abajo de cambios en cualquier función, destreza en el cambio de contexto, la capacidad de construir y gastar confianza en toda una organización en lugar de con un solo socio. Por eso contratamos casi exclusivamente PMs senior. PMs que están hartos de reuniones interminables de alineación y ansiosos por construir de nuevo. O convertimos a personas prometedoras de ventas u operaciones y les dejamos aprender haciendo. Siempre estamos buscando al contratado de mitad de carrera L5/L6 que es un hoyo en uno, pero las estadísticas no mienten sobre lo raro que es encontrarlos.

Finalmente, todos envíamos, incluyéndome a mí. Siempre estoy trabajando directamente con un equipo de ingenieros y diseñadores para lanzar funciones como IC, y también lo hacen nuestros dos cofundadores. Cuando llegó el momento de probar si era factible que los PMs hicieran vibecode de funciones pequeñas, fui el conejillo de Indias. Cuando llegó el momento de incorporar a nuestro primer vendedor en Australia, fue nuestro cofundador Logan quien lo hizo. Cuando Zendesk empezó a dejar caer tickets de clientes, fue nuestro CEO Grant quien habló con su ingeniero de soporte.

Como empresa, exigimos que cada empleado venda, compre y haga tickets de CX o les damos una calificación por debajo de las expectativas. Si los PMs van a liderar en una empresa con ese compromiso con la centralidad en el cliente, tenemos que estar profundos en cómo funcionan las cosas y amplios en el por qué. Lo llamamos "ser en forma de T" – tener amplitud de contexto y profundidad en tu área, simultáneamente. La profundidad y la experiencia te permiten tomar decisiones rápidamente, no tener que esperar a que 5 capas de gestión lo revisen significa que esas decisiones se convierten en acciones.

Miembros del Personal Técnico

Hay tanto ruido ahora sobre "construir"... No, los documentos de requisitos de producto no están muertos. Un PRD es solo un recipiente para pensar claramente sobre un problema y articularlo a otros. Hazlo interactivo si quieres, a nadie le importa. No, el costo de lanzar un producto malo no ha llegado a cero, todavía lo pagan tus clientes. Lanzar espagueti a la pared 16 veces más rápido no es, de hecho, una revolución, es simplemente molesto. Y no, todo el mundo no va a ser un S-tier de Ingeniería, Diseño y PM todo en uno. Algunas personas lo serán, pero los mismos impulsores de la especialización – lo que la gente disfruta y en lo que es buena – seguirán impulsando cómo trabajamos.

Lo que está cambiando es la realización de que ser un IC es una forma mucho mejor de usar las habilidades, la experiencia y el tiempo limitado de muchas personas en esta tierra que redactar el mismo documento por quinta vez para ajustarse al formato preferido de los pedantes actuales. Algunos PMs en Whatnot son gerentes, pero cada uno de ellos pasa el 90%+ de su tiempo como IC. No hay distinción en nuestros títulos o compensación para aquellos que gestionan o no, porque no vemos ninguna virtud inherente en ello. La IA nos da un apalancamiento increíble – puedo moverme más rápido en casi cada tarea del proceso de desarrollo, ya sea entender datos que solían requerir un científico de datos para desenredar o convertir un PRD en cada permutación de SOPs de CX que normalmente serían el tema de largas noches en la oficina en la semana de lanzamiento. Puedo construir un bot para triar las 100 preguntas semanales de ventas o para encontrar las brechas de localización que dejamos en un experimento reciente.

Lo más disruptivo de la IA para los PMs es que ha mostrado que el apalancamiento de entrenar a personas y trabajar a través de ellos ya no es la fuente singular de apalancamiento que solía ser. Especialmente si esas personas son – sin culpa propia – profundamente promedio. Pero ese apalancamiento solo está disponible para personas que todavía saben hacer el trabajo.

Lo que es especialmente alentador de esta tendencia es que va a atraer a los mejores PMs de vuelta a hacer trabajo real de PM. Pensar en las necesidades del cliente y el negocio y el buen gusto para resolverlo de la mejor manera. Como cliente de otras empresas, estoy emocionado de ver a las luminarias de nuestra industria volver a construir – va a hacer que sus productos sean mejores. Como alguien obsesionado con construir el equipo de PM más pequeño y altamente apalancado de la historia, estoy emocionado de que libere a los increíbles humanos que han estado haciendo acto de presencia en las revisiones de roadmap durante media década.

Muestra, no digas

A continuación voy a copiar (completo) el único documento que tenemos sobre cómo trabajamos en Producto en Whatnot. Si nos hemos reunido aunque sea una vez, no necesitarás que te diga quién es el autor – así es como hablamos y cómo trabajamos.

También puedes ir a ver quién trabaja en nuestro equipo – hay al menos seis personas en el equipo hoy que podrían ser CPO de una startup serie B-C que pasarán su noche al teléfono con vendedores, 400 consultas en un Hex Thread o redactando comunicaciones v1 para el lanzamiento de mañana. Son cuatro ex fundadores que nunca en su vida han aceptado que algo está fuera de su ámbito. Son cuatro ex directores de FAANG que ya no pasan sus días debatiendo sobre dónde debería vivir la gente en una cuadrícula de nueve casillas. Son seis PMs de etapa temprana con un gusto increíble, a quienes se les dice que necesitan probar más cosas porque solo aprendemos haciendo.

Dudo que nuestra declaración de máximo 20 PMs dure – la oportunidad frente a nosotros en Whatnot es tan enorme que no nos limitaremos arbitrariamente – pero el listón para a quién contratamos solo subirá a medida que la industria y las herramientas de IA sigan recompensando a los grandes ICs con apalancados con apalancamiento. Si eres una de esas personas, y lo que he descrito arriba es lo que te motiva, encontrarás la manera de ponerte en contacto conmigo.

Construir en Whatnot

Construir grandes productos es difícil. No es solo que tengas que tener la visión correcta del problema, obtener los detalles correctos, llevarlo al mercado correctamente, medirlo correctamente para entender su rendimiento o iterar rápidamente. Es que tienes que hacer todas esas cosas o no funciona. Peor, fallar es caro. Tenemos pocos equipos y una enorme cantidad de oportunidad frente a nosotros – batear .300 es genial si juegas en las MLB, pero para realizar nuestras aspiraciones necesitamos cerca de .500. Sin un promedio alto, o limitamos el crecimiento a corto plazo o acoplamos el crecimiento del negocio al crecimiento del headcount y nos limitamos a largo plazo.

Este documento tiene 2 partes:

1. Nuestra filosofía – esto no cambiará
2. Nuestros procesos – estos evolucionarán y el estado actual se mantiene aquí

Cómo construimos nos da apalancamiento

No puedes construir un edificio habitación por habitaciones, tienes que diseñar todo el edificio completo y construirlo todo a la vez. Afortunadamente, no trabajamos en construcción, trabajamos en software. Construir iterativamente es nuestra superpotencia. Siempre lanzamos la unidad más pequeña que proporciona valor real al usuario y una experiencia de usuario sólida, pero diseñamos las cosas más allá para asegurar que podemos escalarlo.

El camino feliz de un producto exitoso aquí sigue 7 pasos consistentemente:

1) Es algo que importa para los usuarios y nuestro negocio

Prioriza implacablemente las cosas más impactantes que resuelvan las necesidades de nuestros usuarios y del negocio.

• Debes poder articular ese valor explícitamente "permitir a minoristas escalados vender productos almacenados en múltiples ubicaciones en un solo show – actualizando 'se envía desde' para que sea un campo de producto, no un campo de show"
• Piensa en el sistema.

1. ¿Es este producto inmediatamente valioso cuando se lanza?
2. ¿Es un 'bloque de construcción' para otras cosas?

Si (1) no es cierto, no procedas. Si (1) es cierto, trabaja en cómo puede convertirse en (2) con el tiempo.

2) Es algo que la gente quiere

Entiende sus puntos débiles, deseos y comportamientos para crear un producto para ellos.

• No lo sabes a menos que entiendas al usuario para el que estás construyendo en detalle. Combina cualitativo y cuantitativo.
• Piensa en tu producto en el contexto del flujo de trabajo existente.
• No superpongas basura.
• No explotes un flujo de trabajo que resuelve el problema B porque estás enfocado en el problema A
• Si el problema es real – ¿sabes cómo lo están solucionando hoy?
• Cuidado con los objetos brillantes. Especialmente los objetos brillantes que has construido en otro lugar en el pasado.

3) Las necesidades del cliente no se alinean con nuestros organigramas / nunca se satisfacen con una sola función.

Si estás construyendo localmente, estás construyendo ingenuamente.

• Debes trabajar desde una experiencia completa del cliente, no desde el código. Ve a resolver el problema, punto.
• Lo inverso también es cierto – otros PMs necesitarán empujar en "tu área". Ayúdalos.
• Este principio es por qué nos esforzamos por tener el equipo de Producto y Diseño más pequeños posible. Cuantas más personas cuyo rol está definido estrechamente, más miopes se vuelven los roadmaps y más tiempo perdemos en coordinación y consulta.

4) Es la solución más simple posible que resuelve el problema.

La clave para construir productos rápidos y confiables que los usuarios amen es evitar trabajo innecesario y sin impacto

• Simple no solo es rápido de construir, también es típicamente el más exitoso.
• Pensar en el sistema no significa construir todo el sistema de antemano.
• Cuanto más construyas antes de saber que tienes razón, más caro es cuando te equivocas.

5) Fue validado con la audiencia más pequeña posible.

Solo estás adivinando hasta que alguien lo está usando.

• Pon prototipos de papel o interactivos en manos de los vendedores lo antes posible. El dogfooding del personal detecta errores mejor que valida una solución porque no somos nuestros clientes.
• Piensa en tu movimiento de GTM
• Productos orientados a vendedores: Comienza con <10 vendedores, escala por cantidad de vendedores o a unas pocas categorías antes de pasar a GA.
• Productos orientados a compradores: Comienza con una categoría o un pequeño % y aumenta con señal.
• Productos de ecosistema (visibles para ambos): Comienza con una categoría o un mercado pequeño
• Si estás en modo de validación, resolver la conciencia (interna o externa) es un modo de fallo.
• Es tan subescala que realmente no impacta a las personas
• No sabes si va a funcionar todavía – no pierdas el tiempo de la gente

6) Una vez validado, lo iteramos como locos.

Una vez en vivo para los clientes, estamos enviando mejoras semanalmente si no diariamente.

• Si escuchas "una vez que enviemos X podemos pasar a Y" es una bandera roja gigante.
• Una vez que sabemos que va a ser algo, debes volver y resolver para Catex y CX
• Lanza, valida, mide, itera, itera, itera > luego pasa a la siguiente prioridad.

7) Atravesamos paredes una vez en beta

Conseguir una chispa es difícil. Una vez que tienes una, tienes que echarle combustible o se apagará.

• El mayor riesgo de lanzar productos híper simples e híper tempranos es que están incompletos y por lo tanto no son realmente útiles a largo plazo. Una vez que lanzas, estás contra el reloj para pasar de alto potencial a alto impacto.
• Concéntrate en maximizar el valor que estás creando y no en gestionar cada pequeña queja, riesgo o repercusión.
• Determinar qué quejas, riesgos y repercusionesiones preocuparse es una cuestión de juicio para cada lanzamiento. Preocuparse por los no riesgos es tan peligroso como no preocuparse por ellos

8) Esto no es el soltero – desacopla todo

Hay una tendencia natural al diseñar un sistema de querer enviar múltiples partes a la vez. En un sistema suficientemente complejo como el nuestro, es probable que múltiples equipos estén trabajando en componentes de un sistema en paralelo y puede parecer sensato enviarlos juntos para que sea un gran cambio en lugar de dos. También es una trampa.

• Siempre que cada pieza sea independientemente viable y beneficiosa para los clientes, lánzalas lo antes posible
• Nos permite medir cada una más efectivamente y entender sus contribuciones relativas
• Dejar productos beneficiosos esperando en staging por otro es malo para los clientes

El papel de las revisiones y la retroalimentación

Hemos documentado un proceso de producto cuyo propósito es asegurar que estamos trabajando en las cosas correctas y de la manera correcta. Esto incluye funciones de visibilidad, aprobación y responsabilidad. Más importante que adherirse ciegamente a ese proceso es internalizar la filosofía subyacente – que está bien articulada en este hilo de Twitter… (en serio, léelo antes de continuar)

1. En un sistema complejo necesitas mucha más alineación de la que piensas para llegar a la respuesta correcta. Porque esa palabra puede ser malinterpretada:
2. Alineación nunca significa consenso. El consenso es enemigo de la buena toma de decisiones.
3. Alineación no significa acoplar flujos de trabajo. La coordinación es enemiga de la velocidad.
4. La prueba de fuego de la alineación – un plan escrito. Si Grant está pidiendo uno, no estamos alineados.
5. La autonomía en Whatnot es autonomía de implementación. Nadie tiene o debe esperar autonomía de estrategia. Sin alineación, la autonomía se desperdicia.

Para cumplir con las expectativas en Whatnot, un PM o Diseñador

1. Identifica cosas que necesitan alineación inmediatamente y las busca activamente
2. Se mueve rápidamente de la alineación a la implementación porque entienden profundamente la discusión y la alineación. No escuchan un 'sí' en las discusiones.
3. Puede llenar los detalles de implementación con su equipo / desbloquear rápidamente decisiones que siguen a la alineación.

Por qué la Velocidad Importa

Todo nuestro sistema está premisado en maximizar la velocidad de enviar lo correcto. Los pasos 1-3 del camino feliz son sobre descubrir qué creemos que es lo correcto, 4-7 sobre cómo validamos, iteramos y escalamos eso. Hacemos eso porque:

1) Todo en nuestro sistema se compone – lo bueno y lo malo

En 2025 ejecutamos 750 experimentos en aproximadamente 250 días hábiles, lo que resulta en aproximadamente 3 decisiones de enviar/no enviar por día. Si simulas el impacto a largo plazo de tomar cada una de esas decisiones solo 3 días calendario más rápido, el impacto en un horizonte de 2 años es >$1.1B de ganancias incrementales para los Vendedores de Whatnot. No el impacto de esos productos, solo el impacto de tomar esas decisiones fraccionalmente más rápido. Cada retraso en enviar lo correcto daña a nuestros clientes, y cuanto más grandes nos hacemos, mayor es el costo de oportunidad/costo de la velocidad.

2) Una vez que se pierde la velocidad, nunca regresa

Los humanos naturalmente se conforman y llegan a confiar en los procesos, por lo que incluso los inventados para casos de uso estrechos se aplican más liberalmente de lo previsto. Los incentivos se desplazan a seguir el sistema en lugar de tener el impacto que el sistema fue diseñado para asegurar, y la memoria muscular de la organización para "saber, pero ir" se atrofia y se pierde. Casi no hay un solo error que podamos prevenir que valga la pena a largo plazo para ralentizar la velocidad con la que construimos.

3) La velocidad no es la razón de los errores/fallos

Los comités solo previenen errores como subproducto de prevenir el progreso. El juicio es lo que realmente previene errores. Enviar con más frecuencia construye nuestro juicio – como un atleta, nos fortalecemos con las repeticiones. Mientras construyen repeticiones, los equipos pueden aprovechar el juicio de aquellos con más repeticiones y más contexto – orientación continua ad hoc de los líderes de producto, visibilidad para mitigaciones de riesgos clave como legal y comunicaciones en las etapas más tempranas de la planificación (si hay huracanes que evitar en el Atlántico, necesitamos saberlo cuando estamos trazando el rumbo, no cuando zarpamos), líderes de categoría o país que puedan proxy cómo reaccionarían clientes específicos. Como parte de pensar en el sistema, los PMs deben buscar anticipar los impactos de sus lanzamientos, pero nunca están limitados ni por haber buscado, ni por tomar cualquier retroalimentación o entrada que reciban. La revisión de producto es la única puerta en nuestro proceso de desarrollo.