Idea de negocio
En esta página se recoge el feedback proporcionado por el profesor y los compañeros relativo a la idea de negocio en las presentaciones realizadas por los grupos durante las sesiones de clase. El objetivo principal es identificar los puntos fuertes y aspectos a mejorar con el fin de aprender de los errores y mejorar para el futuro.
Feedback del día 07/02
- Tener cuidado con las ideas demasiado ambiciosas.
- Hay que tener muy claro nuestros casos de uso y en quénos diferenciamos de los competidores.
- Invertir una gran cantidad de recursos y tiempo en el análisis de competidores para asegurar una solución competitiva es esencial.
Feedback del día 14/02
- Definir claramente el público objetivo y el modelo de negocio.
- El modelo de negocio debe estar más centrado y especificado.
- Identificar correctamente usuarios y clientes en el modelo de negocio.
- Diferenciar entre cliente y usuario en el modelo freemium.
Feedback del día 21/02
- Profundizar en el modelo de monetización, identificando quién paga realmente y cómo.
- Justificar la estructura de costes e incluir costes sociales con datos de referencia.
- Analizar mejor la percepción del valor del producto y cómo afecta la experiencia del usuario.
- Asegurar que la gestión de riesgos esté alineada con debilidades identificadas en el DAFO.
- Explicar claramente la diferencia principal frente a la competencia.
- Evaluar los costos de mantenimiento y su viabilidad a largo plazo.
- Definir bien la escala del proyecto.
- Asegurar un respaldo económico adecuado para una idea arriesgada.
- No asumir todo el coste de los beneficios sin una estrategia clara.
Feedback del día 07/03
Priorizar volumen de clientes/usuarios para la viabilidad del proyecto.
- Evaluar si el tiempo de respuesta para la devolución del dinero es suficiente, considerando imprevistos.
- Mejorar el análisis de ingresos con un caso realista.
Feedback del día 14/03
- Al explicar las estimaciones, es necesario indicar con qué usuarios se ha validado, así como hacer un mayor énfasis en los porcentajes de suscripción, si procede.
- En los riesgos, hay que decir si son nuevos o son ya identificados. También definir si los problemas son ajenos a los riesgos o no.
- Hay que tener cuidado con los cambios repentinos de planteamiento del producto a mitad del proyecto, sobre todo si generas dudas al explicarlo en las presentaciones.
Feedback del día 21/03
- Realizamos estimaciones de la rentabilidad en términos monetarios, pero estas se basan en la penetración de mercado (cantidad de usuarios absorbidos). Por lo tanto, es fundamental considerar ambas métricas de manera coherente.
- Uso de datos cuantitativos, a los inversores no les basta con decir "Seremos muy rentables", es necesario indicarles cuánto será necesario que aporten, en cuánto tiempo recuperarán la inversión y qué ganancias procederán desde entonces. Todo con datos específicos.
Feedback del día 04/04
- El volumen de mercado debe aparecer en los hitos.
- Es esencial transmitir claramente la funcionalidad principal.
Feedback del día 11/05
- Parte de un problema concreto y relevante.
- Se valida rápidamente con usuarios reales.
- Es clave entender bien al cliente y diferenciarse de lo que ya existe.
Feedback del día 25/05
- A veces se presenta desconectada de la demo o del anuncio, lo que diluye el mensaje.
- En varios casos no se explica claramente cómo se genera dinero o de dónde vienen los ingresos (Grupos 10 y 11).
- Se usa terminología como "aburrimiento crónico" sin respaldarla con fuentes visibles.
- Mostrar problema real, solución clara, modelo de ingresos concreto y conexión con el público objetivo.
Feedback del día 02/05
-
¿El mínimo 16 años no es ser mayor de edad? Es por el mínimo para tener tarjeta. (relacionado con la viabilidad del modelo de negocio según público objetivo).
-
Al hablar de competidores, se deben mostrar todas las funcionalidades que se ofrecen, no solo las que se diferencian.
-
Hubo un grupo que dejó un público objetivo de entre 18 y 35 años. A los profesores les pareció raro, ya que había mucho usuario potencial que se quedaba fuera de ese rango. Lo importante es que si tiene justificación, que la expliquen.
-
Es mejor centrarse en funcionalidades clave, más que aquellas que se entienden que la aplicación va a tener de manera prácticamente asegurada.
-
Revisar periódicamente su actividad debido a que desaparezcan y dejen de serlos. Al contrario, podría surgir un nuevo competidor, esto refuerza la idea de que sea un enfoque iterativo.