Introducción

1

Qué aprenderás sobre crear startups

2

Qué necesitas para crear una compañía

3

Qué se necesita para fundar una Startup

Cómo validar tu idea y lanzarla

4

Cómo hablar con usuarios/clientes potenciales

5

Cómo lanzar tu startup

6

¿Cómo validar tu idea?

7

Landing pages

Entender cómo trabajar con OKRs

8

¿Qué son los OKR?

9

¿Cómo plantear OKR?

10

Herramientas para seguimiento de OKRs

11

Cómo implementar objetivos para equipos de trabajo

Legal

12

¿Por qué los asuntos legales son importantes?

Sales & Revenue

13

¿Por qué las ventas son importantes para las startups?

14

Sales funnel y sales pipeline

15

¿Cómo construir un equipo de ventas eficiente?

16

El modelo de compensación ideal

Aprender sobre Producto y Tecnología

17

¿Cuál es el papel de CTO?

18

¿Cómo construir un equipo de ingeniería?

19

Construir y ejecutar un roadmap de producto de forma eficiente

20

Errores de producto más comunes

Operación

21

El rol del COO y por qué es importante

22

¿Cómo ser un buen COO?

23

Tips y buenas prácticas

Finanzas de una Startup

24

Las finanzas en una startup

25

¿Cómo calcular cuánto puede vivir una startup?

26

Indicadores financieros importantes en early stage

27

Indicadores financieros desde serie semilla hasta series A

28

Indicadores financieros para series A en adelante

Cultura

29

¿Qué es la cultura, misión y valores de una startup?

30

¿Cómo dar feedback honesto?

31

¿Cómo liderar equipos de alto rendimiento?

Priorización

32

Why focus matters for startups

33

Key concepts and misconceptions

34

How to prioritize

35

How to scale a culture of focus

Growth

36

Unit Economics

37

¿Qué es Data Science y por qué es importante?

38

¿Cómo empezar con Data Science?

Fundraising

39

Lo básico que debes saber antes de levantar capital

40

Los principales términos legales que debes saber cuando levantas capital

41

¿Cuánto vale tu empresa?

42

Cómo hacer una IPO de pequeña capitalización

43

Construir una estrategia de levantamiento de capital

44

Información para construir un pitch

45

El storytelling detrás de un pitch

46

¿Cómo aprobar el Taller de Creación de Startups?

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Errores de producto más comunes

20/46
Recursos

Aportes 47

Preguntas 5

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Errores de producto más comunes

1. Construir demasiado pronto

  • Prototipo a MVP a Producto
  • Web y Móvil simultaneo

2. Escalamiento anticipado

  • Dedicar tiempo y recursos en optimizaciones
    -La compañía es demasiado joven para saber qué necesitará en el futuro

  • Distrae del verdadero objetivo: crear un producto que el mercado necesita, ahora

3. Utilizar tecnologías no probadas

  • Dedica recursos al aprendizaje y no a la construcción de features

  • Dificulta iterar rápido

  • Dificulta encontrar soluciones

  • Dificulta el reclutamiento

4. Contratar a los ingenieros incorrectos

  • Ingeniero corporativo

  • Elite computer scientist

  • Ingeniero Junior

  • Ingenieros subcontratados

Conclusiones

  • Responsabilidades de un CTO

  • Como construir equipos de ingeniería

  • Como construir producto

  • Precauciones y posibles errores

Yo fundé hace tiempo una empresa de desarrollo de apps y junto con mi co-founder (CTO) buscamos ingenieros para crear el área de tecnología (in house). La lección aprendida fue que los ingenieros juniors aportaban pero nos tomaba mucho tiempo y esfuerzo poder implementar soluciones en producción y junto con el costo de ingenieros senior, el costo de la nómina estaba fuera de presupuesto.

Yo tuve la experiencia personal de que mi primer trabajo fue en una Startup, al principio me costó mucho adaptarme y fue bastante frustrante no poder hacer muchas cosas porque simplemente no sabía cómo hacerlas. Empecé a aprender rápido y al cabo de unos meses, fui asignado a reconstruir el CORE de una nueva versión de la aplicación, desde cero en Flutter. El CEO y CTO quedaron encantados con el nuevo CORE de la aplicación, logrando así el MVP.

Hoy estoy construyendo mi startup Tutting. Un marketplace para tutores particulares. Lo llaman el “Uber de tutores”.

https://tutting.app/

El caso de la subcontratación me hizo recordar el caso Hertz que vimos en el Curso de Tecnología para Gerentes y Directores.

Porque en aquella etapa, siendo una corporación que tenía que competir con algo como UBER lo más lógico es que hubiesen invertido en poseer un equipo de tecnología interno que pudiera desarrollar, sustentar y hacer viable la transición.

En su lugar decidieron “mandar a hacer” toda la plataforma y el resultado ha sido catastrófico. La empresa encargada de crear la plataforma no cumplió, se paralizo el trabajo, demandas legales, costes en abogados, juicios, además tuvieron que contratar a una segunda empresa… todo un caos.

De haber armado su equipo interno, tuvieran todo listo, más económico y con ADN tecnológico en la corporación.

Es importante saber que equipos son los más sanos en cada etapa.

Funde una institucion de servicios de atención psicológica. Al no tener un capital de trabajo hicimos con mi socia de todo: marketing, web (plantillas), administración, contabilidad y muchos etc. Nos desgastamos. Hoy seguimos, y sobrevivimos. Luego de 13 años ya hemos aprendido que NO hacer. Hoy aprendemos lo sí es saludable y sano para la institución, los clientes y para cada socio.

En la parte de utilizar tecnologías no probadas me siento muy identificado, ya que hace 1 mes en mi agencia, acabamos de desarrollar una app para Android e iOS en Flutter (Dart) y nos dimos cuenta que habían cosas que no estaban al 100% maduras y que era mejor implementarlo en nativo. Además de que lo que el equipo y yo dominamos es iOS y Android nativo. Fue aventarnos a desarrollar nuestras propias librerías como lo que le pasó a David. Pero se aprende de eso, no hay ninguna duda de que se aprende de eso.

El tiempo es el recurso más importante de mi startup.

Me paso lo de el Elite computer scientist, no es que me crea la gran cosa ni nada, pero literalmente mi trabajo era demasiado básico (puros cruds y flujos super aburridos), así que a cada rato hacia todo tipo de handlers y helpers que me ayudaran a quemar tiempo.

Al final esas herramientas que hice ayudaron a todo el equipo, pero la verdad es que no me aguanté y me salí de ahí.

hay ocaciones en las que un ingeniero junior te puede ayudar mucho pero hay casos y casos. buenas recomendaciones para tenerlas en cuenta.

Seria muy bueno un cursp completo de CTO

Esta clase vale orooooooo. Te evita muuuchos dolores de cabeza futuros.

20.-Errores de producto más comunes


Construir demasiado rápido

  • Se debe pasar de prototipo a MVP a Producto. No saltarlos
  • Escoge la plataforma que más usen los usuarios. En mi caso en móvil.


Escalamiento anticipado

  • Dedicar tiempo y recursos en optimizaciones. La compañía es demasiado joven para saber qué necesitará en el futuro. Enfócate en las necesidades presentes.
  • Distrae del verdadero objetivo: crear un producto que el mercado necesita, ahora.


Utilizar tecnologías no probadas

  • Dedica recursos al aprendizaje y no a la construcción de features.
  • Dificulta iterar rápido.
  • Dificulta encontrar soluciones.
  • Dificulta el reclutamiento.


El tiempo es tu única ventaja.


Contratar a los ingenieros incorrectos: en este caso es porque el perfil puede dificultar la adaptación. Tomar a consideración

  • Ingeniero corporativo: Sistemas grandes.
  • Elite Computer Scientist: No necesarios si es una app sencilla, hacen sobre ingeniería.
  • Ingeniero Junior: Gran actitud y ganas de aprender.
  • Ingenieros subcontratados: Si te dedicas a desarrollar la tecnología es poco estratégico subcontratar una parte core de la compañía.

Utilizar tecnologías no probadas, eso forja el caracter. XD
Está bien aprender cosas nuevas, pero hay que tener cuidado de calcular sus pros y contras al meterlas a algo serio.

Errores de producto más comunes

  • Construir demasiado. Conviene crear la versión más sencilla de un MVP, es decir, solo lo esencial para nuestra propuesta de valor y solo para aquellas plataformas que tengan más sentido para nuestro público.
  • Escalamiento anticipado. No vale la pena dedicar tiempo y esfuerzo en crear un sistema super optimizado y escalable cuando aún no hemos encontrado market fit y nuestra base de usuarios aún es pequeña.
  • Utilizar tecnologías aún no probadas. Requiere dedicarse a aprender en vez de construir features, dificulta iterar rápido, encontrar soluciones y reclutar talento.
  • Contratar a los ingenieros incorrectos. Ingenieros corporativos, Elite Computer Scientist, Ingeniero Junior, Ingenieros subcontratados.

Totalmente cierto. En nuestra experiencia, no fue la mejor idea contratar “ingenieros subcontratados”, mucho menos que trabajen en la otra parte del mundo (Asia) y que usen una tecnología y almacenamiento de datos de los 90! Aprendan a codear y tengan en el equipo a personas innovadoras, apasionadas y técnicamente capaces.

Excelente video, gracias Platzi, excelente video.
Excelente contenido de esta parte del taller. En menos de hora y media me dio mucha más dirección e ideas para seguir adelante con la construcción de mi producto.

ERROR: Utilizar tecnologías no probadas. Nos suele pasar a los técnicos querer programar librerías desde cero, en lugar de utilizar algo ya existente. Pérdida de tiempo y recursos.

Excelentes consejos.

Excelente modulo! gran profesor!!

Hola, soy el CEO, pero esto me ayudo bastante a clarificar lo que uno sabe de manera intuitiva pero es dificil poner en palabras.
A demás suelo estar en búsqueda de talentos y también me va a servir para poder identificarlos mejor.
Gracias

Estamos en el proceso del emprendimiento y esta clase nos llega perfecto , porque tenemos claro lo que vamos a crear y la necesidad que queremos cubrir , pero debemos evaluar si seria aceptada por el mercado , si en realidad es funcional para poder continuar con el MVP. Ahora lo que dice Davis me parece clave , no debe se debe obviar el prototipo , es parte fundamental para llevar al MVP.

Desde mi punto de vista y poca experiencia, creo que lo más rentable para iniciar apps móviles es que sean multiplataforma,
Ademas considero que el futuro camina a centralizar el código y Dart ha ido creciendo, es cada vez más fácil encontrar documentación y liberías
Compartánme su opinión

Que buen video.

tkm david aroesti

Me pasó lo mismo con dart xd

bs días, lo mio es un Producto natural ya hecho acá les comparto un link de las diferentes redes: 👉https://linktr.ee/naturegrape en realidad me gusta mucho la naturaleza y decidimos junto a mis hermanos emprender brindando a nuestros clientes un producto Natural 😊💜😊 gracias. por las clases me ayudan mucho a seguir mejorando 🙏🙌🏼🙏

En estos momentos estoy es una startup, y me senti muy identificado con los errores mencionados. Excelente clase!!

5 errores más comunes a la hora de crear un producto

  1. No comprender las necesidades del cliente: La mejor manera de asegurarse de que los productos satisfagan las necesidades del cliente es asegurarse de entenderlas de antemano. Esto significa investigar y comprender la competencia, así como conocer las tendencias del mercado, las preferencias de los compradores y las expectativas de los compradores.

  2. Intentar abarcar demasiado: Esto es lo contrario del punto anterior. A menudo es tentador querer lanzar un producto que tenga muchas funcionalidades, pero los productos exitosos son aquellos que están enfocados en una funcionalidad concreta y la ejecutan de manera exitosa.

  3. Falta de planificación apropiada: Una vez que se entienden las necesidades del cliente y el alcance del producto, es esencial tener un plan de desarrollo del producto bien definido para asegurarse de que todas las partes involucradas sepan lo que está involucrado y cómo ejecutarlo.

  4. Escuchar demasiado a los usuarios: Mientras es importante escuchar a los usuarios para comprender sus necesidades, a veces es mejor hacer lo que es mejor para el producto, aunque esto significa no atender exactamente a los deseos de los usuarios. El mejor producto es a menudo aquel que se desarrolla con una perspectiva de largo plazo en lugar de una perspectiva a corto plazo.

  5. Falta de pruebas y validación: Es esencial probar el producto antes de su lanzamiento para asegurarse de que cumple con sus requisitos. Esto ayuda a asegurar que el producto sea exitoso y evitar problemas cuando se lance.

Como seria la condición para una empresa que ofrece servicios, suele ser un poco mas sencillo aveces pero estoy en la creación de una Productora de Cine, sin embargo el que la gente necesite a un servicio como el que ofrezco durante estos momentos es un poco complejo y por ende los negocios o empresas el dinero que les sobra no invierten en comunicación. Que podría hacer en esos casos?

Soy empleado y me gusta serlo, pero la mentalidad de Start up siempre me encantará

Amé estas clases con David. Muy didáctico.

¿COMO CONSTRUIR UN EQUIPO DE INGENIERÍA?
 Definir las necesidades

  • ¿Qué tipo de producto se va a construir?
  • ¿Cuál es el presupuesto?
  • ¿Cuáles son las prioridades?
     Para Encontrar al ingeniero correcto este debe tener ciertas características:
  • Emocionado con la misión de la compañía
  • MVP mindset
  • Se siente a gusto con la iteración constante
  • Sabe mantener sistemas y no solo construirlos
  • Empata con los usuarios
     ¿Dónde encontrar talento?
  • Redes especializadas
  • Network propio
  • Meetups y eventos
    Idealmente en una startup debería de utilizarse metodologías ágiles, “La velocidad lo es todo”
    “Sube a la gente correcta al bus, baja a la incorrecta y sienta a la persona correcta en el asiento correcto”
    Jim Collins

CONSTRUIR Y EJECUTAR UN ROADMAP (Plan de programación) DE PRODUCTO DE FORMA EFICIENTE
Para construir un plan de programación ROADMAP, lo primero que debemos preguntarnos ¿Cuáles son sus objetivos?, ¿Qué pretendemos lograr con él? , el ROADMAP (Plan de programación) es una herramienta científica que nos permite iterar de hipótesis – experimento y resultado, si se obtienen los resultados esperados se pasa al siguiente paso, pero si no es así se construye una nueva hipótesis y experimento para obtener un nuevo resultado.
¿CÓMO ESCRIBIR UNA HIPÓTESIS?

  • Definir claramente el problema que se intenta resolver
  • La hipótesis siempre debe seguir una forma condicional (SI SUCEDE ALGO ENTONCES SUCEDE OTRA COSA)
  • Debemos definir las variables dependientes e independientes, si movemos la variable independiente alteraremos la variable dependiente y si es así podremos predecir o interpretar mejor lo que sucede en las condicionales

1- DESCRIBIR EL PROBLEMA:

  • ¿Cuál es el problema que intentamos resolver?
  • Escríbelo de manera clara y reflexiona en la una solución
    2- VALIDA EL PROBLEMA:
  • ¿Es el problema real?, ¿Realmente existe el problema?
  • Estudia a las personas que actualmente se están enfrentando al problema
  • Realiza entrevistas
    3- VALIDA CON EL MERCADO
  • ¿Existe un problema para mi solución?
  • Estudia si el mercado quiere tu solución
  • Puedes utilizar encuestas, landings, etc.

4- CONSTRUYE UN PROTOTIPO

  • ¿Mi solución resuelve el problema?
  • Construye el prototipo más sencillo posible
  • Puedes usar Marvel App, Figma o Sketch

5- CONSTRUYE EL MVP: Este MVP a la larga debe convertirse un product market fit

  • ¿La solución resuelve el problema para muchas personas?

  • Hacer el MVP hará crecer a tu equipo

  • Utiliza Feribase o Heroku
    ERRORES MÁS COMUNES AL MOMENTO DE CONSTRUIR EL PRODUCTO
    Estos son los siguientes errores
    1- CONSTRUIR DEMASIADO RÁPIDO Y PRONTO: Muchas veces se quiere pasar directo a construir el MVP, por esta filosofía de que en las startups se debe construir rápido y veloz, sin embargo debe haber debidos procesos a respetar, tampoco es construir a lo loco sin procesos óptimos, todo tiene un proceso y es importante no saltarnos ese proceso:

  • DESCRIBIR EL PROBLEMA

  • VALIDAR EL PROBLEMA

  • VALIDAR CON EL MERCADO

  • CONSTRUIR EL PROTOTIPO

  • CONSTRUIR EL MVP

Otro error muy común es hacerlo demasiado pronto, muchos founders dicen que están construyendo software para escritorio, para IOS, para android, hasta para sistemas operativos que no se conocen mucho, y eso es un grave error, se debe escoger la plataforma donde más se encuentra los usuarios, debemos escoger la plataforma que tenga el hardware necesario para que el producto funcione.

2- ESCALAR DE MANERA ANTICIPADA: Se suele ver ingenieros que quiere crear sistemas que escalen para 10 millones de usuarios, por la cantidad de esfuerzos que requiere construir estos sistemas para los 100 usuarios que tienes en un principio no tiene ningún sentido, la idea es construir un producto que el mercado necesita ¡¡¡AHORA!!! y no en el fututo, debemos enfocarnos en las necesidades presentes.

3- UTILIZAR TEGNOLOGÍAS NO PROBADAS:

  • Dificulta iterar rápido
  • Se dedica recursos al aprendizaje y no a la construcción
  • Dificulta encontrar soluciones
  • Dificulta el reclutamiento

4- CONTRATAR A LOS INGENIEROS INCORRECTOS:

  • INGENIEROS CORPORATIVOS: Estos ingenieros ya están acostumbrados a sistemas que escalan y ya están estructurados y normalmente no se sienten cómodos en el mundo de las startups, muchos de estos tienen una actitud negativa de cosas que ya deberían de estar como decir (Deberíamos tener a otro equipo para hacer resto), no se toman consideraciones de negocio, ellos están tratando de traer la visión corporativa a una startup donde se tiene que iterar rápido.

  • ELITE COMPUTER SCIENTIST: Este perfil es idóneo si tu startup se dedica a resolver problemas únicos y exclusivos de la ciencia de la computación, pero cuando la startup obedece a clientes no tan técnicos normalmente estos ingenieros se aburren muy rápido, y lo que pasa es hacer sistemas about enginner, es decir empiezan a hacer sobre ingeniería, esto no es óptimo ni de buenas prácticas para una startup.

  • INGENIRO JUNIOR: Para los ingenieros junior son propensos a caer en errores y las arquitecturas que diseñan no sirven para la siguiente etapa.

  • INGENIEROS SUBCONTRATADOS: Puedes subcontratar a otra persona para el diseño de software, pero si la startup es de tecnología y si nosotros nos dedicamos a desarrollar tecnología es muy poco lógico y estratégico subcontratar una parte fundamental de la compañía que es el software

ENTENDÍ AL DEDILLO TODO GRACIAS PROFESOR DAVID.

CTO corporativos > Managers de capital humano

CTO en startups > hands on

Si tuviera el capital preferiría pagar por el desarrollo de la app, pero si no, toca aprender de programar, de administrar, de estudios de mercado, etc.

Básicamente lo que se dice del ingeniero Junior es totalmente cierto, la arquitectura que crean casi siempre no es acorde y necesita ser reconstruida. No es bueno contratar juniors en startups en los primero momentos cuando mas se crece, ya cuando se ha posicionado y tiene bases solidas es hora de empezar a dar estas oportunidades.

Un ejemplo muy claro de no construir demasiado rápido es Beek. Una app de audiolibros que ha levantado millones en inversión y aún no ha dado el paso a versión web.
la recomiendo mucho, la founder es Pamela Valdés, da un curso de Growth para Startups.
https://www.beek.io/

Amigos, para lanzar un MVP, recomiendan una WPA (web progressive apps), alguien tiene experiencia con esto?. Si funciona creo que es una excelente forma de abaratar costos en una primera instancia…

Otro error que tambien cometi, es ponerte aprender una tecnologia o area desde 0 al mismo tiempo que emprendes. Aprendi javascript y angular. Como ingeniero, aprende y luego emprende. El foco debe estar en construir el producto, no en crear un side-project.

Lo que le aumenta la dificultas es contratar a un amigo XD. Lo que si puedo dar fe que funciona es cuando consigues un excelente colaborador y también buena persona, él suele recomendarte a alguien más utiliza los mismos filtros cualitativos además que a este tipo de perfil le gusta estar rodeado de talento #SmileduDemoDay2020

David, gracias por la presentación de este capítulo, aclara muchas cosas respecto al diseño de producto, que no había considerado

Con mi startup he decidido vender productos relacionados a la sustentabilidad como energía solar y con las ganancias poder reinvertir en el core tecnológico del proyecto.

Vender para financiar proyectos es una buena forma para poder construir un producto. Como Elon Musk vendió lanzallamas y gorras para financiar The Boring Company y no recurrir demasiado al capital externo

Estás hablando de dart? Cuándo grabaste éste video?

hola, estoy en el desarrollo de una plataforma de remodelacion con diseñadores y arquitectos, donde sus diseños seran con los productos de proveedores de la misma plataforma, la validacion en paralelo la hacemos con otra empresa de mi propiedad, ya trnemos el MVP, y estamos acqui en Platzi buscando como lanzarla.

Soy mi propio Ingeniero de soft. Zafeeeeeeeee .)