Career reflections

As I recently reached a career milestone, several people have asked for advice on building a career at a large tech company. Here are reflections on what helped me along the way.

1. Good work, consistently, over a long period of time. One Facebook executive has a poster in his office that reads, “Good work, consistently, over a long period of time.” The intention was to speak to the recipe for product growth. This mantra applies equally to careers: consistently delivering high-quality work compounds impact and recognition. As one manager told me, "You work for your reputation, and then your reputation works for you."

2. Find the people who see the magic in you. The role of a good manager in catalyzing growth cannot be overstated. The best managers align you with opportunities that enable you to do your best work and advocate for you in the ways that count. For example, in 2020, I was offered a role supporting the  an Ads team. I had no experience in Ads and wasn't initially drawn to the space, I trusted the manager who encouraged me to take the leap. The work turned out to be more exciting than anticipated, and when we reorg’d six months later, I achieved my goal of becoming a people manager.

3. Cultivate leverage through “pull.” Success at big companies means manifesting influence without authority. My first manager advised me to invest in “peace time” relationships – building connections with colleagues without a transactional purpose. I was later  introduced to the concept of the power of pull, which involves investing in relationships leading to the serendipitous exchange of information. Knowledge attraction, the idea that people bring information to you that you didn’t know you need, is built on trust and reciprocity with people who have expertise.

4. There’s no such thing as “above your pay grade.” It’s easy to view big companies as opaque systems with fixed constraints. Reject this mindset. One manager coached me to apply a perspective as if I were the CEO: with all the levers at the company’s disposal, what would I recommend? And then craft your plans accordingly. This mindset empowers you to tackle problems beyond your assigned scope and with uncommon creativity.

5. Embrace discomfort. Complacency is the enemy of progress. To grow, we must operate just outside our comfort zone, where we're challenged enough to build new skills without becoming overwhelmed. When your responsibilities grow, it's natural to feel uncertain or experience imposter syndrome. Instead of retreating, trust yourself to step up and tackle new challenges. Remember that today's stretch project will become tomorrow's routine task.

Why product takes both optimism and paranoia

The best product people wear two hats: the naive optimist, and the paranoid realist.

When, why, and how to be optimistic

Building new things takes an irrational hubris. And the bigger the swing, the more foolish you have to be. When laying out a vision for the future, you have to believe that your version of reality will come to pass.

On the eve of the Threads launch, Adam Mosseri told The Verge, “Any time you build a new app from scratch, it is much less likely to succeed than to succeed.” He’s right. Meta’s track record of launching standalone apps can best be described as a graveyard.

And yet…

The Instagram team’s try at a standalone Twitter-style microblogging app became the fastest growing app of all time! This was only possible with the craziness to try something that’d never worked and believe that this time would be different. And it was.

I think about this as we build anything audacious. We need a vision so compelling, so inevitable that we might just bring it into existence. We need to provide concrete examples of the real value we can create for people and the world. We must manifest optimism.

When, why, and how to be realistic

Of course, believing something will work is hardly sufficient to make it so. Your strategy and execution have to be perfect. This demands paranoia.

Good strategy is a sequence of investments, within realistic constraints, that achieves success. Emphasis on “realistic constraints.” You can’t pretend to have resources – be it time, people, money, reputation – that don’t exist. When establishing strategy, the more opinionated your tradeoffs, the more resilient you’ll be.

Executional paranoia is even more important. Murphy’s Law says that anything that can go wrong, will go wrong. Ironically, the best way to avoid this happening is to assume it will.

Forcing yourself to enumerate every risk and mitigate it will ensure that you’re executing with rigor. Create redundancies in case of missteps. Budget in the buffer that you’ll invariably need. Communicate bad news early to maintain as much optionality as possible.

I was thinking about an issue I faced on the Avatars team where we identified a series of launch-blocking bugs at the eleventh hour before a major release. To patch them, we put a plan together that addressed the issue. I thought it was a good plan! After walking through it with the team, I read a look of skepticism on a key team member. I asked her why she lacked confidence, and she told me plainly that she’d been doing this too long to believe things would end up going to plan. She advised caution. She was right.

From there, we focused on mitigations to our mitigations, back ups to our back up plans, and a “break glass” approach in case all our preferred options went bottom up. This embodies our commitment to professional paranoia.

Ultimately, it's this blend of bold vision and meticulous execution that propels our most remarkable achievements.

Communicate without subtext

Tl;dr Say the quiet part out loud, even (especially) when it’s hard. Do so with compassion and an open mind.

Effective feedback uplevels work, makes us better colleagues, and catalyzes growth. Feedback is effective when it’s authentic and clear. That’s easier said than done.

Our human tendency is to dilute what we want to say with language that obfuscates the point. Telling people what we really think puts ourselves out there by exposing our opinions. And maybe we’re wrong! Or worse, we might offend someone by critiquing their work.

We can’t let these fears prevent candor. When we mute our true beliefs, we let issues fester and spread. If we suppress feedback about work, the work is worse for it. If we suppress feedback about each other, we internalize bad habits. The more honest takes end up getting shared privately, often excluding the people to whom the feedback is most relevant; constructive criticism devolves to gossip.

So my challenge is: Say the quiet part out loud.

1. Speak up when you disagree. Vocalize if you think we’re headed down the wrong path. Never sit silently working on something you don’t believe in simply because you think it’s not your job to question.

2. Acknowledge tension. If you’re meeting with someone and the stress is simmering, acknowledge it. This relieves the pressure and enables you to have an honest conversation about how to move forward. If you’re discussing a decision with someone and their words are, “I’m aligned” but their face says, “You’re crazy,” acknowledge that outright.

3. Critique directly, not by proxy. If you find yourself chattering with others about how “person x always does this annoying thing,” the compassionate thing is to tell that person directly.

Being direct doesn’t mean being a jerk. I want to be clear:

1. Engage with tact. Investing in relationships over time builds trust, and ensures that even tough to hear feedback lands better. When you have critical feedback, deliver it thoughtfully – typically in private, with a warm tone and stated intent to help rather than demean.

2. Acquire context. Before opening the door to relitigating, you should understand the rationale behind a decision. Although the best work stands on its own, surprising decisions usually have rationale. You may disagree with the rationale! You may think it’s bad rationale! But when you take the time to understand it, you can present a more informed argument. Your feedback will be better, harder to write off, and feel more respectful.

3. Keep your opinions weakly held, and be ready to disagree and commit. Feedback is (almost) never better unsaid. But sharing an opinion is not license to get your way. When you surface an argument, do so with an open mind and readiness to be persuaded otherwise. Even then, you may not reach consensus. While you should feel empowered to push or escalate when important, recognize that we don’t always get our way and that shouldn’t prevent us from moving forward with conviction.

How to make good tradeoffs

Tradeoffs are the heart of a good strategy. Despite our desire to have our cake and it too, building products requires making opinionated choices on how to allocate scarce resources. High performing teams make these decisions rigorously. When evaluating opportunities, they don’t say “yes” or “no” without due diligence. Nothing is free, yet with enough creativity, nothing is impossible, either.

Tl;dr on how to make effective tradeoffs:

1. Identify the options. Get creative in identifying all possible routes. Hold nothing sacred, and accept no constraints as fixed.

2. Illuminate & rank the criteria. The most common criteria are maximizing impact (metric, strategic, and comms & marketing), adherence to your principles, precedent, and minimizing cost (short-term, long-term, and risk).

3. Evaluate & make a recommendation. Create a color-coded scorecard that evaluates each option according to your criteria. Simplify before you socialize. Always, always, always make a recommendation. Then, invite debate but ensure you do make a decision.

Step 1: Identify the Options

To begin, describe the core decision you have to make. What motivated you to tee up a tradeoff in the first place? Often, that will look like: Should we build A, or should we build B? Then, you flex your creativity:

1. Identify the third options. Could you do some of A, and some of B? Reflect on what it would take do both A and B, or build one now and the other later. Maybe there’s a completely different option C. Consider brainstorming with your team to ensure you exhaust possibilities. Ensure the options are as specific as possible for accurate vetting and clarity in your path forward.

2. Hold nothing sacred, and accept no constraints as fixed.

   1. Define your ideal outcome, and reflect on what it would take to make it happen. Then, dial each constraint up or down: What would you do with more or less time? people? money? What would it mean to pursue more or less scope? tolerate worse or demand higher quality?

   2. If you find yourself saying, “We have to pick between two options, because we don’t have enough time to do both,” recognize you’ve implicitly made the tradeoff decision just there by fixing your deadline. If you find yourself saying, “We couldn’t build A because we don’t have enough people to do it,” recognize you’ve assumed that increasing the number of people is off the table. Sometimes, neither is the case, and articulating these options might persuade your leadership to unlock resourcing.

Step 2: Illuminate & Rank Criteria

Next, clarify your decision criteria.

It can be tempting to simply list out pros and cons of options. In some cases, this is straightforward. Many tradeoffs can be simplistically solved by weighing ROI (time to implement vs. metric impact), but explicating a decision framework enables nuance. Here are the most common criteria:

1. Maximize Impact

   1. Metric Impact. One of the main reasons we have goal metrics is to dictate prioritization. If you have a good metric, forecast the metric value each option will deliver.

   2. Strategic Impact. Metrics don’t capture everything, and some options will advance your team’s strategic aims. As part of this, consider how users will respond to various paths; for example, certain strategies may churn the user experience in a way not fully realized by your metrics. There may also be more learning value imbued in certain options that will help you make better decisions down the road.

   3. Comms & Marketing Impact. Finally, you should understand any PR value or risk in supporting your comms goals or exacerbating risks in areas like privacy, integrity, and more.

2. Adhere to Your Principles. Grounding decisions in principle creates more coherent products. The best principles are enduring, comprehensive, and opinionated. (Crystalizing opinionated principles is useful specifically because it can help resolve tradeoffs.) If any options violate your principles, that’s a clear cost; sometimes a principle violation may be enough to strike an option altogether. If you find your team debating principles locally for each decision and project, it’s a sign you should formalize them.

3. Consider Precedent. The decisions you make now inform decisions later. Sometimes this tips the scale from a short-term, myopic approach to one that’s enduring. Pay particular mind to decisions that are irreversible: “one-way doors” are cause to scrutinize decisions meticulously.

4. Minimize Cost.

   1. Short-Term Cost. The cost of an option is typically how long it’ll take to get it done. Scope the number of person-days needed (e.g. “x engineering days”), as well as whether elements of the implementation timeline can be parallelized or must be pursued sequentially. In some cases, there are other costs ($$$) to represent, too.

   2. Long-Term Debt. Beyond the immediate cost, options may induce long-term technical or design cost. The paths that do something the “right” way are preferred, but urgency may demand cutting corners.

   3. Risk. You’ll also want to understand the degree of uncertainty. For example, option A may probably be ~5 days, but could be 20, whereas option B might definitely take <10 days. How much is risk a factor?

Not all of these criteria are created equal. Record how important each is, must have vs. nice to have, hard vs. soft constraint, and stack rank if possible.

Step 3: Evaluate & Make a Recommendation

The last step is to determine your recommendation and align on the path forward. If your options are specific and criteria clear, the evaluation should be straightforward.

1. Create a scorecard. Determine how each option scores on each criterion. Like with the options themselves, ensure the implications for all criteria are crisp. For example, if you say you’ll need to deprioritize something else you’re building, identify what that is and exactly what “deprioritized” (delayed? descoped? scrapped altogether?) means. Color coding makes your evaluation easy to parse.

2. Simplify before you share. As you socialize your recommendation, distill complex topics. Consolidate the many options you initially explored into the core ones worth serious consideration (and punt the “non-options” to the Appendix). Pro tip: Number and title each option for easy reference.

3. Always, always, always make a recommendation. The recommendation is the most important detail, but ironically is often left out. You possess the deepest context, and it’s your job to have an opinion.

4. Invite debate... When you do share, encourage your team, peers, and leadership to discuss the decision. Critically, when others disagree, elucidate what it is they’re challenging. Do they take issue with the criteria? The importance of the criteria? Or what “good” means for each? If you’re not clear on the root of the disagreement, you’ll talk past each other and swirl with frustration.

5. ...and make a decision or escalate. Preference for consensus means alignment may prove evasive, but even the most vigorous debate must come to an end. Indecision is a decision itself (and typically the worst outcome of all). In these cases, call out that fact and urge others to disagree and commit. And if you can’t align internally, escalate as needed.

The paradox of running

Running is a good hard thing.

Primitively, running is our most and least natural instinct. As kids, we run when carefree (like at recess) or careful (like from danger). But our bodies also tell us not to run, to conserve our energy.

This paradox captures the essence of my running experience.

• • •

Running is an expression of joy. I love the routine, the repetition, the cadence. I love finding flow, feeling present and mindless at once.

Yet, every run is a chore. Getting out the door is a negotiation. Running takes time and effort, and sometimes I have none to offer. I rarely want to run, even though I’m happier when I do.

So running is good, and running is hard. Running is a good hard thing.

But I don’t value running in spite of its challenge. I value running because of its challenge.

The harder the run, the more satisfying its conclusion. Running is great, having run is greater.

Each run is a small victory, a feat of physical and mental fitness. When done habitually, these small victories become a great one. More than other sports, running is democratic. You get out what you put in. Run a lot and with intention, you get faster. Natural talent may gift a head start, but discipline and consistency matter most.

• • •

There’s no clearer manifestation of this than a marathon. Toe the start line without proper training and you’re in for a very long day. But if you put in the effort to train in earnest, those 26.2 miles will feel like the ultimate celebration.

Don’t get me wrong, running a marathon means suffering. The closer you get to the finish line, the farther it feels you have to run. Time slows. Exhaustion consumes. Your heart beats faster, faster, faster with every strike into the pavement.

In those last miles, the muscle to flex is grit. When your body is telling you to slow, you remember: this is what I trained for. Every time you laced up your shoes at the crack of dawn or the last light of dusk. The runs under the scorching sun or frigid rains, up steep trails or through monotonous roads. The intervals, the tempo runs, the long-slow distances. You did all that so you could do this. So you don’t stop. You just put one foot in front of the other.

Proverbial finish lines are great but literal finish lines are greater. You sprint through the finish line (you may be crawling, but you’re sprinting) and reality sets in that you made it.

This moment is on par with the most intense emotions I’ve experienced. It’s euphoria. A cocktail of triumph laced with intoxicating fatigue. Even the soreness feels good, evidence of your accomplishment. You wrap yourself in a heat blanket, devour a banana, and embrace the moment with thousands of others feeling the exact same thing.

• • •

I won’t spell out the metaphors. They’re so on the nose that “marathon” describes any daunting task. Suffice to say, run a marathon and the unachievable becomes achievable. Do one hard thing and you can do another. Keep running — it’s the ultimate good hard thing.

Extreme Clarity

Good business communication is extremely clear. It needs to be skimmable, clear, precise, and memorable. Here's how to achieve that:

1. Make it skimmable:

   1. Tl;drs. Always.

   2. Make your point bolded / in headers.

   3. Lists > paragraphs. Easier to digest and less intimidating. Pro tip: Numbers are better than bullets for quick reference.

2. Make it clear.

   1. State your objective. Lead with the “why.” Inform? Align? Escalate?

   2. Provide context. You know your area better than your audience, esp. execs.

   3. Avoid acronyms / jargon.

   4. Highlight the crux of disagreements. Don’t gloss over why you’re escalating.

   5. Use scorecards for options. State your criteria and score green / yellow / red. Always include your recommendation.

3. Make it precise.

   1. Unambiguous language. Objective facts > subjective descriptions. (No adverbs, please.)

   2. Represent data accurately. Be mindful of relative vs. absolute figures, and include confidence intervals when relevant.

   3. Link off for more info. Point people to analyses or references for going deep.

4. Make it memorable.

   1. Tell a story.

   2. Include quotes / videos and other anecdotes (esp. from users).

   3. Use visuals.

   4. Highlight striking information. Data with drama sticks.

   5. Be expressive. Don’t be afraid to add your personality (emoji, memes, gifs)...in moderation.

There’s no such thing as “above your pay grade”

One of the sayings at Facebook that resonates with me the most is, “Nothing at Facebook is someone else’s problem.” Swap out Facebook with your company. Internalizing that you should act like an owner and help wherever you can is an empowering perspective.

When I started my career, I accepted my team’s M.O. as the way things are. This was comfortable, but limiting. Re-orgs, process pivots, and strategy changes would happen to me. The everyday inefficiencies I’d encounter...well, I figured there must be some rationale.

As I’ve grown in my career, I’ve seen behind the curtain at big companies. Every org norm is the byproduct of someone’s thinking and work, implicit or intentional. Company culture is the aggregation of the actions of many people.

But you don’t need to be a senior leader to influence or drive things. While seniority begets authority, it doesn't ordain leaders with unique wisdom. If anything, the causal arrow goes the other way around: demonstrating the competence to tackle problems beyond your assigned scope is a path to promotion.

Facebook, for example, has a uniquely bottoms up culture. Some of our best stuff has come from the rank and file showing initiative.

Major Facebook features like Facebook Marketplace and Facebook Video were born at hackathons. Then there are stories of employees thinking outside the box: my former manager, when an individual contributor PM, identified a way to supercharge her team and initiated an acquisition. Even at the biggest companies, that’s not a conventional lever.

On a personal level, I’m most fulfilled when championing an idea. When I was an associate PM, I started a new team to reimagine how we share big events on Facebook, largely because I was personally unsatisfied with how my own engagement was represented on the platform.

These may feel like anomalous stories, but we can embody this mentality every day. Everyone leads if they want to. I read this advice from a Content Design leader, Kay Streit, I’ve worked with:

You don’t have to be a PM to drive product strategy. You don’t have to be a VP to make executive decisions. Heck—even EVPs have to insert themselves into meetings and projects. We excel from collaborative leadership. Where you might see levels, you should see partnerships. Where you might see lack of control, you should seek to grow your influence. Where you may not have power, you should take responsibility. These actions combined are what cause others to see you as a leader.

Consider upleveling yourself by embracing ambiguity. Evolve from executing on solutions that others have scoped, to identifying the solutions, to defining the problems to solve. Rather than asking, “What is the best way to get this done?” ask, “Is this the right thing to do?”

Now, this isn’t easy. Shaking the beehive is scary, and some companies are more top down than others. Moreover, bias makes it easier for some to sell in an idea – whether because of title, personality, or demographics. When navigating the corporate jungle gyms is intimidating, consider engaging mentors for advocacy and advice.

Because ultimately, there are few professional attributes as powerful as innovative thought coupled with the grit to execute.

Product growth myth busting: Why good growth work can drive product quality

The tension between product growth and quality is common for any team trying to scale usage. But these concepts shouldn’t be misaligned. Good growth work drives product quality, while reasonable definitions of quality should be deferential to metrics.

This note defines what it means to apply a “growth” approach to a product, and ensure it supports quality.

tl;dr

1. “Growth” means data-driven optimization. We place a laser-focus on increasing a specific metric, and on iterative experimentation backed by a clear hypothesis.

2. Growth and Quality are two sides of the same coin. People misconstrue growth work as detracting from a focus on our users through hacky, short-term gains, but growing a metric over the long term requires caring about sustainable improvements that drive user value.

“Growth” means data-driven optimization

Product growth is the practice of data-driven, iterative optimization to grow a specific metric. There are a few attributes that differentiate growth from conventional development:

Growth Tenet #1: Data-driven development with a laser-focus on increasing a specific metric.

Growth work starts by enumerating the levers we have to influence the metric, then prioritize work based on what can make the biggest impact on it. Of course, this means that picking a good metric is essential; in fact, I posit it’s the most important decision growth teams make.

Growth Tenet #2: Iterative experimentation backed by a clear hypothesis.

Growth means testing single-changes to an interface. Each experiment tests a specific hypothesis, yielding learnings around what works and what doesn’t. This has a few notable implications:

1. Hypotheses correspond to the problem you’re solving for users. Aimlessly modifying the UI would get you nowhere.

2. Not everything you build will deliver impact, but you should view conclusive resolution to a hypothesis as its own success. Quickly wind down invalidated experiments, and use the learnings to inform future work.

3. Quantity (and velocity) beget quality. You need to test a lot of stuff to deliver meaningful results at scale. To achieve this, you need to move quickly. That means being especially careful to minimize scope and the upfront investment on an experiment in favor of true MVPs. You should also aspire for replicable process that allows us to move quickly.

Growth and Quality are two sides of the same coin

Myth #1: Focusing on metrics detracts from a focus on users

If there’s one misconception to correct, it’s that metrics and quality are in tension. Experiential product quality should be defined as how effectively a product solves user needs and results in positive attitudes toward the product. Metrics are objective ways to measure progress achieving goals, and can help achieve these outcomes.

If your metric represents an outcome that is misaligned with this definition of quality, you need a better metric. Of note, ensure your metric is globally optimal (i.e. represents outcomes that are good for the product holistically) and not locally so (i.e. represents outcomes good for a specific feature, at the expense of your product’s value).

Myth #2: Growth is all about “growth hacking”

Growth hacking implies you trick users into doing something they don’t want to do. This work, sometimes called “dark patterns,” is not only ethically questionable, but also bad for business. Manipulative growth tactics lead to a short term spike that’s eroded in favor of long term churn. Instead, create sustainable growth by tracking long term impact and only shipping things that yield sustained step or angle changes.

This is not to say you shouldn’t employ design changes that are “growthy.” For example, effective CTAs and notifications can be useful tactics! Clear buttons can direct users to take the action in their best interest, while notifications can alert users to something worthy of their attention. Moderation and clear principles ensuring intentionality are key.

Myth #3: Growth thrashes users

Experimenting is a fast and focused way to improve the product. Forgoing any change in favor of stagnation is a path to paralysis where you never make the product better for our users.

It doesn’t come without tradeoffs, but there are many ways to minimize disruption. Consider experimenting on the smallest possible audience within the constraint of sufficient statistical power, or avoiding experimentation on certain key user cohorts (especially if you’re an enterprise product).

Write for the 30s, 2 mins, and 10 mins+ reader

The objective of business communication is to ensure your audience digests your message. Readers are likely diverse in their interest and investment with your work. So a lesson I’ve internalized: Explicitly structure your communication to support the 30 seconds, 2 minute, and 10 minute+ reader.

This means making it dead-simple to glean the top takeaways, but easy to go deeper.

For my 30 second audience: Make it easy to skim with tl;drs, bolded key messages, and visuals – but provide depth under the hood, sometimes embedded with links.

For my 2 minute audience, let’s go deeper:

1. Make it easy to skim.

   1. Tl;drs — always. I’ve never met a doc that wasn’t improved with a quick summary. The trite “too long; didn’t read” label literally conveys that you’re providing a faster way to get the gist.

   2. Bold your key messages. Use headlines / subheads to convey your key points. In a deck, make the slide heads convey the key message. In a doc, do the same with H1 / H2s and bolded text. If you skim a doc / deck with headlines like “Problem,” “Opportunity,” “Solution,” you won’t learn anything; if you skim something that embeds the messages there directly, you’ll absorb the narrative.

   3. Use visuals. Our eyes glaze over verbose paragraphs, but diagrams and photos can be, to steal a Sheryl Sandberg phrase, "thumb stopping content." Even lists (ahem, this post) can appear more accessible than a wall of text. I usually opt for tables as ways to organize content. I even have a teammate known to convey key messages in his docs with memes, iykyk.

2. Provide depth under the hood.

   1. Skimmable docs give you permission to go long. If you follow these best practices, brevity is less essential. Including depth, like actual data, wins credibility with those who take a greater interest. Be careful though: Sometimes, the sticker shock of a high page count can scare people off. In which case...

   2. Link off for more! Aggressively link off to posts, docs, or data for those who really want to go deep on a topic. When I write upward communication, I’ll sometimes even prepare two docs — shortform, longform — so that the main artifact is succinct but interested parties can go under the hood.

Product Strategy Template

Every PM has stared at a blank screen with the intent to write a product strategy. After going through this one too many times, I formalized a template to give myself a head start. I won’t claim it’s especially novel, but here’s the template I use for any strategy, ranging from a specific product concept to a multiyear vision:

Tl;dr

Summary of everything

• Consider simply mapping to the doc structure:

  • Context:

  • Problem:

  • Opportunity:

  • Strategy:

  • Risks:

Context

Objective: Share the background information the reader needs to know that will motivate your strategy.

• What is the current state of the world?

• Is there a backstory to why you began investigating this area? Is it new or an extension on something?

• Is there a specific business insight or problem that motivated this? [This is related to the problem, but can be more generic and higher level. For example, you could say, “Here’s some data that shows this is an opportunity” but use the Problem section to address the “why” behind the data.]

Problem

Objective: Frame the user problems that you want to solve

• What data suggest there is an opportunity? What isn’t working well for users?

• Really focus on the why. For example, if the problem is, “This thing is complicated for users,” explain what makes it complicated.

• Surface lots of data and research nuggets

• Frame this narratively — tell a story!

Opportunity

Objective: Illuminate what success looks like and why that success is meaningful

Vision

• One-liner on what success looks like, framed aspirationaly

Jobs to be done

• Specific user jobs. Why will users hire your product?

Value for the Business

• Why does this matter for the business? How does solving this problem make a dent in our company mission or business objectives?

Measuring Success

• What metrics will you use to evaluate success?

• Consider using a table that includes: Metric Name, Priority (Goal / Tracking / Counter), Metric Definition, Rationale (why this metric maps to your goal).

Strategy

Objective: Explain what you are actually going to do to achieve your goals

Approach

• What are the key hypotheses you have, and why do you have them?

• Share the specific workstreams and tactics. It should be clear to the reader what you actually want to build, and even more important, why this is the right thing.

Risks

Objective: Answer what could get in your way to impede success, and include the mitigations you’re recommending.

Tips for effectively asking for feedback on your work

This note details how to ask for feedback on your work, and shares corresponding tips for feedback givers:

1. Set the right context by outlining the purpose of the work and its audience

2. Highlight why this person is giving feedback, such as their expertise or your general reverence for their opinion

3. Establish feedback expectations by asking for it at the right time, sharing how you want it, and setting a deadline

4. Define the type of feedback needed, like whether you want approval vs. input, specific advice vs. general reaction, and suggestions on substance vs. form

Effective feedback starts with effective asks

There’s a trope that most of what PMs do is write docs. It’s not entirely wrong! A lot of what we do is write out ideas, solicit feedback on them, and share thoughts on others’ work. In sum, we trade in feedback. The quality of this feedback varies a lot. But it’s not usually because of who’s giving the feedback; rather, it’s because of how well it’s asked for.

The more effectively you ask for feedback, the better the feedback you receive will be.

Asking for feedback with insufficient context or expectation setting is not only unproductive, but also selfish: it places the burden on the feedback giver to infer what the feedback is for.

So, if you’re asking for a lot of feedback – here’s how to maximize its value:

1. Set the right context

Feedback will be more nuanced if shared in the broader context of the work. Often, it’s useful to share this context at the top of the doc. If that’s not feasible because the doc’s audience is already too broad, share this directly. Important context includes:

1. What is the purpose of the doc: Clarify the true purpose of the doc, and then ask whether it achieves that purpose. Consider a doc called “Defining success metrics for our team.” Ostensibly, the purpose of the doc is to define success. But there’s more to it than that. Is the purpose persuasion (i.e. convincing your reader that your definition is the right one) or clarity (i.e. ensuring your reader knows how to operationalize the strategy)?

2. Who is the audience: Explain who the doc written for, and which person or people are the most important stakeholders. Share the preconceptions they may bring to reading the doc, like their context or biases.

Tip for feedback givers: Solicit this context if it’s not provided. Answers to these questions should underpin the feedback, so view them as must-knows, not nice-to-knows.

2. Highlight why this person is giving feedback

If you’re asking for someone’s time, they should know why. Explain why you’ve engaged them, personally. You may need their alignment. They may have relevant expertise, either in the domain or problem space, type of work, or even the audience you’re sharing with. Or perhaps, they’re just really smart! No matter the rationale, make sure they know it.

This simple step is often the difference in getting feedback or having your request ignored. Personalized context is flattering, empowering, and useful.

Tip for feedback givers: Lean into your expertise. Your skills and experiences give you a unique perspective. You may know a ton about the relevant problem space, possess unique context, or are an expert on this type of work. When you share feedback based on your area of expertise, it’s not only likely to be higher quality, but also you may be the only one evaluating the content from this lens.

3. Establish expectations on when and how to give feedback

Feedback is only as effective as your ability to take it. To maximize its utility, define all the logistics up front — the timing, the form factor. You should:

1. Ask for feedback at the right time: If you’re looking for people to review your thinking, share it early. If all you want is suggestions on framing, late in the game is probably okay. When you want earlier feedback, deliver it in a form factor (e.g. outline) accordingly. Then, let the feedback giver know how early you are (“this is just a draft” vs. “this is 98% finished”).

2. Share how you want feedback: Edit directly? Comment in line? Ping you on chat or email? Remove ambiguity by sharing your preference.

3. Set a deadline and signal the priority: You should share when you need the feedback by. If you foresee a tight turnaround, give the person a heads up that the request is coming. On the other hand, if the feedback is a nice-to-have, relay it accordingly.

Tip for feedback givers: If the person is targeting a specific date, be forthright around whether the timeline is realistic for you. And when you share feedback, consider the audience: Very critical feedback is best delivered via private channels, not spotlighted in a doc’s comment section.

4. Define the type of feedback needed

The more specific the feedback ask, the easier it will be for the person providing it to focus. Asking someone, “Does this look good?” will get you vaguer responses than, “Are you aligned with my recommendation? If so, how might I make it more convincing?” Specify whether you want:

1. Approval vs. input: Feedback givers should know if their feedback will be blocking or not. In particular, if you intend to represent that this person is “aligned” to what you’ve written, you should be clear about that fact and ask for explicit rather than tacit confirmation. Conversely, if you may ignore the person’s feedback, they should have this expectation going in.

2. Scoped vs. general: Is there a specific topic or question you want feedback on? If the person has particular fluency in one area you cover, direct them to focus on it. If there is a particular part of what you’ve written that you think is weak or controversial, flag it.

3. Substance vs. form: While feedback on substance is typically most important, it can be useful to hear perspective on the form – either the framing, or the styling (especially if it’s a deck). Make sure to clarify which you want.

Tip for feedback givers: Prioritize feedback within the constraints of the ask. Of note, you may have feedback beyond the scope of the original ask. As a principle, it’s better to err on the side of honesty; if you have a constructive opinion, it’s likely others may share it and the person will benefit from hearing it earlier and more tactfully than when it’s truly too late.

Moreover, consider your intentions. When offering feedback, you should have an objective. The most common one will be to help the person make their work better. But this isn’t always the case! If you’re asked whether you’re aligned on something, your feedback should represent your opinion and failing to convey it is a mistake.

Oh, and a quick tip: Regardless of the feedback type, if you see typos, correct them. Its always helpful to fix them, like adding in missing apostrophes ;)

Build for the future, not the present

Change is the only constant in technology.

Large companies are filled with hundreds or even thousands of people modifying single products. This comes amidst the non-stop pulsing of the tectonic shifts that define the tech industry. This means there’s a growing chasm between the present state of our products and the future we’re headed toward.

As a product team shepherding our own corner of the ecosystem, we’re left with two options: You build for the short-term alone and watch your product decay in its relevance. Or you build for the long-term and deliver enduring value.

We need to build products for the world we’re shipping in, not building in. And the longer the lead time for a project, the bigger the delta in these realities.

Future-proofing your work requires intention. We must:

• Anticipate trends. Seeing the future doesn’t require precognition, but the vigilance to recognize ongoing trends in our businesses and market climates. Then we need to shape our strategy to fit within them; simply acknowledging these in a roadmap is a useful forcing function. It’s also important the product executives prioritize transparently so individual teams can fit their strategies to them.

• Proactively align. “East-west” partnerships are challenging, but understanding peer roadmaps will equip you to fit your roadmap into those teams’ direction.

• Orient toward the long-term. Short-term optimizations can yield meaningful wins worth capturing, but we must recognize that lasting value is rarely succinctly expressed. Define the end state you’re building toward and back into the milestones that represent progress.

Intro to Goal Maps

What’s a goal map?

Goal maps are visualizations of your team's strategy that show how tactics, strategies, metrics, goals, and visions ladder.

These maps facilitate cohesive strategies where everything is connected and build to something great. They're also convenient ways to visualize your entire roadmap.

How to create and use goal maps

• Go from goal --> tactic. (And not the other way around.) Goal maps should be developed top to bottom, i.e. you start with the vision, then explicate goals, then metrics, then strategies, and eventually tactics. This ensures that all your projects align to your vision.

• Everything needs to fit. By putting everything on a map, you're forced to show the relationship between projects (tactics) and your overall team vision. If something doesn't fit on the map, it's probably something you shouldn't be doing. One way to ensure this: Use strategy statements as "how might we" prompts for brainstorming.

• Make the vision enduring and tactics flexible. The highest rows on the map (vision, goals) should be enduring and persist through the quarters or even users. The lowest rows (tactics, strategies) should be malleable and change periodically. This ensures that each half / quarter builds on the last as you come closer to your north star, while making the actual work you do build on previous tactics and responsive to new information.

7 common mistakes in product reviews

Product reviews are a crucial forum for aligning as a team and with leadership on strategic decisions. I have drifted into repeating mistakes, so I wrote out guidance to remind myself for avoiding them.

The thread between these issues is abdicating ownership. It’s easy to assume the purpose of a review is for your boss to solve your problems or make a decision you’re unprepared or unwilling to. It’s not. You have the most context and focus, so your job is to frame up the problem, provide the relevant information, propose solutions, and drive the process of resolution.

Here are some mistakes to avoid:

1. Not enumerating the meeting goal or type of review. Is the goal to inform and get feedback or to align on a decision? State this up front, and direct the conversation to focus on the areas you need feedback.

2. Skipping the context. You live and breathe what you work on, but your leadership does not. Explain how this discussion fits into broader org and team context, define key terms, and calibrate metrics. For especially dense topics, include extra context in a pre-read even if you skip it during the meeting.

3. Presenting options without sharing a recommendation. This is the most severe tactical mistake. Remember that your team knows its space more than anyone. You may want feedback on the decision, but you should anchor with your opinion.

4. Obfuscating disagreements. While teams should align on a recommendation, if there isn’t consensus you should represent the various points of view and the crux of why there’s disagreement. This is especially important for escalation reviews, where you need to explain the source of conflict.

5. Only sharing what you think your managers want to hear. This is the most severe strategic mistake. First, you should build the strongest strategy you can — even if it goes against the org’s conventional wisdom. Second, you should share the ground truth — even if it’s nuanced, difficult, or makes you look bad. Your leaders are allies, not clients to be managed, and honesty will build trust and credibility.

6. Presenting risks without proposing mitigations. It’s useful to share what might prevent you from succeeding, but share what you plan to do about it. Emphasize mitigations that require leadership’s support (e.g. more resources, helping align with a partner team).

7. Forgetting the next steps. At the end of the review, recap the discussion and share next steps / action items. Follow up in writing to ensure clarity and create a record.

Career tip: Impact and scope are not the same

I once received feedback from a peer that my priorities were dispersed, and they noticed I dropped a few things. It inspired reflection on incentives and what really matters.

Working on the Lyft driver team, our prior was that drivers want to minimize work and maximize earnings. You don’t need a Phd in Labor Economics to grasp this.

White collar culture flips this on its head. Perception is: If you are ambitious, you should maximize your scope. Never say no. But this is, at best, short-sighted, and at worst, counter-productive.

Even if you’re laser focused on career growth, scope is not the goal. Impact is.

Impact is a function of the volume and value of your work. Acquiring scope appears to be a fast track to increasing your output volume, but that’s not necessarily true. You may be able to stretch yourself, but your time is a finite resource.

Enhancing the value of the work you do is a more sustainable path. Work smarter, not harder. Advice saying, “Do your job…but better” may sound blatant, but internalizing this perspective will inspire you to deepen rather than widen your focus, and invest in learning rather than production alone. In fact, promotions typically bias to the strength of your skillset — which is a leading indicator of your future impact — more so than one-off and unsustainable wins.

So the next time you’re invited to step into more work, evaluate it against your current slate. Can you drop something to make this happen? If the answer is no, be honest. Set clear, realistic expectations for yourself and your coworkers.

Your team, career, and sanity will benefit from it.

Product principles should have tradeoffs

Taking a principled approach to product development is prudent. Good principles tell us what to do and what not to do; they bring focus.

Too often, teams identify principles that are so obvious they end up meaningless. An example: “Build quality experiences.” Okay, sure. But how is that actionable? Were you previously considering building a low quality experience? Famously, Google has the principle, “Don’t be evil,” but it’s hard to imagine scenarios where a team confronted a crossroads and was brought clarity by this declaration.

Good principles should *not* be self-evident. In fact, the best principles should catalyze debate and disagreement up to the point when the team formalizes alignment.

When principles are opinionated, they bring resolution. They make decision making faster, clearer, and more objective. When Mark Zuckerberg proclaimed in Facebook’s early days, “Move fast and break things” he established that the company valued speed over stability, a tradeoff that helped the company scale (and yes, beget many of its problems). When he amended this in 2014 to the far less pithy, “Move fast with stable infrastructure” and plastered posters that said “Slow down and fix your shit,” it ushered a different reckoning.

A substantive principle relating to quality might be: “A feature isn’t an MVP if it makes the product harder to use.” This stake in the ground suggests that we shouldn’t ship anything if it regresses usability metrics. This would actually be quite bold; many new features bloat products and create new learning curves. But if you align on this with conviction, you can hold the line on new features that are complexifying.

As teams approach roadmapping, reflect on what tradeoffs you’re ready to make. Have the hard conversations to reach alignment now, as you strategize but before picking the tactics, knowing it will accelerate progress later on.

Metrics are divine. Metrics are worthless. What’s the truth?

A dominant aspect of product culture is our obsession with and divisiveness around metrics. Metrics can be a super-power or a major vulnerability. I’ve observed that individuals, and even full teams, tend to fall into one of two camps:

1. Metrics are worth everything

2. Metrics are worth nothing

These views lack nuance. Metrics are at once blunt instruments that must be contextualized – and powerful tactics to achieve a goal.

I wanted to share a note warning of the risks of these absolutist views, and highlight ways to avoid them.

Risks of over-fitting to metrics

Some teams seem ready to hire experimentation tools as their PM. But to paraphrase wisdom from a Facebook product executive:

“Do not outsource your product intuition to experiment results.”

Before we place our unadulterated faith in metrics, we should reflect on why they exist in the first place: Metrics are proxies for a goal.

Products exist to solve problems for or add value to people, or simply to achieve business objectives. In either case, products ladder to an aspirational mission, like helping people entertain each other or making meaningful connections between people and businesses.

Since missions are intentionally abstract, we create metrics to measure our success achieving them. The metrics get ingrained in the way we prioritize what work gets done, and tell us what’s working and what’s not. This makes metrics operationally relevant to our day-to-day in a way that missions often are not. Still, we can’t lose sight that the hierarchy between a mission and a metric is irreversible: the metric should evolve to fit the mission, the mission shouldn’t change to fit the metric.

The phenomenon of prioritizing metrics at the expense of goals is understood in academia. A UX researcher who also has a PhD in cognitive psychology, once surfaced two social science laws to me, and they stuck:

• Goodhart’s law: When a measure becomes a target, it ceases to be a good measure.

• Campbell’s law: The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor.

These resonate with my product experience. I once worked on a product team whose goal was to increase brand equity. For a metric, we chose a sentiment measurement instrumented by surveying users each day.

We developed a playbook for moving the metric. Among the most effective tactics was using the exact language of the survey question within in product copy. That tagline became prolific. Every product cycle, copywriters would suggest alternative framing, and every time PMs like me would shoot them down.

It’s no wonder: If you continually make a statement to people, a small proportion of people will respond differently to a survey that uses its language verbatim.

Now, the fact that people responded differently to the survey may indicate we were changing their hearts and minds. You could also argue this was the reasonable manifestation of a strategy to create the brand we desired, not unlike any company plastering their tagline across all their marketing. But on its face, it’s likely we were overfitting our strategy to a narrow sentiment metric rather than achieving our goal to build a sustainable brand foundation.

Risks of writing-off the data

Yet, it’s as bad a mistake – or worse – to ignore data we don’t like or fail to collect sufficient signal.

We’re all understandably passionate about our intuition. Companies hire talented designers, creatives, and product thinkers for their minds. It feels good to go with your gut, and even righteous to claim that we’re doing the “right thing” in spite of metrics.

What we forget is that numbers on a dashboard are not abstract concepts, but aggregated views of real people’s behavior. The ability to see how thousands or even millions of people are interacting with something in a single chart is an almost inconceivable innovation.

When a number regresses, we shouldn’t think of it as a chart inflecting, but as a shift in behavior of a lot of people at once.

Building and shipping things blind to metrics is a form of narcissism. It means you’re prioritizing what you like rather than what your users empirically value.

Embracing nuance

The remedy for these extreme perspectives is embracing nuance.

First, take time to pick the right metric. In my opinion, this is the single most important thing a PM does because it is the biggest influencer in determining what work gets done and what work survives.

In the context of avoiding metrics that incentivize the wrong thing, pressure test a metric by enumerating what you would do to game it. If required, flag counter metrics that will protect you from hitting your metric at the expense of your goal.

And while every team member should own this, I challenge product executives to consistently emphasize accountability to underlying goals; we don’t want people to perceive a choice between doing the right thing and a good performance rating.

Second, always contextualize data. Your obligation is to contextualize information, and pursue a product strategy that marries data with principles. Take a quantitative insight and state in sentence form what it means. Uncover nuance behind numbers through qualitative research. If you’re advocating to proceed in spite of a regression, explain why. If you’re advocating for doing what the data say in spite of misalignment with intuition, explain why. Don’t move on until you (and ideally, your team) feel convicted. Always be intentional about the relationship between data and your decisions.

Finally, and most importantly, use common sense. It’s often obvious, if unspoken, when we’re going down a path that’s good for numbers and bad for the goal. I find people with fresh eyes are particularly insightful at recognizing this because they lack institutional baggage and disillusionment. And here’s a litmus test for PMs: The harder you have to work to justify your strategy, the worse it probably is.

A metric is only as useful as your ability to measure it

The most important attribute of a metric is that it tracks well with your goal. The second most important attribute is that you can effectively measure it. I want to share lessons from picking a metric that aligned well with our long term strategy, but was challenging to measure, track, and move. To summarize: Metrics need to be not only strategically valuable, but also feasible to use operationally. Consider metrics that:

1. Measure impact over a holdout group, rather than goaling on a topline number

2. Measure absolute numbers, rather than proportions

3. Measure cohort effects or conversion, rather than acquisition

What were the issues with our metric?

Our goal was to drive adoption of a product. Specifically, this meant that we tried to inspire each of our users to adopt a feature once in their lifetime. We derived a lot of value to our platform when this happened, so this adoption represented something very meaningful. And yet:

Even if a metric is strategically valuable, if you can't operationalize it, it's a poor metric.

This was exactly our problem. Our metric was hard to measure, track, and move. Here were the issues:

1. It was vulnerable to factors outside our control: Our metric measured the number of users who adopted our product divided by the total number of users on our platform. This exposed us to changes in the user mix. New users are least likely to have adopted a specific feature, so as growth accelerated for our platform, our metric sagged. This was good in some ways (it encouraged us to focus on experiences for new users), but the effects were so large that our team's efforts were overshadowed.

   1. Recommendation: Goal on the difference between a test and holdout group. While it's standard practice to measure the impact of tests using a holdout group, teams choose whether their goal will be the topline metric or the delta between test and holdout groups. Topline goals force teams to confront external factors, whereas goals focused on impact over a holdout isolate the team's impact. Had we goaled on the difference between a test and control, the changes in user mix would have been irrelevant given they'd impact both groups equally and we could've understood our team's contribution more clearly.

   2. Recommendation: Measure using absolute numbers rather than proportions. Rather than proposing we increase adoption +10%, we could have proposed increasing adoption +X, where X is equal to +10%. These two numbers represent the same thing, but the latter wouldn't have been muddled by changes in user growth.

2. It was a lagging indicator of progress: We needed to convince users to do something once. Adoption goals are often lagging indicators; in other words, adoption metrics move after a trend change has occurred. Our changes could bend the adoption curve, but net very small benefit immediately. Consider a change made on the last day of a measurement period (e.g. a quarter or year) that makes new users 2x likelier to add your product on their first day: it would have no immediate impact on adoption even though it's very valuable in the long term. We can try to forecast long term impact, but extrapolating trends is imprecise and time bounding “long term” is arbitrary. There is no perfect replacement for adoption, but there are relevant alternatives depending on the team's strategy.

   1. Recommendation: Measure cohort behavior. When trying to change new user behavior, you can measure cohort differences. If our goal was to ensure this week's new users were adopting our product at greater rates than last week's new users, we could use cohort analysis to track just this.

   2. Recommendation: Measure conversion: If the goal is to fix a leaky funnel, you can measure conversion. For example, we know that some number of people an adoption flow each month where we prompt them to use our product. We could measure what proportion of the people who start the flow take the desired action. Notably, this lacks incentive to drive top-of-funnel traffic (which is sometimes the most effective lever). For that, adoption is the only option.

Development lessons for building a 0-1 product at big companies

Earlier in my Facebook career, I built a standalone app. Where many projects at big companies involve incremental changes or modifications to existing surfaces, we had the opportunity to build something from the ground up. Through our successes and tribulations, we learned four key lessons to share with teams building a 0 to 1 product:

1. Maximize input from research and other functions

2. Embrace iteration, but avoid last minute thrash

3. Increase accuracy of the engineering timeline by incorporating variance

1. Maximize input from research and other “Understand” functions

One of the great assets of a large companies that often differentiate them from scrappier startups is the depth of experts. In shaping our app's strategy, we maximized diverse perspectives. Strategies are best when developed in active consultation with people in “Understand” functions whose job it is to synthesize data.

Research and marketing teams often work day in and day out with our target users, so are in consistent conversation to understand needs. Ops teams are on the receiving end of passionate feedback from users, so can share pain points back to the product teams.

Research defined the app's purpose, core functionality, and helped improve our UX. Nearly all our product decisions had roots in a specific insight.

2. Embrace iteration, but avoid last minute thrash

There is a healthy push-pull relationship between embracing iterative work and minimizing thrash.

Facebook has a saying: “We're 1% finished.” Sometimes that's an overstatement! Since we were building something new, we made opinionated product decisions that were sometimes wrong. The team kept adaptive as our product and designs evolved.

Product feedback came at various stages of the process, and sometimes it took having an actual build we could dogfood to understand a feature's implications. It's always easier to move a button in a design file than it is to rewrite code, but reverting a feature doesn't need to be “churn;” it's the iterative process at work.

On the other hand, eleventh hour changes are painful. With less time to address changes, late-breaking feedback forces compromises to work-life balance, code quality, or even the product itself. To reduce the likelihood of disruptive feedback, consider these lessons:

1. Set clear expectations with leadership: We did not galvanize the scrutiny we needed with our product leadership early enough. We thoroughly reviewed product goals and strategy, but did not provide sufficient visibility into what we were building (and when we did, it was too much an after thought). To remedy this, we should have established a “one way door”: solicit prescriptive product feedback when there's sufficient time to pivot, rather than late (once code complete or “through the door”), when it'll ignite a firedrill. Another trick is to find a forcing function. Use milestones like public tests and betas or senior exec reviews to spawn the internal attention that a big launch otherwise precipitates.

2. Budget time for dogfooding and soak: If I could speak with my past self, I'd say, “Finish roadmapping. Identify a launch date. Now push it back by.” Budgeting time for quality polish is critical. All the theorizing in the world can't replace the experience of testing the real thing. The challenge is to use dogfooding and soak time earnestly, rather than as an opportunity to accelerate last minute feature development that could on its own create new regressions and bugs.

3. Increase accuracy of engineering timeline by incorporating variance

We committed externally to shipping the app before a specific date. As we conceptualized the app, we estimated build times so we knew how much we could fit in our MVP. Unfortunately, our timelines kept slipping. We identified several ways to increase accuracy of forecasts:

1. Be honest, and remove implicit pressures: Internal or external pressures beget unrealistic timelines. There may be a date we want to hit, but setting false expectations is counter-productive. Engineers or designers should be the ones generating estimates, and ought to prioritize honesty. For project managers likes PMs, EMs, and designer managers, remove implicit pressures and frame questions that solicit genuine responses (“What is a realistic range for how long this will take?” vs. “Do you think you can get this done by Friday?”).

2. Create estimates as a range: High variance in build times is inevitable as unexpected obstacles arise...or don't. Engineers can consider providing an estimate as a range (“My best guess is 1 week. Best case I'll be done in 5 days, worst case it'll take 2 weeks.”) rather than as an absolute (“1 week”). As important, communicate risks early and often so we can narrow and shift timelines accordingly.

3. Vocalize risks and tradeoffs: As execs are keen to say, everything is a prioritization problem. The whole team has responsibility to identify tradeoffs. Could we get this done faster if we simplified a feature in a certain way? Is a bigger upfront investment worthwhile to reduce tech debt down the road? The more internally communicative we are, the more we can evaluate tradeoffs with intention.