Dogfooding as a Pipedrive Product Manager

Eating your own dog food, also called dogfooding, is a slang term used to reference a scenario in which a company uses its own product to test and promote the product.[1]

I started actively thinking about how I ate my own dog food as a product manager when I started listening to the podcast This is Product Management. In there, Mike Fishbein (the host) always asks his interviewees a series of questions at the end of the show for their own reflection. One of them used to be “how do you eat your own dog food?” [it has been replaced now by how to learn about the topic of that episode].

It had always come naturally to me that if you work on creating, building, writing something, you always try it yourself to see how it came out. The problem is that you cannot always use a product for your own benefit because the product is trying to solve a problem that you don’t have. In this case, you have to make an effort and find a similar problem so you can truly feel you’re using the product with real purpose. Once you have a purpose, things start happening. You see the real value, you find the flaws, you think of ways to make it better. If you combine this with a constant effort to understand your customers point of view, their frustrations, what is important to them, etc… you almost start thinking like the customers, and so it’s easier for you to build something of value to them. You could also argue that thinking differently to them gives you a different perspective, which is also good.

That’s my experience with Pipedrive, where I work as a Product Manager: I am not a salesperson, so I don’t have a need to manage any sales pipeline in there. However, I do have people (colleagues, customers) that I have “deals” with (projects, events, roadmaps), for which I need to have an action plan. The action plan is my main focus at the moment: You see? My role has recently changed: I have more responsibility, therefore I am accountable to more people. It is critical to me that I spend my time doing the right things that will help my teams move forward, or that at least won’t get in their way.

Pipedrive allows users to create custom activity types, so what I did is I created activities matching the areas where I usually spend my time: Research, team events, planning, business trips, etc:

Pipedrive Custom Activity Types

Pipedrive Custom Activity Types

I plan my day and my week using the calendar in the app, and choose the corresponding activity type for each scheduled thing:

My weekly calendar in Pipedrive

My weekly calendar in Pipedrive

Whenever I plan an activity or mark one as done, this will be reflected in my activity reports. This is my favorite part. I can have a look at where I have been spending my time and make sure I adjust if I see I can be using my time more wisely next week. I can also take preemptive measures as I can also  see reports for planned things. So I don’t have to wait for things to go wrong before I fix them:

My activities report in Pipedrive

My activities report in Pipedrive

In the end I gain in two ways: I get to use the product I am responsible for in a really meaningful way to me, that allows me to learn about the product and about myself.

This is just one of the many ways in which I eat my own dog food. I do recommend product people doing the same if you are not doing so already.

If you are doing it, I’d love to hear some of your experiences and what you have learned from it? Or even better, do you think there’s something wrong with this approach?

Refresh Conference 2017: Key Takeaways

I spent last Friday at Refresh, a conference for Product, Design and Front End people that takes place every year in Tallinn since 2015.

I don’t go to conferences often, but when I do I like to come back with the feeling that I learned something new and that I interacted with fine, like-minded people. I like going home with a new vision on an old topic, a new topic to dig more into, or a new idea to try out.

Conference Swag: A notebook, pen and pencil which I used straight away to take my notes. A shirt, a cloth back, a card holder with RFID and stickers.

Conference Swag: A notebook, pen and pencil which I used straight away to take my notes. A shirt, a cloth bag, a card holder with RFID and stickers.

Taking handwritten notes is my way of making sure I can focus even when there’s a difficult or boring presentation, and it is how I can take out specific bits of useful information. I tweet some of that during the event to share the love with the online community; and when I return to work, I also write a quick summary of these things to share with my work mates (like this post). This last bit is something many of us are putting into practice in the Product & Design department at Pipedrive as a way of sharing knowledge.

I had been to the first edition of Refresh in 2015 with very little to no expectations and I left with a positive attitude. Presentations, content, venue, food and people were great. I couldn’t make it to the 2016 one, but this time around they managed to deliver again. While in 2015 the presentations were in one single stage mixing up all the topics, this time around they had two parallel tracks: one for Product & Desing; another for Front End. I spent the full day at the… guess? Product & Design one, of course.

Below is a summary of the key things I learned during my three favorite presentations. Things I assessed in these:

  1. The topic: was it of my interest and did the content deliver on it?
  2. The presenter: did she/he did a good job delivering the message?
  3. The slides: where they digestible and well-prepared?
  4. Applicability: Can I do something with this when I get back to work?

Here they are, from OK to the best:

Number 3: How to design Experiments that Don’t Suck

Presenter: Willie Tran, Growth Product Manager @ Dropbox

Willie is a very dynamic presenter (spoke too fast at times) and I personally like that style. I am interested in experimenting and research in general, since this gives great direction to my work as a Product Manager. Willie delivered 3 specific lessons all contextualized in his own experience running experiments at Dropbox. He started from emphasizing the importance of being methodic when running experiments, and he did so by quoting the Mythbusters:

He dissected the definition of the hypothesis and how getting it right is basically getting your experiment design right, since a hypothesis contains in a single paragraph the [execution] of your experiment, the [metric] you think will be affected by it and the [assumption(s)] you have. If you get those wrong, your experiment will not work.

While there were three lessons, I caught only two. I get easily distracted (which is why handwriting helps me as well) and I seemed to have been mentally elsewhere when he mentioned the second one. But here are the ones I got:

Lesson #1: Do not blindly follow successful experiments by others. Just because it worked in their context does not mean it is the right experiment for you to run. Basically, all those out-of-the-box experiment tools are not real sh*t.

Lesson #2: (dreaming of the next coffee break…).

Lesson #3: When do you give up experimenting? When you have stopped learning.

The main message of Willie is that experiments are useful not necessarily if they pass, but if you learn from them and, my own addition: if you apply those learnings. Experiment, learn, iterate, rinse and repeat. Quit when there’s no learning.

Number 2: Designing for Learning Applications

Presenter: Jonn Galea, Lead Designer at Lingvist.

Jonn was a very articulate and clean presenter. His presentation was neatly organized and went from one point to the next in a very logical way. This was great, but maybe because his tone of voice was too even all along or because it was the second part of the day, towards the end of his turn, it got hard to follow.

I chose to pay attention to this presentation because teaching is very dear topic to me (I was a teacher for five years). I could also relate with his approach and the work we do at Pipedrive.

Jonn talked about the importance of understanding what the process of teaching was like when building a learning application. He broke it down into steps that he then correlated with the process of product design. He also talked about the app as a teacher, and the user as a student. I could see the common elements with the work we do at Pipedrive, and I cannot imagine a product manager or a designer doing a good job without understanding the process of the work done by the professional or the person for which they are trying to solve a problem, or the role they play when using the app, or the app in itself. It is that bit of knowing the area of business in which you are that make some product managers or designer strongers than others.

I am not strong at all in sales, but if there’s a topic I have learned a lot about in the last two years that’s the one. The same happened when I was working for fintech software companies, and I’ll repeat it in whatever business area comes next.

Jonn’s bottom line was that to have a great foundation to build a (winning educational) app you need to have:

  • A product concept
  • Strong back-end, data,…
  • A great team
Coffee break

Coffee break

Number 1: Machine Learning from the Product Perspective

Presenter: Inga Chen, Product Manager at Squarespace

Inga was by far my favorite. She was dynamic, with a perfect pace (not too fast, not too slow), delivered clearly applicable information with beautifully designed and digestible slides.

Although many presenters are great at making Machine Learning sound like a couple of buzzwords that get randomly squeezed into their presentations, Inga delivered on what she promised. She covered:

  • What Machine Learning is
  • What problems are good to solve with it
  • What can product managers do when considering to work on a product with ML
  • Why we should care about ML

She quoted Arthur Samuel’s definition from 1959:

Machine Learning: Field of study that gives computers the ability to learn without being explicitly programmed.

Data is critical to building a Machine Learning Model, and this data should be ideally labelled. There are several problems that ML can help solve, but mainly:

  • Decisions with many outputs
  • Decisions with many inputs
  • Decisions at scale

One example she brought and that I noticed myself while using the app a few weeks ago were the Slack Highlights:

Machine Learning used in the Highlight feature from the Slack app

Machine Learning used in the Highlight feature from the Slack app

My favorite part was how she made clear what product managers needed to bring into the table when considering using machine learning in a product:

  1. The problems: we bring the problems that we think can be solved with the help of ML
  2. The data. We need to make sure we have the data needed to feed the model
  3. Alternatives: we need to consider alternative non-ML solutions, because this is a time consuming expensive approach. In most cases we will be able to solve the same problems with simpler tools / techniques
  4. This is what Inga highlighted as the most important bit if we went down the ML path: Designing for when the ML Model fails.

She also covered how a product development cycle was different when it was being built using ML and a bit that I much wanted to bring with me but could not capture (my mind was boiling with ideas at that point) was what were the converging trends that indicated why we should care about ML.

Overall

It was a lovely event and I feel I came with ideas and refreshed knowledge. I’ll see about next year, but first I need to get these new ideas and knowledge rolling.

Lo bueno y lo malo de estar con una startup: mi experiencia

SWG Demo Day 42Ya son 184 días desde que me embarqué en la tarea de explorar diferentes oportunidades con la libertad (e incertidumbre) de estar sin un trabajo fijo.

En resumen, no he llegado a ninguna conclusión. Supongo que eso es bueno. O tal vez no. Así estoy. Sigo dándome cabezazos con mis propias ideas, miedos y deseos. Inicialmente pensé que estaría en esto unos 3 meses, a lo sumo. O, más bien, planifiqué para tres meses que era lo que el presupuesto me permitía. Sin embargo, han pasado casi 7 meses y yo sigo en mi viaje.

Una de mis hipótesis era que trabajar en una startup me haría más feliz porque sería más emocionante, intenso, activo. Estaba lo suficientemente convencida de que una startup sería una buena elección como para rechazar una oferta estable en una empresa hace rato establecida.

Participar en tantos eventos de networking facilitó que me pusiera en contacto con una startup que estaba buscando un perfil como el mío: Investly. Un equipo pequeño, joven y diverso construyendo una plataforma para préstamos colectivos a pequeñas empresas, con visión de expandirse a varios países. Han pasado 6 meses desde que me uní al equipo, y he aquí un resumen de la experiencia hasta ahora:

Lo bueno

  1. El equipo es tan pequeño, pero la diversidad de tareas es tan grande que es fácil estar expuesto a una amplia variedad de temas nuevos. Desde que estoy con el equipo, he aprendido algo nuevo de finanzas, algo de tecnologías y algo de marketing y análisis de datos.
  2. Una amplia red de contactos: siempre estamos en la búsqueda de soluciones, recursos, ideas, respuestas. Esto nos obliga a estar en contacto con una red enorme de personas con diferente experiencia en diversos campos.
  3. El tamaño del equipo también implica compartir muchas cosas. Eso crea lazos cercanos más rápidamente que en una empresa grande. (Las relaciones personales tienen mucho valor para mí).
  4. Cualquier logro es motivo para celebrar: hay un futuro tan incierto por delante, y todos estamos apostando tanto, que cualquier cosa que logramos alegra mucho. Pasar de 3 a 6 usuarios, por ejemplo, es fabuloso. Es un número pequeño, pero es un crecimiento…¡del 100%!
  5. Autonomía: de nuevo, hay tantas cosas por hacer y tan pocas personas, que cada uno está obligado a responsabilizarse por mucho y confiar en el trabajo del otro. Esto da paso a tomar decisiones que en otros contextos estarían muy limitadas.
  6. Flexibilidad: usualmente las empresas tienen esquemas muy rígidos con horarios y espacios de trabajo. La falta de recursos de una startup (o la cultura de los fundadores) obliga a ser más flexibles con su equipo a cambio de motivación que suele significar ser más efectivo. (Nota: esto no implica prescindir de orden y coordinación entre el equipo, lo cuál es necesario para facilitar la comunicación y la disciplina que conduzca al logro de objetivos).

Lo malo

  1. La incertidumbre: aunque las cosas han salido bien, el cambio es muy lento para mi nivel de aguante (de 3 que yo podía a 7 meses que he estirado, ustedes me dirán). No sabemos quién estará mañana y quién no. Si llegaremos al número deseado antes de morir o no.
  2. La falta de recursos: ha sido difícil cerrar la ronda de financiación, aunque ha habido más de un grupo de inversionistas interesados. Si están familiarizados con el término bootstrapping, saben a qué me refiero.
  3. Trabajar con gente: lo de siempre. Independientemente del tamaño o etapa en la que esté una empresa, lidiar los unos con los otros es difícil. Es aceptarnos en lo bueno y lo malo. No ser fundadora sino primera empleada hace que a veces me sienta excluida de decisiones. Ahora se siente menos porque hay un nuevo miembro en el equipo, pero esto aumenta mi incertidumbre de a ratos y me pregunto cosas como:¿realmente quiero ser el  experimento de otro? ¿por qué no fallar con mi propio experimento?
  4. La responsabilidad: esto es bueno y es malo. Todos cargamos parte del peso que resulta en triunfo o fracaso. Hay días en los que te preguntas: ¿qué carajo estoy haciendo? ¿por qué no estoy tranquila en un trabajo estable con la mayoría de la gente? Pero ya ven, me gusta la aventura…

En general, los elementos positivos son más que los negativos. En cualquier lugar, me atengo a los puntos que resumían mi plan de acción hace 150 días y que aquí vuelvo a repasar:

  1. Tener paciencia. Contener las ganas de saltar a lo primero que salga por la presión financiera. La he tenido, pero se me está acabando.
  2. Seguir explorando opciones de forma activa y rigurosa. Lo estuve haciendo con menos dedicación porque me había concentrado mucho en el trabajo, pero a medida que aumenta la incertidumbre, vuelvo a enfocarme en la movida fuera del trabajo.
  3. Aprender cosas nuevas. Sigo aprendiendo. A veces menos, a veces más. Independientemente de la situación, espero que eso no cambie.
  4. Agradecer y aprovechar que tengo el apoyo de  gente que me importa, y sobre todo, de mi pareja. Sigo teniéndolo y soy feliz por ello, pero creo que nada es eterno.