Book Recap: The User Experience Team of One by Leah Buley

TL; DR: If you want to do user research but don’t know where to start and could use a collection of no-nonsense tools that focus on practicality instead of formal correctness, consider picking up this quick read.


The User Experience Team of One by Leah Buley is written for a specific kind of person.

If you’re a part of a mature product team or your company has one, this book might not be for you.

But if you need to be able to go from idea to a solid, research-backed product spec without much help and don’t have a ton of experience, this is absolutely the book for you. A few scenarios where it will come in handy:

  • You’re working on a side project and want to take it to the next level without leaving your day job.
  • Everyone is suddenly asking you to “provide a strong vision” and a “crisp roadmap” without giving you a lot of specific direction. You’re not sure where to start.
  • While you historically relied on your intuition to figure out what you (and your team) should work on, for whatever reason, that is no longer working.

If this sounds like you, you could benefit from this book.

If you don’t have the bandwidth to read an entire book but would still like to learn a bit about how to do user research in the next five minutes, read my Poor Man’s Product Research Tips post instead! 😏

Format & Contents

The majority of the book is a collection of practical UX research and design tools & practices, organized based on where in the overall process they come in. There are also a bit boilerplate-feeling, “what is user research?” and “how can I grow as a UX person?” chapters that seem safe to skip for most readers.

The parts of the process the tools & practices cover:

  1. Planning & Discovery introduces methods like UX Project Plan or Strategy Workshop to help you set the overall project goals & rough direction.
  2. Research lists methods that take you through conducting user research and information synthesis.
  3. Design goes over essential design tools like Wireframes and Task Flows.
  4. Testing and Validation helps you validate your designs through Black Hat Sessions, UX Health Checks, and more.
  5. Evangelism shares tips on leveraging artifacts you produced throughout the process to spread the UX gospel in your organization.

Altogether, the tools & practices portion of the book is around 140 pages.

The Good Parts

The User Experience Team of One is a great book to give you a quick sense of the glaring gaps in your UX design process. It also helps you patch them by providing practical tool ideas you can quickly put into practice. After finishing the book, you will likely walk away with a few concrete ideas you can try in the following weeks or months.

The book presents all tools with a consistent structure that makes the book a great reference. I especially appreciate the inclusion of:

  • Average time Being explicit about how long something should take makes it easy to prioritize where to put your effort.
  • Try it out – Step-by-step instructions make a bulk of each tool’s description. The steps are always clear and easy to imagine.

If you suffer from imposter syndrome as a product manager, this book should help. You are likely already doing a fair amount of the activities mentioned in the book. Seeing that you are not that far off in your process from someone who has written a book on the topic and most of the gaps in your process are relatively straightforward to patch should make you more confident about the level of your product work.

Lastly, if you like paper books, do yourself a favor and get it in paper format. It’s full color, quality paper, and lots of fun to leaf through. Mine arrived only after I wolfed down the ebook, and I wish I had waited for the paper book as the ebook doesn’t contain any of the visual flourishes of the paper edition.

The Bad Parts

The book was written in 2013, and part of it feel stale. Picking up the book, I expect that the problem area will lend itself to evergreen content well, but there are two areas where the book shows its age:

  • If you work remotely… – These sections are written in an era where working remotely meant you were working alone, detached from the physical office where the rest of your team is located. Therefore, the tips presented are impractical for fully remote organizations and doubly so for async ones.
  • Mentioned software tools – Figma has taken the world of design by storm, and many of the tools mentioned in the book feel a bit obscure at this point.

The second thing to mention is that at 39USD for an ebook, the book feels relatively expensive given the rather casual nature of its content. At the same time, this is a book for a particular market, which makes the price feel more justified.

Note to Europeans: Avoid ordering from Rosenfeld if you can. They are very slow to ship and send books from the UK, making it likely you will need to pay a not-so-small import tax.

Biggest Takeaway

If you’re not talking to your current or prospective users, find someone to talk to and schedule a call this week.

Before you get your bearings, ignore articles about selection bias, unrepresentative sample sizes, etc. Instead, focus on getting the ball rolling. Remember that since your research techniques are not rigorous, you still need to apply your product taste to check them, and you’ll be fine. Once you feel comfortable scheduling calls and talking to real people about your product, you can gradually add more rigor to your process.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!


Book Recap: An Elegant Puzzle by Will Larson

An Elegant Puzzle: Systems of Engineering Management by Will Larson is an excellent entry into the growing collection of books by Stripe Press.

The book is a personal narrative of leading larger technical organizations. It presents the author’s take on some of the most crucial challenges like organizational design, the hiring pipeline, career narratives, and product work.

In this post, I’m trying to pick out some of the best gems I’ve found. There’s a lot more to the book than I’m covering here; it’s a worthwhile read.

Four States of a Team(‘s Technical Debt)

Technical teams can be in one of four stages of technical debt.

Understanding the current stage helps the manager pick the right approach to guide the team along the progression curve.

  1. 😩 Falling Behind – The team is taking on technical debt. The system fix is to find quick wins and keep up the morale while hiring more people.
  2. 🤹‍♂️ Treading Water – The team is not taking on more debt, but it’s not repaying it either. The fix is to limit work-in-progress (kanban can be a great tool here!) and ensure that team members primarily look at the overall team performance instead of their individual one.
  3. 👷‍♂️ Repaying Debt – The team is paing down technical debt. Support the team by giving them more time to continue debt repayment and look for easy user-facing wins to prove to stakeholders that the team is not staying still, alleviating external pressure to stop focusing on debt repayment
  4. 💪 Innovating – The team’s technical debt levels are low and they are free to move quickly and innovate. Maintain slack (i.e., don’t aim for 100% utilization), innovate, and ensure that innovation is valued within the broader company

Grow Teams in Bursts

After each hire, a team undergoes a gelling process, i.e., going through forming-storming-norming-performing. Adding new hires disturbs this process and resets it to a degree.

For that reason, the author recommends going through “growth spurt” periods with periods of low hiring activity in between. This approach gives teams time to gel fully before adding more members that restart the process.

Ad-hoc Communication

Ad-hoc communication is a know productivity killer. Asks for help, feedback, troubleshooting assistance, external communication takes a lot of time.

The recommended setup is:

  • Funnel all team interruptions into an ever-smaller surface and automate aggressively (i.e., ask people to file tickets instead of having ad-hoc conversations)
  • Create a rotation of people that manage this communication surface

On a side-note, at Doist we handle this by having a “hero role”, which is a similar concept. We have a blog post if you’re interested in the details!

Goal Definitions

A good goal has four parts:

  • A target to reach
  • A baseline that defines the current state
  • A trend that describes the current velocity if no action is taken
  • A time frame in which the target should be reached

An example of a good goal would be: In Q4, we will improve the 2nd-day retention of our plugin users from 15% to 25%. Since the launch of the plugin, the retention has remained static at around 15%.

When defining goals, setting a countervailing metric can be useful to prevent focusing solely on reaching the target to the detriment of other metrics.

You can read more about goal setting on the author’s blog.


Lastly, here are a few snippets from the book that are interesting even outside of their context:

  • There is a lot less competition for hard work. When discussing how to grow professionally, the author points out that it can be more useful to picking up new work areas instead of focusing on the formal career ladder. EDIT: I kept thinking about this one and have written a subsequent blog post about it here.
  • It’s one thing to know that you’ve never used your education budget, and something else entirely to know that you’re the only person who isn’t using it. Showing people where they fall on the distribution to make a strong point.
  • Treating your peers as your first team allows you to begin practicing your manager’s job, without having to get promoted into the role first. This rings true with my experience! Taking on your manager’s work leads to closer collaboration with the manager as you’ll get insights into the problems your manager is having.
  • Rather, that approach (weeding out folks who don’t show passion about their work during the hiring process) seems to mostly filter for candidates willing to represent enthusiasm, as opposed to finding authentic passion. Something I’m always mulling over when discussing the hiring process as there’s frequently contention about this point.
  • Because (career) level expansion is typically driven more by the need for career progression than by the introduction of objectively distinct accomplishment, levels added at the top create downward pressure on existing levels. Expectations at a given level decrease over time. Having worked intensely on career definition in the past year, I’m curious if this statement will turn out to be true.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!

Cover Image Credit: Photo by Jeffrey Blum on Unsplash


Book Recap: Scrum, The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

One of the strongest books I read this year. Well written and to the point, it dives deep into motivations behind the elements of Scrum.

While the book focuses on “pure” Scrum, many of its ideas are applicable beyond Scrum as well.


Scrum is a way to build fast-moving, cross-functional teams. Some of the basic elements are:

  • Team performance is the main focus. Measuring individual performance is not a core part of Scrum.
  • Gain commitment and speed by time-boxing. Time-boxing is the practice of assigning work to a specific iteration. Every iteration has an equal, fixed duration. In contrast, Kanban achieves commitment and speed by constraining work in progress. More on that my next post 🙂
  • Relative estimation is the preferred method of sizing up work. The core idea is that relative comparisons of task complexity and size are less error-prone than estimating effort in hours.
  • Teams determine their capacity by looking at historical performance, called velocity.
  • Commitment to continuous process improvement is a core part of Scrum. Every iteration should yield ideas for further improvement in the process. These small improvements are called kaizen.
  • Scrum measures team happiness by the end of each sprint. Happiness is a leading indicator of future performance. According to Andy Grove, tracking and evaluating leading indicators is one of the most critical activities a manager should do.
  • Road maps are loose visions at best. The actual plan changes from sprint to sprint based on learnings from past sprints.

Further reading: Microsoft published a research paper that discusses practical concerns of implementing Scrum in software engineering teams. It’s a good read.

Solid Ideas

Shuhari 守破離. Breaks down mastery of Japanese martial arts into three stages.

  1. In the first stage (守), you obey rules without question.
  2. In the second stage (破), you experiment with breaking the rules and making them your own.
  3. In the final stage ( 離), you become the physical manifestation of martial arts ideals, rendering the rules irrelevant. This is an amazing way to think about learning any kind of system, including Scrum.
Image for post

Cross-functional teams. Small autonomous teams, also called feature teams, are the best way to organize work if you want to move fast. Instagram recently moved to this model. There are a few reasons for this kind of team:

  • Hand-offs between teams are an opportunity for disaster. Hence you need your feature teams to be cross-functional
  • The goal is set outside the team, but only the team decides how to achieve it
  • The marginal value of adding the 10th team member and above is negative

Use Planning Poker for effort estimation. Planning poker gets the best of the team’s collective wisdom when estimating. At the same time, it helps with preventing herd mentality and can surface diverging perspectives on implementation.

Process improvements are a part of the process. Kaizens are a fantastic idea for two reasons. First, by making process improvements a core part of the process they’re improving, you can make sure that they get priority. Second, by making it explicit that everyone needs to come up with kaizens, you increase the chance of soliciting good ideas from teammates.

The product owner needs to have enough time for the role. Jeff Sutherland recommends against appointing senior executives to be product owners. The reason is that a product owner is a time-consuming role. Senior executives tend to be time-constrained, so they might not be the best fit.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!

Cover Photo Credit: Photo by Quino Al on Unsplash


Book Recap: High Output Management by Andy Grove

High Output Management is a collection of recipes for squeezing more performance out of your organization.


The output of managers is an output of organizational units under their control or influence. All focus should be on increasing team, not personal, performance.

A lot of Andy’s bear similarity to SCRUM. Both seem to be influenced by Toyota. Both focus on continuous process optimization and setting up a system that keeps people challenged and motivated.

Solid Ideas

Impacts of defective products are impossible to predict. So, any compromises on quality are unacceptable. Recognizing it can lead to a big change in prioritization patterns. When you recognize reliability as an attribute that cannot be compromised on, saying no becomes easy. Since we decided to make reliability a priority for our Todoist for Windows 10 app, saying a confident no to projects that would divert our focus has become much easier.

A manager’s day ends when they’re tired and ready to go home, not when they are done. Managers are never done. It’s a feeling that’s hard to escape. Setting more explicit daily/weekly goals could be a good start to mitigate this feeling.

Eliciting peak performance means going against something or somebody. This is an idea shared with John Legere, T-Mobile US’s CEO. Having something to compare against can be a powerful motivator for some people.

During performance reviews, assess actual performance, not potential. Andy is very strict about assessing a person’s performance. Talking about potential is best left for 1:1s.

Finding a way to create such opportunities could help create a more aligned and connected organization.


Book Recap: Work Rules! by Laszlo Bock

Work Rules! talks about the principles and practices applied by Google’s people ops team. It paints the picture of a data-driven, risk-seeking culture that’s willing to experiment and takes advantage of its scale by mining internal data to improve employees’ lives.


Let’s try to make people ops act more like a software organization. Select small groups of employees to test new benefits, don’t be afraid to iterate on ideas. When something doesn’t work, scratch it right.

Use data about your organization heavily. Employee satisfaction surveys, compensation data, percentage of pull requests accepted without the need for revisions and other data points.

People Ops should have the capability to integrate data from across the organization, analyze them, set metrics and come up with actionables. But don’t lose your soul. Keep in mind that keeping your people happy is always your ultimate goal. If you achieve it, the score takes care of itself.

Solid Ideas

Treasure and analyze your best performers. The top 10% of your people are not better than the average by 10%, but by 1000%. Reflect their performance in the way you treat them. This approach is somewhat contrary to the current industry trends, where equal pay seems to be the ultimate goal.

Google’s approach to unequal compensation should be adopted carefully. People from cultures where modesty is valued could be uncomfortable with being publicly called a top performer and being compensated differently than their peers.

Aside from paying top performers incredibly well, you need to put them under a microscope. The differences between your best and worst tell you how you can help your weakest players. That requires you to measure a host of different employee behaviors, which many organizations do effectively.

Use non-cash awards for better employee happiness. Awarding non-cash prizes such as team trips or fun hardware makes people happier in the long run than giving cash even if they tell you otherwise in the beginning.

For committee-based processes, calibration is vital. When you set criteria for candidates or performance evaluations, it’s key that committee members agree on a baseline. E.g., the baseline for an optimal hiring goal can be an existing employee.

Create easy-to-consume resources for your managers. The quality of managers is the most significant determinant of employee retention. Invest in your managers by giving them dead-simple tools to help with everyday activities (e.g., checklists for good career conversations). Give managers data that helps them understand what holds their teams back and what they can do about it.

Help your people with routine tasks, let them focus on the important stuff. Mundane activities take away your focus from critical work. Where possible, manage routines for your people (on-site hairdresser) or give them nudges to improve their behavior (make saving part of their income the default choice).

Interesting Tidbits

  • Veterans’ Affairs is a fantastic resource for interview questions.
  • Keep the compensation and performance conversations separate to prevent people from getting defensive when you suggest improvements.
  • Google’s Project Oxygen identified what makes a manager an amazing manager. It’s one of the more actionable lists of its kind you’ll see.
  • “Most companies celebrate promotions but do nothing to reach out to people who missed the cut”. This feels like a low-hanging fruit that could make a lot of difference.

Book Recap: Agile Project Management with Kanban by Eric Brechner

In classic Microsoft Press fashion, Agile Project management focuses on execution and pragmatism. To that end, I’ll structure this recap a bit differently.

Overall, where Scrum feels like a structured approach with an eye on speed, Kanban feels like a flowing river. There’s no time-boxing. Instead, Kanban focuses on creating a clean and narrow channel for your work to flow though.

Let’s take a look at the Kanban process.


The core idea of Kanban is similar to what Andy Groove talks about. Find your limiting step and optimize the rest of the process around it.

Here are the basics steps, simplified for brevity:

  1. Define the steps of your process. Specify, Design, Implement, Test, Release might be a good start.
  2. Find your limiting step. It’s the one that determines the throughput of the system as a whole. For Doist, specify and design is frequently where we spend a significant portion of the process.
  3. Optimize your limiting step. I. Break it down to multiple steps; II. Increase throughput if necessary (i.e. deploying more resources); III. shorten it (this is called elevating the constraint)
  4. Define done rules for individual steps. For coding, it could be e.g. Code complete and unit tests pass
  5. Calculate WIP (work in progress) limits for individual steps. Start low and increase the limits where necessary.
  6. Visualize your process as a board.
  7. Create an ordered backlog
  8. Let the work can start flowing
Image for post
A simple Kanban board in VSTS

After you set up the process, you need to fill it up with work. A frequent way to do this is to define an MVP (Minimum Viable Product). How do you know what fit’s in the scope on an MVP tho’?

Determining MVP Scope

All task are sorted into four priorities:

  • 0 — Must be included in the MVP. To determine these, ask the question: “Would we really hold up the release for that?”
  • 1 — Should be in the MVP
  • 2 — Would like to have in the MVP
  • 3 — Would be nice to have it in the MVP

Having work item buckets like this should make the backlog ordering much easier and enable you to react when the scope needs to change.

Comparison with Scrum

If you’re not familiar with the essential traits of Scrum, it might be worth skimming my post about Scrum before continuing.

In some ways, Kanban shares a lot of traits with Scrum, but they have significant differences as well.

Effort Estimation

Since Kanban doesn’t have time-boxing, effort estimation might not be needed at all in a lot of cases. Instead of the burn-down chart in Scrum, Kanban works with the Cumulative flow diagram.

Image for post
Cumulative Flow Chart in VSTS

There are a few things going you can see from the chart:

  • How much you’re shipping over time.
  • Is your backlog growing or shrinking over time? Seeing that the backlog is growing no mater how hard your team tries might not be best for motivation
  • How much work is in progress right now and in what stages

Notice that the unit of the Y axis is Work Items Count. If this was Scrum, it’d say Story Points. But Kanban doesn’t work with Story Points.

Instead, Kanban assumes all tasks are roughly equal in size. This means that in practice, 1 task = 1 story point. From there, you can easily deploy estimation methods like wideband Delphi in case you need to. The only difference is that you go from “How many story points will this user story cost” to “How many tasks will this feature result in?”.

Late Binding

In Scrum, you can choose whether you assign team members to specific user stories or tasks as part of the sprint planning meeting or if assignment happens organically during the spring.

In Kanban, late binding seems more mandatory. When a team member finishes a task, they should ideally take the top one from the backlog.

It’s going to be key in Kanban to make sure people still work on stuff that excites them instead of working on an item simply because it was on top of the queue.


In Kanban, there are no sprints and in extension, no sprint retrospectives that generate kaizens. Instead, Kanban relies on WIP limits to expose friction and create motivation to fix problems. When work starts piling up in a specific step, it’s time to start asking questions.

Daily Standups

The assumption of daily standups is an Achilles’ heel of both Srum and Kanban from a remote team’s perspective.

A major advantages that remote teams have is that members can do deep work for days at a time without any distractions. At least for us at Doist, this makes daily meetings a no-go.

We will need to experiment with this at Doist Windows, but initially it looks like Scrum will be more welcoming to dropping the meeting requirement. Time-boxing creates strong commitments, sohaving a single meeting per sprint to do planning as well as retrospective could be enough. For Kanban, the daily standups feel a more key as it’s the main vehicle to discuss kaizens and re-prioritize work when needed.


Eric had a few interesting remarks that are not strictly related to Kanban, but still peaked my interest 🙂

  • Developers tend to pick a workflow that works for them and stick with it. This is usually a workflow they learned in their first professional experience.
  • The role of a product manager at Microsoft combines the responsibilities of a project manager and a business analyst.
  • There’s a difference between continuous deployment and continuous delivery. Continuous deployment is deploying every build to production while continuous delivery still leaves the decision which builds to deploy to production up to the user
  • When coordinating work across multiple teams, regular weekly meetings with progress reports and plan adjustments are useful. It’s like a scrum of scrums
  • Internally marketing working on support issues as a fantastic way to get to know both the product and the customer is a smart idea
  • A ton of our processes as a human race could be vastly better if reengineered from the ground up. The problem is that as systems develop over time, most of the focus is put on local optimization, but global optimization is tough to achieve

Cover Image Credit: Photo by Joseph Greve on Unsplash