Gerentes de producto: ¿Cuál es la etapa más difícil en el desarrollo de productos y por qué?

Esta es una pregunta difícil de responder directamente. Creo que puede tener diferentes respuestas según los tipos de productos. Supongamos que está en el campo de la tecnología, y no en bienes de consumo envasados.

Si usted es una empresa de hardware, hay desafíos únicos que deben abordarse durante las primeras etapas de diseño y construcción. ¿Se pueden construir las partes? ¿Las especificaciones mecánicas son demasiado estrictas? ¿Qué hay de las especificaciones de componentes electrónicos? (Un producto que administré tenía una ruta de entrada analógica muy sensible que tenía una resistencia de especificación súper crítica). ¿Se puede documentar adecuadamente el proceso de compilación? ¿Qué pasa con los problemas de la cadena de suministro? ¿Algún componente fuente crítico único? ¿Dónde lo construirás, en casa o en un fabricante por contrato? ¿Qué pasa con los márgenes, lo que es aceptable? ¿Existe un camino hacia la reducción a largo plazo de los costos para ayudar con la presión de precios que enfrentará aún más en el ciclo de vida? Para mí, estos problemas son la parte difícil del lado del hardware.

Si su producto es principalmente software, tiene diferentes desafíos. No es sorprendente que la cartera de características del producto de los clientes y la traducción a un plan viable para el equipo de desarrollo. Enfrentar las múltiples rutas de entrada (la prioridad más alta de los clientes es directa, las ventas son mucho más bajas y el resto en algún punto intermedio). Sin embargo, equilibrar las prioridades con las facciones políticas puede ser una tarea muy desafiante y potencialmente un campo minado para navegar. .

En cuanto a la parte más frustrante del proceso, en ambos tipos de productos, el proceso de prueba Beta. Para el lado del software, supongamos que el producto es un producto de clase empresarial. En un producto de hardware, una prueba beta puede ser difícil por varias razones. Primero, si se descubren fallas importantes de diseño (que no se detectaron durante los ciclos de construcción de prototipos y alfa), puede haber costos de reelaboración significativos tanto en tiempo como en dinero. Por lo tanto, la tendencia es pasar más y más tiempo en los primeros ciclos para atraparlos y prevenirlos. Sin embargo, esto no es una panacea, ya que a menudo comprimirá el programa permitido para las pruebas beta. Es realmente importante establecer también las expectativas dentro y fuera de la organización para el costo y las implicaciones de tiempo de las pruebas. Suponga que regalará o venderá por debajo del costo a los primeros beta testers, una suposición que puede ser difícil de justificar para la alta gerencia.

En una oferta de software, las pruebas beta son diferentes. Primero para el mundo empresarial, generalmente hay un buen grupo de candidatos, y es probable que tengan entornos de prueba, por lo que no tienen que arriesgar los sistemas de producción para probar el software. Sin embargo, esta clase de clientes generalmente tiene un riesgo adverso y, si bien pueden estar dispuestos a probar lo último y lo mejor, la probabilidad de que adopten (y sean socios de lanzamiento) es relativamente baja. Por lo tanto, usted como gerente de producto pasará una cantidad excesiva de tiempo administrando los detalles tácticos e intentando extraer valor del proceso.

Para mí, estos siempre han sido la parte más difícil del proceso de desarrollo de productos.

     

Advertising Here

Descubrir que la hipótesis de su producto no era válida cuando su producto se está acercando a perder la financiación para continuar.

Pensaste que tu producto iba a tener éxito haciendo X, pero las pruebas han revelado que X no funciona. Todavía te apasiona el producto y estás decidido a hacerlo funcionar. Tiene tiempo para una iteración más antes de que el producto pueda ser eliminado. Que deberias hacer

¿Deberías seguir golpeando la fórmula original con la esperanza de desbloquear algo mágico? ¿Quizás una cosita te llevará a un punto de inflexión?

¿Deberías probar algo radicalmente diferente? ¿Qué elementos anteriores guardas? ¿Cuáles tiras?

O tal vez necesites más tiempo. ¿Debería intentar extender la pista del producto complaciendo a las personas que le dan dinero o la compra ejecutiva? ¿Tal vez puedas deslumbrarlos con algo brillante que sabes que es una mierda?

Si el producto se mata, ¿sentirá que le dio la mejor oportunidad de tener éxito o se sentirá torturado para siempre por la dirección del producto que nunca intentó?

Si haces el movimiento correcto, aún puedes pegar un jonrón.

La verdad es que hay momentos desafiantes de cada sección del viaje,
ya sea que esté adoptando el ciclo Lean de Build -> Measure -> Learn, o la progresión más tradicional Discover -> (Design & Develop) -> (Maintain || Evolve || Sunset).

Ninguna sección es más difícil que la siguiente; simplemente requieren diferentes tipos de pensamiento para hacer el trabajo.

He expuesto algunas de las partes más complicadas de cada etapa del ciclo de vida, tal como las he experimentado, y espero algún consejo para evitarlas.

PUNTOS DIFÍCILES AL PRINCIPIO
Digamos que recién está comenzando, y tiene una idea de producto que PIENSA que resolverá un problema en particular, o tiene un problema grave que aún no tiene la respuesta.

Uno de los principales desafíos para los gerentes de producto en mi experiencia es simplemente alejarse de su gran idea nueva y preguntarse: “¿Es este el problema correcto para resolver para nuestros clientes / audiencia?”. A veces, simplemente reformular el problema desde el punto de vista de un grupo diferente de clientes revela una mayor necesidad en otro lugar.

Centrarse demasiado al principio es otra trampa. Todos estamos realmente entusiasmados con nuestro último concepto, y es tentador apresurarnos a especificar en el enésimo grado exactamente cómo funcionará una solución. Solo no lo hagas. No por mucho tiempo. Mantén la cabeza en alto, explorando el paisaje en busca de alternativas, comparaciones, nuevas oportunidades de experimentación. Cambiar la idea en múltiples prototipos (baja fidelidad si es posible) es infinitamente más valioso.

Demasiados datos históricos por adelantado. Finalmente, descubrí, especialmente con empresas maduras, grandes y con un conjunto de productos que ya utilizan muchas personas, que se dedica demasiado tiempo en las primeras etapas del desarrollo a analizar datos antiguos. El problema con eso es que solo aprenderás a ajustar. Nunca sabrás cuándo subir palos y pasar al próximo pasto.

PUNTAS DIFÍCILES AL CREAR
Contratando a las personas adecuadas. Este es el paso más fácil para equivocarme, y tendrá un efecto tan dramático en el resultado final.

Trabajando UX en un equipo ágil. Nunca he conocido un matrimonio perfecto entre personas de diseño / UX e ingenieros en un entorno ágil. Hay frecuentes disputas, quejas sobre los desarrolladores que no ven el panorama general y quejas sobre los diseñadores que intentan sobre pulir lo que debería ser un prototipo aproximado y listo. Hágase un favor y dele a su equipo de diseño un proceso con el que puedan vivir; hornee a tiempo para pensar en el diseño y mantenga al equipo de diseño comprometido durante todo el ciclo de desarrollo. Y asegúrese de que los diseñadores asistan y participen en retrospectivas y demostraciones de fin de carrera.

Agregar cambios de las pruebas de usuario. Su equipo de desarrollo acaba de terminar una nueva versión brillante de su producto y desea que se envíe. Mientras tanto, ha probado la versión con los usuarios, y existen problemas fundamentales con la experiencia que deben clasificarse. Los gerentes de producto deben tener tacto al equilibrar la necesidad de escuchar los comentarios con la pragmática de la entrega, pero nunca es fácil.

PUNTOS DIFÍCILES CUANDO ESTÁS ARRIBA Y CORRIENDO
No se puede enseñar la intuición, solo se puede absorber a través de años de exposición tanto al fracaso como al éxito. Algunos de los momentos más difíciles en el ciclo de vida del producto son cuando se le llama a defender su intuición con datos. La gerencia de negocios quiere hechos, evidencia y datos para respaldar sus afirmaciones de que la función X mejorará la conveniencia del producto para los clientes Y, o que tal y tal enfoque es el correcto para emplear. Y con razón. Tienes el presentimiento de que algo funcionará y mejorará la experiencia de tus clientes de una forma u otra, pero no puedes probarlo (un poco como probar la eficacia de algunos tipos de publicidad). Y cuanto más tiempo se pasee buscando la prueba, más tiempo perderá sacando su idea al mercado y probada.

Eric Reis podría decir que solo haga llegar ese experimento a los clientes, un pequeño lote controlado de ellos para comenzar, y pruébelo de esa manera. Pero a veces es difícil argumentar el caso para cambiar dramáticamente la táctica sin evidencia por adelantado. Saber cuándo pivotar es difícil si no puedes probar tus hipótesis.

BIT DIFÍCIL ALREDEDOR DEL LANZAMIENTO
Cuando lanzas un producto, te miden en muchos niveles. ¿Su producto cumplirá las promesas de su comunicado de prensa / página de bienvenida? ¿Su producto resistirá su uso? ¿Has explicado lo que el producto hace lo suficientemente bien? El desafío es superar la tormenta de comentarios y comprender qué recomendaciones o quejas seguir. Tener un conjunto riguroso de principios con el que se mide cada comentario es invaluable en este escenario.

MORDIDA DIFÍCIL CUANDO SU PRODUCTO ESTÁ ENVEJECIENDO
Muy pocos datos … el contrapunto al argumento de “demasiados datos” anterior es no tener suficientes datos para tomar las decisiones correctas cuando su producto está envejeciendo, y debe decidir si eliminarlo, mantenerlo o convertirlo en algo nuevo. Si no tiene el conocimiento profundo sobre el uso de su producto por parte de sus clientes, puede hacer la llamada equivocada y vivir en un estado de constante preocupación de que le faltó información suficiente para tomar la decisión correcta.

More Interesting

¿Cómo responde a los clientes cuando plantean errores / problemas en su producto que es probable que no se solucionen de inmediato?

¿Es importante para el propietario de un producto en un equipo Scrum que hace que el software tenga conocimiento técnico?

Cuando la situación del mercado es difícil, ¿es mejor lanzar un producto de gama alta o un producto de gama baja? ¿Por qué?

Al comenzar a desarrollar un producto, ¿cuál es la mejor manera de obtener una base para los aspectos de fijación de precios del producto?

¿Es más valioso desarrollar una API para construir una comunidad de desarrolladores o desarrollar los productos usted mismo?

¿Qué es mejor: hacerlo primero o hacerlo bien?

¿Quién determina en última instancia la aceptación y el éxito de un producto?

¿Cuáles son las mejores aplicaciones alternativas con soporte móvil para Trello?

¿Alguien prueba Craft.io? Necesito tu opinión!

¿Cuáles son algunos ejemplos de cómo se utilizan los datos para justificar malas prácticas de desarrollo de productos?

¿Cuáles son los buenos KPI de desarrollo de productos?

Como gerente de producto, ¿qué métricas considera para evaluar el éxito de su producto de software?

¿Cuáles son algunas de las compañías de TI basadas en productos como Oracle e IBM?

¿Qué debe construir primero al desarrollar su startup: el capital inicial, el producto o el equipo?

Estoy interesado en crear un nuevo producto electrónico para un nicho en particular. Sería similar a otros productos disponibles, pero para un caso de uso diferente. ¿Cómo puedo averiguar quién fabrica estos otros productos para abordarlos y trabajar en mi producto también?