How to give and receive feedback

In school, grades are the primary way we judge our progress and if things are on the right track (their effectiveness is the subject of another post). But what happens after we graduate and get a job?

If you wait until a formal performance review to understand how things are going, you miss a critical opportunity to speed up your learning by collecting informal feedback.

From this perspective, learning how to give and receive feedback is one of the most important real-world skills, yet most schools and workplaces offer little to no training on the topic.

I wanted to share some things I’ve learned about feedback from working in cross-functional roles at big, mature companies and smaller high-growth ones. You can start experimenting with many of these tactics right away—I’d love to hear if they resonate with you.

Receiving feedback

1/ Ask for it!
If you only remember one thing from this post, this is it: You won’t get what you don’t ask for. Feedback conversations can be awkward and for the most part, people won’t be jumping up and down to share their honest thoughts with you. The best way to get around this is by explicitly asking for and reminding people that you welcome their feedback.

There are a couple of things to keep in mind when making the actual ask…

1a/ Have the right intentions
Be honest with yourself about your motivations for requesting feedback and your readiness to hear candid comments. Maybe you want to improve a key working relationship or figure out how to set yourself up for a promotion. Bottom line: It should be in the spirit of self-improvement. People will see through attempts to get validation or requests for feedback just for the sake of appearances, and be less likely to take you up on your offer.

1b/ Make it as easy as possible for the other person to give you feedback
Remember that you’re asking people for a favor and to take time out of busy schedules to think about you. Avoid generic requests like “Hey, could you give me some feedback on how I’m doing?” This puts all the burden on the other person to figure out where to start and what to focus on.

Instead, tailor your request to a specific area: “I’m working on my public speaking skills. Could you watch for filler words and eye contact when I give my presentation on Wednesday?”

If it’s a more general check-in, provide structure to guide the conversation. It can be as simple as:

  • What’s going well
  • What can be improved

2/ Listen
Once you’ve convinced someone to give you feedback, ensure that it won’t just be a one-off thing by making it worth their time. Have the conversation in a quiet, distraction-free place. Give the person your undivided attention, take notes if you need to, and don’t interrupt. Ask follow-up questions if anything is unclear or you sense something has been left unsaid.

3/ Express appreciation
The first thing you should do after someone has offered their thoughts is thank them for taking the time to give you feedback. As anyone who’s done this before can tell you, it takes courage to be candid and thoughtfulness to do it well.

Try not to get defensive about the constructive parts and don’t feel pressure to address all (or any) of the points right then and there. It’s totally reasonable to say, “These are good callouts. Let me take some time to reflect on them and get back to you.”

When someone gives you a compliment, don’t brush it off in an attempt to act modest. That devalues both you and the effort that went into delivering the compliment. A simple “Thank you, I really appreciate that,” works great.

Giving feedback

1/ Most of your feedback should focus on the positive stuff
There’s been a lot of research on the optimal ratio of positive to negative feedback, but this sums it up nicely:

positive feedback tweet

2/ Constructive feedback should be timely
The longer you wait to deliver feedback, the harder it is to establish shared context and get your message across clearly. I remember being in a meeting where a coworker was giving a presentation to people on our team and cross-functional leaders. I noticed she was only making eye contact with the former and mentioned this to her right after the meeting ended. This kind of small but significant observation would have been hard to communicate and less impactful even a couple of hours after the fact.

3/ Constructive feedback should be specific
The more specific your feedback, the more receptive the other person will be to your message, and the more productive the conversation. If you feel like you’re being micromanaged, instead of saying “I don’t think you trust my work”, point to a project where you didn’t have enough decision-making autonomy, or a time when something could have been delegated but wasn’t.

4/ Constructive feedback should be actionable
This ties closely to the previous point; in general the more specific your feedback, the more actionable it is as well. Are there clear next steps the person can take to address the feedback? The goal here is to separate the behavior change from the person. Try to focus your language on verbs vs. adjectives and personality traits.

For example, instead of “You seem too quiet for this leadership role”, break down the expectations for that position and where the gaps are:

  • You need to be able to wrangle cross-functional consensus and push back where appropriate. There was a missed opportunity to do this when…
  • You need to be able to inspire confidence within your team. Let’s brainstorm ways you can practice this…
  • etc.

It’s rare that any of this stuff is second nature, but it does get easier with practice. Let me know if you find these tips helpful and if there’s anything I forgot to mention; I’d love to hear from you.

Reflections after 6 weeks of the newsletter experiment

  • Biggest worry going in was running out of things to write about. Turns out, as with most creative projects, public commitment has an uncanny way of spurring inspiration. New worry is finding time to write about all the things.
  • Favorite unexpected benefit has been speeding up the ‘time to meaningful conversation.’ So often when we catch up with a friend or meet someone new, we retrace a worn trail of updates and getting-to-know-yous. Rarely do we venture into the brambly brush that leads to new perspectives, unguarded feelings, and moments of shared vulnerability. The newsletter jumpstarts these meatier conversations, which pick up over coffee, brunch, etc.
  • In the internet age, a newsletter is maybe the simplest, the most atomic unit of community. Sustaining that community requires you to a) establish a point of view on the world, and b) put that perspective out there in the hope that others will stay awhile and share their thoughts. One of these things is obviously hard to do, the other less so, but still harder than you think. Practicing both has helped shape a more assured voice in other parts of my life.
  • One of the most opinionated and confident people I know told me, “I’m hesitant to put things in writing because it feels like such a permanent commitment. What if I change my mind?” I was reminded of one of my favorite quotes:

Do I contradict myself?
Very well then I contradict myself,
(I am large, I contain multitudes.)

Lead with conviction and confidence will follow

My senior year of college I was part of a case competition team where we had to present to a panel of judges for the final round. To choose who would represent the team as speakers, we held a tryout of sorts with our professor. Five years later, I still remember my audition clearly—that’s how bad it was.

What went wrong? Nervousness and an over-reliance on notes.

Fortunately, public speaking, like most individual skills, has a straightforward path to improvement—practice. More practice more confidence.

But there are also competencies where the relationship between practice and confidence isn’t quite so deterministic.

Take the fuzzy skill set of “leadership.” For a long time I thought of leadership as the sum of:

credibility + confidence

The problem, of course, is that you can’t just shut yourself in a room and “practice” leadership.

Credibility is not something you ever possess, but rather is bestowed on you by others, the accumulation of a multitude of interactions, big and small.

I’ve struggled with the confidence piece for a few reasons: imposter syndrome, scarcity of role models who come from a similar background, cultural and childhood influences, etc. Tactics like the ones below, in the vein of “Fake it till you make it,” have helped somewhat:

  • Raise your chair and sit up in meetings.
  • Dress comfortably and neatly.
  • Talk twice as slowly as feels normal.
  • Avoid upspeak.
  • Maintain eye contact.
  • Edit out gratuitous apologies, thanks, and qualifiers like “This might be a dumb question but…”
  • Do some power poses before a presentation.
  • If you have trouble speaking up in groups, adopt an arbitrary rule like “Contribute within the first five minutes” or “Chip in at least three times before the meeting’s over.”

My personal experience from applying these strategies has been unsteady progress—a sense that I’m targeting ad hoc symptoms but not the root cause.

And then, a small breakthrough. Our team was getting pushback on an experiment that was showing inconclusive results. Unsure of whether we should keep iterating or shut it down, I mentioned it to my lead in our 1:1. He immediately asked, “Do you believe that XYZ is good for Pinners?”

That’s when I realized why my old approach had always felt slightly off—it lacked the set of core convictions that supports and sustains confidence. Without it, the latter will only ever be a superficial facade. It’s much easier to build confidence as a by-product of credibility and conviction, rather than trying to conjure it out of thin air.

credibility + conviction + confidence

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 product managers 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 apply this 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…”