Sprint: Review of the book

Sprint: How to Solve Big Problems and Test New Ideas in Just Five DaysSprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp

In January 2018 I will be taking part in a Design Sprint, and I’ve been reading the book to dig into the details. Only then I will feel I have all the information needed to rate the book since it is basically a practical guide to put the methodology in practice.

Although there is mostly step by step instructions (well explained), there are also some good bits and pieces that are valuable on their own. One of my favorite was a chapter on prototyping where they talked about what they refer to as “The Prototype Mindset”; after listening to the chapter I ran a Google search and found this post by Eric Ries with an excerpt of precisely that part, so go ahead and read it yourself: The Prototype Mindset.

I will come back to this review after running the sprint and share here my perception of the book after putting into practice.

View all my reviews

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.


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.