E61: Enfoque de Basecamp para desarrollar productos SaaS

Hola a todos, bienvenidos al episodio 61 de SassProductChat y por primera vez en 60 episodios puedo decir, Claudio Cosío, bienvenido al show, por fin en persona, nos podemos saludar y bueno, hoy queremos dedicar el episodio que va a ser el último antes del verano a hablar de Basecamp y de su enfoque para desarrollar productos digitales y sobre todo centrarnos en la guía o el documento de Ryan Singer, que lleva 16 años trabajando para Basecamp y en todos estos años ha ido escribiendo y ha ido tomando notas de todo el proceso de desarrollo. Y como vamos a comentar ahora, Basecamp tiene un proceso muy particular porque ellos no desarrollan cualquier producto o feature que se les venga a la mente, sino que antes prefieren esto E. Prefieren dejar por escrito una metodología, tener claro cuál es el coste, darle forma y esto pues vamos a ir punto por punto. No vamos a hablar de los 14 capítulos de la guía, vamos a centrarnos en las ideas núcleo. Pero bueno, Clau. Nada, un gusto estar aquí en Barcelona, veranito, la playa, la piscina y bueno, aquí tenemos este... Pues sí, creo que Basecamp es el claro ejemplo de una empresa que ha podido hacer un cambio que muchas empresas en las cuales hemos trabajado o en las cuales han trabajado ustedes han hecho, ¿no? Que es pasar de servicios a múltiples productos y después un solo producto, ¿no? Y matando algunos productos que de cierta manera sí tenían éxito, ¿no? Creo que también eso es muy interesante platicarlo, ¿no? O sea, cómo fue ese proceso de decisión que ellos tomaron de decir, ¿sabes qué? Y de hecho, hicieron otra cosa también, cambiaron de nombre, ¿no? O sea, de 37 Signals, que era todo lo que tenían, pero era lo que los diferenciaba del resto de las empresas, dijeron, ¿saben qué? Matamos 37 Signals, ¿por qué? Ahora somos Basecamp, ¿no? Entonces creo que eso fue un proceso que no fue de la noche a la mañana, obviamente, pero fue algo como muy natural. Y sobre todo lo documentaron, ¿no? O sea, documentaron ese proceso de lo que funciona, lo que no funciona, ¿no? Y creo que también ese tema de transparencia es algo muy importante que Basecamp ha, de cierta manera, influenciado en toda la industria de desarrollo del software, ¿no? Más software SaaS, ¿no? En la nube. Sí, llevan eso muchísimos años como yendo a contracorriente, teniendo una filosofía de trabajo como muy suya, ¿no? Para mí, en Basecamp ocurre algo que hay pocos empleados, ¿no? Tienen un filtro de selección como muy fuerte. Y pasa un poco como en lo que me contaba Mario de la Osa de GitLab el otro día, que ellos tienen muchos pasos en el proceso de selección porque tienen la seguridad del que entra. Puede realmente ser autónomo y no depender de nadie para sacar su trabajo. Entonces, creo que en Basecamp pasa un poco esto. Esto quiere decir que casi todos sus empleados son senior y tienen unos empleados que... La barrera de entrada es muy alta para gente que quiera aplicar, pero al mismo tiempo ellos creen que su cultura tiene que ir por ahí. Y precisamente cuando Ryan Singer habla de los planes, los meeting plans que tienen en Basecamp... siempre están compuestos por el CTO, el CEO, el Head of Strategy y un líder senior de ingeniería. Y son cuatro personas las que después de definir lo que es todo el apetito del producto que llaman ellos, de definir el pitch, el pitch es la documentación que recogen ellos de cómo tiene que ser la feature, pues estas personas, estos cuatro líderes, son los que deciden si es un producto que está bien definido y por tanto que pueden empezar estas seis semanas, este ciclo de desarrollo de seis semanas, o realmente no es completa, por tanto tienen que volver a repensarla. Sí, yo creo que lo muy importante aquí es que ellos no ponen nada escrito en piedra. O sea, y si toman ese riesgo de aceptar que no es un feature, ¿no? Independientemente de que corren todo el proceso, ellos en cualquier momento se pueden echar atrás, ¿no? Entonces, o pueden repensarlo, ¿no? O sea, no tienen, creo que en su último libro, este, Doesn't have to be crazy at work, hace mucho énfasis en eso, ¿no? O sea, oigan, nosotros, por ejemplo, obviamente es algo que ya muchos de nosotros lo hacemos, no hacen un release en un viernes, por ejemplo. O si ven que van a hacer un release en viernes y ven que algo no falle, lo paran y ¿saben qué? Nos esperamos a lunes, ¿no? Entonces creo que ese dar dos o tres pasos atrás, tomarse el tiempo de tomar buenas decisiones, creo que es algo que Basecamp ha hecho muy bien y ha documentado, ¿no? O sea, el hacer el all-nighters, ¿no? El de hacer eso siempre, ¿cómo se llama? El estar 24x7 conectado, ¿no? También creo que eso han hecho una muy buena, como... cultura de trabajo en el cual respetan a las personas y por ende también respetan su expertise, ¿no? O sea, si alguien no está de acuerdo con ese cierto feature o tiene cierta información que no cuadra o dice, no estoy cómodo, pues no dicen, bueno, no hacemos caso y tiramos adelante, ¿no? Sí, son súper exigentes en esto, ¿no? Y de hecho, shape up significa en español, bueno, como creo que se traduce es como darle forma, ¿no? Tenemos... una idea abstracta, esto pasa siempre en equipos de producto, de desarrollo, salen ideas y ellos quieren de esa idea abstracta definir algo concreto que tenga todos los elementos necesarios para encontrar esa solución que necesitan antes de ponerse a programarla. Esta solución se compone básicamente, bueno, la tienen que ejecutar sobre todo un diseñador y dos programadores. Así es como ellos lo tienen como estructurado. Y luego también son muy específicos en cuanto a dibujar la idea. Ellos siempre, si ves el documento, tienen todo en sketch y tienen todos los elementos dibujados. No tienen por qué ser como un sketch perfecto, sino que tienen que tener todos los elementos. Y después esto tiene que ser de alta fidelidad para que luego, dentro del pitch, dentro del pitch se pueda entender y entonces estos cuatro líderes puedan decidir si entra o no en el roadmap de Basecamp. Sí, y sobre todo también lo que ellos han sido muy buenos es a nivel de sus clientes, ¿no? O sea, sí definir muy bien, ok, o sea, ellos tienen muy claro para quién va dirigido el producto, entonces eso les facilita poder hacer todos estos... mocks, sketches con cierta rapidez, mucha iteración más bien, mucha iteración, porque conocen a la perfección quién es su cliente. Y eso lo hicieron muy bien a través de una estrategia de pricing. Ellos dijeron, ya, antes era tier pricing, ¿no? Tantos usuarios, tanto, tanto, y el problema que eso conllevó fue que, obviamente, los clientes de Enterprise, pues, quieren ser tratados VIP, ¿no? Ellos dijeron, ¿saben qué? Vamos a quitar todo eso. Un precio único para todos y a todos se les trata igual, ¿no? Y eso permite acelerar, no acelerar, sino tener mucha confianza en este proceso de iteración de sacar estos features, ¿no? Porque entonces ya no estás como, bueno, es para más de 500 usuarios, es para un cliente de data center, ¿no? Entonces eso creo que es algo que Basecamp lo ha hecho a la perfección. ¿No animaría a muchos de nosotros a hacer eso? Porque obviamente... Estamos hablando de Basecamp, o sea, tienen ya más de 20 años en el negocio, ¿no? O sea, obviamente tienen un install base que es grandísima, ¿no? Posiblemente no tan grande como Atlassian, ¿no? Sí. Pero sí que tienen muy claro en qué área están jugando, ¿no? Sí, al menos, o sea, habría que ver métricas, el charm rate, ver realmente si los clientes que tienen se retienen durante los años, ¿no? Yo creo que Basecamp destaca en el tipo de cliente que tiene, pero también en cómo trabajan. Básicamente, en la introducción a ShapeUp, Jason Fritt lo que hace es decir lo importante que es para ellos este documento y es una guía de cómo ellos trabajan y cómo comunican, cómo hacen los ciclos de desarrollo. los filtros que tienen para desarrollar fichos. Esto es lo que hace especial a Basecamp. Luego hay cosas encima que creo que también son importantes. Lo que has dicho de los clientes que tienen, cómo contratan, etc. Pero basándonos en ShapeUp, diseñadores y programadores creo que tienen mucho que aprender de este documento. De hecho... Ellos lanzan un concepto que me parece interesante, que es el de apetito, y básicamente vienen a decir que el apetito es lo que pueden impactar al usuario final o al negocio desarrollando una feature. No tanto la estimación de cuánto les puede llevar. Es esta contraposición de... de frente a otras metodologías que pueden tener ciclos de una semana. Sí, que el enfoque es más el tiempo y el arroar de ello. Exacto, no tanto ese impacto en el usuario o el impacto en Basecamp, pero al final ellos también lo ven como algo más abstracto, me parece a mí. Es algo como esta feature estéticamente se ve bien, es funcional y luego que ellos son como muy concretos, no quieren desarrollar un calendario que tenga todas las features posibles. Ellos van a un caso de usuario y hablan con el usuario. De hecho, ponen el ejemplo de, llaman al usuario, le preguntan qué es lo que realmente necesitas, cuándo lo necesitas. Le preguntan el tiempo para saber exactamente si pueden incluirlo en el siguiente ciclo. Ellos no tienen sprints, ellos van por ciclos de seis semanas. Entonces, una vez definen que es posible incluirlo. porque pueden desarrollarlo con los recursos que tienen, lo hacen, ¿no? Pero no dicen, venga, quiero crear user notifications para grupos. Entonces, esta feature creemos que nos va a llevar X semanas. No, dicen, vamos a desgarrar la feature. Sí, lo descomponen, lo descomponen. Y eso no tiene que ser crazy at work. Lo mencionan mucho, ¿no? ¿Por qué seis semanas? Porque dice, se mantiene enfocado, ¿no? O sea, si el feature es demasiado grande, lo separan, lo desgranan y lo pasan a seis semanas. Tiene que encajar en esas seis semanas, ¿no? Y en esas seis semanas tiene que estar todo. O sea, QA, ponerlo en producción. Entonces, en seis semanas, pues realmente, de desarrollo a desarrollo, va a haber tres semanas. Más o menos, aproximadamente cuatro, ¿no? Y el resto es, pues... Que el copy, que los ya, el pixel perfect que le llaman, ¿no? Los diseñadores. Que tanto aman los programadores a veces. Pero creo que ese es una pieza crucial, ¿no? Creo que muchas veces, por ejemplo, no sé, hay gente que le llaman sprint a un release de tres meses, por ejemplo, ¿no? Lo cual es, pues, en teoría no debería ser, pero hay veces que sí lo hacen así, ¿no? Y creo que eso... más que nada es el reto que tienen las grandes empresas de cómo pueden de cierta manera emular la agilidad de una empresa como Basecamp, ¿no? O sea, creo que sí es un buen ejemplo a seguir. Y ShapeUp sí es un documento que puede... No sugerimos tampoco que esto va a ser el... ¿Cómo se puede decir? Me quería... Iba a mencionar unos libros religiosos, pero mejor no lo voy a mencionar. No es tanto que sea el modelo a seguir para... todas las SaaS en el mercado. Claro, claro. Esto es su forma de trabajar. Evidentemente, yo, como he dicho al principio, no estoy de acuerdo con todo lo que hace Basecamp o lo que dice, pero sí creo que cada vez que leo algo o escucho un podcast de Basecamp, me hacen replantear mis propios argumentos. Y es bueno tener también metodologías propias. Es que empiezas a tener la conversación con tu equipo, ¿no? Con tu equipo y con tu organización de si la manera que están ustedes desarrollando software... sobre todo si es software en la nube, es la correcta, ¿no? O más bien, ¿qué necesita mejorar? ¿Dónde está el elefante en el cuarto, no? Que muchas veces, generalmente son personas. Ahí llego y regreso a lo de ShapeUp, ¿no? O sea, ellos se enfocan mucho en eso. ¿Sabes qué? Es un proceso donde están involucradas personas, donde hay cuatro stakeholders, donde cada uno tiene su perspectiva y donde cada uno tiene algo que aportar y sobre todo tiene algo que aprender, ¿no? Hay un tema también que mencionan en el ShapeUp y es cómo ellos tratan los tickets o de alguna manera no los tickets, sino cómo priorizan ellos las tasks. Ellos no usan un sistema de ticketing como podemos usar con el ecosistema Atlassian, sino más bien se basan en lo que ellos llaman Hill Charts, que son diagramas básicamente donde se muestran las tasks y un poco de lo desconocido a lo conocido. Hacen el diagrama, eje... eje X, eje Y y van pues según lo avanzado que esté esa tarea, la van moviendo. Y eso pues de alguna manera simplifica un poco tener que actualizar constantemente el estatus de la tarea y tal y luego también para los managers o los líderes les facilita el hecho de poder ver el diagrama y decir esto necesita de mi aporte, de mi apoyo porque está estancado, voy a echarle una mano a este equipo. Y creo que, bueno, es válido. Yo no lo he visto en otra empresa, lo de los Hillcharts. No sé hasta qué punto puede ser demasiado simplificado para una organización grande porque entran muchos tickets y tener miles de diagramas, no sé hasta qué punto... No, en hacerlos, ¿no? O sea, simplemente mantenerlos, ¿no? Obviamente ellos ya tienen un programa. Exacto, es una picha que ya crea esto, ¿eh? Sí, sí, sí, pero... No, definitivamente para nosotros los mortales que tenemos Jira o que tenemos Pivotal Tracker, definitivamente o Trello, eso es inviable, ¿no? O sea, es la verdad. Creo que el tema de los tasks depende de cada equipo, porque hay equipo que o necesita mucho contexto, en algunos casos muy visual, en algunos casos muy, ¿cómo se llama? Heavy on text o muy verboso, ¿no? Entonces ahí depende, ¿no? De cada equipo que es... Y sobre todo de cada... Es que al final es... Volvemos a lo mismo. Es cada persona, cada individuo, ¿no? Según su expertise y su nivel de experiencia también, ¿no? Entonces creo que... Pero bueno, regresando a lo de ShapeUp. Algo muy importante aquí que ellos también hacen en este documento es describen un poco el rol de cada una de las personas que están... Que van a... Que intervienen en la decisión, ¿no? Este, creo que en la mayoría de los equipos, y lo digo también en el equipo donde trabajamos en NIRSOC, muchas veces nos falta esa claridad de dónde limita tú, dónde está tu área, ¿no? O sea, de qué eres stakeholder, ¿no? Define bien de qué eres stakeholder, ¿no? Y muchas veces no lo defines en el equipo. Cae eso así como por arte de magia muchas veces, ¿no? Y creo que también eso es algo importante que el equipo tiene que dialogar, ¿no? y de cierta manera también ir poniendo, ir plasmando en un proceso. Sí, a mí algo que me gusta mucho de Basecamp y creo que elimina mucha frustración en programadores y en diseñadores es el hecho de que no tienen tanta planificación, no tienen tanto management, como que eliminan esa capa de management y a lo que se enfocan es a lanzar y a la ejecución. Ellos no tienen daily stand-ups. ellos no tienen sprints, ellos lo que hacen es todo este proceso de pre-shape-up, el shape-up, todo lo que está en el pitch y lo que aprueban luego el equipo de líderes y empiezan a trabajar en ello. Tienen un ciclo de seis semanas y cuando lanzan esa feature están felices. Si no la lanzan, hay un problema. Ellos dicen que no vuelven atrás. No sé qué pasa en ese estado de... Pero ellos consideran que... haciendo todo esto que hacen antes de aprobar la feature, tiene que lanzarse. Yo no sé más porque no estoy dentro de la empresa, pero me imagino que les está funcionando. Yo considero que esto es posible si hay mucha autonomía. De verdad, lo repito otra vez porque un desarrollador con menos experiencia o un diseñador que necesita más apoyo O un Product Manager, ¿no? Que, bueno, pues, o sea, yo creo que en Basecamp esta noción del self-service, de hacérselo uno, pues, está muy desarrollada y afortunadamente pueden hacerlo. No, y obviamente ellos tienen el lujo de tener un liderazgo que pocas empresas tienen. Esa es la realidad. O sea, por ejemplo, en Atlassian, ya los co-CEOs, ellos no se ven involucrados para nada. Ya están más en tema operativo. Y aquí en Basecamp se ve, obviamente, que están ahí metidos. O sea, Jason Fried, este... David. Sí, David, están ahí bien, están metidos, o sea... Sí, David es este tío y es también el creador de Ruby and Rails. De Ruby, entonces, creo que ese es el tema, o sea, por eso les funciona, hay un muy buen liderazgo, obviamente el tema de la cultura lo tienen al 100, ¿no? Y creo que eso es algo que también plasma muy bien ShapeUp, ¿no? Como que plasma muy bien los KPIs que tienen cada quien, ¿no? O sea, a nivel individuo, a nivel equipo. y ponen sobre todo un ETA, ¿no? O sea, ponen esta... O sea, todos es en seis semanas. O sea, no hay ni más ni menos, son seis semanas. Entonces, esa restricción les permite tener esa claridad, ¿no? Y sobre todo esa transparencia. Sí, pues básicamente era eso. El libro, esto, tiene 14 capítulos. Los vamos a poner en la descripción, vamos a poner otros links también de Basecamp, que creo que tienen una cultura que puede ayudar mucho a equipos de producto. Pues hablar de temas que quizá preocupan y que ellos lo han solucionado o proponer nuevas maneras de hacer las cosas. Creo que Biscamp tiene su propia manera, no queremos decir con esto que haya que hacerlo así o implementarlo de esta manera, pero que si el equipo en el que tú estás se ajusta a esto que hemos dicho, puede tener ciclos de desarrollo de este... Este tiempo, el tamaño del equipo también, pues yo creo que puede ser una buena idea. Sí, más que nada una introspección, ¿no? O sea, el libro es lo que invita, ¿no? Obviamente emular es muy difícil, pero sí ya tienes introspección y también tomar aquello que puedas tú aplicar en tu equipo, ¿no? O en tu empresa, o en tu startup. Y bueno, yo lo que sí me llevaría y que recomendaría sobre todo es el tema de las seis semanas, ¿no? Sé que muchas veces no se puede, porque ellos dicen, bueno, pues, si trata siempre de, bueno, ellos lo ponen como seis semanas, fijo, ¿no? Entonces, a veces nosotros no, o sea, a veces yo, hacemos una estimación para no ser un nuevo producto y son ocho semanas, por ejemplo, ¿no? Este, pero cuando son features, seis semanas, creo que este es tiempo de más. Entonces, está muy padre, denle la de ida. Sí. Este, y bueno, Dani, ya viene el verano. Viene el veranito de agosto, vamos a descansar el podcast. Sí. pero queremos volver en septiembre y como siempre os animamos a que nos sugiráis nuevos tópicos, invitados, estamos abiertos, nosotros nos enfocamos en desarrollo de software. Sí, creo que también aquellos Product Managers, Product Owners que estén por ahí que nos escuchen, mándenos un mensajito, no tienen que ser rockstars para nada, nada más si quieren compartir su opinión, estamos aquí. Por favor, déjenos sus comentarios, síganos en las redes sociales, ya saben, es sashat, chatsas, perdón, en Twitter. Y sashproductchat.com en la web, ahí tenéis todos los episodios. También estamos en YouTube y en todos los feeds de podcast, aplicaciones de podcast, Breaker, Apple Podcast, Google Podcast, etc. Muy bien, nos vemos bien. Buen veranito, maestro, por fin. Nos vemos. Un saludo a todos, chao.

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 accionariado: https://www.breaker.audio/the-knowledge-project-with-shane-parrish/e/44654277

- Basecamp está cerrando su oficina en Chicago porque su trabajadores​ prefieren el trabajo remoto. La pregunta que se hacen ahora no es qué oficina reemplazará la actual, sino si realmente necesitan una... Probablemente prueben un año sin para ver cómo va: https://rework.fm/office-space/

- Kristin Aardsma es líder de soporte en Basecamp. Recalca por qué es tan valioso repensar cómo funciona el servicio de atención al cliente y asegurarse de que estás humanizándolo y no dar la sensación de que lo manejan robots: https://m.signalvnoise.com/People--Not-Robots--Bringing-the-Humanity-Back-to-Customer-Support/