Por qué lanzamos Residence, nuestro programa especial para Startups

Lanzamos Residence porque nos apasiona trabajar con startups. Y el modelo típico, en que nos contratas para hacer un cierto desarrollo acotado y/o por un valor hora determinado, no funciona bien. Hay excepciones, pero creemos que para la mayoría de las startups, podemos ofrecer algo mucho mejor. Y eso es Residence. Postula acá para ser la startup seleccionada de esta generación.

Para entender mejor por qué Residence es genial, empecemos con las razones de por qué el modelo típico no funciona. En general estamos hablando de una startup que aún no tiene formado su propio equipo técnico.

Mala idea #1: Mandar a hacer un MVP en base a features

Ya hablamos de este error hace unos años:

Muchas startups llegan a nosotros y parten de la misma forma que la industria tradicional: Con un “request for proposal” o equivalente, que describe (en mayor o menor detalle) tooodo lo que quieren que diseñemos y construyamos.

Lo que es pésima idea, porque:

Por muy buena que sea la visión inicial de una startup, lo primero que hay que hacer es transformar el cerro de hipótesis y suposiciones iniciales en conocimiento y aprendizaje validado. Y construir un MVP es el medio para llegar allí, no el fin en sí mismo. Lamentablemente muchas startups deciden hacer un MVP “big-bang”, que toma un par de meses en desarrollarse y donde se ponen a prueba una docena de hipótesis de una sola vez. En vez de probar hipótesis de a poco, se opta por “construir la app y ver qué pasa”

El consejo acá es que una startup debe preocuparse de cuánto aprendizaje acumula y no de cuántas features se desarrollan. Lamentablemente, no es un consejo fácil de seguir. Es infinitamente más fácil cotizar “desarróllame una app que haga X, Y y Z” que “validemos si mis supuestos son ciertos”. En general, ni el emprendedor ni las empresas de desarrollo saben como resolver lo segundo.

Mala idea #2: Tener tu core tecnológico fuera de tu startup

Supongamos por un momento que resuelves el punto anterior (De hecho en Continuum hemos desarrollado metodologías como Lean UX y herramientas como el Scope Canvas para eso). Igual es mala idea que incluso Continuum sea el encargado de tu core tecnológico. En parte, porque es uno de tus activos más preciados, si lo que tienes es una startup tecnológica. Y también porque las startups tienen un ritmo que simplemente no encaja con la dinámica de una consultora. ¿Acabas de cerrar un nuevo e importante cliente pero tienes que implementar un cambio antes del 1 de Marzo y estás a mediados de febrero?

— “Aló PartnerTecnológico, hagamos este cambio, cuando partimos y cuanto me cuesta”

— “Hola EstimadoClienteStartup. Por supuesto. Tenemos disponibilidad para empezar en 3 semanas más”.

— “Uhm, la verdad necesito esto terminado para 2 semanas más”,

— “Claro. Podríamos reasignar gente que está trabajando en otro proyecto o que está libre. Pero vamos a tener que explicarles todo el contexto porque no tienen idea de tu negocio, ni de la solución tecnológica que implementamos hace algunos meses.”

Ugh.

Resumiendo: No quieres correr una maratón conectado a un balón de oxígeno externo. Por bueno que sea el balón de oxígeno, es preferible que uses y desarrolles tus propios pulmones.

Mala idea #3: Acortar tu pista de despegue (‘runway‘)

De nuevo, supongamos que el punto anterior no es problema. En Continuum aún no encontramos como resolverlo, pero tal vez hay alguna fórmula. Como sea, tu buen PartnerTecnológico te cobrará precios de mercado para buena calidad y velocidad (porque, si tiene un buen equipo y con lo escaso que es el talento, sus desarrolladores y diseñadores también estarán cobrando sueldos de mercado). Digamos que tuviste suerte y encontraste un buen partner por 45 USD/hora. Y digamos que te ganaste un Startup Chile y dedicas dos tercios del presupuesto (es decir, unos USD 20.000) en diseño y desarrollo de tu tecnología

20.000[USD] / 45[USD/hora] = 444 horas.

Esas son aproximadamente 11 semanas. Tu pista de despegue para conseguir que tu producto vuele ha sido reducida dramáticamente a menos de 3 meses.

Residence al rescate

Diseñamos Residence para resolver estos problemas:

Tan pronto inicia el programa, hacemos el mismo proceso de Lean UX contigo que el que ofrecemos a nuestros clientes. El mismo que hemos aplicado como partners de Wayra, en forma abreviada en talleres para S-Factory, o con startups reconocidas de la talla de ArchDaily. Le daremos claridad y prioridad a tus hipótesis y las validaremos lo mejor posible antes de escribir una sola línea de código. Luego nos tendrás literalmente al lado para acompañarte en mejoras y re-diseños por los 6 meses que estés con nosotros. Y más que obsesionarnos inmediatamente con el crecimiento, la masividad y salir en la prensa, partiremos por ver qué estamos haciendo, por qué y para quién.

In the first few weeks of a startup’s life, the founders really need to figure out what they’re doing and why.  Then they need to build a product some users really love.  Only after that they should focus on growth above all else.

A startup that prematurely targets a growth goal often ends up making a nebulous product that some users sort of like and papering over this with ‘growth hacking’.  That sort of works—at least, it will fool investors for awhile until they start digging into retention numbers—but eventually the music stops.

I think the right initial metric is “do any users love our product so much they spontaneously tell other people to use it?”  Until that’s a “yes”, founders are generally better off focusing on this instead of a growth target.

— Sam Altman, YCombinator partner: “Before Growth”

En realidad no se trata sólo de construir un producto en 6 meses. Se trata también de construir un equipo y una cultura de ingeniería y de producto que tenga la capacidad de construir, pivotar, rediseñar, mantener, soportar y escalar. Las bases de ese equipo, de esa cultura, se forman en las primeras semanas o meses de vida de tu startup. Nosotros te ayudamos a encontrar a tu equipo (como mínimo un desarrollador, que se proyecte para cumplir el rol de CTO a futuro). Le contagiamos a tu equipo, de primera fuente, la cultura que en Continuum nos preciamos de tener y que se refleja en nuestro trabajo y en la satisfacción de nuestros clientes. Tu equipo estará rodeado de expertos en iOS, Android, Rails, Java, front-end, IoT, UX, etc, etc, etc. Pero más importante: de excelentes personas.

Why is culture so important to a business? Here is a simple way to frame it. The stronger the culture, the less corporate process a company needs. When the culture is strong, you can trust everyone to do the right thing. People can be independent and autonomous. They can be entrepreneurial. And if we have a company that is entrepreneurial in spirit, we will be able to take our next “(wo)man on the moon” leap. Ever notice how families or tribes don’t require much process? That is because there is such a strong trust and culture that it supersedes any process. In organizations (or even in a society) where culture is weak, you need an abundance of heavy, precise rules and processes.

— Brian Chesky, co-founder AirBnB: “Don’t Fuck Up The Culture”

Y sobre el runway, la única manera de no acortarla es no pedirte tu escaso cash a cambio de nuestro apoyo. Si bien sueldo de tu equipo residente y tu infraestructura tecnológica la tienes que costear tú, calculamos que muchas startups pueden funcionar por los 6 meses de residencia con USD 20.000. ¿Te acuerdas cuanto runway calculamos más arriba para 20K? 11 semanas. Acá tienes para 6 meses.

Nuestro apoyo (recruiting, Lean UX, residencia dentro de la oficina de Continuum, apoyo del equipo) lo valoramos en USD 30.000, pero en lugar de cobrártelo te pedimos una nota convertible que nos convertirá en tus socios minoritarios en tu siguiente ronda de inversión. Aún estamos afinando los detalles sobre dicha nota (son comunes en EEUU, pero no tanto en Latam) pero la esencia es que queremos tener una participación menor en varias startups con gran potencial.

¿Track record?

Es cierto que recién estamos lanzando abiertamente el programa. Aún así tenemos un track record:

  • GetOnBoard es el prototipo interno y orgánico de este programa, compuesto de miembros del propio equipo de Continuum. Líder en su nicho, GetOnBoard ha generado en ingresos más de lo que se consigue en el fondo público promedio y ha crecido sustentablemente durante años.  Y ha sido cash-flow positive desde el fin de su residencia.
  • Haus, la solución de seguridad vecinal fue nuestro primer prototipo de Residence el año 2015 (hay que practicar lo que se predica, y Residence tenía supuestos que había que validar). Hoy Haus tiene comunidades activas en Chile, México, Brasil, Colombia, Perú, Uruguay y Argentina. Ha sido destacado en diversos medios de prensa nacional. Como resultado de la residencia levantó más de USD 100.000 entre fondos públicos y privados y su equipo ya incluye dos desarrolladores y una diseñadora UX. Además, el desarrollador inicial reclutado por Continuum cumplió y superó todas las expectativas, convirtiéndose en el CTO de Haus.

A Continuum llegamos con un PowerPoint y hoy nos vamos como un Emprendimiento competitivo. Lo recomiendo a ojos cerrados

— Andres Gallardo, CEO de Haus

¡Postula!

Buscamos a los mejores founders que aún no hayan formado su equipo tecnológico. Con ideas y proyectos ambiciosos, de alcance mundial o cuando menos latinoamericano. Que sepan que las ideas son sólo un multiplicador y que la ejecución vale millones de dólares y estén dispuestos a jugársela en su ejecución. Que se encarguen desde el día 1 de levantar fondos, desarrollar el negocio, y desarrollar sus clientes, porque son parte clave de la vida de su startup.

Fuera de eso, no hay reglas. ¿Te animas?

Continuum Residence

Se da inicio a la temporada de Charlas 2015

Como todos saben, en Continuum no sólo nos dedicamos a tomar cerveza desarrollar y diseñar pensando en el usuario, además compartimos conocimiento. Por eso, algunas de nuestras mentes más brillantes participarán como charlistas de los eventos que se vienen para el último trimestre del 2015. Así que si algo te ha sonado el Latinity o estás esperando la StarTechConf (no olvides comprar tu entrada), presta atención para que no te pierdas nada.

Taller “Innovación de Guerrilla” por Sergio Nouvel.

Fecha y hora: 29 de septiembre, 11 AM (GMT-5).
Lugar: Pontificia Universidad Católica del Perú (Lima).

¿De qué va?
¿Cómo logran pequeñas startups sacudir el negocio de gigantes en una industria con innovaciones radicales e inesperadas? Innovar no tiene por qué ser costoso. Al contrario: las restricciones de tiempo y dinero hacen aparecer mejores ideas. La espontaneidad y la tolerancia al caos estimulan mucho más la innovación que procesos complejos o conceptos rimbombantes.
En este taller, Sergio entregará lineamientos, herramientas y trucos sencillos, basados en su experiencia directa como fundador de startups y como consultor de empresas, para despertar el hambre de innovación en cualquier organización.
¿Por qué es imperdible?
Si eres alguien interesado en estimular la innovación en tu organización, tendrás ejemplos y trucos basados en experiencias directas (no-bullshit conceptual) para poder aplicar en forma efectiva.

Charla “Scope Canvas: Cómo empezar un proyecto de UX” por Sergio Nouvel.

Fecha y hora: Por definir (6 o 7 de noviembre).
Lugar: StarTechConf (USM, sede San Joaquín).

¿De qué va?
¿Cómo empiezas un proyecto de UX y reduces la brecha que separa a tu equipo entre la idea y una experiencia impecable? Scope Canvas es la herramienta que hemos diseñado en Continuum para darle impulso a los proyectos de Lean UX, con énfasis en tender el puente entre las necesidades de negocio y los objetivos de usuario.
En la charla, Sergio contará cómo hemos usado Scope Canvas para proyectos y entornos de trabajo muy diversos, desde startups hasta empresas consolidadas, pasando por ONG’s e intra-emprendimientos.

¿Por qué es imperdible?
¿Quieres comenzar a llevar a tu equipo hacia el sendero de la UX? ¿Necesitas manejar mejor los proyectos UX con tus clientes?, esta charla te ayudará a visualizar los típicos problemas de empezar un proyecto centrado en el usuario y cómo salvarlo usando Scope Canvas.

Charla “Polígrafo: Estudiando el consumo energético de apps” por Rodrigo Araya.

Fecha y hora: Por definir (6 o 7 de noviembre).
Lugar: StarTechConf (USM, sede San Joaquín).

¿De qué va?
Rodrigo nos mostrará el comportamiento de los smartphones desde el punto de vista de consumo energético bajo los distintos escenarios que día a día enfrentan sufren nuestros dispositivos con las aplicaciones. Además, nos recomendará las claves de un desarrollo optimizado para disminuir el gasto de energía en smartphones.

¿Por qué es imperdible?
El impacto energético de las aplicaciones, dentro de los dispositivos móviles, es un tema que estuvo olvidado por bastante tiempo.  En el último año, los desarrolladores de sistemas operativos (Apple y Google) han agregado herramientas para obtener de forma imprecisa y aproximada el consumo que posee las aplicaciones instaladas dentro del teléfono.  Lo que verán en esta presentación es el resultado de un experimento que se convirtió en un estudio, analizando el consumo energético directamente desde el hardware del dispositivo, modificando el teléfono para lograr utilizar un “Polígrafo”, midiendo verdaderamente el consumo energético con un Multímetro.

😮

Charla “Coordinador de Servicios” por Liliana Reyes y Carolina Rojas (de nuestro cliente, Previred).

Fecha y hora: Por definir (9 o 10 de noviembre).
Lugar: Latinity (Universidad Mayor, campus Manuel Mont).

¿De qué va?
Liliana y Carolina nos contarán cómo la superintendencia de AFP al lanzar la normativa NCG-115 generó el gran desafío: Que un cotizante pueda cambiarse de una AFP a otra a través del portal web de la AFP destino.
Para poner en práctica el proyecto, cada AFP debía crear una aplicación web a exponer en su portal, la cual debía consultar a las otras por la información del trabajador que está intentando su traspaso. El coordinador de servicios de Previred consolida la información y la entrega como una única respuesta para la AFP de destino.

¿Por qué es imperdible?
Un desafío técnico importante, la puesta en práctica patrones de diseño de Arquitecturas orientadas a servicios y un gran desafío en la gestión: ¿Cómo coordinar y poner de acuerdo a los comités de 6 AFP? ¿Cómo trabajar y colaborar activamente con tu proveedor, para que éste no sea “uno” de los cuellos de botella?
Durante la ejecución del proyecto, pusimos en práctica metodologías ágiles de desarrollo y gestión, logrando que PreviRed y Continuum funcionaran como un sólo equipo y no existiera brecha entre proveedor-cliente (nivel: “Daremos una charla juntos”) . Tenemos anécdotas y tips dignos de compartir.

Bikeshedding y Branding — Parte 1: De Plantas Nucleares y Cobertizos de Bicicletas

¿Qué pueden tener que ver una planta nuclear y un cobertizo de bicicletas con la toma de decisiones de tu organización y la forma de diseñar tu marca?

¡Muchísimo! En esta serie de posts voy a comentarles como un insight formulado el 1957 explica mucha de la confusión y frustración que suele ocurrir cuando te enfrentas al desafío de diseñar tu marca (y muchas otras decisiones complejas, por cierto).

Partamos entonces por esta historia de plantas nucleares y cobertizos de bicicletas.

Cyril Northcote Parkinson era un marino e historiador, pero la mayor parte de su fama viene de su Ley de Parkinson, surgida de los estudios que hizo mirando la práctica de la gestión y toma de decisiones en organizaciones. Pues bien, hay otra ley más importante descubierta por Parkinson en esa época, mientras estudiaba la toma de decisiones del comité encargado de aprobar los planes de una planta nuclear.

Naturalmente, una planta nuclear es un tema serio que requiere cuidadosa deliberación y estudio. El problema es que Parkinson advirtió que la mayor parte de la deliberación, discusión y tiempo del comité se gastaba en cosas triviales, como los materiales para usar en el cobertizo de las bicicletas ¡Y no en el diseño de la planta nuclear misma!

¿Por qué?

La explicación principal: No todos tenemos los conocimientos o experiencia para criticar constructivamente los planes de una central nuclear ¡Pero opinar sobre el cobertizo de bicicletas es pan comido!

Por cierto, como en inglés cobertizo-de-bicicletas se dice bikeshed, en el mundo del desarrollo opensource se ha popularizado el termino bikeshedding. Así se pueden interrumpir de manera rápida esos interminables detalles superfluos donde todo el mundo tiene una opinión diferente diciendo, esencialmente, “cortémosla con el bikeshedding y enfoquémonos en lo más importante”. Y todos entienden.

De vuelta a Parkinson, recuerden que el tipo estaba estudiando como se comportaba el comité en sus reuniones. Por ende, la manera en que Parkinson formuló su Ley de Trivialidad es la siguiente:

El tiempo gastado en cualquier item de la agenda de una reunión será en proporción inversa a la cantidad de dinero involucrada.

Como en general las cosas que cuestan mucho dinero (como las centrales nucleares) son complejas, el tiempo y la atención se van a las cosas triviales y baratas.

En el siguiente artículo de esta serie veremos como esta ley aplica al proceso de diseño de marca/branding/personalidad, de acuerdo a nuestra experiencia en múltiples proyectos en Continuum. Después de todo, diseñar tu marca no es precisamente barato, pero igual todo el mundo tiene una opinión que dar al respecto.

¿Qué creen ustedes que diría Parkinson si nos viera en esas reuniones en que discutimos el diseño de marca, logos y/o look & feel?