Getting to “technical enough” as a product manager

“Why are you the product manager for search if you’re not technical?”

The question was posed with the blunt earnestness you come to expect of social interactions in the Valley. And it was a fair one, to the asker’s credit, though maybe not something I would have fired off within the first five minutes of meeting someone.

Conventional wisdom, and most job descriptions for product managers, say that candidates should have a “BA/BS in Computer Science or related technical field, or equivalent practical experience.” The latter usually means a side project you can point to and say “I built that.” There are notable exceptions to the rule, but being technical is still more of a must-have than a nice-to-have.

Recently, companies have started to reframe this requirement as “Product managers should be technical enough.” Note the language in these job descriptions (kinda fun to try to guess the company):

Though I’m a bit biased, I think this shift is generally a good thing, and will only accelerate as awareness of and demand for the role grows. Product management is as much art as it is science, psychology as it is statistics, big picture as it is the smallest of details. The day-to-day responsibilities, and technical bar, varies widely depending on the industry and size of the company, as well as the part of the product you work on. At the same time, the qualities that make someone a universally respected PM rarely have to do with technical expertise (“That’s a waste of a good engineer,” as some would say).

But the question remains—what does it mean exactly to be “technical enough”? How do you get there? And how do you build credibility with your team in the meantime?

When I transitioned from marketing to product management three months ago, I realized the internet had surprisingly little to offer on this subject. I want to share my experience trying to answer these questions while navigating the first 90 days as a PM at Pinterest, focused primarily on search. Hopefully it’s helpful to other PMs coming from a non-technical background, and kickstarts more conversation.

The rest of this post is broken out into two parts, reflecting my general onboarding approach:

  1. Establish a baseline of technical understanding and invest more over time.
  2. Build trust and credibility by figuring out how you can add immediate value.

Establish a baseline of technical understanding and invest more over time

First, what does it mean to be “technical enough” as a PM? There will be many opinions here, but I think of it as the ability to do the following, in order of difficulty:

  1. Trace a user issue (or set of issues) back to the underlying problem.
  2. Estimate how long it will take to build A vs. B.
  3. Anticipate implementation challenges with a particular proposal.
  4. Brainstorm potential solutions to technical problems.
  5. Identify opportunities that arise from new technologies.

The relative importance of these criteria will vary depending on your productit might be more critical for a consumer app to stay on top of new technology, for instance, while B2B companies should be extra mindful of project scope to hit scheduled release datesbut it’s reasonable to expect a PM to be able to weigh in on all these issues.

With a better understanding of where we need to go, the next question becomes how do you get there? Some steps that I’ve found helpful, roughly in order of importance:

Start from a place of curiosity

This is the only must-do on the list. A genuine curiosity about technical problems will take you a long way; without it, things are a non-starter. It’s possible to cultivate this curiosity to a certain extent, but I’d try and get signal here during the interview process. Ellen Chisa has a great post on this topic if you’d like to read more.

Appreciate the creativity inherent in engineering

This point flows directly from the one before. You don’t have to poke far below the surface to realize that, at its core, engineering is about creating something from nothing, and comes with all the messiness that’s part of any subjective process. Behind every effort to bring a feature to life, there’s an engineer making dozens of judgment calls, weighing subtle tradeoffs, and thinking through implementation details and edge cases. Failing to understand this dynamic deprives engineers of the autonomy and ownership needed to do their best work.

Set aside time early on to pick an engineer’s brain

Read everything you can get your hands on in the first few days, keep a running list of questions, and then grab a whiteboard and time with an engineer to run through them. Get enough of a baseline understanding to ask intelligent questions, but don’t put off the last part for too long. There’s only so much you can absorb from staring at a screen, and the initial investment of a team member’s time will go a long way.

Synthesize what you’ve learned into a shareable format

At this point you’re probably swimming in a sea of acronyms and scribbled diagrams. Synthesize all this new information by writing it up in a doc. Share it with new hires as an onboarding resource. Even better, find an opportunity to present the information to another team, e.g., give a Search 101 presentation to partner managers. This is a great way to test your understanding and highlight areas where you need to dig in more.

Use feedback and bug reports to pattern match different issues

Returning to our definition of what it means to be “technical enough,” the first criteria is being able to trace a set of user issues back to the underlying problem. One way to do this is by pattern matching feedback and bug reports.

As a PM, you have the honor of being first responder for product feedback. On any given day you might field multiple reports about things that are confusing or broken. A coworker slacks you, “Including apostrophes in my search doesn’t return any suggestions.” Then your mom emails, “Tried searching for ‘williams-sonoma’. Can’t find it :(”

If you’re organized with your issue tracking, two things happen over time:

  1. You pick up on the vocabulary that engineers use to discuss certain bugs.
  2. You start to link issues together as symptoms of the same root problem.

So the reports from your coworker and mom would get rolled up under the parent issue: “Autocomplete normalization logic doesn’t handle punctuation.” Through this process you’ll also develop a sense for the relative magnitude and priority of different issues.

Familiarize yourself with bits of the code base

No need to go crazy here; the goal is to be able to answer simple questions like where and how we’ve defined a particular variable, without having to bother an engineer.

Focus on core concepts

Every field has a set of concepts that crop up again and again, e.g., recall vs. precision in search, cardinality in data modeling, etc. Identify what these are for computer science generally and your product area specifically, to help prioritize your learning.

Develop a thick skin

Cunningham’s Law states, “The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.” In many ways this is the perfect metaphor for the role of a PM—it’s your job to come up with the initial spec or Google Drawings mock that everyone else then picks apart. The point isn’t that you proposed a crappy strawman (most first drafts are), but that this gets the conversation started.

Build credibility by figuring out how you can add immediate value

Learning any new skill takes time, but when it’s happening on the job, you don’t have the luxury of being a full-time student. You have to identify areas where you can make an immediate impact and start contributing, while you’re ramping up. Hopefully this isn’t too difficult, as part of the reason you were hired in the first place is because of the complementary skill set you bring to the table. Some things to consider:

Dig into the data

There’s this idea that each function has a superpower; some quality that, when wielded, makes other people jump to work with you. For designers, it might be the ability to quickly produce a range of high fidelity explorations. For engineers, maybe it’s the ability to hack together a prototype but also know when to invest in clean, extensible code.

For product managers, I think the closest equivalent is data fluency. Any time someone asks, “Do we know how many people use ABC feature?” and you can say, “Yeah, it’s roughly 123,” you build credibility. This is probably why product analyst positions have become one of the more common feeder roles into product management.

Practically speaking, being data fluent means knowing:

  • Which frontend and backend events are logged, and how
  • Where this data is stored
  • How to query the data
  • How to analyze experiment results
  • Experiment design best practices

Do the blocking and tackling work that keeps trains moving

Run efficient meetings. This usually means:

  • The purpose of the meeting is clear to everyone invited.
  • All necessary decision-makers are present.
  • You’ve set the right level of context at the beginning of the meeting.
  • There are clear action items and owners at the end of the meeting.
  • You take notes and share them promptly.

Err on the side of over-communicating and over-documenting. Know when email is the best communication channel and when it’s not. Keep track of common questions you get from other teams and centralize the answers in a self-serve resource.

Ask your engineers: What are you doing now that you’d rather not do? Anything you’re able to take off their plate—filing bugs, specifying logging requirements, pulling data, responding to requests from other teams—do.

Lean into your experiences and strengths

Early on, I tried to avoid drawing attention to my marketing background because I didn’t want to remind people that I wasn’t technical. In retrospect this was pretty silly, as my unique set of experiences was partly why I was hired. Whether it’s shipping an email campaign, running a quick survey, or setting up user interviews, build momentum by accumulating small wins.

Provide a shared framework for decision-making

Remember the superpower metaphor from before? This one’s a close second to knowing your data. Good PMs bring clarity to every conversation they’re involved in. They have a knack for asking incisive questions. They can tell you what problem we’re solving and why, how we measure success, and the order of operations to get from here to there. More importantly, everyone on their team can do the same, and apply the shared framework to make the best call even when the PM isn’t there.

Take the time to give your team broader context

As a product manager, you’re often the only representative from your team sitting in on a certain meeting or cc’d on an email exchange. Keep everyone updated on these interactions with other parts of the company. There’s often no immediate benefit to doing so, but the cumulative context makes it easier to discuss controversial decisions down the road. Over time, your team will start to proactively come to you with questions and concerns.

I’d love to hear from you if you’ve made it this far, especially folks who’ve transitioned (or are thinking about transitioning) into product management from a non-technical role. As I noted at the beginning, there aren’t a lot of resources on this subject, and it’s hard to learn best practices beyond the narrow slice of your personal experience. Let’s change that!

The upside of anger

All our core emotions joy, sadness, fear, anger, disgust have intrinsic value.

A friend and I were discussing this theme from Pixar’s Inside Out as we walked out of the theater.

“The only one I’m not really convinced about is anger,” I remarked. “I mean, what’s the evolutionary benefit of feeling angry?”

My friend nodded her head in agreement. “Yeah, I have a hard time relating to that one.”

I recounted this observation to another friend a few days later. Laughing, she commented, “That’s because anger isn’t a dominant emotion for you!”

After a moment of reflection, I realized she was right. Annoyance, frustration, disdain I experience these feelings as much as the next person. Palpable rage or emphatic fury? Not so much. When something really upsets me, I tend to get quiet or, if I’m close to the person on the other side of the conflict, emotional. But very rarely angry.

Part of this stems from a belief that most disagreements can and should be debated calmly and rationally. And if they can’t, I’d rather walk away instead of escalating. It just doesn’t seem like the best use of energy.

Gender norms factor in, too. Anger is an emotion to be tapped occasionally by manly men; women are best served when they don’t get too worked up over anything.

The truth is that “keep your cool” is a great strategy in most contexts, most of the time work, friendships, customer service calls to Amazon, etc. But I’ve realized recently that there are also meaningful downsides:

  1. You invite people to define their behavior towards you on their terms, instead of your own. If you don’t like the way you’re being treated or how someone’s acting, you have to make this fact known before things can change. Visible, outward expressions of anger make it clear that a line has been crossed. It’s also a way of standing up for yourself and the respect you think you deserve.
  2. Over time, habitually suppressing anger can cause you to doubt your own reactions and instincts. In recent conflicts, I’ve found myself rationalizing the other party’s actions and magnifying my own perceived mistakes. I’ve had to retrain myself to not only trust my gut, but also to act on it in the moment, even if it’s uncomfortable.

I’m not necessarily resolving to be angrier; that’s rather a sad goal. But I’d like to get to a place where I’m comfortable leaning into that emotion. Turns out some of us have to practice anger, just like any other skill. And that’s actually pretty funny.

Sometimes the illusion of choice is all that matters

Part I

I was in Golden Gate Park the other weekend when I overheard a debate between a dad and his young son, Caleb. The gist was whether Caleb should clean his room later that afternoon. After some back and forth where it was clear neither side was convincing the other, dad changed the subject.

Dad: Omar’s coming over tomorrow, right?

Caleb: Yup!

Dad: What do you guys want to do?

Caleb: Play in my room.

Dad: Wouldn’t it be nice if your room was clean when he came over?

Caleb: (pause) We can play outside. With the copter.

Dad: Where is the helicopter, by the way? I haven’t seen it in a while.

Caleb: (longer pause)

Dad: I bet you’ll find it pretty quick if you clean your room.

Caleb: (pause, then sigh) Okay. Can you help me?

Part II

As part of a redesign of their shipping centers, FedEx hired a consulting firm to understand how customers ship packages. The research led them to develop four personas based on how prepared people were when they arrived at the center, and how much help they wanted from FedEx employees. The most interesting customers were the “Confirmers.”

I am a classic Confirmer — generally well-prepared but nevertheless anxious about all the things that could go wrong. I’m the person standing next to you in line thinking, “Do I have the appropriate size box? Did I pick the right shipping speed? Did I fill out everything on the label correctly? Did I put the label in the right place? Should I get insurance? What about delivery confirmation?”

Confirmers, in case you couldn’t guess, like to be reassured. And there was one aspect of the FedEx experience that made Confirmers particularly nervous: After they handed their package over to an employee, the agent would turn around and place it in a gigantic pile of other boxes (“the leaning tower of packages”).

Even though the leaning tower had no impact on whether packages made it safely to their intended destination or not, the mere sight of it gave Confirmers the impression that the process wasn’t very reliable.

To put Confirmers at ease, FedEx placed a divider with five presort windows behind the service counter. Agents were instructed to take a package from a customer and slide it through one of the windows, signaling that it was safely on its way.

Of course, behind the dividing wall was the same leaning tower of packages.

Part III

The illusion of choice is just as applicable to designing software as it is to parenting or comforting nervous FedEx customers. Product teams tend to think in terms of actions or features they want users to try. But people don’t wake up in the morning with an urge to “Add a file to Dropbox” or “Install the Pocket browser extension.” They’re trying to solve a problem — share a video with grandparents or save an article to read later.

Your goal is to draw a clear path from that problem to your solution, integrating the product actions you need people to take along the way. The better you are at crafting this story, the more successful you’ll be in motivating someone to act. The optimization challenge is to deliver the right message, at the right time and place, to the right person.

The good news, as demonstrated by Caleb and the FedEx wall, is that there are often multiple ways to nudge someone towards the same outcome, whether it’s a clean room or peace of mind. The key is to bring people along willingly and to make them feel like joint problem solvers instead of helpless order takers.

From a product design perspective, this means that the words you use and the reasons you give are just as important as picking the right next action. For example, let’s say the first thing you want all new users to do is to install your desktop app. You should still frame it in a way that resonates with their particular use case:

  • Back up photos on your computer faster [by installing Dropbox]
  • Share files straight from your desktop [by installing Dropbox]
  • Access your stuff even when you’re offline [by installing Dropbox]

Another implication of the “Focus on the journey, not the destination” approach, is that you should look for multiple places in your product where you can encourage the same action through a different value prop. Even if people don’t bite the first time, you’ll eventually find a message that resonates (or just wear them down, depending on your POV). So if you’re trying to get users to auth their email provider:

  • At signup: Create an account in one click –> connect Gmail
  • When sharing: Make it easier to share with your contacts –> connect Gmail
  • When editing your profile: Have a consistent profile photo –> connect Gmail

Sometimes, the illusion of choice is all that matters.

Which Enneagram type are you?

I’ve taken my fair share of personality tests (Myers-Briggs, StrengthsFinder, Insights Discovery). The Enneagram is my favorite for a number of reasons:

  • It focuses on motivations and values as opposed to more intrinsic qualities like extraversion or introversion
  • There are clear implications for how teams can communicate and work better together
  • It’s easy to identify areas for personal growth
  • The nine archetypes are a distinct yet manageable number to keep track of, as opposed to remembering 16 four-letter combinations or 34 individual strengths

You can pay for the full-length test or take a free, abridged version, but I’ve found a simpler self-typing exercise to be just as accurate. Many people who go the self-typing route identify with more than one archetype, and the process of reconciling to one primary type is an enlightening exercise in itself.

The app that wouldn't go away

For an app that’s all about disappearing content, Snapchat just wouldn’t leave me alone. The routine went something like this:

  1. Read seventh article about “hot new messaging app” that teens are flocking to
  2. Download the app
  3. Hem and haw over what to snap and who to send it to
  4. Delete the app

A couple of weeks pass.

  1. Overhear friend exclaim, “Did you see Matt’s snap with the cat? Soooo funny!”
  2. Re-install the app
  3. Wait around for someone to send me a snap. *Crickets*
  4. Delete the app

…this happened four or five times.

But then it finally stuck. Like white on rice.

A lot of smart people have talked at length about Snapchat’s secret sauce — making it fast and easy to create content, limiting that content’s shelf life, mimicking the personal and immersive quality of in-person conversations, feeding our curiosity for variable and unpredictable experiences, etc. I won’t rehash these. But I think two aspects of the experience have been overlooked.

Multiple ways to create content: Active messaging vs. passive publishing

The thing that finally made Snapchat stick for me was the release of their “Stories” feature. Up until that point, I was a passive consumer, basically only opening the app when I received a snap from someone. There was too much friction to publishing my own snaps — the issue usually wasn’t coming up with the content, but deciding who to send it to.

My Snapchat graph in the beginning was pretty small and composed mainly of friends I had met recently in Seattle; many of my closest friends weren’t using it yet. The personal nature of the medium can be a double-edged sword. On the one hand, there’s an immediacy and casualness to the interaction that makes it extremely engaging. On the other hand, it can inspire anxiety at the thought of imposing on someone who might not feel the same level of familiarity. The fact that you had to individually check each recipient’s name when sending snaps amplified this feeling of “I’m interrupting someone,” in addition to making it tedious to send snaps as your network grew.

But the ability to passively publish snaps and have them viewable to all your followers for 24 hours changed things. Suddenly I didn’t have to worry about the “who to send it to” part. I just posted to my Story and went on with my day. The key is that Snapchat closed the feedback loop by showing me the people who viewed my Story. Once I could see who was already looking at my stuff, it felt natural to send them a snap directly. Oh hey, a positive feedback loop!

Besides turning consumers into creators, “Stories” gave people another reason to open the app beyond receiving direct snaps, which meant more frequent and longer sessions. It also opened up a monetization channel for brands.

Matching emotional payoff with required investment

“It’s confusing.”

“How was I supposed to know how to do that?”

“I don’t get it.”

I hear this a lot from friends. Admittedly, Snapchat doesn’t have a great track record when it comes to straightforward UI, often burying new features in the settings, disabled by default. This would be a death knell for most products; people don’t have the time, patience, or attention to sit down and learn the intricacies of yet another messaging app. But Snapchat not only seems to get away with it, it actually thrives off of this dynamic. A few hypotheses as to why:

  • Snapchat’s seed audience, which evolved into its current base, is teens. This demographic likes to be the first to try new things and the density of their social circles ensures that interesting ideas spread quickly.
  • A novelty-loving user base is a big advantage, but it’s not enough. People will only invest in learning your UI to the extent there’s a proportionate emotional payoff to doing so. This is where Snapchat delivers — explorers unlock new filters, gigantic emojis, topical geotags, and other Easter eggs that make their snaps richer and more engaging. And as they discover and play around with these features, they spread it organically through their networks, piquing the curiosity of those they interact with.
  • Once people have sunk a bit of time and effort into your app, they feel more attached as a result of this investment. They’re more likely to tell their friends and take the time to bring them up the learning curve.


Tinder's secret sauce

Funny that out of all the dating apps I’ve tried—OkCupid, Coffee Meets Bagel, Grouper, HowAboutWe, Nerve, Hinge, Tinder—the latter’s the only one that’s resulted in dates. It’s also been the most successful in terms of number of matches and message to match ratio.

There tend to be two schools of thought when it comes to online dating: either optimize for quality by curating a smaller number of more targeted matches, or optimize for quantity and let people sift through the haul.

The problem with the first approach is that it assumes machine learning can predict what I want in a date based largely on self-reported characteristics. Sure, the technology will only improve, but it’s a tall order when I often don’t even know what I want for breakfast in the morning. Tinder’s design reflects the belief that dating is more of a serendipitous numbers game.

It’s fast

This is important when you’re dealing with a picture heavy experience. Hinge takes 5-6 seconds to load someone’s profile, which means it’s less likely I’m going to open it during one of those in-between moments when I’m in line or waiting for the elevator.

It’s super casual and engaging

Tinder positions itself as a spiffed up hot-or-not; not only does this keep expectations low, it offers a habit-forming reason to engage with the app outside of dating, which becomes a by-product. That’s why people “Tinder” with friends; as superficial as it is, it’s fun to make split-second judgments, especially in groups. The bigger point is that the more frequently you’re opening the app, the more opportunities there are for serendipitous encounters.

As a counterexample, Hinge only shows you matches who are second or third degree connections, which it surfaces very prominently. Because it relies on your Facebook graph, I’ve found this leads to one of two situations: your one mutual connection is someone you friended during freshman orientation and haven’t talked to since (more common), or you have 50+ mutual friends and significantly elevated expectations for the initial interaction.

Rethinking what it means to sell

Word association time:

I say “salesperson,” you say ________?


What’s ironic about these stereotypes is that they’re only true if you’re not very good at your job.

As I’ve shadowed sales calls over the past weeks, I’ve realized that the best aren’t “selling” at all in the traditional sense. In fact, I think the most successful salespeople actually view their job as two different roles:

  1. User researcher

  2. Problem solver  

The first requires the ability to listen, empathize, and draw out the underlying problem that you’re solving for. The second calls on your creativity, resourcefulness, and flexibility.

What this approach highlights is that the foundation of the entire process is understanding the use cases and paint points your product needs to address. Which means most of your time should be spent listening and asking thoughtful questions, not talking. I wouldn’t be surprised if there’s an inverse correlation between number of words spoken and deals closed.

This philosophy is helpful on a tactical level too. When you’re fielding questions or handling objections, try taking a step back to understand what’s motivating the concern. Otherwise you miss a valuable opportunity to gather context; it’s like being asked to pack a lunch without knowing if you’re going on a lazy picnic or an eight mile hike. To take a couple of examples:

Customer: “How much do you cost?”


You: “$795 a year for the first five licenses and $125 for each additional seat.”


You: “Annual billing is our most popular option and that’s $795 for the first five licenses and $125 for each additional seat. Are you looking to replace an on-prem server or switch from an existing cloud solution?”

Customer: “We have an on-premise server at the moment.”

You: “Ok, well let’s do a quick calculation of how much you can expect to save over five years…”

Customer: “I need something that’s more secure.”


You: “We encrypt your files at rest and in transit using the same technology as banks — 256-bit AES encryption and SSL for data transfers.”


You: “I’m happy to talk more about security. Can you tell me a bit more about your specific concerns and what your team needs?

Customer: “Well, we work with a lot of external vendors so the ability to set different access permissions is really important.”

You: “I see. There’s a couple of ways you can do that with Dropbox…”

How to disagree constructively

I’ve been in my fair share of meetings and have noticed that the best collaborators and leaders do one thing especially well: they know how to disagree constructively. That is, they can express a conflicting point of view in a way that moves the conversation forward and keeps the focus on the ideas instead of the people.

This skill also happens to be one that less effective communicators stumble over frequently, either by failing to voice their opinions assertively enough or bruising egos and their reputation along the way.

Liane Davey recently wrote an article in HBR with actionable advice for improving how you communicate a differing perspective. The key recommendations are:

1. Use “and” instead of “but.” It’s not necessary for others to be wrong for you to be right. Rather than try to override someone else’s idea, just add your reality. For example, “You think we should do X and I’m proposing Y. What are our options?” This engages your teammates in problem solving instead of competition.

2. Use hypotheticals to get people imagining a different scenario. This is especially effective if people don’t seem receptive to your ideas. For instance, “I hear your concern about XYZ. If we could address it, what could the campaign look like?”

3. Focus on the underlying goal. When you disagree with an idea, start by trying to understand what’s behind the suggestion. For example, “I’m surprised you suggested XYZ. What’s your aim in doing that?” Many conflicts arise over approach as opposed to the end goal. If you can agree that the problem you’re both trying to solve is the right one to prioritize, that’s common ground to start looking for a solution.

4. Ask about the impact. If you have concerns about a plan of action, ask people to think through the impact of implementing it. For instance, “How will this launch affect XYZ?” The key here is showing that you’re genuinely open to ideas and curious about the right approach.

5. Ask for help. If something really catches you off guard, be a bit self-deprecating. For example, “I think I’m missing something here. How will this help us with XYZ?” Be careful that your questioning doesn’t come off as insincere or leading. As with #3, people can quickly sense whether you’re making a real effort to understand someone’s reasoning.

360 feedback experiment

Inspired by this Quora post, a friend and I decided to reach out to people whose opinion we valued for feedback on our strengths and weaknesses. Here’s what we asked:

  1. What role does Alice play in your life? (How do you know her)
  2. What is Alice good at? Describe her at her best.
  3. What are some ways you’d love to see her build on these strengths?
  4. What is Alice not so good at? Describe her on an off day.
  5. What are some ways Alice can improve on her weaknesses?

What I learned

Three themes that came up most frequently in my off day feedback were: being more assertive, dealing directly with conflict, and handling unmet expectations. Alice and I actually shared a lot of the same areas for improvement and I was kind of disheartened to see how much of it broke down along gender stereotypes.

Most of these were things I knew in the back of my mind but hearing them crystallized by others makes me feel empowered to “get an ounce cockier,” as someone put it. It was interesting that more than one person pointed out I could benefit from behaving in what feels like an extreme way but that won’t actually be extreme at all.

Things that surprised me

Going through Alice’s feedback, I was surprised at how consistent the comments were after just a few (~3) responses. I imagine most of us think that only our family and closest friends see certain sides of our personality. The reality is that though the degree to which we express them might vary, our quirks and inclinations are relatively stable across contexts.

The majority of the feedback focused on the “how” rather than the “what”. Less of a surprise, but I was still struck by how strongly the comments skewed towards approach as opposed to accomplishments. How do you make people feel when you’re around them? What’s your process for tackling problems and disagreements? It got me thinking that there has to be a better way to incorporate this qualitative measure into the job application process.


Make sure your list of people includes a range of perspectives. Some dimensions to consider: relationship (friend, family, coworker, mentor, etc.), how long you’ve known the person, gender, and age (older points of view can be especially insightful).

Per the consistency point earlier, you really only need a handful of insightful responses to start seeing patterns. Alice and I had between 15 and 20 people on our list and a ~55% response rate. Some ways to improve this percentage:

  • Give people a heads up this is coming…so your dad doesn’t ask your friend if the experiment is real after the second reminder email (oops).

  • Insightful comments take some reflection. Allow two weeks for people to send in their thoughts.

  • We probably could have cut questions three and five as a lot of people ended up answering them in their responses to two and four. Additionally, while many of the suggestions raised were actionable, you’re going to be the best judge of what next steps make sense in your situation.

Use this as an opportunity to test your self-awareness. Write down what you think are your biggest strengths and weaknesses and see how it compares to others’ perceptions.

If you’re interested in giving this a try, here’s the email we sent and a spreadsheet to track responses. Would love to hear what you learn!

The useful answers are always the more forgiving ones

I spend almost eight hours every week commuting to and from work on the bus. (Not ideal, I know).

Most of the time I actually don’t mind the opportunity to read, nap, or just think. And most days, I’m free to do exactly that. But public transportation necessitates a certain amount of exposure to a wide range of occasionally amusing, often distracting behavior from fellow passengers.

There’s the woman on her phone two rows over, busy informing the entire bus about her weekend plans. The man who insists his dog have a seat to itself when it’s standing room only. The guy next to you whose briefcase is poking you in the side the entire trip.

I could go on, but the point is there’s no shortage of opportunity to be annoyed about something if you wanted to be.

In the past I would just try to take these moments in stride, with varying degrees of success. And then this quote happened:

“The useful answers, the answers that help us solve problems, are always the more forgiving ones. They’re based on a line of inquiry that assumes there is always a good reason for everything.”

Barbara Sher

It wasn’t a sun-bursts-through-the-clouds moment when I first read it. I remember thinking, “Hm, that’s interesting, I should put that in my Evernote.” So I did, and kept reading. But I couldn’t get the idea out of my head, and the more time that passed, the more profound it seemed.

Maybe the woman on her cell phone is in a long distance relationship and her significant other is coming to visit this weekend for the first time in three months. Maybe the dog doesn’t handle crowds well and is much more at ease on a seat than on the ground. Maybe the guy sitting next to you just bought a new briefcase and can’t get over how nice the leather feels in his hands.

It doesn’t matter how implausible any of these explanations sound. By directing your awareness out instead of in, you change a potential source of irritation into an opportunity to exercise creativity and empathy.

The beauty of this philosophy is that it’s applicable in many other contexts as well:

Practicing user-centered design

I was on an email thread the other day where the product team was discussing findings from a usability study. Participants in the lab were overlooking the placement of a new answer on the results page and there was debate as to whether we should break the answer framework to make it more prominent.

One argument against doing so was a principled desire to avoid “designing for failure.” I agree it’s not possible to solve for every corner case, but a blanket stance like this assumes your users are robots instead of humans.

Some might also contend that a forgiving approach is at odds with having a strong product vision. I disagree. Steve Jobs was unyielding in the pursuit of his vision, but the devices and experiences he created were successful precisely because they were so intuitive to use and crafted with deep attention to the needs—and imperfections—of the people who would be interacting with them.

Change is hard. Creators have a responsibility to push the envelope, but you have to allow for the fact that not everyone is going to get it on day one. Roll out gradually and give people the option to go back to the old experience if they’re not ready.

Leading and managing teams

Effective managers have a habit of asking “Why?”

When you invite their feedback on an idea or problem, they first want to understand the assumptions you’re making and the motivations of the parties involved. They usually have an instinct about the right course of action, but rather than jumping to conclusions, they learn how you’ve approached the issue before offering advice.

As a leader, it’s tempting to equate an approach where you assume there’s a good reason for everything with weakness and being a pushover. But in the same way you can show respect even if you don’t agree with someone’s perspective, there’s a difference between acknowledging where a person is coming from and endorsing their point of view.

Whether it’s in the workplace, classroom, home, or even just on the bus, I’ve never regretted taking time to consider the more forgiving explanations behind people’s behavior.