Saas Product Chat

Llega un nuevo episodio de SaaS Product Chat esta semana y con un invitado increíblemente especial. Jeduan Cornejo nos visita para hablar de su camino hasta convertirse en ingeniero de software para la comunidad global de viajeros Airbnb, generalista vs. especialista, todo lo que puedes lograr con JS en 2019, consenso para poder migrar en tecnologías, planeación de features dentro de Airbnb (por ejemplo: rediseño visual de la barra de filtros), cómo resuelven en Airbnb para no desalinearse y que todos los miembros optimicen hacia el bien del equipo, movimiento de comunidades tech o qué le ha funcionado a Jeduan para aprender cosas nuevas en específico. Lo podéis escuchar en vuestra app de podcast preferida.Perfiles sociales de Jeduan:Twitter: https://twitter.com/jeduanGitHub: https://github.com/jeduanLinkedIn: https://www.linkedin.com/in/jeduanMedium: https://medium.com/@jeduanEnlaces recomendados:Jeduan Cornejo comparte un par de técnicas para lograr tus objetivos profesionales como ingeniero en PlatziConf 2

La refactorización es una de las soluciones activas para frenar el miedo a cambios de modificación o ampliación del código. ¿Es buena práctica refactorizar a partes? ¿Reescribirlo todo es un error? Los programadores con un mínimo de respeto por la estructuración huyen de esta clase de embrollos pero a otros la arquitectura les trae sin cuidado, y tal vez se sienten cómodos programando por inercia pero poner parches día tras día no es la solución. Saber cuándo y cómo refactorizar en ingeniería de software puede ayudarte a escribir código más legible y mantenible en el tiempo. En este episodio hablamos sobre cómo enfrentarse a una refactorización, por qué programar con orientación a objetos tiene muchos factores buenos, la necesidad de implantar una cultura de testing, refactorización y pruebas unitarias para eliminar el miedo a modificación y ampliación del código o por qué la legibilidad y estructuración debería importarte y no solo que el código haga su función. También hablamos sobre cómo estar seguros que

Estimar en desarrollo de software moderno es difícil por los altos niveles de variabilidad y más en un entorno de incertidumbre. En el episodio de SaaS Product Chat de esta semana hablamos del esfuerzo de estimar en proyectos de software, los riesgos intrínsecos y extrínsecos asociados a estimar, las variables desconocidas que influyen o invertir tiempo en hacer backlog grooming para priorizar y marcarse deadlines vs. estimar en fases iniciales del desarrollo.Enlaces recomendados:Libro de Steve McConnell sobre cómo estimar proyectos de software: https://www.amazon.com/exec/obidos/ISBN=0735605351/stevemcconnelconEpisodio del podcast The Engineering Commons Podcast sobre la importancia de estimar con precisión el tiempo y el presupuesto: http://theengineeringcommons.com/episode-139-estimation/Hacer una estimación para un proyecto de software no ayuda a nadie a programar mejor y es muy difícil, sí, pero ahora mismo ser "deadline driven" es la mejor alternativa para clavar la estimación: https://blog.pragmaticeng

La gente de Blockstack lleva haciendo las cosas bien desde hace muchos años en el mundo de los crypto assets y, aunque siempre habrá tecnología muy experimental y habrá bugs de experiencia de usuario que hace que la tecnología sobre blockchain no sea tan fina, hemos dedicado este episodio 65 del podcast a las plataformas descentralizadas porque creemos que estamos en el año donde hay un verdadero ecosistema que está teniendo un nivel de conversación sobre lo que se puede construir institucionalmente usando un blockchain que se está poniendo muy rico. Hablamos del cambio de paradigma en el contexto de ethereum en concreto porque el nivel de conversación está realmente en el punto de discutir gobernance, la naturaleza de la participación, qué es la identidad y tratar de hacer experimentos encima del blockchain por la composability que da esta red por ejemplo. En este SaaS Product Chat también te contamos lo que nosotros entendemos por blockchain y por qué puede demostrar de manera feaciente y no necesita que se

En este episodio hablamos de los generadores de sitios web estáticos que ya son una solución realista en el mercado para crear sitios rápidos y escalables. Además explicamos cuáles son sus principales beneficios (páginas generadas corren muy rápido) y sus inconvenientes (las funciones dinámicas como comentarios o formularios son más complejas de implementar) o por qué separar el origen de datos del resultado final en sitios pequeños donde no se genere mucho contenido puede ser un buen aliado. En el segundo bloque compartimos de las bases de un modelo de desarrollo con JAMStack orientadas hacia el cliente y no hacia el servidor y ahondamos en la diferencia competitiva de los Headless CMS frente al CMS tradicional.Enlaces recomendados:- VuePress es un generador de sitios web estáticos con Vue.js: https://vuepress.vuejs.org/- Una lista de los generadores de sitios web estáticos más conocidos del mercado con opción para filtrar por estrellas en el repositorio (popularidad) o seguidores en twitter: https://www.sta

Dedicamos este episodio a hablar con Álvaro Trigo de fullPage.js, que acumula una experiencia notable en desarrollo y mantenimiento de proyectos de código abierto a tiempo completo. Con Álvaro hablamos de los dos tipos de pull requests en el soporte de proyectos open source y qué hacer para no saturarse, los retos de cobrar por un componente frontend de JavaScript y los beneficios de crear un sistema de extensiones limitado por clave de licencia. También hablamos sobre desarrollar en móvil cuando no tienes acceso a la consola de JavaScript en ciertos navegadores, cómo hacer un proyecto open source fiable y mantenido en el tiempo y por qué Álvaro nunca ha usado marketplaces y prefiere anunciar en su propia página.Te recomendamos:Perfiles sociales de Álvaro:- Twitter: https://twitter.com/IMAC2- GitHub: https://github.com/alvarotrigoEnlaces de interés:- fullPage: https://alvarotrigo.com/fullPage/- Q&A en el blog de BrowserStack: https://www.browserstack.com/blog/open-source-spotlight-fullpage-js-alvaro-trigo

¿Por qué tus usuarios dentro del periodo de prueba no saltan al plan pro? ¿Por qué dejan de usar el producto y se vuelven inactivos? ¿Cómo prevenir el churn y mejorar activación en nuestro producto SaaS? Estas son preguntas comunes en las comunidades de fundadores SaaS y charlas de equipos de growth, hoy tratamos de contestarlas. Traemos al show este tópico de ingeniería de crecimiento como es la activación de los usuarios inactivos después del periodo de prueba para compartir los puntos de datos a tener en cuenta, consejos de growth y marketing para atacar la métrica del churn, qué se puede hacer desde el lado de producto y mejores prácticas de cualificación de usuarios inactivos para crear estrategias de lead nurturing.Enlaces recomendados:- Blog de Close - 3 ways to nurse lost trial leads into activation (https://blog.close.com/3-ways-to-nurse-lost-trial-leads-into-activation)- Los elementos de una buena estrategia de emails automáticos para activación (Customer io): https://customer.io/blog/reactivation-e

En este episodio contamos de lo que aprendimos al leer «Shape Up», el documento que usa Basecamp para desarrollar productos SaaS. Enlaces recomendados: "3 Compelling Concepts from Basecamp's Shape Up", escrito por Sachin Rekhi (Fundador & CEO, Notejoy): https://www.sachinrekhi.com/basecamp-shape-up El libro "Shape Up": https://basecamp.com/shapeup/ El líder de estrategia de Basecamp te explica en qué consiste su trabajo (definir lo que el producto debería ser y hacer) y técnicas/noción/método detrás de "Shape Up": https://rework.fm/shape-up/ Ryan Singer hace estrategia de producto en Basecamp. Esta serie de vídeos informales se enfocan en cómo planifican, desarrollan y construyen lo que realmente quieren lanzar y cuándo lo quieren hacer: https://youtu.be/VxMLpe9dQ2g?list=PL9wALaIpe0PxhhD0NVmeO-4NhC-WS434H Jason va a su rollo y nos encanta su filosofía de trabajo contracorriente. Basecamp es rentable, autofinanciados desde el primer día! Jeff Bezos es parte del accio

En esta emisión de SaaS Product Chat tuvimos de invitado a Fernando Seror, Ingeniero de Software de Google. Aprovechamos para conversar con él del proceso de entrevistas para entrar en Google, su experiencia trabajando en interfaces gráficas para productos de seguridad y privacidad de Google Cloud después de 6 años trabajando en Ruby, cómo evaluar programadores, por qué se ha enamorado de Ruby y algunas buenas prácticas para programar en este lenguaje. Fernando también nos habla del valor del mentoring. Disfrutad de este episodio y no dudéis en dejar vuestros comentarios sobre el show. Te recomendamos: Conecta con Fernando en perfiles sociales: Twitter: https://twitter.com/Ferdy89 GitHub: https://github.com/Ferdy89 Enlaces: Charla que dio Fernando Seror en RubyHACK sobre mentoring: https://youtu.be/KIiLoVwL7H4 The Bike Shed podcast: http://bikeshed.fm/ Lenguaje de Programación Ruby: https://www.ruby-lang.org/es/ Google Cloud: https://cloud.google.com LeetCode: https://leetcode.com/ Interview

En tu carrera como profesional en tecnología deberías conocer de marketing y growth porque todos tenemos que posicionar y promocionar nuestro trabajo. En este SaaS Product Chat Thomas Petit nos comparte sus experiencias como experto en growth acerca de la importancia de la adquisición de usuarios para mejorar el funnel, cuánto volumen necesitan los experimentos, problemas de no tener un partner de atribución cuando invertimos en adquisición, por qué cada experimento debería tener su tamaño de cohorte necesario, los factores off-metadata que google tiene en cuenta para ranking, aprendizajes después de probar varios métodos para hacer testing en Google Play (Android) como Apple Store (iOS), discrepancias de datos entre networks de publicidad, consola, backend y método de atribución, definir una fuente de verdad que no es perfecta pero sí consistente entre equipos y una recomendación de slack para miembros de la comunidad especializados en ASO, Apple Search Ads y Google UAC. Te recomendamos: Perfiles sociales de

En este episodio nos acompaña Jordi Mon Companys (Senior Product Manager de Códice Software) para contarnos sobre Plastic SCM, un sistema de control de versiones que lleva desde 2005 resistiendo contra Git y hacen el stack completo (línea de comandos, herramientas gráficas, merge, diff, etc) con clientes en más de 20 países, desde equipos indie de videojuegos hasta coorporaciones con más de 3.000 licencias de Plastic. Jordi nos habla de su rol como PM gestionando PlasticSCM, SemanticMerge y gmaster (abreviación de Git Master), factores diferenciales con otros sistemas de control de versiones como Git o Subversion, su proceso para recoger feedback con desarrolladores, por qué el equipo de soporte es fundamental para producto, cómo compiten en precio con productos como Perforce o por qué decidieron integrarse con Unity aún compitiendo con funcionalidades core de Unity. También menciona su contribución como coorganizador de Product Hunt Madrid y por qué son tan exigentes con los speakers para centrarse en enseña

En este SaaS Product Chat conversamos de las ventajas de un iPaaS frente a las soluciones tradicionales para integración de datos empresariales. iPaaS es lo que se conoce como "plataforma de integración como servicio", que básicamente permite resolver la problemática de gestionar grandes volúmenes de datos integrando diferentes aplicaciones entre sí. Además explicamos con ejemplos por qué hoy más que nunca marketing tiene que ver mucho con ingeniería y en base a datos podemos hacer iteraciones y mejoras en el producto. Enlaces recomendados: Los stacks de crecimiento (growth) para el 2019 explicados por la gente de Segment: https://segment.com/blog/the-growth-stacks-of-2019/ La explosión de herramientas SaaS ha creado necesidad cruzada entre equipos de operaciones y nuevos negocios. Este rol de ingeniero de crecimiento trabaja uniendo puntos entre tooling, equipos y datos, optimizando el negocio. Más sobre Growth engineering: https://www.hull.io/blog/growth-engineering/ No ha habido un mejor mo

En este episodio nos acompaña Mario de la Ossa, desarrollador backend de GitLab. Hablamos de GitLab como empresa, los productos que tienen, las herramientas propias de GitLab para facilitar el flujo del desarrollo (Auto DevOps, Integración y entrega continua con GitLab sobre Docker, etc) y los diferentes aspectos del desarrollo dentro de GitLab (herramientas que usan para comunicarse y organizarse). También hablamos de por qué la transparencia de GitLab hace que uno se sienta como trabajando para un proyecto de código libre, por qué tienen un proceso de selección tan fuerte o de qué se encarga Mario como parte del equipo de Plan (issues & épicas). Te recomendamos: Perfiles sociales de Mario: Twitter: https://twitter.com/mdelaossa GitLab: https://gitlab.com/mdelaossa Enlaces: Está brutal que GitLab tenga las posiciones que buscan incluídas dentro de los equipos (abiertos al público). Se agradece tanta transparencia en estos detalles tan importantes cuando uno aplica: https://about.gitlab.com/jobs/

En este episodio hablamos sobre lo que aprendimos analizando el nuevo term sheet que Atlassian ha hecho público para hacer adquisiciones con menos fricción y más justas porque aseguran que el proceso de M&A (mergers and acquisitions) está roto. Ponemos el foco en Atlassian porque han invertido casi 1.000 millones de euros ($1 billion) en adquirir más de 20 compañías. Platicamos sobre por qué esta hoja de términos puede suponer una base para que los fundadores de SaaS puedan pensar en posibles compradores target, las ventajas del buyer vs. seller (caso de Walmart-Cornershop) y por qué estamos viviendo un momento importante en adquisición en SaaS y este framework es amigable pero solo es un punto de partida y siempre hay que tener presente el marco legal por país. Enlaces recomendados: Blog de Y Combinator - A Standard and Clean Series A Term Sheet (https://blog.ycombinator.com/a-standard-and-clean-series-a-term-sheet/) Blog de Atlassian - The M&A process is broken: https://www.atlassian.com/blog/te

En este SaaS Product Chat hablamos sobre la planificación de funcionalidades y las características que tiene que reunir una funcionalidad para considerarse preparada para añadirla al backlog. Además explicamos cómo mantenerse organizados en este proceso y compartimos algunos tips específicos de cómo llevar un registro de las fases necesarias en diseño de producto para la planificación del lanzamiento de la característica. Enlaces recomendados: Episodio de Independence podcast en donde hablan sobre Feature Planning: https://independence.fm/54 Alex de Todoist creó plantillas para la planificación de características: https://todoist.com/templates/design-product/feature-planning Los elementos de buenas historias de usuario: https://www.romanpichler.com/blog/tag/definition-of-ready/ Cómo escribir requerimientos de producto: https://www.atlassian.com/agile/product-management/requirements Dentro de la serie de episodios sobre planificación del podcast "Developer Tea", John Cutrell dedicó uno espe

En este SaaS Product Chat entrevistamos a Chema Ballarín, responsable de desarrollo de negocio de Eventbrite para España y Portugal. Chema también ha estado detrás de empresas tan ambiciosas como Cisco o Dropbox. Nos cuenta su experiencia en desarrollo de negocio durante más de 15 años en tecnología y nos habla detalladamente con qué plataformas concretas puede integrarse Eventbrite. También nos habla de la evolución de Eventbrite como producto, cómo validan o comprueban desde negocio que hay suficiente demanda cualificada en un mercado, qué tiene que entender el equipo de negocio antes de crear un ticket para desarrollo, qué cualidades buscan en la parte de desarrollo de negocio en empresas con un rápido crecimiento y la posición de Chema como miembro de la IAPP (International Association of Privacy Professionals) en relación a la GDPR. Te recomendamos: Perfiles sociales de Chema: LinkedIn: https://www.linkedin.com/in/chemaballarin/ Twitter: https://twitter.com/Chemaballarin Sitio web: https://chemaballarin

En el episodio de hoy hablamos sobre uno de los roles peor entendidos en desarrollo ágil, el Product Owner – sus responsabilidades principales, su papel como mediador entre stakeholders y desarrolladores para no hacer todo lo que piden o la correlación entre el valor de una historia de usuario y su tamaño. También comentamos una una serie de compromisos entre el equipo de desarrollo y el product owner para reducir los riesgos de inclumplir los plazos razonables para entregar una funcionalidad o producto (por ej.: encontrar un equilibrio entre el trabajo reactivo y el proactivo) y las diferencias entre un product owner y un product manager. Enlaces recomendados: Excelente vídeo de Henrik Kniberg ("Scrum and XP from the trenches") explicando lo que hace un PO en la práctica (subtitulado en español): https://youtu.be/5pm0lpa1VVw Vanesa Tejada, Head of Product Delivery en LATAM Airlines, sobre el product Owner y la labor de conexión entre roles: https://vanesatejada.com/2018/04/29/el-product-owner-y

Mario Valle dejó su puesto como ejecutivo en Electronic Arts y se lanzó como inversionista porque vio una oportunidad histórica de invertir en videojuegos de creadores independientes de los mercados emergentes. Mario nos cuenta sobre su fondo Altered Ventures, por qué funcionan como un publisher de videojuegos y no le piden a los desarrolladores que les cedan un porcentaje de sus compañías, por qué sí necesitas un prototipo jugable y no tanto un vertical slice, qué necesitas para crear un prototipo, por qué hay que tomarse en serio los hobbies y el cambio de mentalidad necesario en mercados emergentes para volverse competitivos. Perfiles sociales de Mario: LinkedIn: https://www.linkedin.com/in/mariovalle/ Twitter: https://twitter.com/bilbeny Página: http://www.altered.vc/ Enlaces recomendados: La Realidad Virtual cambiará tu experiencia con los videojuegos: https://youtu.be/c2IJpq3QRDo Mario Valle en el podcast "El valle de los tercos": https://cuonda.com/el-valle-de-los-tercos/mario-val

En este episodio nos acompaña Pedro Piñera, ingeniero de producción en Shopify. Pedro nos cuenta un poco sobre cómo detectar y mitigar problemas de escalabilidad en apps móviles antes de que sean una carga pesada para la empresa imposible de arrastrar. También nos comparte sobre compilación incremental, cómo deciden qué priorizar en su equipo de mobile tooling, patrones problemáticos en relación con las bases de datos para evitar dependencias, factores que hacen aumentar los tiempos de compilación (y cómo alertar a los desarrolladores), Shopify Polaris (su sistema de diseño) o la flexibilidad de la compañía para trabajo remoto. Te recomendamos: Perfiles sociales de Pedro: LinkedIn: https://www.linkedin.com/in/pedro-piñera-buendia-9765a9125/ Twitter: https://twitter.com/pepibumur Checa su portafolio: https://ppinera.es/ GitHub: https://github.com/pepibumur Soundcloud: https://soundcloud.com/ppinera Enlaces: En la edición de T3chFest 2018, Pedro ya tocó el tema de escalar una aplicación móvil: htt

En este episodio nos acompaña Miguel Oliva Márquez, diseñador freelance para compañías como Microsoft, Leica Camera AG, Monzo o Frog Design. Nos comenta de la evolución de su carrera como diseñador y de cómo consiguió su trabajo en Microsoft. Miguel también comparte con nosotros sobre sistemas de diseño (caso Skype o Monzo) y el proceso detrás de diseñar un marca o una interfaz. También tocamos por qué Miguel solo trabaja con un cliente a la vez, qué es lo más importante a la hora de escoger un cliente, cobrar por proyecto vs. cobrar por día o cómo conseguir mantener la confianza como freelance. Te recomendamos: Perfiles sociales de Miguel: LinkedIn: https://www.linkedin.com/in/miguelolivamarquez/ Twitter: https://twitter.com/olivamarquez Checa su portafolio: https://www.miguelolivamarquez.com/ Toptal: https://www.toptal.com/designers/resume/miguel-oliva-marquez Enlaces: Entrevista de InterfaceLovers a Miguel: https://interfacelovers.com/interviews/miguel-oliva-marquez Entrevistas con diseñadore