Construcción y otros temas

En los últimos dos años, 31,832 personas solicitaron ser Gerente de Producto en Whatnot. Contratamos a una. Tienes el doble de probabilidades de hacer un hoyo en uno que de conseguir un trabajo solo con postularte.

Eso no es una falla del proceso. He estado construyendo productos — y equipos de producto — por más de una década y uno de los factores más importantes para decidir para decidir venir a Whatnot hace ~3 años fue la cultura de producto muy deliberada. Nadie sabe qué significa ser PM en el mundo de la IA, pero todo lo que veo dice 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ó en respuesta a la escala — los equipos de ingeniería se volvieron demasiado grandes para que los CEOs o GMs los gestionaran directamente, así que se necesitaba un conducto entre negocio y tecnología. Con el tiempo generalizamos perezosamente el rol a "cargo 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 poder, a su vez, crecer ellos mismos 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ó el COVID y la industria contrató una cantidad alucinante 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 realmente sucede, enseñados a hacer PM con libro de colorear por números en una escuela de producto, en una era de crecimiento de engagement inmerecido donde aparentemente todo funcionaba.

La probabilidad de que alguien surja de todo eso con excelentes instintos de producto, experiencia y determinación parece en realidad 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. Eso no les gusta y lo etiquetan como microgestión en una encuesta anónima, así que te echas atrás. ¿Entonces cómo gastas tu tiempo? Cuentas historias, guías las cosas a través de revisiones para que tus equipos estén 'teniendo éxito', justificas recursos. Pero no sabes qué historia contar, así que creas una historia, así que creas un equipo de investigación de usuarios que te diga los trabajos por hacer, y luego una función de PMM que cuente esa historia a los clientes. La función que llegó a ser estratégicamente importante porque reunía 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 la analítica — no en la bonita matriz 2x2 hecha 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 más opacos, 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 todos los que eran buenos en producto hace siete años fueron ascendidos 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).

La forma Whatnot

Desde sus inicios, el equipo de Whatnot se ha construido sobre una premisa algo simple: lamentamos que la gestión de productos exista. Ventas e ingeniería se llevaban muy bien antes de que nos contrataran, así que donde puedan, deberían simplemente lanzar sin barreras 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 haciéndolo.

Estaba en una entrevista recientemente donde alguien me dijo que Whatnot se sentía como si Twitch y eBay hubieran tenido un bebé — culturalmente no podría ser más incorrecto, pero en lo cultural, 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 en total.

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

Tener que trabajar en 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 los 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 esa contratación de nivel medio L5/L6 que es un hoyo en uno, pero las estadísticas no mienten sobre lo seguido que los encontramos.

Finalmente, todos lanzan, 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 "vibecodearan" funciones pequeñas, yo fui el conejillo de indias. Cuando llegó el momento de incorporar manualmente 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 gestione tickets de CX o les damos 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 profundamente en cómo funcionan las cosas y ampliamente 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 niveles de gestión lo revisen significa que esas decisiones se convierten en acciones.

Miembros del Personal Técnico

Hay mucho ruido ahora mismo sobre "construir"... No, los documentos de requisitos de producto no están muertos. Un PRD es solo un vehículo para pensar con claridad sobre un problema y articularlo a otros. Hazlo interactivo si quieres, a nadie le importa. No, el costo de lanzar un mal producto no ha llegado a cero, todavía lo pagan tus clientes. Tirarles espagueti 16 veces más rápido no es, de hecho, una revolución, es simplemente molesto. Y no, no todos van a ser un ingeniero, diseñador y PM de nivel S todo en uno. Algunas personas lo serán, pero los mismos impulsores de la especialización — lo que la gente disfruta y se le da bien — seguirán impulsando cómo trabajamos.

Lo que está cambiando es la realización de que ser un IC es un uso mucho mejor de muchas habilidades, experiencia y tiempo limitado en esta tierra que redactar el mismo documento por quinta vez para ajustarse al formato preferido del pedante de turno. Algunos PMs en Whatnot son gerentes, pero cada uno pasa el 90%+ de su tiempo como IC. No hay distinción en nuestros títulos o compensación para los 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 largas en la oficina durante 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 demostrado 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 aún 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 del 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 mejorar sus productos. Como alguien obsesionado con construir el equipo de PM más pequeño y más apalancado de la historia, estoy emocionado de que libere a los increíbles humanos que han estado haciendo reseñas de roadmap por teléfono durante media década.

Muestra, no cuentes

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 en el equipo que podrían ser CPO en una startup Serie B-C que pasarán su noche al teléfono con vendedores, 400 consultas de profundidad en un Hex Thread o redactando comunicaciones v1 de comunicaciones para el lanzamiento de mañana. Son cuatro exfundadores que nunca en su vida han aceptado que algo está fuera de su ámbito. Son cuatro exdirectores de FAANG que ya no pasan sus días debatiendo 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 un máximo de 20 PMs dure para siempre — la oportunidad que tenemos por delante en Whatnot es tan enorme que no nos limitaremos arbitrariamente — pero el estándar para a quién contratamos solo aumentará a medida que la industria y las herramientas de IA continúen recompensando a los grandes ICs 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.

Construyendo en Whatnot

Construir grandes productos es difícil. No es solo que tengas que tener la visión correcta del problema, acertar en los detalles, llevarlo al mercado correctamente, medirlo adecuadamente para entender su rendimiento o iterar rápidamente. Es que tienes que hacer todas esas cosas o no funciona. Peor aún, fallar es caro. Tenemos pocos equipos y una cantidad masiva de oportunidad frente a nosotros — batear .300 es genial si juegas en las MLB, pero para alcanzar nuestras aspiraciones necesitamos cerca de .500. Sin un promedio alto, restringimos el crecimiento a corto plazo o acoplamos el crecimiento del negocio al crecimiento del headcount y nos restringimos 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 habitación, tienes que diseñar todo el edificio a la vez y construirlo todo a la vez. Afortunadamente, no trabajamos en construcción, trabajamos en software. Construir iterativamente es nuestro superpoder. Siempre lanzamos la unidad más pequeña que proporcione valor real al usuario y una experiencia de usuario sólida, pero diseñamos las cosas más allá para asegurar que podamos escalarlas.

El camino exitoso de un producto aquí sigue 7 pasos de manera consistente:

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

Prioriza sin piedad las cosas que tengan el mayor impacto y resuelvan las necesidades de nuestros usuarios y del negocio.

• Debes poder articular ese valor explícitamente: "permitir a los 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 lance?
2. ¿Es un 'bloque de construcción' para otras cosas?

Si (1) no es cierto, no continúes. Si (1) es cierto, averigua cómo puede convertirse en (2) con el tiempo.

2) Es algo que la gente lo quiere

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

• No lo sabes a menos que entiendas en detalle al usuario para el que estás construyendo. Combina cualitativo y cuantitativo.
• Piensa en tu producto en el contexto del flujo de trabajo de producto existente.
• No superpongas basura.
• No destruyas 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 lado en el pasado.

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

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

• Debes trabajar desde una experiencia completa del cliente, no de la propiedad del código. Ve y resuelve el problema, punto.
• Lo inverso también es cierto — otros PMs necesitarán incursionar en "tu área". Ayúdalos.
• Este principio es por lo que nos esforzamos por tener el equipo de Producto y Diseño más pequeño posible. Cuantas más personas cuyo rol esté definido de manera estrecha, 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, sino que suele ser también el más exitoso.
• Pensar en el sistema no significa construir todo el sistema por adelantado.
• 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 de lo que valida una solución porque no somos nuestros clientes.
• Piensa en tu estrategia de GTM
• Productos para Vendedores: Comienza con <10 vendedores, escala por cantidad de vendedores o a unas pocas categorías antes de pasar a GA.
• Productos para Compradores: Comienza con una categoría o un pequeño porcentaje y escala 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 para la conciencia (interna o externa) es un modo de fallo.
• Es tan subescala que en realidad no impacta a nadie
• Aún no sabes si va a funcionar — no pierdas el tiempo de la gente.

6) Una vez validado, iteramos como locos.

Una vez que esté en vivo para los clientes, estamos lanzando mejoras semanalmente, si no diariamente.

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

7) Atravesamos paredes una vez que estamos 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 verdaderamente útiles a largo plazo. Una vez que tienes el reloj en contra 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 repercusiones 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 "The Bachelor" — desacopla todo

Hay una tendencia natural al diseñar un sistema de querer lanzar 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 lanzarlos 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 de manera más efectiva y entender sus contribuciones relativas
• Dejar productos beneficiosos esperando en staging por otro es malo para los clientes

El rol de las revisiones y la retroalimentación

Tenemos documentado un proceso de producto cuya intención es asegurar que estamos trabajando en las cosas correctas y de la manera correcta. Esto incluye funciones de visibilidad, aprobación y rendición de cuentas. Más importante que adherirse ciegamente a ese proceso, sin embargo, 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 crees 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 ni 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 las cosas que necesitan alineación inmediatamente y la busca activamente
2. Pasa rápidamente de la alineación a la implementación porque entiende profundamente la discusión y la alineación. No escucha buscando 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 se basa en maximizar la velocidad de lanzar lo correcto. 1-3 del camino feliz se tratan de determinar qué creemos que es lo correcto, 4-7 de 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 equivale a aproximadamente 3 decisiones de lanzar/no lanzar por día. 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 lanzar lo correcto perjudica a nuestros clientes, y cuanto más grandes nos hacemos más grandes, más la oportunidad/costo de la velocidad.

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

Los humanos naturalmente se conforman y llegan a depender de los procesos, por lo que incluso los inventados para casos de uso estrechos se aplican de manera más liberal 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 actuar" se atrofia y se pierde. Casi no hay un solo error que podamos prevenir que sea un buen intercambio a largo plazo por 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 los errores. Lanzar 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 del liderazgo de producto, visibilidad para mitigaciones de riesgos clave como legal y comunicaciones en las etapas más tempranas de 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 actuar como proxy de cómo reaccionarán clientes específicos. Como parte de pensar en el sistema, los PMs deben anticipar los impactos de sus lanzamientos, pero nunca están limitados por haber buscado, o por tomar, cualquier retroalimentación/input que reciben. La revisión de producto es la única puerta en nuestro proceso de desarrollo.