Book review: “The User Experience Team of One” by Leah Buley

The User Experience Team of One: A Research and Design Survival GuideThe User Experience Team of One: A Research and Design Survival Guide by Leah Buley
My rating: 4 of 5 stars

I started reading this book when we were a small team of product managers and product designers in the job. Often finding myself stuck in how to go on about a problem, and seeing that product designers were always full of work, I wanted to learn some more specific things about UX that I could apply myself to help move forward things without waiting for someone who already knew how to do it. Doing research, sketching ideas, presenting results.

Suddenly the team around me started growing really fast, and very talented people were coming in to tackle the problems faster than it would have taken me to learn the best techniques to do it myself, so I abandoned it temporarily and focused on learning on the job, from real practice.

I am glad I came back to the book. While I don’t have the same urgency I did when I first chose it, I discovered the book is like a small treasure (or cheat sheet) that comprises a ton of practical techniques to do UX work, from problem definition, to delivering results. When I finished it, I immediately found myself applying at least three of the techniques, giving some of my work more meaning and structure than it had before I knew about them.

I am not a team of one. In fact, I think I am part of a privileged group that gets to work with people who have very clearly defined roles inside of the different areas that entail product (researchers, designers, data analysts). But I still benefited a lot from this publication. If you’re starting in product management or UX design, it will be really useful to get an overview and tips of how to go about certain things. If you’re experienced in this area, it can be a good way of getting an overview of big part of what your job entails and perhaps refresh some of the areas or skills you might have unintentionally let to rust or gather dust.

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?