Book Review: “Radical Candor” by Kim Scott

Radical Candor: Be a Kickass Boss Without Losing Your HumanityRadical Candor: Be a Kickass Boss Without Losing Your Humanity by Kim Malone Scott
My rating: 5 of 5 stars

Before reading this book I felt I had some pieces of a big and difficult puzzle. While I read it I managed to validate this, but I also realized how incomplete my picture would have been had I known how to organize the pieces.

In other words, I understand better now where the practices and techniques I was putting into action fit in the vast and complex world of people’s management. More importantly, I learned a lot of new ones that I can try as I find the need to develop in an area or another with my teams.

The book was both rational, and emotional. I loved that. It gave me objective indications (of how much time to spend on something, or in where to start from with the areas to cover, for example), but also left space to use my intuition and reminded often that people are different, and difficult (or easy), contexts are also unalike.

As for the format: I went once more for an audiobook (this must be the fifth book I listen). I was not particularly happy with the voice of the author (she narrated herself), but as with Extreme Ownership, I quickly stopped paying attention to that detail and started being captivated by the lots of good lessons she had to share (and the voice was not as extreme as the ones in Extreme Ownership ;))

Another book I would like to revisit at one point – although I must confess I lately think too much about how short life is to revisit a book 😀

View all my reviews

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

Sprint: Review of the book and first design sprint XP!

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

Before running a design sprint

(December 4, 2018)

Sprint: 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

Update: After my first design sprint!

(January 27, 2018)

Last week I finally took part of my first design sprint and I have to say: it was worth it!

The initial promise was real and immediately perceived by all of us who took part in it, but the real value to the end users will come after we move forward with what just started, so the true test lies ahead. However, I can already feel that the framework helped us accelerate at a pace that would have been otherwise a thing of months.

The things that I believe made the framework work are all described in the book, but I see them in a whole new differently light after having put them into practice. Here’s a summary of the ones that stuck out to me and I hope I can convey their importance here even if you read this without having had yet the opportunity of experiencing a design sprint yourself yet:

  1. We chose each role very carefully. We considered them keeping in mind the fuzzy problem at hand and what we expected to do after the sprint if we succeeded in identifying the right goal and questions to answer. We were a total of 6: a facilitator, a decider, one designer, one developer, one product manager and one subject matter expert. We were a group of people that new each other a bit, but not too much, so we respected each others area, yet were free of biases that can build from knowing someone too well. What I mean is, we never knew exactly how someone would act or answer to something, and that kept us interested and open to what they were bringing to the table. Everyone was a true expert in their area, and had the right skills to perform each of the important tasks well: facilitating, designing, interviewing, etc.
  2. We all were truly interested in solving the problem, and had our own ideas, but we were all open enough to be surprised by whatever would unfold during the 5 days.
  3. The framework is full of techniques that we might have heard of before but tend to forget to apply in our day to day work. If we did, we would probably be more productive and more successful than we usually are. One very clear example of this: mapping the problem and talking to experts. A diagram says more than a thousand words. Having a visual representation of how we understood the problem helped us see were we saw things differently in a non-abstract way. Relying on the experts observations to modify the picture until we were all satisfied, rather than turning to ourselves in the group also helped us avoid endless and frustrating discussions.
  4. Doing real tangible work, and doing it all each individually, but then putting it all in a common bunch. The fact that we all, regardless of our role or skills, got to sketch and contribute directly to the solution was both refreshing and motivating. For those who don’t get to do it in their day-to-day work, it was exciting. For those who do, it was challenging and positively surprising to see how people in other roles also had ideas that made sense and contributed to the solution.
  5. Talking to real users while things were fresh: this was very reassuring. After four days of such intense work, being able to see in the same week the reactions and feedback of real users made the investment of the previous four days pay off. Even if we got things wrong, we could learn quickly. If we got it right, we felt hope.

There are another bunch of things that make this really useful. One thing to clarify: we followed almost all the book step by step, with some few small exceptions. Details matter (materials, location, considerations to choose the right people, planning ahead what would happen after).

It paid off, but as I said above, we still have work ahead of us to see the real results. But I would recommend to try it: if you have a complex, fuzzy problem, and you have the people to spend 5 days working together, fully focused on it, give it a go!