While most unicorns seem to be slowing down, there’s one that feels like it's just getting started: Ramp. 

From Techcrunch in July 2022:

Despite a cooling market, corporate spend management startup Ramp reports that it has more than doubled its revenue run rate since the start of the year.

The feat would be impressive in normal times, but is particularly so when tech companies — big and small — are laying off, freezing hiring and/or reporting slowing growth. 

How is Ramp continually able to grow, ship and improve the lives of its customers?

I spoke with Geoff Charles, Ramp’s VP of Product, to go deep into the decisions Ramp made to build a high-functioning product culture that scales.

Will:  How would you describe your product culture at Ramp? 

Geoff:  We have three vectors of our product culture. The first, which Ramp is mostly known for, is high product velocity. Over the last two years, we've shipped about five new product lines and a flurry of features for businesses of all sizes. And when we think about velocity, I think you essentially have to define or design your entire org and culture around speed, and be very open to the shortcomings of anchoring on speed. 

The second vector is around empowerment. A lot of times, especially in non-tech companies, product is the recipient of requirements from the business, so you have the business and the product teams, and they're separate organizational structures. And it's especially true in finance, tech, or FinTech, because finance tech is mostly finance companies that have a tech arm to it.

When tech companies really came out, they put that all on its heads, where business is actually led by the tech organization, they sell the products we build, we don’t build the products that they sell. That was a really intentional culture that we set forth at the beginning of Ramp to be product-driven. What that really means is building products for customers in service of the business, not for the business in service of customers.

The third vector is being okay with building what should be and not what is. That’s especially true in B2B, where it’s easy to take orders from customers, adding a button and a column, and you start building really poor B2B products that becomes nothing for everyone instead of something meaningful for a few people. So a third cultural aspect that we really anchored on was the ability to truly define what customers need instead of what customers ask for, and the ability to really deeply think about what things should be. 

Product Velocity 

Will: What are the trade-offs with anchoring around velocity? 

Geoff: There are a couple of dimensions here. The first is that the need for velocity falls mainly on our feature-facing teams whereas platform teams focus on precision, quality and uptime. We built very strong platform capabilities like authorization, payment systems and decision systems, that have compounded over time.

The feature-facing teams had less of a technical roadmap with regards to the long-term view of what they were building, and so the risk wasn’t “are we building it right?”, it was “is what we’re building what a customer wants?” So you essentially need velocity to ship it as quickly as possible and validate it with a customer.  Sure, you can use Figma prototypes–and we do use that a lot. But we also need to just build something fairly quickly and ship it. We definitely added tech debt in certain areas meaningfully, but deliberately, because we wanted to test it.  

The second is more on comprehensiveness, we shipped features that we’re not covering even close to 80% of the use cases. But we’re still meaningfully better than what was there today. It’s this concept of like, think through the 10x experience, walk back to the 1x or 2x experience and incrementally build and ship, which builds momentum. Nothing kills velocity more than a six month project that never sees the light of day. People get demotivated, and then the environment and the data changes. So ultimately, what you’ve actually set out to do is the wrong thing in the first place. So velocity helps mitigate that as well. 

So we end up sacrificing on two things. One is the tech debt in areas where we’re not certain, and two is the full-fledgedness of the feature. So the feature might have good user experience, but not solve every single problem for everyone. I think one way of reducing scope and increasing velocity is being much more opinionated around what you’re solving for. For example, permissions. Every single company will think about permissions in a different way. You could spend three years building the best permissioning system that has checkboxes for everything, which every single feature needs to be aware of and then your entire product development process slows down.

Or, you can say that we have four roles, and you take it or leave it. Sort of like a menu at a restaurant. You can train your entire staff to cook everything under the sun, or you can have six options. And you’re really good at those six options, and you’re much faster at actually creating that food. So we went down the opinionated route, and that helped us improve dramatically in terms of velocity because it reduces a lot of complexity with regard to our build and its maintenance. So there are certain things we decide that have an impact. Now the customer may really want fully customisable permissions, so we might lose that deal. That’s fine, we’re willing to lose these deals so that we can anchor back on velocity. 

But we never sacrifice user experience. We never, ever ship something that was a bad user experience. And the way we did that was to have a design report to the CTO just like product and engineering. Sometimes you have design reporting to product, and I think that’s a mistake because you essentially have conflicting priorities in terms of what is the right design and user experience. So having a very, very strong design team that is an equal partner in the product development process helps us make sure that we never sacrifice user experience. 

Empower your engineers

Will: Who is involved in the solution design once a problem has been defined?

Geoff:  One of the things I’ve realised within tech is that empowered engineers do not want to be given a requirements doc - they want to be co-founders of the solution. So the question really is when do you involve engineering? The moment that you have found a strong signal on the fact that you’ve found a very interesting problem and you’re converging on a potential solution, or forming an opinion on that solution. That’s when I’d bring in the engineering and design teams.

For each of these problem areas, we define a product leader, a design leader, and a tech lead. We don’t involve other cross-functional stakeholders but we do create visibility. We go into prototyping and come up with different solutions. We spend a lot of time thinking about user experience and using lightweight prototyping such as Figmas to go back to the initial customers that we did research on and say, “Hey, here’s a product that we built for you, interact with it, and let me know what you think? How do you feel? What do you value?” 

We spend a lot of time with engineering, designers and product in the room to build that empathy and energy from the customer. We spend a lot of time at the point and sometimes you’re like, why is an engineer in the room? They will code and build 10x faster after these types of calls, because they have empathy and they’re empowered. That upfront investment is so important. It has led to engineers being very different today than they were even three or five years ago, where they’re actually much more cross-functional. They’re more like product thinkers,not really interested in just the technical part, or that’s the DNA that Ramp looks for. I deeply believe that prototyping, involving cross-functional teams, being in the same room helps to find a good solution. Let’s go build something as quickly as possible and launch it. 

Respect for technology

Will: You mentioned that the business side is not telling you what to build, but you’re telling them what to sell. That’s a really fascinating dynamic. I’m curious how that was created, and what does it look like in practice? 

Geoff:  We started Ramp by building out the tech organization first. So the culture was set from the beginning around like a tech-forward culture. The way it’s maintained is continuing to hire people who deeply understand, empathize and respect technology. So in the interview process, it’s actually really important to harness that, as you can easily destroy a team if you hire a salesperson who just sees tech as IT that builds features that customers are asking for, without deeply understanding the fact that customers don’t actually know what they want.

To build long-term value at a company, you need to really invest in the technology you’re building and take bets that you’re probably three to five years away from customers actually wanting, and within the market it hasn’t even materialized. I think it really starts with the culture you set out at the founder level, because culture is set from the top. As a product leader, I was involved in hiring across marketing, sales, account management, talent and legal, and ensuring candidates each had a deep respect for technology.

Lastly, I think it’s about trust. If your tech team is building random stuff that customers don’t really use, it’s a sure way of reducing that trust, so with great power comes great responsibility where you need to prove every quarter, every sprint, every year the fact that customers love your product. And I think that’s really what I’m held accountable towards is the growth product through strong product market fit and word of mouth. And as long as that continues, then I’m trusted by the sales leaders to make those decisions. 

If you’ve made it this far, you may enjoy Product Life. Join thousands of product managers growing their careers by subscribing below:

Subscribe now

PMs are bats and product comes first

Will: How does a product or feature at Ramp go from inception to market? 

Geoff:  I love transparency and data. So I anchor on an extreme amount of data points that are constantly moving around in the organisation. I sort of picture PMs as like bats, where we are blind and have sonar, and as long as we continue getting signals back we’re able to effectively navigate the crazy ambiguous world we live in. We have processes where we get a ton of feedback from customers at every single point. We have surveys, analytics, in-app product reviews, third-party reviews, sales calls, sales-driven requests, account managers, customer success gives support, feeding data–it’s just constant data and feedback back to the PMs. And then the question is, how the hell do you deal with all these different data points?

So I’ll give the example of travel. There were a lot of data points, pointing to the fact that companies had a problem with regards to controlling spending on Ramp that was associated with travel. So Ramp came out of the pandemic, there was no travel. So our entire product was really focusing on the accounts payable use case, you buying software and you paying your ads on Ramp. As travel picked back up, we basically woke up to the fact that many people were requesting to travel in different areas, spending tons of money on airfare and hotels, and a lot of companies were requesting Ramp to build a booking platform that helps me control what my employees are booking on.

So again, customers were like, let me be prescriptive with this solution. They pattern match with what already exists today, the TripActions or the Concurs of the world basically forces the employee to use a clunky, expensive and terrible platform to book their business travel. So Ramp was like, there’s an opportunity here. We are not going to take that solution and are going to explore this opportunity the right way. We prioritised it because we saw an increase of 10x the number of spend that was happening on our platform, we had data on how much money was being spent outside of Ramp on travel. And we saw that there was a big business opportunity for us to focus on getting more travel spend on the Ramp corporate cards. 

We did a bunch of interviews, took a look at the market, our competitors, win-loss rates, and segmented customer interviews based on industry and size of company. And we found that what the vast majority of businesses truly wanted at the end of the day was visibility and accountability. So Ramp decided that the problem wasn’t that you couldn’t book on the platform, but what you truly want is the ability to know who is spending in and out of policy and correct that behaviour. What if the moment that you actually swiped our card we gave visibility to the finance team on what you actually bought, all the way from the class of ticket, itinerary, price and per diem? And we could automatically flag anything that was out of policy and enable the finance team to call that back. That is a better experience than having to force everyone to book through a certain portal and charge $30 per trip to do so.

So that’s the Ramp travel experience, which was mostly an expense policy and travel integration with account information that automated all the visibility of business travel within a single platform, and that was with your corporate card. So you can book from anywhere but still have centralised control. This led us to have a different type of product and take an anti-Concur, anti-managed travel solution for the vast majority of businesses that don’t have a ton of travel needs, but all businesses need that control and visibility. 

Product Management at Ramp

Will: What do you look for when hiring product managers?

Geoff: One is, I look at people who deeply care about the customer.  Do you care deeply about the customer? If someone is having a pain point with your product, are you going to say you don’t know because you don’t use it, or are you going to take ownership and try to solve it? These are very different thinking structures. I look for people who you can ask them a question and they’re not just going to answer the question, they’re going to explain their thought process, framework and principles.

I find those types of people to be so much better at cross-functional work because they’re able to explain how they got to the conclusion. I do have a strong bias towards experiences, especially for early on start ups, you can’t take a bet on people with no experience. I anchor toward people who have shipped products in the past.

That said, I also love internal transfers–we’ve had two on the team. People who have come in through different areas that are more generalist, like Biz Ops or even a UX designer, and giving them the opportunity to take on small parts of the product, are always great ways of hiring people.

I also like ex-founders, people who have started a company are excellent PMs because they have grit.

And lastly, communication. People who are very concise in the way they communicate and are able to effectively tell a story are incredible. Those are the must-haves. 

If Ramp’s culture speaks to you, they’re hiring for tons of roles across product management, design, engineering and more. Check out their open roles here.

Thanks again to Geoff Charles for taking the time to share his experience on building product cultures, org design and product management. Give him a follow on Twitter and follow Ramp to keep up with their product velocity in real time.

If you want to see more deep dives like this, drop a like, comment or reach out to me on Twitter.

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Subscribe now

Until next time,

Will

After several years as a product manager at Meta, I was ready to jump into the world of “web3”, a new ecosystem of applications built on top of blockchains.

But navigating web3 is hard. There’s a ton of hype, FOMO and acronyms (DAOs, DeFi, NFTs) that made it challenging to find the perfect fit for me.

Today, I wanted to share the playbook I used to navigate my job search in web3.

While my situation is web3 specific, I think this playbook can be extended to almost any emerging industry. So read on even if you’re not sold on web3 yet.

The outcome of this playbook is to help you go from 100s of possible entry points into an industry to 3-5 amazing fits for you.

There are three steps in this process. Each helps you narrow the aperture of opportunities to the ones that best align with your goals:

1. What stage of company am I looking for?

2. What area do I have the highest conviction in?

3. Who are my ideal teammates?

So if you’re exploring your next play in Web3 or an emerging industry, try working through the three steps below.

Step 1: What stage of company am I looking for?

Companies are more similar across stages than across industries.

For example, working at an early stage music NFT project will be more similar to being at a Y Combinator backed e-commerce startup than working at OpenSea.

Nikhyl Singhal, a VP of Product at Meta, introduced me to this concept. In one of his great essays, he shares how the cultures, compensation, exit opportunities, manager quality and background of peers vary wildly by the stage of the company.

There are a few reasons for this:

1. People sort themselves by risk-appetite (amongst other factors)

2. The problems being solved require different approaches

3. Operational cultures vary by stage

For these reasons, he suggests starting at the right stage for you before even looking at companies.

Nikhyl divides traditional companies into four main stages: the drunken walk, product-fit, hypergrowth and scale.

Web3 and many emerging industries are a little different.

1. The entire industry is nascent meaning even the largest companies (e.g. Coinbase, Opensea, Consensys) have potential to grow even more.

2. Company metrics like funding rounds, employee count or valuation aren’t as widely used. For example, the Ethereum Foundation has no external funding, ~400 employees and a token market cap of ~$370 billion. What stage is that at?

But the principle remains the same: deciding which stage to jump into will drastically change your experience.

For this reason, I’d suggest choosing between one of three stages of Web3 Growth.

Here are the key considerations of each stage of team.

Early: Pre-Product Market Fit

• Key question: Do you want to build the first iterations of a Web3 product?

• Pros: creative, small teams, more potential upside, less process, less politics.

• Cons: higher risk, unproven model, less need for a traditional product manager.

Growth: Post-Product Market Fit

• Key question: Do you want to grow a Web3 product that has traction?

• Pros: fast-paced, existing consumers/customers, more established team.

• Cons: can be stressful, ambiguous, and lack structure.

Scale: Expanding to new markets

• Key question: Do you want to work on Web3 products with the structure of an established team?

• Pros: structure, strong mentorship, resources, brand recognition

• Cons: slower moving, more process, upside may be already captured

The key metric here is Product-Market Fit — this means the team has released a product that has significant traction. Lenny Rachitsky has a great compilation of how the best experts define product-market fit.

Think about the right stage for you, regardless of the specific area or company.

Step 2: What area do I have the highest conviction in?

It’s now time to explore the landscape itself.

But in true PM fashion, define your decision-making criteria ahead of discovery to have better results.

The desired outcome of this step is to find the sector of Web3 that you have the most conviction in. Conviction is a combination of optimism for its mass adoption, signs of explosive growth and an understanding of the problems it solves.

To do this, create a table of all of the areas in Web3 that you want to explore. From here, I’d suggest looking at the following five-axes to assess your conviction.

1. Mass Adoption - how large can you see this getting?

2. Talent Inflows - can this space attract incredible talent?

3. Capital Inflows - can this space attract capital and customers?

4. Innovation - how much better is the web3 solution versus web2?

5. Your specialized knowledge - how many unique insights do I have about this space?

Measuring your conviction against axes makes it quantifiable, transparent and objective.

Use a table to assign scores across each axis for your areas of interest. My table looked like this, with a 10 point score for each axis.

From this exercise, you’ll have 1-2 areas that you have high conviction in.

Going one step further, turn that area into your own Web3 thesis. This is a statement that encapsulates your conviction and why you hold it.

Here’s a template:

I believe [area X] will solve [important problem Y] through [innovation Z]. This is based on my [experience/unique insight] and the [talent/capital inflows] this sector is attracting.

Here’s my thesis:

I believe DeFi will solve regional barriers in financial infrastructure through digitally native asset rails.

This is based on my experience building WhatsApp Payment for Brazil and the influx of incredible talent and partnerships that this sector is attracting.

Get creative with your thesis. The more unique it is to you, the more conviction you likely have.

(P.S. if you write a thesis, tweet it out, tag me and I’ll retweet it to help you find companies that are building against your thesis).

Step 3: Who are my ideal teammates?

One thing I love about Web3 is the diversity of backgrounds it attracts. This ranges from artists to community managers to game developers.

Defining your ideal teammates will help you whittle down a medium list of teams to a handful of excellent fits.

Move past the obvious filters — like smart peers, a good manager, leadership you respect etc. — and ask questions that can help you distinguish between companies.

Here are some of the questions you may want to ask yourself:

1. Experience Level: do I want to be with industry veterans or newcomers with no preconceptions?

2. Product Culture: do I want to be on a team with an established product culture or do I want to help build it?

3. Manager involvement: do I want an active manager or one who will give me significant independence

4. Cross-functions: do I want to primarily work with designers, business development, data scientists, community managers, marketers or engineers?

Assessing these will take time. LinkedIn is your best friend for the first pass, but beyond this, you’ll need to start speaking to people on these teams.

Twitter is the easiest place to reach out to web3 operators. They’re also very excited to speak with you — hiring great talent is at the top of everyone’s mind right now.

In my web3 job search, I reached out to my future manager with this simple message:

Hey XXX. I’m a PM at Facebook working on developer experiences. Before this, I worked as a PM on WhatsApp Payments.

I’m excited by crypto and am exploring the right next step. Paxos seems great and I’d love to learn about your team. Would you be open to a quick chat?

So once you’ve found the 3-5 teams that you want to explore more, reach out to some operators with this template.

Recap on the process

If you’re looking for your perfect role in Web3, try answering these three questions:

1. What stage of company am I looking for?

2. What area do I have the highest conviction in?

3. Who are my ideal teammates?

If your exploring non-web3 areas, try this approach anyways!

It will force you to narrow your focus, be objective and find the best fit for your career goals.

Good luck!

🚨 Featured job opportunities

👾 Dapper Labs: Product Manager, Data Analytics (Remote - North America)

💸 Argent: Senior Product Manager - Mobile (Remote - Europe)

🤝 Paxos: Product Manager - Securities Settlement (New York City, US Remote)

🧑‍🏫 Synthesis: Senior Product Manager (Remote)

🩺 Canvas Medical: Technical Product Manager (San Francisco, Remote US)

If your team is hiring, share a role with 9000+ product people here.

Life update: I’ve decided to make the jump from Facebook/Meta into the world of blockchain, crypto and web3. I’ll be joining Paxos as a product manager to modernize financial infrastructure using blockchain. 💸

I consider myself very logical. I don’t tend to act rashly and get a kick out of building frameworks and decision-making structures.

So I want to share my step-by-step process for making this big life decision. I’ll break it down into three repeatable steps:

1. Choose an area - find a growing area with a problem that you have personal conviction in.

2. Choose a stage - Decide if you want wartime or peacetime, then zero in on the right maturity for you.

3. Find a team-fit - find colleagues you respect, a need for your skills, and a strategy you buy

I hope this helps other people who are thinking about their own life transitions. ☺️

1/ Choose an area

Here’s a simple idea: work in a growing area. Venture capitalist Arianna Simpson put this well:

A rising tide lifts all boats. Being in a growing industry or space gives you more room to learn, develop valuable skills and meet other people in similar stages of their careers. I wrote about this idea in more depth here.

The less simple piece is finding the tide you are most bullish on. This requires a combination of objective measures (ex. user growth, top talent mobility) and personal experience.

For me, I’ve been optimistic about payments and financial infrastructure for a long time.

In university, I did my thesis on M-PESA (the largest mobile money network in the world) and its effect on household spending in Kenya.

I was amazed to see how this new financial infrastructure allowed people to send more gross remittances, save more and spend less on transportation (because money was no longer needed to be transacted physically).

I could also see how people could access other financial services other than payments, like loans, mortgages, investments, through this new infrastructure. This was the clearest example I had ever seen of technology giving people better economic opportunity and mobility.

This excitement led me to become a product manager on the WhatsApp Payments team at Facebook. During this time, I led teams focussed on two areas: launching WhatsApp peer-to-peer (P2P) payments in Brazil and scaling our compliance platform to better support anti-money laundering (AML), counter-terrorism financing (CTF), and risk screening.

On the team, I kept bumping into the limitations of payment “rails”. This is the infrastructure (or plumbing) that allows money to move from one account to another. An example of this limitation is how regionally focussed it is -- it's infinitely more challenging for money to move between countries than within countries. This has many consequences, including

1. the need to customize/re-build payment products in each country

2. many emerging markets miss out on financial infrastructure

3. use cases limited by old infrastructure

I shared some of these learnings on Twitter in December 2020 and multiple people suggested that web3 technologies could be a solution.

Blockchains, for example, let digital currencies move instantly on infrastructure not owned by oligopolies and could allow people in Nigeria, Peru, and Japan to all access the same financial products. This got me excited and I started to explore web3.

Looking at my next step, I wanted to solve some of the problems I had encountered trying to build payment products in emerging markets. While many have built on top of existing rails in the past, I was excited by blockchains’ abilities to build new ones altogether.

For that reason, I knew I wanted to dive into the area of new financial infrastructure with blockchain.

The key idea here: I didn't want to choose an area because of hype. Yes, growth is an important factor. But I wanted a rising tide that is in a space I have personal conviction in.

2/ Choose a stage

Nikhyl Singh, a VP of product at Meta, wrote a great piece called Stage of company, not name of company. In it, he divides all tech companies into two types: peacetime and wartime.

Big tech is peace. Stable, predictable and "default-alive". There is a lot of benefits to this environment and I learned a ton from my time at Facebook — evidenced by this newsletter’s 40+ articles and 50,000+ words!

But I yearned for war: less structure, more ownership and room to create new ways of doing things. 

I’m also at a stage of my life where I’m flexible and can take risks (no kids, no mortgage and some financial runway). It felt like a good time to introduce more risk and accountability.

Nikhyl suggests that there are two "wartime" stages: the drunken walk and hypergrowth. Deciding between the two was interesting and required reflection on my personality and goals.

Although I could see myself becoming a founder one day, I ultimately landed on hypergrowth because it’s where I feel I can add the most value as a PM.

To recap, my framework now had two things completed:

1. Space: blockchain-based financial infrastructure

2. Stage: wartime + hypergrowth

It was just down to finding a mutual fit with the right team.

3/ Find team-fit

I looked for a team with:

1. Colleagues I admire

2. A strategy I believed in

3. A need for my skillset

After many great conversations, I knew that Paxos was the right fit for me. The team is incredible, they have great traction and a strong direction for the future.

Paxos is a regulated financial infrastructure company. Many people (even in web3) haven’t heard of Paxos because it operates behind the scenes of some major breakthroughs in crypto. Here are some of the exciting work the team is doing:

1. Powers the crypto wallets of PayPal, Revolut, MercadoPago, InteractiveBroker and more

2. Supports USDP and Pax Gold, two regulated stablecoins that unlock new use cases for retail and institutions. Notably, USDP was chosen by Novi (Facebook) to be the stablecoin in the Novi pilot facilitating remittances between Guatemala and the US.

3. Settlement solutions for institutions like Credit Suisse, Bank of America and Mastercard. This is one of the most exciting areas for enterprise-grade blockchain use cases, allowing for new functionality like T+0 settlement.

The strategy was also clear: build regulated infrastructure that allows assets to move instantaneously, anywhere in the world, at any time.

This strategy, especially the focus on regulation, aligned with my view on how to approach this space based on my time at WhatsApp Payments. I loved that there was a big mission and a deliberate path to get there. I was sold.

P.S. If this mission sounds exciting, Paxos is hiring a ton across many roles:

• Software Engineer, Product Managers

• Business Development, Sales, Customer Success, Ops

• Legal, Compliance, Talent, Accounting

Open roles here. If you have questions, DM me on Twitter.

Ultimately, deciding on the right team is about defining what makes a good team to you. For me, this skewed heavily to the people and was a strategy I could help advance. If you’re still thinking of how to narrow down teams, I’ll suggest another great article by Nikhyl Singh that helped me think about the details of team selection.

Conclusion

I have a lot to learn about blockchain, stablecoins and financial infrastructure and I’m excited to dig in.

I’ll be writing about my lessons from building products in web3 in this newsletter. If this peaks your curiosity (and you’re new here), subscribe below: 

Subscribe now

If you’re building in web3 or work on financial infrastructure, respond to this email, leave a comment below or DM me on Twitter. I’d love to say hello.

Let’s build! 🧱

An uproar ensued. Many felt like this was further proof that product managers don't do anything. Others (mostly PMs at other companies) applauded this model. PMs from across the internet weighed in on this method.

John Cutler from Amplitude pointed out one truth to the situation: people were quick to judge with no context.

Today, I want to add some context and share how we define the PM role at Facebook, how our relationship with engineers works in practice and why this model works for us (and perhaps your team too).

The Role of a PM = Execution + Strategy

Since joining Facebook, I've been a PM on four teams across different parts of the company. They were in wildly different areas and the day-to-day responsibilities varied. But the constant was what I was expected to deliver and my working model with engineers.

Product managers at Facebook are responsible for two key outcomes: great strategy and great execution. A former manager explained this principle in a catchier way:

The role of a product manager is to figure out what game we're playing and how we're going to play it.

Strategy is choosing the game we're playing. It’s finding worthwhile areas to invest in and creating a compelling vision for how we can succeed in this game. A great strategy connects to the evolving need of users, aligns with the business’s direction and has a reasonable set of pillars to make progress.

Execution is how we play the game. It’s the day-to-day processes, decisions and actions we take to make progress towards our mission. Execution is what Ben’s tweet was referring to, so I’d like to spend more time here.

In my mind, great execution boils down to nailing two large categories of sub-tasks:

Prioritization involves, roadmapping, estimating impact and deciding on the right features to build. This is an important part of my role and this is the category of execution where I spend the majority of my time.

The other side is process management. The process is everything that is necessary to go from a product brief to a launched and successful outcome.

Doing these sub-tasks well can help create a great execution rhythm. But If a PM were to do all of these for every feature that they were involved in, this would be a full-time role.

And for more junior PMs, this is the full-time role. When I first became a PM, the majority of my day was supporting the execution rhythm of the team. This was project management, Gantt charts, discussing experiment results and writing weekly summaries. When I first started, I was more of a feature manager than a product manager.

But after my first evaluation cycle, I learned a key point: PMs are responsible for the outcomes of the team; the inputs are subjective. For example:

• No one cares that you built a Gantt chart; they care that you delivered the project on time.

• No one cares that you created meeting agendas, wrote weekly emails or created tasks; they care that the project had an impact when shipped.

• No one cares that you wrote SQL queries because your data scientist was on PTO; they care that your goals were reasonable and achieved.

This understanding made me stop defining my role by the tasks I needed to do and instead focus on the output I was responsible for creating.

Let me be clear: PMs are 100% accountable for the results of your team. If your team fails to hit your goals, it’s your neck on the line. Cemre explains this well:

But results are an outcome; the inputs to create that outcome are your team’s decisions. Your goal as a PM should be to find the best combination of inputs to maximize the outcomes of your team. Ray Dalio calls this systematic thinking.

This means you don't need to do every task related to execution. In fact, the only way to scale your role/impact in the org is to begin meta-execution.

Meta-Execution

Meta-execution is executing through others. This is how product directors can steer a team of 200 people without writing tickets, doing experiment reviews or writing weekly updates.

The ability to empower leaders within your team to have more ownership is what separates execution for a PM on a 5 person eng team and a PM who drives a 40 person eng team.

Meta-execution is about empowering leaders within your team to have more ownership. This allows the PM to focus on the problems they are uniquely able to solve.

Let's revisit the list of execution items above. You could stack rank these into a list of items that the PM is uniquely positioned to solve. My view would be:

The ones towards the top of the list are the ones that will always need your attention while the ones on the bottom can be delegated to other leaders on your team.

Meta-execution requires finding capable leaders to drive more execution independently. Once you’ve identified these leaders, empower them with ownership and continue to offer support along the way.

This helps you get to a world where meaningful parts of execution are driven by other team members.

A model like this makes sure you're helping the team execute on the areas where they need your support the most. It also frees up your capacity, which you can then use to define the longer-term strategy for your product area.

Key points:

1. PMs are responsible for the outcomes of the team; the inputs are subjective. Your goal should be to find the best combination of inputs to maximize the outcomes of your team.

2. The more senior a PM you become, the more impact you can have with strategy. Freeing your own capacity while not allowing outcomes to suffer requires meta-execution.

3. But regardless of your delegation abilities, you will stay accountable for execution.

If you’ve made it this far, you may enjoy Product Life. Join thousands of product managers who are growing their careers by subscribing below:

Subscribe now

Empowered Product Teams

You don't need to look far to find criticisms of this method. From Ben's post:

Criticisms like these create an adversarial view between product and engineering. It's saying that PMs have certain tasks they need to do and engineers have others.

This criticism is only valid when teams do not decide what to build. If you don’t decide what to build, then all that matters is how you deliver the project that was assigned to you.

If your team does decide what to build, then the outcome you create is how you’ll be judged — not “who does what”.

This is what Marty Cagan refers to as the difference between empowered and non-empowered teams.

In most companies, technology teams exist “to serve the business.”  That is very often the literal phrase you will hear. But even if they aren’t explicit about it, the different parts of the business end up driving what is actually built by the technology teams.

However, in contrast, in strong product organizations, teams exist for a very different purpose.  They exist “to serve the customers, in ways that meet the needs of the business.”

This perfectly highlights the contrast. At Facebook, product teams decide what is the best thing to build and are responsible for the outcomes.

In this world, there is a significant amount of work on understanding the customer, user, business and market needs for what you're building. This is why a PM focussed solely on execution is a sign of a non-empowered team. Dare captures this well:

If your team is responsible for outcomes, engineers are happy to drive parts of the execution if it enables the PM to find the most impactful outcome to create.

When engineers are evaluated on the impact they create (ex. grew DAU by +5%), they want the projects that can deliver massive impact. If I were in their shoes, I’d much rather my PM spend time finding these projects rather than managing the tasks of the project I’m working on.

Key points:

• Empowered product teams are responsible for outcomes, not inputs. This is why people take on tasks outside of their traditional roles (to support the outcome).

• On an empowered product team, everyone thinks about the best way to improve the outcome. This may involve changing the inputs (ex. engineers drive parts of execution so PMs can identify the right areas to focus on).

• The best way for a PM to help an engineer is to ensure they are working on the most impactful work.

From the Engineers POV

Let’s go deeper into the perspective of an engineer.

In an empowered product team, all engineers think about the outcomes of the team. They are involved in prioritization, work with cross-functional partners (ex. design, data science) and are evaluated on the impact they create — not the lines of code they write.

Dominik Krejcik wrote an excellent description of what it’s like being a tech lead on an empowered product team:

Being a tech lead in an empowered product team is not a purely technical role. In addition to your typical engineering duties, you are a part of the product manager/tech lead/product designer trifecta and you collaborate on product decisions.

Collaborating on product decisions is possible when engineers have ownership over an area. A way for engineers to grow their ownership is by driving meaningful parts of execution.

Communicating progress, leading experimentation and driving project management will make the engineer the face of the product and necessitate their inclusion in important decisions.

Here are some ways I’ve seen engineers and PMs work together to drive execution:

• Creating roadmaps: PM drives the process (with input from everyone) to find the most impactful projects. Once they have been prioritized and the project has been kicked off, engineers own the solution and track progress towards milestones.

• Communication: Engineers will drive meetings, documentation and general communication for the feature they are supporting. More senior eng will drive progress for larger areas. PMs will drive meetings, documentation and project management for the entire team.

• Project management: PMs create the execution structure (ex. recurring meetings, project tracker, milestones check-ins) and engineers drive it. Engineers who lead these meetings are responsible for raising blockers and support each other for hitting the goals. The PM plugs into the parts of execution that they can best support

These engineers drive execution to develop skills, be involved in product decisions and earn the ability to take on more ambiguous problems.

Key points:

• Empowered engineers want to collaborate on product decisions. Driving execution is a great way to develop ownership and become included in important decisions.

• PMs and engineers should work together to make sure that execution is well-handled. If there are gaps in the process, the PM should aim to fix them.

Putting this All-Together

When a team is evaluated on outcomes, they adjust their inputs to have the most impact. While we’ve spoken about engineers taking on execution tasks, there are many other permutations of this concept:

• If a PM can free up a tech lead’s time to architect a large-scale problem, the PM should jump in.

• If a designer can drive the project management to allow a PM to formalize a new partnership, the designer should jump in.

• If data science needs leadership buy-in to finalize goals, PMs can jump in to drive that alignment.

This is because the product team is, in fact, a team. It’s not a series of individual roles who sit next to each other.

Imagine a football/soccer team where strikers refused to play defence because that wasn’t their role. This is what some of the gripes on Ben’s original post sound like.

Product managers are leaders on a team. Not because we have any authority, but because we are responsible for the long-term outcomes of our teams.

Sometimes, it’s in the best interest of our teams for the PM to take a step back from execution to develop leaders on the team, define long-term plans and make sure we’re working on the absolute highest priority items.

Thanks for reading. It took me a while to frame my ideas on this topic so I’d be keen to hear your thoughts on Twitter. If you enjoyed this read, share it with a friend:

Share

And if you’re new here, join thousands of product managers who are growing their career by subscribing below:

Subscribe now

See you next week,

Will

Two years ago, I joined Facebook as a Rotational Product Manager (RPM). This is a role designed for people new to product management, and it offers them the chance to rotate through three teams across Facebook (the company) over an 18 month period.

This experience changed the trajectory of my life and career. It’s also an experience I get a lot of questions about. Today, I want to share the story of my 18 months as an RPM, my three rotations and the lessons I learned along the way.

For those interested, applications for the RPM program open on July 26th and we’re hiring for our offices in Menlo Park, Seattle, New York and London. I wrote about my 4-year journey to the RPM program here.

I’m also writing a short guide that shares all of my application, resume and interview advice for the program. If this sounds useful, reply to this email. If you’re reading this on the website, subscribe below and respond to the welcome email.

Subscribe now

Finally, this won’t be a short article — I’d like to tell you the full story, so you really understand what being an RPM is like. Alright, let’s do it.

👍 Ramping Up

After 5 months of backpacking through Asia with my girlfriend, I relocated from Vancouver, Canada, to Menlo Park, USA.

On my first day, I arrived at 1 Hacker Way, Facebook’s global headquarters, with a sense of wonder. People zipped around on bikes, gathered in courtyards eating free breakfast and sipped smoothies on their way to meetings.

Over the first four weeks, this sense of wonder remained. We had some training around engineering, data science and product basics. But more importantly, we had time to get to know our managers and the rest of our cohort of RPMs.

My manager was an awesome, extremely experienced PM named Matt. We hit it off, and I remember pouring out my life story to him on Day 1. He would be my manager for the full 18-month program, helping me grow my career and improve as a product manager.

If I could use one word to describe my cohort of fellow RPMs, it would be impressive. These people had impeccable credentials and really great personalities. We spent time ramping up together and exploring the Bay Area — including a winery trip to Sonoma, hikes near Sausalito and happy hours in San Francisco.

It soon came time to jump into our first rotations. Before we joined Facebook, the RPM program director sent us all an email and asked us what we were interested in working on. These would inform our first rotations. Here’s the list I shared:

On my second last day of training, I woke up to a post in an internal group with the title “R1 RPM Rotations for H2 2019”. I fumbled with my phone to open it up.

I scrolled down and found my name next to a project called “Profile Memorialization/Supporting the Bereaved on Facebook.” I’m a little embarrassed to admit it, but my immediate next action was googling the word “bereaved”.

💐 Rotation 1: Death 101 and learning the game

A few days later, I officially started my first rotation on Facebook’s Memorialization team. This team tackled an incredibly important problem: creating positive experiences (and minimizing negatives ones) for the bereaved on Facebook.

Training had given me a rough idea of where I should start: have 1:1s with all of my teammates, understand how I can start adding value and speaking with my manager about where I can have the most impact.

But nothing could prepare me for my second day of work. My team had two user researchers — people with incredible academic backgrounds who help to understand the qualitative nuance of building in specific spaces. They had organized a session for me that they called, “Death 101”.

We spent two hours going through the latest research on death online, where people seek comfort during bereavement and how our products fit into their journey.

It was heavy. But it impressed on me the importance of what the team was doing.

The first six weeks were dedicated to understanding the team, our products and my role on the team. My manager on this rotation was a veteran PM who was exceptionally strong in creating direction in an ambiguous area. She eased me into the role by allowing me to shadow her in a few meetings, letting me ask any question (no matter how dumb) and sharing her views on where the team could go.

From this rotation, one of the items that really stuck with me was my manager’s definition of the product manager’s responsibility:

Product managers decide what game we’re playing and how we’re playing it.

Succinct and to the point, it helped me understand that I needed to know “which game” before making rash decisions on how to play it.

After six weeks on the team, I was able to start driving new projects rather than supporting existing ones. This started with a brainstorm around a new team strategy that the leadership team had been discussing for a while.

From here, we voted on the ones with the highest impact to effort ratio. We came to a great shortlist of a few ideas.

I took these ideas back and decided to work with relevant people to scope them out. If it was a design-heavy project, for example, I worked with our designer to define it. This led us to define some initial product briefs — documents that outline the goal of a product, the details of what we would build it and how we’ll measure success.

Midway through the six months, I felt like a true part of the team. I led our weekly meetings, worked with engineers on features and was accountable for deliverables. At this moment I felt like I understood the broad strokes of the role.

I was also beginning to think more about our strategy. While I inherited a charter, my research into “what game we’re playing” led me to conversations with our leadership team to understand how our team was in line with the broader Facebook strategy.

I struggled to manage these strategy explorations with the day-to-day execution (project management, feature definition, communication). I felt like I needed to be involved with every detail of the project for it to succeed. I eventually realized this was unsustainable and began to loosen my attachment to any individual feature to think about the direction for the next six months after I left

As my time on the team was coming to an end, I thought about what else I wanted to learn at Facebook. Being a cult follower of Chamath Palihapitiya, I knew that I wanted to spend some time working on a consumer growth team at Facebook. Facebook is best known for the growth PM archetype— moving incredibly fast, being analytical and scaling things internationally. I knew I’d kick myself if I left Facebook without learning this skill set.

For your second and third rotations as an RPM, teams submit projects and RPMs are encouraged to speak to these teams to find a good fit. I spoke to about 10 teams, all of whom were hiring an RPM to focus on growth. Eventually, I landed on a team with insane growth, a great manager and an even stronger PM culture: Facebook Watch.

Lessons from Memorialization

• The role of a product manager is to decide what game your team is playing and how you’ll play it

• Stepping back from the day-to-day is critical in order to think about long-term strategy

• Give yourself enough time to understand the nuances of your space before pushing new initiatives

• I wrote a whole article on specific product lessons I learned from memorialization.

If you’ve made it this far, you may enjoy my newsletter Product Life. Join thousands of product managers who are growing their careers by subscribing below:

Subscribe now

📈 Rotation 2: Growth, Covid Surge and Execution

Watch was growing at a dizzying pace. It felt like every month we were passing an insane new milestone. I was keen to jump in and learn how to develop my execution skills, my knowledge of growth principles and my ability to use data.

My area of ownership was Activation — getting new people to try Watch and become active users.

In Memorialization, the goals were hard to define which made product intuition the key area to develop. This was the opposite of Growth: the goal extremely well-defined (“get more users”) and it was all about how we would do that.

From day 1, my role was to understand which users were the most important to activate (“what game we’re playing”) and how we would activate them (“how we’ll play it”). This may sound simple, but at Facebook’s scale, there are thousands of cohorts, billions of data points and limited time/resources to have an impact.

Fortunately, Watch had an incredible group of product managers who I could spend time with and learn from. My manager was a rockstar PM who excelled in driving execution across a broad portfolio — the exact skill set I wanted to develop during my time on Watch.

I also benefitted a lot from time with our Growth lead. He was an MIT physicist turned McKinsey consultant turned growth product manager extraordinaire. He shared a lot of practical advice around navigating my career.

I learned that being a growth product manager is about making changes in the product that increase its discoverability, engagement, retention or monetization. These changes make up a portfolio of two types of projects: short-term, incremental tactics and long-term, habit-changing products.

I started on the former. These involved defining features, working with design to determine the experience, supporting engineering as they built it and working with analytics to review the experiment results. I was shocked at how fast this cycle would move. For some projects, it went from idea to public launch in 4-6 weeks. And these weren’t all minor changes - sometimes they would bring millions of new people into the product every day.

The long-term bets, however, required partnerships with other parts of the company. One, for example, was working closely with the Facebook News Feed team to identify long-term opportunities to boost the discoverability of videos in the feed. This involved more strategy alignment, escalating areas where we did not have consensus and then collaborating on a bigger project.

In the middle of my rotation, the first wave of COVID-19 lockdowns started to sweep the world. With people stuck at home, more people were spending time on enjoying videos on Facebook.

The area I was responsible for, activation, saw a huge surge. But with the surge upon us we realized the need to improve our first-time user experience (FTUX) to make sure those new users came back.

I decided to lead this sprint as it was a natural extension of my scope. It involved creating a new strategy, aligning quickly with our leadership, and executing a series of brand-new features. This challenged me to grow my leadership skills and ability to tackle critical projects.

Towards the end of my rotation, I started to feel confident in my execution abilities. At this point, I wanted to find a team where I could develop my strategy skillset and work on an area I was especially passionate about.

Remember the list of teams I said I was interested in before I joined Facebook? WhatsApp Payments was #1 on the list. I did my undergraduate thesis on mobile money in Kenya and was passionate about financial inclusion.

I listened in on the WhatsApp Payments All-Hands and was impressed by one of the product leads. I sent her a message afterwards and asked her to submit an RPM project to take me on. Two months later, I joined her team to support the launch and growth of WhatsApp Payments in Brazil.

Lessons from Watch

• When you’ve nailed a strong direction, you can focus on perfect execution.

• Choose a team for the product managers you’ll ultimately work with. These are the people whose habits and skills you’ll adopt.

• Seek opportunities to extend your scope in order to grow.

💸 Rotation 3: Money, Stakeholders and Brazil

Six days before joining the team, the Brazilian Central Bank suspended the roll-out of WhatsApp P2P to “preserve an adequate competitive environment” (source). This was my first clue into how visible and high-level the work was going to be.

At this point, I had become pretty good at ramping up. Joining the payments space, however, was a whole different animal. In addition to the product teams, there was a whole suite of roles involved. This involved:

• Go-to-market teams like product marketing, partnerships, operations and customer support.

• External payment companies that we were working with for the launch like Mastercard, Visa, Cielo and Nubank.

• Compliance, legal and risk teams to ensure that we were following the laws, making informed policy decisions and following financial regulations like Anti-Money Laundering (AML) and Know Your Customer (KYC).

• Technologists with payment expertise like partner engineers, solutions engineers, external consultancies and technical program managers.

With all these roles and the news of suspension in Brazil, my role quickly evolved into supporting the relevant moving parts to support going live again.

[While I usually try to be open with my experiences, I won’t go into as much detail given the sensitive nature of this work.]

Product management in payments was wildly different from my past two rotations. The PM in this area was more responsible than ever to build alignment, define a path forward and then lead execution on it.

Tactically, this meant that I did a lot more decision-making frameworks than I did product briefs. It also meant closer collaboration with leadership teams to make sure our strategy was coherent.

My manager in this rotation was incredible and held me to a high standard. She didn’t care if I was an RPM, she expected me to operate at the same level as the more senior PMs on her team. I appreciated this and found myself growing immensely under her mentorship.

A lot of the impact I had that half involved scaling up new teams to tackle areas of the payment stack that would be necessary to roll out the product to different markets. At times, this would mean defining strategy, targets and an execution plan for workstreams that involved 50+ people. More than anything, this decision taught me leadership and the skills necessary to coordinate large teams.

Towards the end of my rotation, we were able to land important strategies for the growth of WhatsApp Payments, scale platforms to help us meet high levels of compliance and support other payment initiatives across the company.

Lessons from Payments

I actually shared a Twitter thread with all of my specific learnings from this rotation. Have a look:

In closing

Looking back with some time to reflect, I’m so grateful for my 18 months as a Rotational Product Manager.

It really was an accelerated path to being a strong product manager. It also gave me the chance to meet great people along the way. I want to close with some of the high-level lessons I learned from my experience:

1. People > Area: While learning the nuances of a space is great, its ultimately your manager, teammates and mentors that will determine how fast you’ll grow.

2. When starting out, prioritise execution over strategy: Strategy is sexy and everyone wants to call the shots. But getting better at execution — project management, making decisions, defining features etc. — is table stakes to growing your career as a PM. Don’t neglect it!

3. Be proactive: This is the most important trait that has helped me get to Facebook and thrive while here. Find the opportunities that excite you, build the experiences you need and act more than you ponder.

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Subscribe now

Summary: There are four archetypes of product managers — engineering-driven, data-driven, design-driven and business-driven. Find the PM archetype that best matches your skillset to have the most impact. If you’re in one of these roles, find ways to stretch yourself to become more well-rounded.

A huge privilege of entering product management as a Rotational Product Manager was the ability to PM several different teams. So far, I’ve been a PM on four different teams at Facebook.

Here’s the interesting part: my role in each team varied wildly.

I tried to understand why by thinking about the different axes on which the teams differed. I thought of a few:

• Stage of the team: early bet, growth, mature, declining.

• Tech stack: Backend, frontend,  infrastructure, ML.

• Users: B2B, B2C, consumer.

• Area: regulation, market positioning, stage of adoption. 

But none of these aptly described the differences. That is until I read Sachin Rekhi’s insightful piece on “Finding Product Culture Fit”. In the piece (which you should read), Sachin lists the four product cultures that dominate tech companies: engineering-driven, data-driven, design-driven, and sales-driven product cultures.

He gives some examples of how different cultures drive some companies:

These helped me understand how companies think of building products. But it also gave me the vocabulary to describe how the role of a PM differs across teams within a company.

I want to build on Sachin’s piece to share the four archetypes of a PM. These are the four different roles that I’ve observed product managers filling depending on the needs of their team.

Understanding PM archetypes has three distinct benefits:

1. Find roles where your inclinations are valued: Not all PM roles are created equal. Find the ones that align with your strengths and interests to learn the most and move up quickly.

2. Find stretch goals: If you’d like to develop outside of your archetype, seek out products that require skills from a different one. This can help you become more well-rounded (which is important for PMs).

3. Humility: Appreciate the different strengths that other PMs have. You may be a rockstar in one area but you still have a lot to learn from others.

I’ll describe the archetypes, how to think of them as axes, and how to use them to build your PM skillset for the most success. Let’s jump in.

Engineering-Driven PMs

What they do: Identify where to apply technical knowledge for the highest impact. Roles like these often require a technical background because what your team is doing is not understandable by all. This role tends to exist in organizations with enough scale to specialize a team on just the tech stack powering other products.

These PMs rely on their engineering counterparts to help with items like feature definition and opportunity sizing. This is because the engineers know the problem space and potential solutions better than other product team members (ex. data science or design). Being able to communicate and earn the respect of senior engineers is a must-have for these PMs.

PMs can have the most impact by understanding the team's capabilities and deploying these against a clearly defined strategy. 

Teams with these types of PMs:

• ML/AI (ex. YouTube Recommendation Engine)

• Hardware (ex. Lidar Programming for Autonomous Vehicles)

• Backend and Infrastructure (ex. Product infrastructure and scalability)

• Technical Domains (ex. Stripe Payout Efficiency)

PM projects in this area:

1. Researching tech trends and identifying how they may affect your roadmap

2. Serve as a product evangelist and subject matter expert internally and externally.

3. Understand hardware constraints on CPU, ML features or latency.

Common background: CS degree and/or domain-specific experience.

Companies with many engineering-driven PMs: Google, Stripe, Docker, Cruise.

Data-Driven PMs

What they do: Define success, uncover opportunities and lead fast execution. Roles like these require understanding basic statistics, experiment design and growth playbooks.

Data-driven PMs partner closely with data scientists and analysts to understand how users use the product at scale. This involves asking the right questions to tease out useful insights. When I was a PM on a video growth team, this involved understanding why first-time users were churning and what actions retained users actually took.

Data trumps product sense in these areas. An empirical case for launching a feature will likely win over gut feelings. This is where rapid experimentation becomes so important. These teams move fast to validate hypotheses and test new features.

Teams with these types of PMs:

• Growth (ex. Growing adoption for Instagram in Egypt)

• Monetization (ex. Amazon “Frequently Bought Together” product)

• Optimization (ex. TikTok New User Onboarding

PM projects in this area:

• Funnel analysis to identify opportunities 

• Experimentation design and rollout

• “Back of napkin” opportunity sizing to prioritize growth tactics

Common backgrounds: Analysts, data scientists or growth marketers.

Companies with many data-driven PMs: Facebook, Wish, LinkedIn, Netflix, Booking.com.

Design-Driven PMs

What they do: Understand user problems and partner with design to build the right solution. PMs on these teams need to navigate considerable ambiguity because they build upon product sense or tackle pre-product-market-fit problems. Data is helpful, but it often doesn’t capture the challenges you’re looking to solve.

A canonical example is of a design-driven PM is Steve Jobs. Rather than rely on in-market data points, Steve needed to understand the root problems users had in various categories - music playing, phones, creative software. These user insights formed the basis of the product roadmap.

Where you’ll find them:

• Consumer teams (ex. Strava social features)

• Pre Product-Market-Fit (ex. building the first version of Clubhouse)

• New Markets (ex. launching new AR Glasses)

PM projects in this area:

• User research, usability tests and customer interviews

• Design critiques and joint wireframing new ideas

• Aligning user experience with user expectations

Common backgrounds: Startup founders, former designers or subject matter experts (ex. pro athletes making wearable sports bands).

Companies with many design-driven PMs: Apple, Airbnb, Asana, Instagram, Spotify.

Business-Driven PMs

What they do: Responsible for ensuring the product succeeds in the market. This involves building partnerships, determining pricing and leading go-to-market. These people are the closest to the “CEO of the product” trope because they need to consider the non-product aspects of success.

These PMs exist because the most value they can create for their product team is to help them navigate the external world successfully. This was my experience working in the payments space where translating regulations and go-to-market plans to technical requirements was key.

Teams with these types of PMs:

• Enterprise/B2B (ex. Affirm partnering with Adyen to improve checkout)

• Highly Regulated Spaces (ex. Launching WhatsApp Payments in Brazil)

• SaaS (ex. pricing for G-Suite to compete with Microsoft Office)

PM projects in this area:

• Drive alignment with external partners on a joint product roadmap

• Work with finance, sales and product marketing on pricing decisions

• Navigate changes to data usage due to iOS 14.5

Common backgrounds: Operations, MBAs, analysts or subject matter experts (ex. bankers building financial services).

Companies with many business-driven PMs: Amazon, Salesforce, Palantir, Microsoft, DocuSign.

Archetypes as Axes

Think of these four archetypes as ends of a spectrum. Given the wide range of PM responsibilities, it’s natural that you’ll fit multiple archetypes. Here are four of my PM experiences mapped on a radar chart:

Try positioning yourself along these axes. This will give you a good benchmark of what skills you’re developing. With this benchmark established, you’ll be able to more easily describe what type of PM you’re becoming, what roles you’re qualified to take on and where you need to invest in becoming a more well-rounded PM.

Bonus: 10-30-50 PMs

(This concept can be a whole deep dive. I want to briefly introduce it here so you can think about the right ways to develop your skills for future success).

Shreyas Doshi, PM lead at Stripe, has an excellent thread on the surest path to PM leadership. He calls it becoming a 10-30-50 PM. This means you’re in the top 10% of one key dimension of product management, top 30% of another and top 50% of a third.

Positioning yourself on the four archetype axis may give you insight into where you’re developing your 10% and 30%. Continue to invest in these to get even better at your craft. Look at the other two dimensions to see where you can become top 50%. This is counterintuitive because we’re often told to focus on our strengths. But PMs can’t do this — they need to be well-rounded.

Summary

Use the four PM archetypes to describe the skillsets you’re developing. Use this knowledge to find new areas to grow into and what roles you may be qualified to tackle.

• The four archetypes of PMs are engineering-driven, data-driven, design-driven and business-driven. Each has unique skills, responsibilities and projects they tackle.

• Find companies that align with your product inclinations using Sachin’s original article.

• Benchmark yourself on a radar chart. Looking at your strengths and areas for improvement gives you a good map towards becoming a 10-30-50 PM.

🖼 Internet Things I’m Enjoying This Week

Why does everyone want to do strategy? by Linda Zhang: A great reminder to us PMs that strategic thinking originates from people and execution.

Will researcher diversity make AI algorithms more just? by Tobi Ogunnaike: a thought-provoking read on the need (but shortfalls nonetheless) of having more diverse AI researchers.

Miami Tech Week: The Start of Startup Cities by Balaji Srinivasan: Balaji has made many successful predictions in the past. Is the “Startup City” the next one?

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Subscribe now

Until next time,

Will

It started in November with an urge to write more and now feels like a product I’m building. I’ve met great people, fleshed out ideas that were sitting in my head and learned a lot of tactical lessons.

Today, I want to share all of the lessons I’ve learned from growing this newsletter. This will be very relevant to people who want to start newsletters, podcasts or YouTube channels. But it will also help people launching a business or a consumer-facing product.

Below, I’ve outlined 25 lessons that I’ve realized along the way. To make this useful, I’m only sharing lessons I’ve personally learned, not clichés I’ve read. I’ll cover:

1. Launching 🎬

2. Imposter Syndrome 😰

3. Distribution 📩

4. Writing ✍️

5. Engaging with Readers 💬

6. The Future 🔮

🎬 Launching

Starting is intimidating — I totally get that. But with a few months of perspective, I have a few tips to get off the ground:

1) Start with Substack: There are a ton of tools out there (ex. Mailchimp, ConvertKit, Ghost) but Substack is the best. The goal of your early tools is to make writing and collecting emails painless. You can always change later if you want more features.

2) Brand it: 20 minutes before sharing my first post, I decided to name the newsletter Product Life. I went to Canva to make a simple logo and banner image. I’m happy I did this — it made the newsletter feel more like a publication than my own diary. In hindsight, I would make sure the domain matches the brand you choose. Try not to make my mistake!

3) Choose topics you care about: Don’t write what you think you should write. Write about a topic you actually care about. Why? Because you have to keep writing about it. 

For me, I felt like I had to write about interviewing/resumes because that’s what people asked about the most. But I REALLY didn’t want to write about that every week. I’ve avoided those topics and waded into unfamiliar territory with product management lessons because it was the most interesting to me. This helped me write consistently every week.

4) Don’t be shy: Launch! Get your first subscribers by sharing with your friends and on social media. Having readers will make you more accountable for your writing practice. You’ll also get feedback and data (like shares, likes and views). Trust me, writing with no feedback is demoralizing. 

My launch post on LinkedIn (where I had the biggest audience at the time) helped me get my first 200 followers.

5) Publicly commit to shipping: Tell your readers when they can expect your next newsletter. This is an excellent way to force accountability.

😰 Imposter Syndrome

I struggled with this a lot. How could I teach if I wasn’t an expert? Also, there were already so many great newsletters by product experts, like Lenny’s Newsletter, Ask Gib and Deb Liu’s Newsletter. What unique value could I add?

Below I’ll share some realizations that made me a lot more confident in sharing.

6) The best teachers are often respected peers: Think back to the people you learned the most from. Yes, some are teachers. But chances are you learned a lot from peers you respect. These could be great friends, all-star coworkers or students a few years ahead of you.

This is because those peers are closer to your current situation than teachers. Their advice may be more directly applicable and relatable. This is where you can add value at any stage of life or career!

7) Personal works better: On this note, I learned that people don’t care about generic advice. They want to know how you did it! I struggle with putting myself into the story too much (I don’t want to be egotistical or narrow) but I try because people get the most value from that. 📜 PMs Create the Truth is a good example of this.

8) Teach people 2-3 years behind you: I’m forgetting where I heard this advice but it is spot on. Imagine someone in your shoes 2-3 years ago. There’s probably a lot you could teach them! Sharing how you learned these things is very helpful.

9) Be a student of the game: All this said, don’t feel limited by your current experiences. For example, you don’t need to know everything about mindfulness to write about mindfulness. In fact, you can research, interview or curate useful content to help yourself and others learn more. I tried this approach with 🧠 How Elon Thinks and people seemed to really like it!

10) Don’t take yourself too seriously: I’m not a pro, so I try not to position myself as a humourless, expert. Make typos and experiment with tone, topics and style. People won’t care about your mistakes so long as you’re still driving value.

📩 Distribution

Your newsletter won’t grow if you don’t distribute it well. I’ve seen friends start newsletters, be shy about sharing them and give up because they couldn’t get it off the ground. Don’t be this guy/girl.

For growth, distribution > writing. You need to make sure your content is being shown to the right people. Here’s how I do it:

11) The highest ROI system: The best system I’ve learned for content distribution is 1) publish your newsletter, 2) tailor the content of the newsletter to a post on each distribution channel, 3) share. I learned this from Harry Dry’s must-read article and it works every time.

Here’s what I mean:

Feel free to use my Twitter thread, LinkedIn Post and Facebook Group post as templates.

This system takes about 1.5 hours a week. But it’s the main way I grow, outside of shares from readers like you. 🥰

12) Tap into underused markets: Don’t feel tied to the platforms that others use. LinkedIn and Facebook Groups, for example, have been the best for me. Occasionally, I’ll get a spike on Twitter but it isn’t consistent. Other channels to explore are Quora, Reddit, HackerNews, Medium publications, Pinterest, Youtube, Instagram and SEO. Here are some stats from my last 90 days to see the relative size of each channel:

13) Distribute where your style does well: I’m not great at witty quips (😅) so Twitter doesn’t match my strength. I’m better at long-form pieces and actionable templates — which happen to do better on LinkedIn/Facebook. Lean into your style.

14) Hook readers: There’s two way that I’ve seen content perform well on social media. They either create intrigue with a teaser (example here) or give value upfront (example here). I’m a big fan of the latter, which usually requires you to share a template, a framework or something else that is immediately actionable.

✍️ Writing

Great writing is the backbone of a newsletter. Here’s some advice I wish I had on Day One:

15) It gets easier: my first pieces were taking me 8-10 hours to finish. Last week’s article took 3-4. You’ll get better and faster at publishing.

16) Timeboxing: You’ll spend as much time as you give yourself to write. If you commit to shipping after 3 hours, you’ll create a finished product in 3 hours. 

17) Systems: Find a rhythm that works for you. I write well in 1 hour, sessions before work on weekday mornings. I’m a big fan of my “creative hour” and it makes me more productive throughout the day.

18) Good enough: I write weekly. Some people write bi-weekly, monthly or quarterly. Adjust the length and fidelity to your writing cadence. I don’t think I can write in-depth, researched masterpieces like Li Jin or Wait But Why so I don’t hold myself to that quality standard. But I am good at condensing medium-sized ideas into short posts — so I stick with that!

19) Editor in Chief: If possible, find someone to edit/critique your initial posts. My girlfriend is my Editor in Chief. In the early days, she would read every article, give comments and fix grammar. With time, you’ll start to internalize the same feedback you keep receiving. For me, this was to flesh out ideas more, not lean as much on images and condense wordy sentences. Make sure to give them lots of love.

20) Find peers: It’s awesome to learn from others who are publishing regularly. Share ideas, learn from their experiences and try to help each other out where possible! Specifically, I’ve learned a lot from Linda of Product Lessons, Janel of BrainPint and Arinze of Arinze’s Weekly.

21) Find role models: When I started, James Clear’s Atomic Habits was my writing North Star. I loved the clarity, the use of models and the emphasis on actionable takeaways. You can see my focus on all of these in my early pieces like

But as time evolved, I wanted to have more fun and be punchier. This is when I found Rework by Jason Fried and David Heinemeier Hansson. I fell in love with the writing style. I remember starting one article, 🔥 PMs Let Fires Burn, copying the structure of their post (i.e. start with a counterintuitive title, give the best part at the start, build on it subsequent paragraphs and then use a specific example to anchor the point). This was a great way to learn how to write better.

💬 Engaging with Readers 

One of the best parts of writing is engaging with readers. Folks will ask questions, challenge your argument or connect you with other great ideas. Here are things I’ve learned about reader interaction:

22) Respond: I’ve made it a principle to respond to every comment, reply or message that I get. This has helped me meet readers and build relationships. It’s also a great source of feedback.

23) Use your newsletter as an FAQ: My first few articles were largely questions I had been asked during coffee chats or cold emails. I wrote about them and can now share them when asked the same question. This gives people more fleshed-out responses and scales my ability to help.

24) Ask people what they like: Send a quick email/survey to some of your subscribers. Ask them what they like, what they don’t and for a testimonial of your newsletter. This survey gave me a really clear direction of what was working (real stories on how I build products) and what wasn’t (generic frameworks, shallow industry analysis).

25) Welcome emails set the tone: When people subscribe, they get a welcome email. This is a great way to introduce yourself, encourage interactions and introduce them to your content. I modelled mine off a few others I really enjoy (mostly Packy from Not Boring).

🔮 The Future

I’m still a newsletter noob. But I’m excited to try new things that come up. I think the next creative frontiers are collaborations, products, courses and research. I would love to hear your feedback on these.

Collaborations: One piece of feedback I’ve received is that folks would love to hear from some other PMs I know/work with. I’m excited to start looping in some great product people I know! If you’re interested, let me know.

Products: I want to build more products. This is more of a passion project than a natural extension of my newsletter. If you’re curious about what I’m building, shoot me a response and I’ll share what I’m up to.

Courses: I made my first course a few years ago on Skillshare. It was a great experience and I got some positive reviews. I’m starting to see if there are any spaces that I can uniquely value to with a course. Stay tuned.

Research: I want to stay a student of the game rather than fool myself into thinking I’m a master. This involves humbly researching how others tackle tough challenges. My first foray was in 🧠 How Elon Thinks. I’d like to do more in this vein.

Summary

• Start now and commit to shipping regularly. Build the muscle and a system to create consistently.

• Remember that growth is driven more by distribution than content. Try the system I use to tailor content to your different distribution channels.

• Find peers, role models and possibly an Editor in Chief. These will make your process more social and enjoyable.

• You don’t need to be a master to share your learnings. Remember to maintain a student mindset to humbly tackle interesting topics.

🖼 Internet Things I’m Enjoying

Black Skinhead by Kanye West by Dissect: Love him or hate him, Kanye makes fascinating songs. Loved this deep dive into a personal favourite.

Using NPS Surveys in Product Development by Gibson Biddle: A breakdown of how Net-Promoter-Scores (NPS) work and how Gib used it at Netflix and Chegg.

Down the crypto rabbit hole I go by Jay Singh: My good friend goes from 0-1 about all the interesting trends in crypto. A really accessible and great read.

Thanks for reading! If you like what you read, subscribe for weekly insights on product management, careers and personal growth:

Subscribe now

See you next week,

Will

P.S. if you want to support Product Life, like, comment or share by clicking the buttons below ⤵️

In a Reddit AMA, Elon Musk was asked, 

How do you learn so much so fast? 

Here was his answer:

I think most people can learn a lot more than they think they can. They sell themselves short without trying.

One bit of advice: it is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, ie the trunk and big branches, before you get into the leaves/details or there is nothing for them to hang on to.

If you’re like me, you probably have two responses to that answer:

1. Thanks, Elon. That’s a really cool idea.

2. How the heck do I put that in practice?

Today, I want to dive into the idea Elon is touching on above: first-principles thinking. This approach can help you creatively address ambiguous problems. It’s the process that helped Elon launch rockets into space, popularise electric vehicles and dig tunnels under LA. 

I’ll explain the concept, its value and how you can practically apply semantic trees to the goals you have in life and work.

🌲 Trunks, Branches and Leaves

Knowledge of a topic can be thought of as a tree. The tree’s trunk is the foundational truth that shapes all of the branches and leaves. These truths often stem from the physical world — like physics, biology or mathematics. The branches and leaves, on the other hand, are details that spawn from these truths.

For example, let’s say you want to know why you feel happy on a given day.  The details of your day, like the weather, may seem like the reasons for your happiness (“I’m happy because the weather was nice today”). But this is a leaf-level answer. A complete answer stems from the trunk of our happiness. But how do we find the trunk?

A popular way is to use the Five Whys. Start with a situation (in this case, a leaf-level detail) and ask yourself, “Why?” 5 times. This will help you go from the leaves to the trunk of a situation.

The Five Whys help us get to the root of our happiness: our body. Happiness is really a chemical reaction in the brain. In response to positive stimulus, the brain releases chemicals like serotonin, dopamine and endorphins. These chemical reactions are the true sources of happiness.

Let’s visualise this with trunks, branches and leaves 

This is an example of finding first principles. Rather than settling for a leaf-level answer (“I feel happy because of the weather”), finding the trunk helps us ground our concept of happiness onto a fundamental truth. 

Thus, a complete answer to “Why do I feel happy today?” may be: I feel happy because my body has released more dopamine, serotonin or endorphins today. This may be a result of the weather, my exercise routine or my breakfast this morning. 

You’ll notice a few things about first-principle reasoning:

• It builds our understanding based on truths: Basing our understanding off small details leads us to incomplete worldviews. Building up from a truth is a way to have a more accurate sense of the problems and opportunities that exist.

• It creates more options: In this example, rooting in brain chemistry can help us pursue multiple paths to become happier.

• It helps you find higher value actions: Improving a branch (ex. spending more time outside) will have a fraction of the impact as improving the tree (ex. leading an overall healthier life). Spend your energy improving the highest leverage points of the tree.

🌌 Huge, Ambiguous Problems

First-principles may not be necessary in well-documented fields. For example, its unnecessary to derive π every time you need the area of a circle.

But first-principles thinking shines when you tackle ambiguous problems. Ones without clear solutions or people who’s lead you can follow. These are the situations where you need to find a creative way to address an ambitious goal.

Leaf-based reasoning doesn’t work in these situations. It can base your strategy off untruths or false causation. In the happiness tree above, imagine your strategy to maximise happiness was to wait for better weather.

Instead, by starting at the foundational truth (the trunk), you can explore paths that have never been charted before. In fact, some problems can only be properly tackled by someone who reasons from first-principles. Here are three examples:

• How can we build a settlement on Mars? 

• How can I make a dent in climate change?

• How can I make commuting in LA less painful?

These are hard problems. But Elon Musk charted a way forward for each of them (SpaceX, Tesla and The Boring Company). Let’s do the same.

🧐 Applied First Principles

There are a few methods of getting to the first principles (including the Five Whys we used above). But here’s one I regularly use as a product manager: algebraic structures.

These are issue trees that are broken down into equations. Each part of the equation is a “lever”. Pulling them will allow you to make progress on the overall goal. This helps make a huge problem more actionable.

Let’s work through an Elon level example: how can I make a dent in climate change?

There are only two ways of fighting climate change: removing carbon from the environment or reducing the rate of carbon entering the atmosphere. Every other action you can think of (climate protests, recycling, policy) service these two big “levers”. 

But this isn’t yet actionable. Let’s go several layers further into “Carbon created every day” and create more equations.

At each stage, you’re asking yourself two questions:

1. What are the levers I can influence the most?

2. What are the levers that would have the most impact on the overall goal?

3. What is the relationship (i.e. formula) that connects them?

After breaking down the problem, we can brainstorm solutions to moving that lever. The best solution is one that has a disproportionate impact on solving the problem. I’ve highlighted emissions per trip as an area of focus given Tesla’s ultimate ambition.

Here’s a solution breakdown. I think we know where Elon landed…

Using algebraic structures helps you go from a large ambiguous space to a small, actionable solution. Try this next time you see a problem and don’t how to get started.

Summary

Elon Musk builds his worldview from first principles. This allows him to make progress on large issues that matter to him. By employing similar ideas and practicing, we can grow our ability to tackle ambiguous problems.

• Base your knowledge of an area on foundational truths (“the trunk”) instead of peripheral data points (“the leaves”). This gives you more creative options to making progress.

• Deploy the Five Whys to go from a leaf-level detail to the root of the situation.

• Unlock the ability to handle ambiguous problems by starting from first-principles.

• Use algebraic structures to break an ambiguous problem space into its levers. Continue this process until you find a lever that has a disproportionate impact on the space.

Internet Things I’m Enjoying

👩‍🍳 The Cook and the Chef: Musk’s Secret Sauce by Tim Urban: An in-depth (and fun) exploration of how Elon thinks differently. Really helped my perspective here.

✍️ Doing Content Right by Steph Smith: A great guide on content and distribution from an expert in the field.

📲 You Belong in Tech 1.0 by Helen Huang and Sefunmi Osinaike: Untold stories from diverse builders and how they got their first roles in tech.

Thanks for reading! If you like what you read, subscribe for weekly insights on product management, careers and personal growth:

Subscribe now

See you next week,

Will

P.S. if you want to support Product Life, drop a like or comment by clicking the buttons below ⤵️

Last week, Product Life crossed 2,000 subscribers! 🥳.

Thank you all, truly, for your support of Product Life. I’m really happy that this content is resonating with folks. I’m excited to continue building this community!

I started this newsletter with the goal of sharing the knowledge that I was accumulating as a product manager. At the time, I didn’t realize how much I would learn from the process.

Today, I want to share three unexpected learnings that I had scaling this newsletter. If you’re launching a product, starting a side hustle or also writing a newsletter, I think these will save you a lot of heartaches. Here they are:

1. Narrow Your Audience 🎯

2. The People Decide 🗣

3. Don’t Trust Your Gut 🗳

I added real data from my newsletter so you can get a peek “under the hood”. I also left key takeaways and some resources I love at the bottom.

Narrow Your Audience 🎯

The two articles I published with the lowest open rates are Get Your Mojo Back ⚡️ and The Best Way to Build Credibility 🤝.

What do these have in common? They are both waaaay too generic. Looking back on them, the target audience appears to be “office workers, ages 18-75”.

I thought writing for the broadest possible audience would lead more people to like it. In reality, it was so broad that no one resonated with it.

I was going to follow that up with an article called “3 Ways to Cut Meetings from Your Calendar”. Instead, I noticed the trend of being generic. I decided to shift the article to be speak specifically to product managers.

The new article, Great PMs Kill Meetings 🔪📆, had one of my highest open rates (46%) and was one of my most popular articles by views, signups and social sharing.

Interestingly, it also resonated with non-PMs! I realized that being targeted doesn’t limit it to your intended audience. Instead, it just grounds it in more specific language and examples. People outside of it may even resonate with it more.

Learning: Great creators deliberately choose a small audience. This can make the article feel more real, relevant and actionable.

The People Decide 🗣

I post all my articles on Twitter and LinkedIn. I originally thought that growth was driven by new traffic to the site. The more social media views, the more new visits and subscribers.

This is only half true. Here are two popular articles from the past. One has more views on social media, a 2x higher open rate and a catchier title. Surely it will perform better, right?

Surprisingly, Meet the team behind your feed 👩‍💻 had 70% more views and 42% more signups than the other article. Why? The answer is organic shares.

An organic share means that someone found the content so valuable that they wanted their friends or colleagues to see it. This is the type of resonance I want to create with my articles.

Organic shares trumped any distribution I could have on my own social media. Someone even made a TikTok about the freakin’ article:

Learning: Organic shares, referrals and word of mouth are the most important things for growth. They demonstrate that you are creating so much value for a user that they want their friends to know about it.

Don’t Trust Your Gut 🗳

About a month ago, I realized I didn’t know why people were reading this newsletter.

Was it for career advice? Or product strategy? Or life advice?

My gut told me that people wanted to learn product strategy and frameworks. This is why my first five articles were a series called Product Strategy 101. But I noticed that this type of content wasn’t resonating with readers.

I started doing user research. I first started collecting feedback at the bottom of some newsletters. This was a great start but I needed more details.

So I surveyed a handful of readers who were actively engaged with my newsletter and asked them for their feedback.

Here are some excerpts from that research (and thank you again to those who helped out):

My main reason for reading your newsletter is that it actually feels “real”. For example, the posts I like the most contain tangible advice and true, personal examples.

Case studies are so good. I really like how you map tactical decisions in product to strategic ones.

Also, there is so much product/career/start up advice on Twitter from the Tech world that is so meaningless and fluffy, whilst your newsletter never feels like that.

These helped me understand my value proposition: real, honest and actionable product insights. Importantly, it told me to focus less on fluffy topics that many other people were already covering (ex. what is a product manager, industry analysis).

Learning: Ask your users what they like and what they would like to see more of. This is more useful than relying on your intuition.

Takeaways and Resources that I love 📝

Takeaways:

• Narrow your audience and take a stand. The more specific you are, the more grounded your content will appear. This can help you build a stronger niche.

• Organic shares are the north star of sustainable growth. Shares mean that people are finding significant value in your content or product.

• Do user research to learn what unique value you’re offering. This can help you differentiate from the market.

Resources:

There is so much great content out there for online writers. Here are some that I’ve personally found really helpful.

• The Ultimate Guide to Writing Online by David Perell

• Marketing Examples (newsletter and articles) by Harry Dry

• Early Learnings from Growing to 450 paid subscribers by Lenny San

• NewsletterOS by Janel

• Great Resources for Newsletter Creators by Kyle Steinmeyer

• Curators are the New Creators by Gaby Goldberg

• For PM specific knowledge: Everything on Twitter by Shreyas Doshi

Once again, thank you for helping Product Life cross 2,000 subscribers. This wouldn’t have been possible without amazing, curious and kind readers like you. ❤️

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Subscribe now

Until next time,

Will

I moved to San Francisco in July of 2019. I was excited and nervous to be joining Facebook as a Rotational Product Manager — my first full-time job out of university.

The Bay Area had everything I could want: great weather, crazy-high salaries, a lot of young people and some of my best friends as roommates. Sometimes I would sit at Alamo Square Park (a block away from my house) and marvel at my luck.

Less than two years later, I’ve decided to leave the Bay Area. The pandemic taught me one thing: there’s so much more to life than your job.

“Duh.” You say.

Yes, I know it's a cliché. But here’s one thing I’ve learned: highly-ambitious people should prioritize relationships over their job. This is a path towards long-term personal success.

This is a story for all highly-ambitious professionals. The ones that move to San Francisco, New York, Toronto, London or Singapore for a job. The ones that want to spend their twenties and thirties building their careers before “settling down.” The ones that feel like they have something to prove, money to make and prestige to achieve.

I was like you. I learned that optimizing on the margins of your job has diminishing returns. After creating a career “floor” for yourself, your time can be better spent investing in relationships.

In this piece, I’ll share:

• How continual investments in my career led to diminishing returns

• Why achievement is not a reliable identity trait

• How it felt taking a $40K salary cut to pursue a new path

I’ll share lessons along the way (and a summary at the bottom). But this is my story.

Climbing the Mountain

Immigrant parents, hustle culture and my own insecurities made getting the best job my number one goal.

This culminated in August 2018 with an offer for Facebook’s Rotational Product Manager program. I had climbed to one of the most prestigious companies globally, the most in-demand role I could imagine and the ability to learn while rotating through the company.

There was literally no higher spot that I could have imagined in my field.

There was one small blip: my girlfriend of 4 years wouldn’t be able to join me in San Francisco. She would have to stay in Vancouver, and we were in for a long bout of long-distance.

She was great — but Facebook RPM?? How could I turn it down?

I started at Facebook in July of 2019. It surpassed all of my expectations.

The people were incredible. I was learning about creating products, working with builders and designing for ethically challenging spaces. My first six months were extremely fulfilling. 

In February 2020, my girlfriend and I went to Hawaii to celebrate our fifth anniversary. Hawaii was incredible. But at the five-year mark, I started to think about the future. 

Life in SF was good. I was loving work, had great friends and was in the best shape of my life (thanks to free food and a gym at work).  

Thinking about my long-distance relationship brought me out of those good times. All I was experiencing was the obligation to call, the exhausting weekend trips to Vancouver and the ambiguity of not knowing when long-distance would end. 

In many ways, I wanted more “me-time” to dive further into work and experience everything I could in SF.

I asked my girlfriend to take a break. Not to see other people, but for us to see if this is something we really wanted. I initially felt relief.

Quarter Life Crisis

I got back from Hawaii on March 6th, 2020. I took the red-eye and went straight from the airport to the office. I didn’t know it at the time, but this would be my last day on Facebook campus.

On March 7th, we were asked to start working from home. Something called coronavirus was starting to spread, and we could now work in our pyjama bottoms. It felt like a snow day.

What I thought would last a few weeks turned into months. I now had all the “me-time” in the world. 

Still, something was missing. I couldn’t tell what it was. All I knew was that I was in a rut.

After talking to other highly-ambitious friends at a similar stage of life, I realize this is a common feeling. A quarter-life-crisis, if you will. A time to assess what’s wrong in your life and chart a path forward.

In my mind, three factors were contributing to my quarter-life-crisis:

More time, same results

I wanted  “me-time” to reinvest time into my work. But as I invested more time, I realized I was hitting diminishing returns. 

In university, investing 1 hour a week into my career work (ex. coffee chats, interview prep) yielded high returns to career growth. Now, investing an additional 5 hours into work yielded a lot less.

This stemmed from a simple idea: I was learning a ton at work! These learnings were coming at a fast-pace, and pouring more hours in seemed to waste time and burn me out.

In the right environment, smart people can stop putting more hours into work because they experience diminishing returns. 

I found myself hitting this point.

The only priority

I had come to know myself as an achiever. Someone works incredibly hard, exceeds expectations and takes risks for big rewards. A pursuit of achievements became the basis of my identity.

With less need to invest aggressively in work, I was losing my sense of self. Questions like, Who am I and What do I really care about were causing me anxiety. 

I was prioritizing work over everything. It was not because I needed more success or financial security, but because this was the only thing I had ever prioritized in the past. 

My top priority has always been work. My mindset, habits, and goals are all optimizing for the best possible work outcome. This needed to change.

Achievement is a hamster wheel

Why was I prioritizing work? I learned it was tied to an obsession with achievement. 

I was already successful in work. But there was always a path to “more success.” It would be to work harder, get a better job, feel happier (maybe). Rinse and repeat, again and again.

This way of living was less about personal growth and more about chasing the high. Less about climbing the mountain and defying the odds and more like running in a hamster wheel. Alone.

Is this what I wanted my life to be like?

No, it wasn’t. I knew I wanted to continue to have new, different experiences that allowed me to grow. 

This rut told me something: the pursuit of individual achievement led me towards a life I didn’t want. This chapter of life — one that was about achieving only for myself — was nearing a close. 

But this raises the question: what is the next chapter of life?

The Next Mountain is different

Michelle Obama’s book, Becoming, is broken into three sections:

Becoming Me, Becoming Us and Becoming More.

I finally understood it. The first mountain in my life was developing myself. Uncovering my values, my skill sets and my voice. Building my own life, complete with physical health, a job and financial security. Enjoying the individual pursuits that life has to offer. 

Becoming Me is a lifelong process. But I had come to a point where I was comfortable with Me. I had built a life for myself and knew who I was. I had built a new foundation of understanding, experiences and stability. From this new “basecamp” I could explore new mountains.

The next phase of my life, I now understand, will be centred on relationships. Not just romantic, but friends, teammates and family. 

From a selfish lens, spending time cultivating relationships can look like they take away from “me-time.” It's as if building relationships is taking you away from self-actualization.

But I’ve now come to appreciate the very opposite. Great relationships create new opportunities that are hard to unlock by yourself. Backpacking trips, launching a startup and starting a family are easier when you have built strong relationships.

The next mountain will not be a continuation of my personal pursuits. It will be the pursuit of us — of building relationships that create life-changing opportunities.

Across the Pond

After realizing the mistake I’d made with my partner, I asked her if she wanted to get back together. In our time apart, she’d taken parallel steps in her mind to arrive at a similar place as me. We decided that we were going to start prioritizing each other over work.

My girlfriend had decided that she wanted to pursue a Masters's degree. Given her econometrics field, London was the spot with the best universities that didn’t require an arm and a leg for tuition. Fortunately, London was also a place where Facebook had a big presence.

By December of 2020, the RPM program at Facebook would end. My cohort and I would be “free-agents” who could find a spot within the company to land permanently. It was a great opportunity for a switch.

With a clear mind and a natural break in my role, I pursued a team in Facebook London. 

After a few months, I found an incredible fit with the Audience Network team. Their charter is to help 3rd party app developers (ex. indie games, recipe apps) make money with in-app ads. As a creator myself (with this newsletter and an online course), I loved the mission and was excited by the challenge. 

It became real when I saw my new contract a few weeks ago. This move would involve taking a $40K salary cut. Part of me cringed — wasn’t career growth about increasing your salary?

But after nearly a year of reflection, I know London is the right decision. Choosing to invest in my relationship has allowed me to get out of my rut and look forward to new life milestones. This is a long-term bet that choosing to build a strong relationship will help me grow and seize new opportunities that weren’t previously available to me. And I’m confident that bet will pan out. ☺️

I’m happy to share that I arrive in London on Saturday. My girlfriend will arrive in the summer. 

Summary

I’m moving to London to prioritize my relationship. I don’t see it as a sacrifice. I see it as an opportunity to climb a new mountain with my best friend. Here are some takeaways as you explore your own next play:

1. Relationships create opportunities, not detract from them: relationships open new mountains to climb - personally, professionally and romantically. Be aware of these when deciding on your priorities.

2. Achievement is a hamster wheel: there will always be more to achieve. Know when to shift priorities to other parts of your life.

3. Update your mindset at major milestones: my mentality held me back from setting new priorities and making progress. Use natural breaks in life to reassess what’s important. These can be as small as a project ending at work to a major geographical move.

4. Diminishing returns can cause a rut: if you feel like you’re not making progress, it may be time to diversify your investments. Try to identify the next mountain to climb and start your journey.

Thank you for reading. This was a really personal piece, and I was a little embarrassed to share it. But hope you enjoyed it!

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Subscribe now

Until next time,

Will

P.S. if you’re enjoying Product Life, share it with some friends or drop a like by clicking the buttons below ⤵️

Have you ever been in a slump? These are those times when you’re apathetic to life, tired, unmotivated at work or anxious about anything and everything. This leads to a lot of time on your phone, a distracted mind and maybe that extra pint of Ben and Jerry’s.

I’ve been in a slump for the last few weeks. It feels like I have no motivation, I’ve been ducking calls from friends who want to catch up, and I’m tired all day (until I’m trying to get to bed and my mind is swirling).

I tend to spiral during these times. This is because I always try to understand why I'm feeling the way that I am. This leads to "stories" that tie my feelings to narratives that often aren’t true:

• I feel stressed because I can't manage everything at work.

• I feel lethargic because I have no passions in life that keep me energized.

• I feel lost because I don't know what I'm doing in life.

Small molehills turn into mountains because we tie our feelings to logical narratives.

Fortunately, I have a method that helps me get my mojo back when I feel anxiety, stress or lethargy creeping in: I check my boxes. This means assessing where I stand on the five tenants of a healthy, happy life:

Checking your boxes can save you time and heartache when you’re in a slump. Most importantly, it gives you a path out of your rut.

Checking my Boxes

Start by answering each question for yourself. Next, identify the ones that you’re falling short on. Here’s why each is important + one tip to improve each of these tenants.

1. Am I sleeping well? 💤

According to Harvard Health, sleep deprivation is overly represented amongst psychiatric patients compared to the general population. This link is well-known and treating your sleep challenges can help alleviate symptoms of bad mental health.

Tip to improve: Find the ideal amount of sleep you need by experimenting. Set a regular bedtime and wake up consistently throughout the week

1. Am I eating healthy? 🍽

Healthy is relative, but you'll know how your body feels. Improving your mental state can be as easy as adding some “premium fuel” to your system.

Tip to improve: Drink more water. This is a low-effort action that has numerous benefits.

1. Am I exercising enough? 🏃‍♀️

Exercise improves mental health by reducing anxiety, depression, and negative mood and by improving self-esteem and cognitive function (source).

If you have a favourite exercise, try to get back into the rhythm and build that habit. If not, try something new!

Tip to improve: Go for a walk every day. This is especially true if you’re working from home. Being outside will refresh your mind while getting some steps in.

1. Am I practicing mindfulness? 🧘‍♂️

Practicing mindfulness (often done through meditation) can help you be more present. This is especially important in slumps when it is hard to focus, and distractions vie for your attention.

Tip to improve: 10-minutes of Headspace can change your day. For me, I try to carve some time out of my schedule in the morning to meditate.

1. Am I spending time with people? 👭

Whether you're an introvert or extrovert, social connection is a key driver in life satisfaction. Spending time with a friend can boost your mood and help you feel a less lonely.

Tip to improve: Schedule a phone call with a close friend or go for a walk with a loved one.

Why does checking your bases work?

Mental health and physical health are fundamentally linked. People living with a serious mental illness are at higher risk of experiencing a wide range of chronic physical conditions. Conversely, people living with chronic physical health conditions experience depression and anxiety at twice the rate of the general population. 

Canadian Mental Health Assocaition (2008)

Rather than obsessing over negative emotions, focus instead on improving your physical health. This will give you more energy, help you become happier and build positive momentum for harder challenges.

Anxiety thrives on our desire to think about the problem a lot. If you're able to shift your focus to a more productive outcome, like practicing mindfulness, you'll spend less time giving into your anxiety.

Once all your boxes are checked, smaller mental health challenges will dissipate. What's better is that you'll now have a much stronger foundation to tackle the real, long-term challenges that make life worthwhile.

Next time you’re in a slump, check your bases to build a path out of it. 

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Subscribe now

Until next time,

Will

1. Builders: people who work with the latest technologies to build products.

2. Global, social challenges: threats to the planet, the cooperation of individuals, free expression, truth, and institutions.

As software eats the world, these two groups are beginning to collide. Problems like climate change, misinformation, and financial inclusion, issues that were once reserved for world leaders and philosophers, are now being tackled by technologists.

The challenge for many builders, however, is that these problems are not like typical software problems. It’s important to adapt the builder's skillset to build for social issues effectively.

I learned this first hand when I joined Facebook. Equipped with a UX design background, I knew I wanted to work on a social issue that Facebook tackled. This desire led me to become a product manager on the Memorialization team.

This team tackled one of the most challenging questions I could imagine: how do you support someone who just lost a loved one? The team was incredibly thoughtful and built products like Memorialized Profiles, a Tribute section for deceased loved ones, and AI models to prevent harmful Facebook experiences.

Today, I want to share the lessons from my time as a PM focussing on the nuanced, ethically challenging space of Memorialization. Specifically, these lessons will show how to adapt the builder's skillset to progress the social issues that matter. These lessons are:

1. Assume You Know Nothing

2. Bring Order to Chaos

3. Proxy the Qualitative

4. Align with the Topline

Assume You Know Nothing

In many areas of tech, you have enthusiasts building products for themselves. Think former-DJs building music software.

This approach doesn't work for social issues. If our Memorialization team asked themselves what they would want for support after losing a loved one, we would likely get American-centric, high tech solutions that catered to our ideas of grief.

But topics like death, misinformation, and wealth inequality are complicated. They require starting from first principles and ignoring any bias that can shadow more nuanced solutions.

Instead of building for yourself, lean on research. At Facebook, we were fortunate to have dedicated researchers who specialized in studying death online. Their cross-cultural findings identified shared ideas of stewardship after death, how social connections form after a node in a social graph is dropped, and real testimonials with users who had experienced this grief. One testimonial from a published paper gave us insight into why people may want a loved one’s profile to stay online:

My grandson recently died... It gave a great number of people a place to express their love of him and has helped all of us with healing and missing him...

If you don't have access to researchers, turn to academia. These are professional researchers who take a relatively unbiased stance on many social issues. Google Scholar is your best friend in this realm.

Lesson #1: Have a beginner's mindset and lean heavily on research. Where possible, study outside of your cultural circle and tap into academics who study this field.

Bring Order to Chaos

Unlike other product areas, our goal — to help the bereaved — was qualitative and ambiguous. There are millions of things that we could potentially do to advance this goal.

The situation demanded the ability to bring chart a path forward in an ambiguous space. 

This is where a MECE framework became crucial. Breaking down a problem space into its Mutually Exclusive, Collectively Exhaustive (MECE) components allows you to differentiate the options available (i.e. mutually exclusive) and identify all possible opportunities in space (i.e. collectively exhaustive). If you want to deep dive into this idea, check out this link.

This is what you're aiming for:

Applying this method to grief, it became easier to group and organize our product development. Rather than focussing on specific tactics to support the bereaved (which was not MECE), we broke it down into two main buckets: 

1. Reduce Harm

2. Offer Support

From here, we could categorize sources of harm and sources of support by leaning on research. By the end, we had a clear map of the possible areas to invest in and where we could have the most impact. 

Lesson #2: Bring structure to ambiguous situations by breaking the problem space into its Mutually Exclusive, Collectively Exhaustive (MECE) components.

Proxy the Qualitative 

How do you measure the amount of support you're providing to someone in one of the most challenging times of their life?

In other areas, measuring qualitative fields is all about surveys. Surveys are how you build other standard metrics like a Net Promoter Score (NPS). But surveying people who are in distress is an ethical quandary. The same would be right for other social issues - like surveying people in countries with repressive governments to ask how free they feel online.

Instead, it helps create a proxy metric: a data point representing a qualitative value you are trying to provide. 

We started at the known qualitative sources of support. We knew from research that one of the most significant comfort sources for the bereaved was community support. 

Specifically, it was new interactions and relationships between people who each knew the deceased separately. Imagine the mother of a deceased child hearing a story from their child's classmate.

We used this insight (which originated from our research) to create a metric that proxied the number of developed relationships through memorialized profiles. This gave us a useful measure to prioritize and assess the impact of our features.

Lesson #3: Use proxy metrics that align with the qualitative value you are trying to provide. Use this to be data-informed, not data-driven.

Align With the Top Line

Collaboration with other teams within a company can scale progress on social issues you're trying to advance. But to agree on a collaboration, you need to build alignment on the strategy.

Alignment is ensuring that the proposed plan is in line with the strategy and interests of both teams. 

A great way to do this is to align your product's mission with that of the company. This enables you to show your work's value in advancing the overall company narrative and aligning with partner teams more efficiently. 

Facebook's mission is about giving people the power to build community. It was essential for us to frame the value that we were providing to our users through the lens of creating community. This was easy because of the significant research that showed bereavement often takes place in communities, and we were in a good spot to support these communities.

Alining with the company mission also allowed us to collaborate with other teams at Facebook more easily. This included a big collaboration with the Profile team on features like Memorialized profiles and a Tribute wall. Because both teams were advancing the overall Facebook mission, this collaboration was a win-win-win.

Lesson #4: Contextualize the work you're doing into the overall company narrative. Prove value and use it to make in-roads into other product areas. This will help scale your impact.

Onwards with technology

As technology and social challenges continue to intersect, we need to adapt the builder's skillset to advance social causes. As you build in this space, I hope that these lessons stick with you.

1. Have a beginner's mindset and lean heavily on research. 

2. Bring structure to ambiguous situations by breaking the problem space into its MECE components.

3. Use proxy metrics that are in line with the qualitative value you are trying to provide.

4. Contextualize the work you're doing into the overall company narrative.

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Subscribe now

Until next time,

Will

This week, we saw something truly incredible: retail investors coordinating to bid up a few stocks to hurt the hedge funds that shorted them. 

At the centre of this episode, we have Robinhood, the investing app of choice for r/WallStreetBets (WSB) users. Robinhood started the week flying high and ended it with a series of lawsuits, a plunge in brand sentiment and a defensive comms campaign from the company's CEO.

A lot has been said about the topic. But I've become fascinated with the product decisions that Robinhood has made to get to this point.

From my view, there are three main product decisions that Robinhood made:

1. Pursued an activation based growth strategy (over retention and engagement)

2. Catered the platform to users with lower financial literacy

3. Encouraged frictionless decision making

This strategy seems reasonable and similar to other growth strategies from tech companies. But having worked as a PM on both growth and consumer fintech products, I learned the hard way that we can’t port over the playbook from traditional software products. 

Robinhood shows us that growth strategies from software products don’t work in heavily regulated industries like finance. Their adoption of popular consumer growth tactics led them to create a frictionless product — exposing them to the risks unique to their domain.

Silicon Valley and Blitzscaling

What makes Silicon Valley companies globally competitive? Reid Hoffman, the legendary investor and co-founder of LinkedIn, describes the uniqueness in a single term: blitzscaling — the pursuit of aggressive growth that prioritizes speed over efficiency.  This is the ethos that has been behind nearly all of the major Bay Area growth stories: Airbnb, Uber, Facebook and yes, even Robinhood. 

Robinhood is a true Silicon Valley company. Founded by two Stanford computer science graduates, the company prides itself on operating as a tech company amongst traditional financial players (think TD Ameritrade and eTrade). Robinhood has an admirable and big mission: democratize finance for all. 

For every tech company, the product is the embodiment of a companies' mission and values. Every design choice, growth strategy and feature gives insight into how the company will achieve its mission. You can learn a lot just from analyzing the design of the product:

We can observe in the product Robinhood’s stated values of being friendly, approachable, and understandable. These values were not chosen at random — they also represent the company's primary way of growing.

The first-principles of product growth

I worked as a growth PM on Facebook Watch, a video tab within the Facebook app. People often think that growth is marketing-driven, but savvy growth teams know that paid acquisition is not sustainable. Instead, the best products look to build growth loops into a product. This helps create organic user acquisition, engagement and retention.

At the base level, product growth is fairly simple:

1. Identify where users receive value.

In startup circles, this is finding product-market fit. What do users love, and what will make them rave about the product to their friends?

1. Remove friction to capture that value.

Friction is any step, thought or emotion that stands between a user capturing value. Watch provides value when users find a great video that they want to watch. My job focused on shortening the time it took from navigating to the Watch tab to find a great video to watch. Most of the features in the tab (Subscriptions, Saved Videos, Video Ranking etc.) are designed to remove friction from receiving this value.

In summary, growth is helping users capture value as easily as possible.

Robinhood’s product decisions 

Through this lens, Robinhood made a series of product decisions and executed on them for years to achieve growth:

💸 Activation-based growth

Robinhood’s product growth seems to be focused on one question: how can users own their first stock in the least amount of time? In other words, they focused on activating new users as quickly as possible. This is because a key value proposition of Robinhood is that anyone can be an investor. If you can have stock in a few minutes, then they’ve delivered on a core value. 

Tactically, they also knew once a user had monetary value in a Robinhood account, they would keep coming back to see if they had made or lost money. Retention and engagement handled themselves.

📚 Cater the platform to users with lower financial literacy

Robinhood values simplicity over power, evidenced in the lack of advanced stock trading tools in the app (ex. analytics tools, insurance). This simplicity provides more value to new, less financial literate users. They’ve continued to cater to these users with an accessible interface and educational modules (ex. Analyst Ratings, Lists and Messages to replace investor reports).

This is why 50% of users say they haven't invested before Robinhood. These may be people who don't know about risks associated with the stock market, how to spot a bubble or what the downsides margin trading might be.

⏩ Encourage frictionless decision making

Robinhood shortens the consideration period of stock purchases to seconds. This is why early marketing focused on commission-free trading. This feature is less about saving users money and more about removing the friction of a commission fee. In this sense, Friction is both the dollar amount and the mental barrier people have when they need to spend money from their pocket. 

Today, a purchase of $500,000 can be made in under a minute on Robinhood. 

These three product principles are not new. Each of them can be seen in other verticals. TikTok nails activation-based growth by dropping you into a feed within seconds. Webflow caters to low technically literate people who still want to build websites. Wish makes purchasing a $5 shirt so frictionless that you may buy 10 different ones in a sitting.

But something differentiates Robinhood from the other companies who rely on the same growth tactics: the real-world consequences of a decision. 

The Tipping Point

By the end of 2020, Robinhood had grown their product to a vibrant community of millennial investors engaged with financial markets. The simplicity of their app blew away the competition, and new investors flocked to it.

Like other tech success stories, Robinhood relied on activation based growth, frictionless decision making and users with lower domain literacy.

This bring us to this week. Robinhood traders pumped up stocks like GME, AMC, NOK, and BB to initiate a short squeeze on hedge funds. The product allows new users (potentially with lower financial literacy) to jump onto the platform to trade these stocks effortlessly. Robinhood is doing exactly what it is meant to do.

But unlike social media, transportation or video streaming, fintech operates in a highly regulated space. A surge of trading is not isolated to the product, which is not true of a surge of bookings on Airbnb, posts on Twitter or riders in a Peloton class. Instead, the trading affects Robinhood's balance sheet, the portfolios of other multinational firms, the SEC and, of course, the finances of millions of individuals. 

In other words, unlike other software-specific domains, Robinhood’s product actions are limited by heavily regulated, measurable real-world consequences.

This led to Robinhood curbing trading on all of the WSB stocks. Multiple explanations for the curb have surfaced, but all of them chock up to one reality: Frictionless trading with users with lower financial literacy led to high volumes of speculative purchases, threatening Robinhood’s ability to service them.

The next wave needs a new playbook

The last 20 years of builders cut their teeth on software building search engines, ranking algorithms and online to offline tools. Embedded in the vertical is a culture of experimentation, product-based decisions, and "blitzscaling.” For builders, this is a skillset that has long been seen as the dominant way of creating value on the internet.

But as we enter a new wave, one that promises to tackle more challenging topics like gene editing, space exploration, autonomous vehicles and finance, we cannot port over all the lessons and culture of the past.

This week, we saw what happens when a product uses the growth playbook from software companies in a highly regulated space. In this saga, we see both the promise of new phases of technology and the dangers we'll have to overcome to capture it. 

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Subscribe now

Until next time,

Will

Subscribe now

I went on a hike a few weeks ago and it started to pour. Fortunately, I brought my rain jacket so I tossed it on and put my phone in my pocket to protect it from water damage. Unfortunately, “waterproof” doesn’t mean “moisture-proof” and my phone was out of commission. No amount of uncooked rice was going to save it this time.

My mom had an old phone lying around the house, so she said she would mail it to me and I would receive it in two weeks. Two weeks? I thought. How am I going to make it through two weeks without a phone? I was worried:

• What was I going to browse when I was bored in class?

• How was I going to know when to leave to catch my bus?

• What was I going to listen to while I go running?

Little did I know that these two weeks without my phone would be one of the most liberating experiences I’ve had in a long time.

Steve Jobs famously compared computers to a bicycle of the mind. This analogy is spot on in many ways: a computer (or phone) can enhance your thought process with additional information, digital services and computing power.

But is enhancing your thought process desirable? Let’s tun through a hypothetical situation:

You’re on the bus and you pass your old high school. You think back to the good times you had and remember a friend in your life who moved to another country. You wonder what they are doing today.

Pause. There’s two ways that this can continue to play out:

1. You whip out your phone and look that person up online. You may see that they are in Germany and enjoying their life. You think of another friend, you look them up, browse around and repeat the process again and again. Next thing you know, you’re at your destination.

2. You let that thought go and you continue to look outside your bus window at other things that catch your eye.

While there isn’t anything necessarily wrong with either of these options, the former takes you out of the present while the latter keeps you in the moment.

While that might sounds fluffy, I noticed this exact thing when I lost my phone. With no distractions, I found that I was more present than ever. On my bus ride to university, I was making eye contact and smiling at people more, I spoke to the bus driver a few times and I even learned the exact order of every stop between my place and school. That may sound trivial, but these are experiences that I remember more than mindlessly browsing my phone.

Without my phone, I also felt boredom for the first time in a while– and it was great! Usually, when I’m bored in a lecture for example, I’d “check out” from the situation and browse my phone. In other words, when I experienced the negative state of boredom, I looked for positive stimulus elsewhere to get quick hit of dopamine. I noticed this trend when I was sitting through a particularly dry lecture. I was bored but I couldn’t check out, so I pushed myself to keep listening to the lecturer. I found myself really trying to extract some interesting knowledge and even found myself writing down my own thoughts on the topic. I engaged with the material in a way that I hadn’t in a very long time. More generally, without the ability to check out I found myself teasing out the most value from each situation.

This was probably best seen on my morning commute. After a day of two of without the stimulus from my phone, I had to find other ways to get enjoyment out of my commute. So one day, I decided to bring a book with me onto the bus and started to read it during my ride to school. It was great; I got to finally start making steady progress on my New Year’s Resolution to read more while also making my commute enjoyable. Win-win!

Music was the next thing I considered. My brother got me some wireless earbuds for my birthday and I had been using these for at least an hour a day to listen to Spotify. But without my phone, I wasn’t able to do this. I love music and I definitely didn’t want it cut it out of my life, but this period gave me a time to reflect on how I use music. My best experiences with music, I found, were when listening to music is the primary activity like during concerts or listening to an album from start to finish in one sitting. On the other hand, I realize that when I’m multitasking with music in the background (like when I’m at the gym or walking around campus) music takes me out of the current situation and drowns my ability to think. With beats and lyrics in the background, I wasn’t creating my own thoughts but rather listening to the stories and thoughts of the artists. This was especially clear during my morning runs. At first, it felt awkward to hear every breath and footstep. But soon, I found that running without music made me appreciate the beautiful landscape that surrounded me which made me calmer throughout my day.

Ironically, I found that losing my phone also helped my relationships. I usually called my parents, who are three time zones away, when I had some free time in between classes or commuting. But now, I had to deliberately make time to video call them from my iPad when I was at home. I found myself less distracted and rushed during our conversations, mainly because you can’t really multitask while holding an iPad up to your face. With my friends, because I was only sending them messages from my computer or iPad, I didn’t have any conversations while I was on the go. For this reason, I started to use technology as a way to coordinate in-person meet-ups and conversation rather than maintain conversation through texts. Naturally, this helped me spend more quality time with some of my closer friends.

So am I saying you should throw out your phone?

Not at all. There are times when they are dramatically useful, like getting directions, coordinating a meet-up with friends, or answering an emergency call. The key takeaway that I gained from this experience is that we need to make technology use a positive addition, rather than distraction, to your life. For example, I no longer use Spotify when I’m commuting, but I frequently use it to listen to a whole album from my favourite artists. Think about your relationships with different devices and services and think about how you can make your relationship with them more positive.

How can you do this? Here are three practical tips:

• Keep your phone out of reach — put it in your bag, in a drawer or across the room. This lowers the temptation to aimlessly browse, but still leaves it available for deliberate and useful actions.

• Make notifications work for you — if you find that push notifications suck you in from the lock screen, for example, try substituting them for “badge” notifications. Think about what information is adds to your day (rather than detracts) and adjust your usage accordingly.

• Carry a book — before you roll your eyes, here me out: the majority of your browsing (be it the news, Twitter or even meme pages) is reading. Replacing these short snippets of reading with a longer, more complete book of your choice is an exercise in maintaining focus on a singular task. If you need a recommendation, here’s my Goodreads reading list.

Thanks for reading. If you liked this, you may enjoy my weekly newsletter where I discuss product management, career advice and frameworks for like. Subscribe below so you don’t miss any new articles.

Subscribe now

This article was originally shared on Medium in 2018. It has over 4,000 claps and is one of my favorite piece I’ve ever written.

August 27th, 2014, I received my first salaried job offer to become a Sandwich Artist at Subway. Just over four years later, I accepted my offer to join Facebook as a Product Manager in their Rotational Product Manager Program. Even writing that down, I still can’t believe it and I’m so excited to get started.

I wanted to share the story of the last four years for two reasons:

1. To share the lessons I learned at key parts of the journey, and

2. To show the work that went on behind the scenes of something I’m really proud of

It wasn’t an easy or linear path, but that’s what makes it meaningful to me. This is neither a short post nor a step-by-step guide on how to get a job at Facebook, but hopefully sharing what I learned through every part of the journey can help you navigate your future (I’ve also left some key takeaways at the bottom).

Subway, San Francisco and China

After high school, I moved from Toronto to Vancouver and enrolled in the Bachelor of International Economics Program at the University of British Columbia. I got my aforementioned Sandwich Artist gig as a way of earning some income to pay for school.

Subway was tough. I would always work morning shifts and the bulk of my job was cutting four vegetables: tomatoes, bell peppers, cucumbers, and onions. Every morning, without fail, I would cut the onions and start to cry. To make matters worse, my hands would smell like onions for the rest of the day and people in the class would even comment on the smell. The people I worked with were great (and even snuck me some 6" subs every now and then), but after a few months, I knew I needed to get a different job.

So I looked at the skills I had and started to work on some projects. The only “professional” skill I had at the time was social media marketing, which I learned by growing my own Twitter following, so I started to write and market articles online to show how I grew my following. My hope was that by sharing my strategies, I would be able to practice social media content marketing and build my own experiences. People made fun of me for being a “try-hard”, but I tried to brush it off. I found that sharing my work publicly was hard and opened me up to criticism. I found, however, that my real friends encouraged my work and offered me feedback instead of judgment.

Going out to events hosted by my university’s entrepreneurship club also got me involved with a Kickstarter campaign with two awesome Vancouver entrepreneurs. The campaign was for a card game that taught kids the fundamentals of coding logic and it gave me experience with product marketing, developing a go-to-market strategy and working with startup founders.

Between this campaign and publishing a few articles, I was able to land my first internship as a Marketing Intern with The C100 Association in San Francisco. I was EXTREMELY fortunate that my older brother was living in SF and I could stay with him rent-free, otherwise I wouldn’t have been able to take this internship.

What I learned:

Start somewhere — I didn’t know if Marketing was my “dream career”, but I had to start somewhere. Leverage your current skills and start accumulating interesting experiences rather than pondering your ideal career path.

Put something out there — sharing my project publicly spoke a lot to my proactivity, knowledge level, and passion for a specific role. I encourage everyone to start putting things out there, regardless of what people say.

Although I learned that marketing wasn’t for me that summer, going to San Francisco exposed me to some really interesting people and opportunities. An example of this was when I met someone who was in The Cansbridge Fellowship — a scholarship for young Canadian entrepreneurs that gives 15 students a grant to take an internship in Asia while giving them access to an awesome alumni base in the Bay Area. The idea of going abroad and meeting people who were also interested in startups/technology was really exciting to me, but I was intimidated by the application process. I didn’t really identify as an “entrepreneur” and didn’t think I met all of the criteria, but I threw in an application anyways. I received an interview and found that the initiative I had taken with publishing articles, running a Kickstarter campaign, and working in San Francisco demonstrated an “entrepreneurial inclination”. I applied in September of 2015 and got accepted to the program that December!

A major part of the program was a self-directed job hunt for an internship in Asia. This was a really demoralizing process. I had never networked for any job before, let alone an internship in countries I had never been to! After about 4 months of failed job applications and networking dead-ends, I began speaking to the Chief Strategy Officer of Sunteng, an Ad-tech company in Guangzhou, China. At this point, I was desperate to land an internship for the summer and when he asked what I could do for their team, I oversold myself and said that I could use my marketing experience to redesign their website. The next thing he said caught me off guard:

OK, show me what you can do. Send me your proposed redesign by the end of the weekend and we’ll see if we want to move forward.

I was nervous. It’s really easy to talk-the-talk, but landing a summer internship was now dependent on my ability to walk-the-walk. That weekend, I spent a ton of time researching website design best-practices, seeing how competitors had marketed their product, and learning about the company’s products. I made mockups of my redesigned website proposal (in Keynote nonetheless) and documented my thought process in detail. I learned a lot that weekend, and fortunately my hard work paid off: I got an offer to join the company as a Strategy Intern in Guangzhou, China for the summer.

What I learned:

Experience compounds — writing articles, getting involved in the Kickstarter campaign and doing my first internship helped me land my next internship. Start getting experience as early as possible and leverage that for the next step.

Nervousness indicates growth opportunities — I was really nervous to redesign a website in a weekend, but I learned a lot from it. I found that nervousness towards an action often indicates an opportunity to learn. Use your nerves as a compass for new opportunities to try.

Prove your value — when applying to a job, build a business plan, redesign a website or create a marketing plan to show your commitment and skills. Most people won’t bother doing this because they can’t walk-the-walk, so show that you can in order to stand out from the crowd.

China was a pivotal experience for me. The team I worked with at Sunteng was incredibly friendly and let me have some amazing experiences over the summer, including going to Techcrunch Shanghai, the RISE Conference in Hong Kong and spending two weeks in their Beijing office. But it was also lonely living in a city where I didn’t know anyone prior to arriving, didn’t speak either of the local languages, and was far-removed from my friends and family back home. My girlfriend got me a journal and encouraged me to keep writing down my thoughts regularly that summer. I tried to write in this journal every Sunday and it really helped me reflect on these challenges. Here’s an excerpt where I came to an important conclusion about my learnings:

I’ve been a little down these past few weeks and have been counting down the days until I’m back in Canada. But I’m starting to put these last few weeks into the context of my summer as a new experience. I’ve never experienced loneliness, full-time work, or tough goodbyes. But having these episodes helps me learn who I am.

While I didn’t enjoy these emotional and ambiguous challenges at the time, I found that I matured and grew a lot from the experience.

Professionally, I also started to fall in love with User Experience (UX) Design at work. I had the opportunity to fully design the prototype for a new mobile CRM tool, conduct usability studies on the company’s products and work with the product team to update the website. Halfway through the summer I knew I wanted to try an internship in UX Design and I started to tell all my friends about my interest. One of my friends, who was then doing an internship at Microsoft, said she would be happy to give me a referral but I had to give her my portfolio in a week. Another tight deadline, but I was able to get my UX design portfolio done and she submitted a referral on my behalf.

Big Tech: Microsoft & Tumblr

A few months passed and I forgot about Microsoft — that is until I got contacted by a recruiter in October 2016 to start the interview process. My jaw hit the floor and I couldn’t believe my luck. Microsoft was a company that billions of people interacted with daily, and I couldn’t fathom the idea of working there.

My phone interview went really well and I was then invited to an onsite interview with other people interviewing for UX Design and Software Engineering internships.

Studying Economics, I had major imposter syndrome on that interview day. All the other designers were studying design, had multiple internships in the field (at places like Shopify and IBM, nonetheless) and even dressed way more like a designer than I did (I was in a dress shirt and khakis). I knew I was the least experienced and thought that maybe I was only here because I got a referral.

But I went through the interview process — which consisted of a 15-min portfolio presentation followed by 4 interviews — with a strategy: to convey a unique and compelling narrative of why I want to build great products. I spoke about my ablity to build products for the Chinese audience, why I loved launching the educational card game on Kickstarter and how I had a background in project management. I felt this would make me more competitive as I couldn’t compete on just my design chops alone (as I would definitely fail). That plan seemed to have worked — I got an offer and I started my internship as a User Experience Design Intern at Microsoft Vancouver in January of 2017.

What I learned:

Share your career hypotheses — I wanted to get into design, so I told others about that goal. These people either challenged my hypothesis or helped me get to the next step.

The only job requirement is the ability to do the job well — I met less than 20% of the “requirements” for Microsoft’s UX Designer job description. But I knew that I was able to do the job well if I got a chance. Don’t let “requirements” stand in your way.

Focus on your narrative — This is key for anyone trying to break into a field where they don’t meet all the criteria in the job description. Keep trying to bring the conversation to your unique story that makes you a compelling candidate.

My internship at Microsoft was in the Garage — their “department” for experimental projects. The format of the internship was unique: a team of 6 (5 developers and 1 designer) would work for 4 months on a project pitched by a team at Microsoft. My awesome team of 6 (pictured below) worked with Microsoft Teams to launch a bot that helped teams coordinate lunch plans. I loved this internship and I’ve already spoken about the key elements of my experience and the lessons learned in depth.

In the internship, I started to gravitate towards tasks that I later learned were traditionally filled by a product manager — including deciding feature milestones, giving presentations on progress, and advocating for the user. This gave me an inkling that maybe UX Design wasn’t the right position for me (I actually asked my manager “What role do you see me in?” and he started his response with “Probably not a designer…”). Since I thought the role of a Product Manager was something that required a few years in a different role — like a designer, software engineer, or data analyst — I decided to give data analytics a try.

This took me to Tumblr (my first time in New York City!) where I was a Business Analyst Intern on the Global Growth Strategy & Brand team. In this role, I learned SQL and worked mainly on product analytics projects, including evaluating the effect of different push notification formats on 7 day retention. I enjoyed the ability to work directly with the product and data science teams to evaluate different features and even had a chance to present one of my projects to 60+ employees at Lunch and Learn. While I loved being more technical, however, I knew that I wanted to work on building a product more directly.

What I learned:

Self-directed learning > school learning — Many people have asked, “If you study economics, how did you work as a UX Designer?” The key lesson I learned was that what you learn outside the classroom, through books, hackathons, or online courses are A) more directly applicable to professional work and B) demonstrate a real passion for the subject matter.

Hustle into Product

I left my internship at Tumblr with a newfound confidence in my abilities. I started to realize that my strengths were in breaking down complex problems into manageable pieces. I also learned that I was a quick-learner and could pick up challenging skills in a few weeks. I decided that for my next internship, I wanted to really challenge myself and take on either a role in Data Science or Product Management — two fields that were definitely a “stretch” for my background, but could therefore provide the biggest growth opportunities.

When I enter any interview process, I put all my eggs into one basket and typically give that process 120% of my effort and energy (i.e. I’m not the type to apply to 40 jobs and interview at seven different companies in a week). The challenge with this though is that failure is all the more disappointing as you’ve sunk considerable energy and time into something with no success. This happened to me three times over the next few months, while I was interviewing for a Program Manager role at Microsoft and Data Science roles at Yelp and LinkedIn. Final round for all of them — but no luck in the end.

Fortunately, I was able to nab an awesome internship at Siftery — a fast-growing B2B startup in San Francisco. The role was a challenging combination of product management, enterprise sales and product analytics. The main things this role taught me were how to hustle and to learn by doing. For example, I had never done a sales call prior to the internship, but within a week of being there I had a full week of demos planned with founders, executives, and CTOs alike. It was nerve-wracking, but a huge growth opportunity.

In San Francisco, I started to learn that there were Product Manager programs for new-grads, like Associate Product Manager programs for Uber, Google, and Lyft. I also heard that they were incredibly competitive, but I knew that being a Product Manager was my dream. I knew I wanted to go all-in again.

Towards the end of the summer, I attended an info session for Facebook’s Rotational Product Manager (RPM) program. At the session, I met other attendees who had extremely impressive (and therefore intimidating) backgrounds. This reinforced the idea that maybe I wasn’t good enough to get in.

But when the presentation started, I could see that the RPM program was the perfect fit for me: an 18-month program that rotates you through the most widely used consumer products in the world including Instagram, WhatsApp, and, of course, Facebook. Importantly, Facebook emphasizes your product sense and execution abilities over your technical background, which was much more aligned with my strengths. I didn’t get a referral because I didn’t know many people at Facebook, but I applied anyways and heard back that I had a phone interview!

Facebook’s RPM interview process consisted of three stages: a phone screen, two technical video calls, and an onsite. I had never interviewed for a Product Manager role at a company like Facebook, so I knew that I would actively need to prepare. I picked up Lewis Lin’s Decode & Conquer, Gayle Laakmann McDowell and Jackie Bavaro’s Cracking the PM Interview, and spent 3–4 hours every day during my interview process preparing.

The phone screen was a series of classic behavioural questions that I felt comfortable answering. The technical calls were more challenging. One tested your “Product Sense”, how you design a solution to an ambiguous problem (A classic example: How would you design a phone for the blind?). The other tested your “Execution”, which centred around choosing the right metric to prioritize (Ex. How would you measure the success of Facebook Stories?). Having done UX Design interviews before, I felt that Product Sense went better than my Execution interview. Fortunately, I did well on the aggregate and advanced to the onsite.

When I arrived at Facebook campus, I soon learned that I was the only new-grad candidate amongst a group of experienced and MBA candidates. It reminded me of my interview at Microsoft and imposter syndrome started to kick back in. I went to the bathroom to take a minute to collect myself and think back to all my experienced that got me here — cutting onions at Subway, facing emotional challenges in China, and hustling for jobs at some of the coolest companies in the world. I felt like I had a unique path to this interview and that I was far from a “cookie-cutter” candidate. I convinced myself that I deserved to be here and decided to give it 120% again.

The onsite featured more behavioural, product sense and execution questions. Everyone I met seemed excited about their job, spoke candidly about some of their challenges with work and why they joined Facebook. My first interview went well, which helped me compound confidence over my next two. I felt strong coming out of the onsite and I genuinely enjoyed the experience.

After my onsite, I received the following email from my recruiter:

Everyone really enjoyed speaking with you and I hope that the feeling was mutual. Before we can make a final decision on your candidacy, we would like to schedule a 30 minute follow up VC for you with the Director for the RPM program on this Friday

I was incredibly nervous and didn’t expect an interview after my onsite, but I was ready for one more step. The director of the program is a celebrity in the tech/product management space and it was a really cool opportunity to speak with him. He asked me a Product Sense style question that evolved into a really interesting conversation around bigger threats in social media, like fake news. The call ended and a few hours later I got a call from my recruiter. I got the offer.

Conclusion

These last four years have been a really exciting part of my life. I’ve learned a ton, met great people and dealt with quite a few challenges. I’m thankful for all the support I’ve had from friends, family and just plain luck. I’m looking forward to starting the next chapter of my life at Facebook in 2019!

I’d like to leave you with three core lessons that I’ve learned from the process:

1. Start anywhere and keep moving forward — Any experience is good experience. Work on interesting projects, travel when you can and expose yourself to great people. These experiences compound and will help you grow personally and professionally.

2. Doing > Learning — I learned early on that executing is a much better use of time than learning. If you want to do UX Design, for example, redesigning your favourite app will provide a much larger return than taking courses.

3. Take your career (and life) one step at a time — Your 10 year plan is daunting and should be subject to change. Think about what you want to work on today and in the next 6 months, this will lead you to a more authentic career path rather than chasing vanity metrics or titles.

Thank you for reading. If you enjoyed this, subscribe to my newsletter where I write about product management, navigating your career and solving life’s ambiguous problems, one mental model at at a time.

Subscribe now