Aspectos a tener en cuenta desde I+D hasta el producto
El pensamiento de ingeniería presta más atención a la eficiencia, las funciones específicas y cómo lograrlas a través de la tecnología. El pensamiento de producto presta más atención a los escenarios, las necesidades de los usuarios y los escenarios detrás de las necesidades. La fusión de los dos tipos de pensamiento significa que no solo se pueden ver las necesidades y escenarios de los usuarios, sino también saber qué tecnologías pueden satisfacer las necesidades de los usuarios. En este proceso, comparto mis tres ideas:
Primero, descubra el PORQUÉ y luego ignore la implementación técnica y piense en el CÓMO.
Cuando los gerentes de producto están creando prototipos de requisitos, primero deben pensar claramente por qué están creando este requisito y luego pensar en el camino para lograrlo y encontrar el camino más corto. En cuanto a las dificultades técnicas internas, su evaluación debe dejarse en manos del personal de I+D. Cuando el personal de I+D se transforma en gerentes de producto, debería estar más inclinado a hacerlo más simple y amigable al implementarlo. En lugar de pensar en cómo hacerlo más simple y mejor implementado. Para planes de implementación técnica específicos, personas con experiencia pueden hacer sugerencias, pero no trasladan sus requisitos al prototipo, y mucho menos afectan su propio diseño de prototipo.
Otro error en el que pueden caer fácilmente los gerentes de productos de I+D es que cuando otros departamentos comerciales hacen demandas y sienten que no pueden cumplirse, responderán: "Esta demanda no puede cumplirse técnicamente. El enfoque correcto es Pregunte al personal de I+D para evaluar el plan de implementación.
En segundo lugar, la finalización es mejor que la perfección.
Muchos técnicos tienen un complejo de perfección, que se manifiesta de dos maneras: una es hacer lo que sea. funciones que quieren. La otra es hacer que la función sea perfecta. Cuando hay múltiples soluciones de implementación, la mejor solución es siempre la más adecuada para una aplicación con decenas de miles de usuarios, diseñando una arquitectura que pueda manejar millones de concurrencias. No es algo de lo que enorgullecerse. La búsqueda de la perfección puede provocar fácilmente retrasos en el lanzamiento del producto. Para los gerentes de producto, garantizar que el proyecto se lance a tiempo es la norma. El producto no teme a los defectos. lo modificaremos repetidamente para la próxima versión.
En tercer lugar, el usuario siempre tiene razón.
Podemos encontrar que una determinada función la hice yo, pero los usuarios no. Úselo. También puede recibir comentarios del departamento de servicio al cliente de que los usuarios de la función XX dicen que no pueden encontrar la entrada o cree que las reglas del evento están escritas claramente, pero los usuarios siguen haciendo preguntas si estos problemas se basan. En las soluciones convencionales, no tendría sentido decirles a los usuarios cómo operarlas. Este es un problema de diseño del producto que debe evitarse desde la fuente, en lugar de pensar que así es como debo operar.