最小可爱产品、Airbnb Plus 复盘，以及信任账户：Jiaona Zhang 的产品课

Jiaona Zhang has taught product management at Stanford for about six years, and in that time she has watched a lot of new PMs succeed and some fail. The mistake she sees most often — and the one that is hardest to untrain — is jumping to a solution: students arrive already attached to a specific thing they want to build. Her course deliberately strips that away, sending people out to study real users and their problems first and only then asking whether an opportunity exists. The sequencing is the point: understand the problem, then assess the opportunity, rather than starting from "I want to build X for Y person."

She traces part of the habit to why people want the job — the appeal of finally having the power to decide what gets built. Her first lesson is that a PM is not a CEO and holds very little true authority, because they manage no one; the role runs on influence. The PM's job is to surface opportunities, pull together the possible paths and edit, not to call the shots.

The mistake she names as her own biggest is Airbnb Plus. The real problem was trust: Airbnb is unmanaged inventory, and guests wanted to know what they were getting themselves into. Instead of attacking that, the team went solution-first and, she says, was competitor-afraid of managed marketplaces such as Sonder, so it decided to inspect and manage inventory. She notes two things the team should have weighed: Airbnb's strategic muscle was marketplace and platform, not operations, and building an operations muscle from scratch is extremely difficult.

Unit economics were the other red flag, and she says there was never a clear path — only magical thinking that things would work out at scale X. For a platform, the scalable quality signal was already free: guest reviews. Even alternative fixes were cheaper and more targeted than inspectors, such as sending every host a lockbox or partnering with local cleaners and folding the cost into a fee, each aimed at the specific quality problem of a specific listing instead of one blunt instrument.

Zhang argues every company needs a big vision — without one, innovation is hard — but the vision has to be paired with thoughtfulness in execution. Her main technique is to be explicit about which phase the team is in: "we are going to try X for three to six months, and we are explicitly going to learn these things." In a learning phase it is fine to do unscalable things and run prototypes, as long as nobody pretends the team is already in delivery mode and simply "going at it."

To avoid the sunk-cost spiral of "we've spent so much, give it one more quarter," she wants success defined up front, with milestones at short intervals. Each quarter becomes a go/no-go point, so the company can truthfully say it invested a quarter rather than two years. Breaking the bet into chunks is what lets a team think really big and still be able to walk away.

On pushing back at leadership, she is direct: if you have total conviction that an idea is wrong, saying no is part of your job. To convince a founder, she starts from the spirit of what they are trying to achieve, gets aligned on that, and then returns with better options — for Airbnb Plus, more granular checks at the moment a host uploads a home, which can be automated rather than done by humans. She eventually moved off the team to work on the review system, the scalable version of the same goal. In her experience it is rare for a smart, motivated leader to insist on a failing solution when someone comes back with data and a better path.

Zhang prefers the term minimal lovable product to minimal viable product. In a market with many options, "it barely meets a quality bar" is not a good enough reason for someone to adopt your product; lovable means knowing, for this specific product, what quality bar actually resonates with your users. She calls the minimal lovable product the new MVP.

The polish bar is relative to the alternative. If you are replacing a manual workflow or a spreadsheet, ship as fast as possible — fifteen additional features are unnecessary when what you have is already perfectly usable, and arguably lovable, by comparison. Tolerance varies by user: a designer has a much higher bar for workflow and craft, while someone on the finance or IT team is comparing you to fifteen manual steps.

At Webflow, the team invested in new functionality such as memberships and logic and concluded it could reach minimal viable but was not sure it could reach minimal lovable in a way users would really want. That raised a strategic question: keep shipping toward lovable, or release what exists and let the ecosystem contribute the lovable piece. Either way, she says, you need a strong point of view about where a given product sits between viable and lovable, and then decide whether the company or its ecosystem closes the gap.

For the finite resources of time, staffing and scope, her rule is to do five things really well rather than fifteen things a little. Lovability often comes from the thing simply working — high quality, not janky — plus a few deliberate extras: keyboard shortcuts for power users, or the "pixie dust" of pre-populating templates from content people already have, as in an Airbnb mobile app revamp. You cannot pixie dust everything, so pick a few places where you do more than users expect.

Zhang's headline roadmapping advice is that you are telling a story: give me themes, the biggest levers to pull, and why these are the things to invest in. The mistake she sees constantly is treating a spreadsheet of projects with RICE-style impact, cost and effort columns as prioritization — that is a race, not a narrative. Humans want to know why they are doing a body of work, and having the story crisp also matters for you, because when you learn something that contradicts your assumptions, the narrative itself has to change, not just a number in a cell.

The artifact she wants is a doc, because decks need a voiceover and teams are often remote or hybrid. It should state what we are trying to achieve, the big areas and themes, the big projects under each theme, and then link out to where work actually lives — Jira, for example — instead of maintaining a spreadsheet that goes stale. Themes are what you edit when major learnings land; the links always show the current state of execution.

Templates and artifacts matter at the org level too. She points to Reforge's work on artifacts — a shared product development process, spec templates, roadmap templates — and says teams always tweak them, but the value comes from bringing them back and sharing them across teams. That is also why Webflow invested in product operations: it greases the wheels and gets all the teams speaking the same language.

Her career advice for new PMs is to become really good at, and known for, something specific. It could be shepherding the most complex launches because you are excellent at quarterbacking go-to-market teams and cross-functional stakeholders, the most technically complex problems, or the most regulatorily complex work. The reason is mechanical: people give responsibility to people who are known for being excellent at something, so the reputation itself unlocks the projects you get to crush.

In her own career it started with analytics: she came from consulting with no computer science or design background and built a reputation for analyzing her game's data and making decisions from it. She also discovered she was good at execution — keeping many plates spinning on the largest studio — and carried that to Dropbox, where she worked across many teams, on brittle APIs, with a very small team and a tight deadline. That reputation earns more responsibility, but she notes it evolves: once you manage, being the best executor is not what earns your team the most responsibility, so you flex the core strength into new forms.

Her biggest tip on OKRs is to get crisp, qualitatively, on what would make the team say "we did a great job." Because people fear OKRs — worrying a miss will hurt their reputation or their promotion — they sandbag and hold off committing to numbers until they are certain, which slows the whole company down. She would rather see red and yellow OKRs with a clear understanding of why things were missed than a wall of green, which usually means the goals were not ambitious enough.

That requires a culture where taking a risk and failing does not damage your performance review, and where the safe path is understood as building something sub-optimal. Ambition still has to come with a plan: a PM who names a huge north star should be able to draw the quarter-over-quarter milestones that get there and explain why the first one matters. She would rather have someone shoot for the moon and admit they do not yet know the path than watch them play it safe.

Zhang spent about a year at WeWork through 2019, and the first lesson she took from it was empathy. She spent her first six months building a team across the US, Asia and Europe, and the second half figuring out what to do with all of those people as the company went through its upheaval. That meant thinking hard about leadership and about giving people proper transition plans — a crash course she notes many managers got again during the recent macroeconomic downturn.

The second lesson was not to over-hire. Laying off half your team, including people you personally recruited, is a terrible experience, so she is now deliberate about tying hiring to gates and demonstrated results: get through these milestones, show these results, then unlock hiring in specific ways. Lenny connects this back to the Airbnb Plus pattern of ambition plus no concrete plan plus heavy investment.

She joined WeWork precisely because Airbnb had not built the operational muscle and WeWork was excellent at operations — but the company hired beyond its skis on the technology side. The core user need was booking; the platform did not need to be futuristic. She still believes the underlying vision, with companies routing their space needs through WeWork instead of owning dedicated offices, is big and relevant, but the key piece of that vision is inventory, and inventory management is an operational play more than a technology one.

Her hardest memory is personal: she was in her first trimester during the layoffs and had to choose between a guaranteed maternity leave on another team and putting herself on the layoff list so the role could go to someone she had hired, who was on a visa and would have less freedom to find a new job. She gave up the role, interviewed during her second trimester, and joined Webflow at the start of her third trimester — exactly 90 days before her first son was born. Her favorite memory is the people: WeWork was full of dreamers, and as at every company, you join for the product and stay for the people.

Her first 90 days at Webflow were unusually time-bound because maternity leave was fixed, so context-building had to happen faster than usual. She mapped who she needed to speak with — her leadership team, her direct team, and people across functions and levels, including the longest-tenured engineers, to learn what was hard about the tech stack and about their day-to-day. The point was not simply to meet peers but to plan deliberately where in each function the most information would come from.

Her second principle was not to simply listen and disappear. Before leaving she wanted a plan in place: what should keep executing, what needed research, and who owned each research question, so there would be a body of work to make go/no-go decisions on her return. She even presented at a board meeting the day before a checkup revealed she was in labor, because she wanted the whole leadership team and the board aware of the gaps she had found — engineering hiring, for example — and executives explicitly asked to be accountable for them.

In practice that meant roughly 20 to 25 conversations with her direct team and the leadership team, and around 40 to 50 in total once other functions were included, run back-to-back and synthesized along the way. For each function she wanted two data points: a read from the function's leader and one from someone closer to the actual work.

Her main regret from that period concerns trust. She pushed for change too hard and too fast, and she now describes trust as a bank: you make deposits, and later you spend social capital to push change, so you should not spend when the account is empty. Specifically, she traded away depth on Webflow's complex product in favor of understanding how teams and functions were working, betting on the deep product context already on the team — a defensible trade-off, but one that left her short of product credibility at the moment she wanted to push.

Asked for one lesson from each of Dropbox, Airbnb, WeWork and Webflow, Zhang gives a single product lesson: understand why people love you, invest deeply in that, and build everything else around it. At Dropbox the team wasted cycles reacting to the market — "Slack is taking off, let's build chat" — when people loved Dropbox for simplicity and ease of use. That should have pointed investment at client performance and sync speed, and at collaboration built around files, since files are the company's real advantage.

At Airbnb the special thing is that these are real people's homes, and managing and inspecting inventory worked against that rather than leaning into it; the better investment was in representing what is actually in a home, plus host onboarding and the guest discovery and booking journeys, instead of spreading into experiences and transportation. At WeWork nobody came for a key card that does ten things — they came for the inventory — so the money belonged in inventory management and tools for the sales and operations teams. At Webflow people love the designer and the CMS that lets them design with data, so depth there beats spreading thin; multi-product ambitions are fine as long as every new bet runs back through the core advantage.

The best advice she has received is to ask for help. Leaders feel the puck stops with them and worry that asking for help signals they do not know what they are doing, but she has pushed herself to do it anyway — with partners, peers, her own team and mentors — because what is in your head is rarely the global best answer. A current example: she is working on Webflow's three-year product strategy and how to use AI to support writers and users who struggle to learn the product, and because she is not an AI expert she asks founders, outside experts and engineers almost weekly as the technology shifts.

In the lightning round she recommends the Design Sprint book, a management book by Julie on how to be a good manager, and Brandon Sanderson's fantasy novels, including the Mistborn series and the secret projects he wrote during the pandemic. Her favorite interview question probes how candidates navigate ambiguity, and she looks for people who impose structure and a path forward, seek input, and define the milestones that tell them whether something is working. Her favorite products are the Snoo and Midjourney for her toddler; her recent process tweak at Webflow is running a technical spike up front to surface unknowns on a complex platform; and her Webflow pro tip is the coming integration of Webflow University and AI into the product in context, currently in alpha and beta. She is also building a Reforge course on managing your PM career and invites listeners to send her the problems they are facing.