Top 3 Product Management Insights from Stripe, Amazon, & Airbnb
Copy these mechanisms this week to build better products — faster
Hi, it’s Ethan & Jason from Level Up — Your guide to grow fast, avoid mistakes, and make optimal career moves. For more: Career Breakthrough Courses | Ethan Evans AI | Level Up YouTube
Top 3 Product Management Insights from Stripe, Amazon, & Airbnb
Watch on YouTube.
In this talk, you’ll learn how top PM teams sustain customer engagement, build a writing-first culture, and structure teams for speed and clear accountability.
Key Takeaways
One of Amazon’s pioneering PM mechanisms is the Working Backwards Document. Instead of starting with an internal target like “How do we sell more?”, you start with what the customer wants (e.g. fast shipping) and work backward on what you can do to make it happen. The core artifact is the PR/FAQ (Press Release and FAQ) — a written launch announcement in plain language (the way you’d explain the product to real customers). The PR/FAQ forces the team to frame the product around customer benefits (not internal goals).
One of Stripe’s standout PM practices is continuous user engagement. PMs talk with customers every week (e.g. calls, Slack, Reddit, Twitter). Stripe even trains PMs on what great customer conversations look like — lead with listening to problems and pain points (customers live demo and screen share) rather than talking about your product and solution. To role model that customer obsession, Stripe’s Leadership Team (led by Co-Founders Patrick and John Collison) hosts Friday Fireside Chats — 15 minute candid conversations with customers ranging from small mom-and-pop shops to large enterprises.
At Airbnb, product teams are comprised of product managers, engineers, designers, and cross-functional stakeholders (e.g. finance, treasury) aligned to a shared objective (even within siloed orgs) — the key to success is clear roles, responsibilities, and accountability. With this model, team composition shifts based on the end user. At Stripe, developers are the core user, so teams are engineering heavy. Whereas at Airbnb, guests and hosts are the primary users and thus UX is priority.
Top actions for you:
Engage real customers this week and make it a routine habit — join calls, read reviews (set aside time everyday), answer Customer Support contacts, go and experience real customers using your product. For more formal customer relationships (e.g. government agencies, banks) you may need to have structured feedback sessions such as panels, roundtables, top-to-top meetings.
Put your thoughts in writing and work backwards from the customer want/benefit to drive clarity of thought.
If you do not have holistic product teams, think about what you would do to get resources and what can you organize to motivate teams to think holistically about your product.
PR/FAQ “Problem Paragraph” Explained
Bill Carr (Co-Author Working Backwards, ex-Amazon VP of Digital Media) breaks down how to successfully overcome the hardest section when writing a PR/FAQ.
At Amazon, we would often spend months working on a single paragraph of the PR/FAQ for a new product idea. This was the "problem paragraph". Done well, it could lead to a successful product. Done wrong, it will lead to failure. Here is how to write a successful problem paragraph:
The “problem paragraph” defines the customer problem you’re solving. Without this, you will build a product that doesn’t address a customer pain point. It shows whether you truly understand your customer's needs, not just your company’s capabilities.
To write this paragraph, start by precisely identifying the customer segment that will be served by your product. Great products are built for specific people with specific needs. For instance, designing a car for single urban professionals under 35 differs significantly from designing for suburban families with three kids and a dog.
If you think your product is for everyone, you’re mistaken.
A strong way to begin your paragraph is:
“Today, [customer segment] has [problem], which they currently solve using [methods A, B, and C]…”
Next, quantify the problem:
→ How large is the segment? (e.g., 17 million households)
→ What methods do they use? (e.g., 45% use A, 25% use B, 30% use C)
→ What are the tradeoffs? (e.g., speed, cost, quality)Here’s an example for a hypothetical robot vacuum product:
“Today, 15 million busy urban and suburban professionals earning between $100,000 and $200,000 struggle to find the time and energy to keep their homes clean. Approximately 30% of these households use traditional vacuuming, which requires up to 2 hours per week. 55% hire a cleaner at a minimum of $50/week, and 15% use robot vacuums that cost $600 plus $100/year in maintenance, while leaving behind up to 30% of dust and dirt.”
This problem paragraph quantifies the customer problem in terms of money, time, and other metrics where possible (in this case, the dust and dirt left behind). The problem should always be quantified; otherwise, how can you assess the potential value of a product that solves it?
Well-defined customer problems are built on data-based insights. Insights are gleaned from swimming in data and metrics. This includes customer usage metrics, process or operations metrics, user interviews, demographic data, customer feedback, customer support data and anecdotes. The more data-based and specific your insight, the more accurate and helpful your problem paragraph will be. This is why the process can take months. However, distilling these quantified insights into a single paragraph gives you the best chance at building a truly useful product.
At Amazon, this paragraph was always the most debated section in a PR/FAQ. This is because getting the problem wrong is the worst mistake you can make in building a product. Everywhere else, you can pivot. But if the problem is incorrectly diagnosed, nothing else matters.
Think of it like this: the customer is the patient, and you are the doctor. If you misdiagnose the condition, even the best treatment won’t work.
If your product doesn’t solve a clearly defined, meaningful customer problem, it will fail even if it is well built using the latest technology. If you get the problem paragraph right, your odds of success go way up.
Explore here if you want to learn more from Bill and Colin.
Free Workshops: The AI-Native Product Manager Series
We are thrilled to be featured in Maven and Lenny Rachitsky’s “The AI-Native Product Manager” series.
There are already a combined 23,213 people (wow!) signed up across our workshops.
All are free and if you cannot attend live, don’t worry about it, you will be automatically sent the video recording.
RSVP to all and share with your network.
(March 19) Raise Your Technical Bar as an AI-Native PM. Learn why you must write structured logic engineers can test against and see live demos of a system.md that translates a PRD and evals.md.
(March 20) AI Powered Product Skills for Executive Leaders & GMs. Learn how to lead with AI and what to expect from your modern PMs and teams.
(March 20) No Vibes, Just Evals: Proven Frameworks for AI-Native PMs. Learn how to define “good” before you write code, write behavior specs (not feature specs), and how to set your autonomy dial).
(March 31) How to Get and Keep Executive Roles in the AI Economy. Learn how to balance AI hype with real business needs, how to manage ongoing disruption and uncertainty, and how to role model GenAI as a senior leader.
(April 1) Executive Presence for Poor Public Speakers. Learn how to enhance your “gravitas” without being loud, performative, or needing to control the megaphone.
If you found this valuable, give it a like and share it with your team—it helps us know what to bring you more of.
Connect With Ethan & Jason
Follow Ethan on LinkedIn.
Get our career advice on YouTube.
Connect with Jason (Ethan’s Co-Founder & COO) on LinkedIn.
Learn more about our live online courses and on-demand courses.
Contact us for corporate training, keynote speaking, guest writing, and more.
Join our Level Up Slack Community of 1300+ members and 23 specialized career channels with active peer support.
Reach out if you want to sponsor this newsletter trusted by leaders and builders scaling companies and careers across Fortune 500s, Big Tech / FAANG, and high-growth startups.
I have mixed take on this "engage real customers every week". People often say you should engage real customers and work backward from what they actually want. For a long time, that idea was hard for me to apply.
But recently it started to click. When people reach out to me about my products and I actually took action, it felt different. The same thing happened with my newsletter. One article began with a relatable experience using Notion AI for autonomous database updates. Someone told me that approach resonated, so I wrote more pieces around similar real experiences, Claude Code projects, onboarding Claude, OpenClaw...
Only after repeating this for a while did the mental model feels powerful and start to stick. It’s something I still need to practice.