Jiaona Zhang
SVP of Product at Webflow, Stanford lecturer, former product leader at Airbnb, WeWork and Dropbox
Where to hear and read about Jiaona Zhang1 episode or test
Jiaona Zhang is SVP of Product at Webflow and a Stanford lecturer who previously led product at Airbnb, WeWork and Dropbox. The thing most worth learning from her is to find why people already love your product, build a few things to a lovable bar on top of it, and run big bets in short, gated phases.
understand why people love you double down on that
Building minimum lovable products, stories from WeWork & Airbnb, and thriving as a PM | Jiaona Zhang
Jiaona Zhang: the story and the lessons
1Jiaona Zhang's career and the one-strength rule
Zhang has led product at five companies across consumer and platform. She is SVP of Product at Webflow and teaches a product management course at Stanford. Before that she was senior director of product at WeWork, a long-time product leader at Airbnb, and a PM at Dropbox and at the gaming company Pocket Gems.
She came from consulting into gaming with no CS or design background.
She built her name on one strength, then changed how she used it. At Pocket Gems she became known for analyzing data, then for keeping many plates spinning across the largest studio, and she took that to Dropbox. There she delivered a launch across several platforms with brittle APIs, a very small team and a tight deadline, which brought more responsibility.
Once you manage people, being the best executor no longer wins the most responsibility. At Airbnb and WeWork she flexed the same strength in new ways.
Zhang tells PMs to get really good at one thing and be known for it. It could be shepherding the most complex launches, taking on the most technically complex problems, or regulatory-heavy work. You crush those projects and build a reputation that earns more.
In her words: "people tend to flock and give responsibility to the people that are known for being excellent at something".
2Why Airbnb Plus failed, in Zhang's telling
Fear of managed competitors pushed Airbnb into a solution too early. Managed rivals such as Sonder had the company asking what to do about them, and the answer was to inspect and manage inventory more. The goal was sound, since not everyone trusted a platform where homes are not hotels.
The real problem was that guests wanted to know what they were getting into, so the answer was better representation of homes.
Zhang says Plus ran outside Airbnb's strengths and the economics never worked. Airbnb was a marketplace and weak in operations, and asking teams to build that muscle from the ground up is really difficult. She personally doesn't think the unit economics ever would have worked, and says the team should have dug into that at the very beginning.
She describes the trap as "magical thinking around unit economics", the belief that it all works out at scale.
She saw cheaper, targeted fixes than sending inspectors to every home. Guest reviews are essentially free and are the right way for a platform to signal quality. Other options were a lockbox for everyone, partnering with local cleaners with the cost built into the fee, and more granular questions to hosts at upload that technology can automate.
"it is actually cheaper to go send everyone a lock box than to deploy an inspector". Her rule: find the best fix for the problem on this listing, not one blunt instrument for all.
3How Zhang builds minimum lovable products
Zhang trains new PMs to ignore the solution they want to build. Students arrive saying they want to build X startup, or bring research from their own field. She tells them to study real people and their problems first, and only then ask whether there is an opportunity.
She calls jumping to solutions the hardest habit to untrain, and says every human has it.
She argues a lovable minimum is the new viable minimum. With many options available, a product that barely meets the bar loses. She prefers five things done really well over fifteen done clunkily.
"minimal lovable in five areas as opposed to minimal viable in 15 areas".
Zhang sets the polish bar by what the user does today. If the alternative is a spreadsheet or manual workflow, the bar can sit lower. A designer expects a much higher bar than someone on a finance or IT team, who are used to doing around 15 things by hand.
She adds pixie dust in only a few chosen places. Lovable mostly means plainly good, not janky and not weird to use, plus small touches such as Webflow's keyboard shortcuts for power users. In Airbnb's mobile app revamp, templates came pre-populated from content users already had.
Pixie dust costs time, staffing and scope, and more of it pushes out the launch date, so she picks a few areas and goes a bit beyond what users expect.
At Webflow she weighed shipping short of lovable and letting the ecosystem finish. On memberships and logic, the team could reach viable but doubted it could reach lovable. The choice was to keep polishing into diminishing returns, or release and let the ecosystem add the lovable piece.
Releasing is not putting it out and hoping. The team needs a firm view on viable, lovable or in between, and must say whether the company will close the gap itself.
4Zhang on big bets, roadmaps and OKRs
Zhang dreams big but runs the dream in named phases. She names the phase, what the team will learn in it over three or six months, and a go or no-go at each quarter-long step. For Plus, that meant signals on host communication or on listings run by hosts with multiple properties.
Unscalable things are fine while prototyping, as long as everyone knows that is the phase. It guards against sunk cost: "I invested a quarter in it but I didn't invest two years".
She writes roadmaps as a story of themes, not scored projects. Themes name the biggest levers to pull and why, and the team works out the projects and the how. A spreadsheet of RICE scores is not prioritization, because people want to know why they are doing the work.
A crisp story lets new learning change the plan, such as finding more power users or more non-technical users. Her ask of a team: "you're telling a story so what I want from you is I want themes".
Her roadmap is a doc that links to the live systems. Decks need a voiceover, which is hard in remote and hybrid teams, and writing prose forces granularity. Linking to Jira keeps the roadmap from becoming an outdated snapshot.
She edits the themes only when the team learns something major.
Zhang starts OKRs by defining in words what a great quarter looks like. She asks what would make you say you really crushed it, then draws the line from the input metric to the outcome users and the business should feel. Without that, a team can hit every OKR while users feel nothing different, which she calls the worst outcome.
She prefers red or yellow OKRs with lessons over all green, which signals goals that were not ambitious. Fear of missing leads to sandbagging and late numbers.
She pairs ambitious OKRs with a milestone path and does not punish misses. She expects the PM to state the north star, say it can't be hit in one quarter, and lay out about five milestones across quarters with the first one explained. Performance is judged on whether the story and path made sense.
She would rather someone aim for the moon without a full path than aim low. "your job is to dream big and also have a plan to go tackle it".
5Why Zhang says to double down on why people love you
Zhang found the same rule at Dropbox, Airbnb, WeWork and Webflow. Find why people love you, invest there first, and build the rest around it. She asks "what is your alpha", meaning why people come to you in the first place.
A company is not a one-trick pony, but each new product should leverage the core advantage in an adjacent area or as an add-on.
At Dropbox she saw files and sync as the core, not a Slack rival. Dropbox considered a Slack competitor when people loved its simplicity and fast syncing. For a period it underinvested in client performance, though sync time is a big part of the experience.
Her view is that the best collaboration experience for Dropbox centers on files, not just conversation.
At Airbnb she would have invested in knowing what is inside a home. Airbnb's edge is real people's homes, but experiences and transportation pulled attention away from the core. She names host onboarding, discovery and guest booking journeys as better investments, so guests are not surprised.
Spreading thin left things that sort of worked but not quite.
She read WeWork's edge as its inventory and Webflow's as the designer. WeWork's edge was its inventory, not a tech team or a clever key card. At Webflow the designer is the core and the CMS adds to it, because with the CMS you can design with data, so she wants deep investment there.
6How Zhang pushes back, earns trust and asks for help
She pushes back only when she has conviction, not while still learning. Mike Lewis, head of product for another new bet at Airbnb, realized he was the person who should say no. Zhang's test is whether you have total conviction or are still learning; with total conviction, saying no is the job.
It was hard because the founder, Brian, was very into the idea and everyone was rallying behind it.
Zhang restates the founder's goal and brings better options backed by data. She aligns on what the founder is trying to achieve for the user and the business, then returns with a better path. Smart, motivated people rarely still want a failing solution once a much better one is shown with data.
She moved off the Plus team to evolve the review system, the scalable route to the same goal.
She says trust works like a bank: deposit before you withdraw. In her first 90 days at Webflow the time limit made her push for change too hard, too early. Her fix is to gain trust first and then spend it on change, and she notes most people do not have only 90 days.
She chose team context over product context and paid for it in trust. Webflow is complex and her team already held deep product knowledge, so she spent early time on how functions worked together. She did not use the product enough to say she knew how things worked firsthand.
That earned trust on the discipline but not on product fundamentals. Without a deadline she would go deep on the product first.
Zhang asks for help as a leader and tells her team when she doesn't know. She asks partners, peers and mentors, and has pushed herself to do this since she started managing people. For Webflow's three-year product strategy she asks founders, outside experts and engineers what is changing in AI, since she is not an AI expert.
"be honest about what you know and what you don't know and ask for help when you don't know something".
7What WeWork and Webflow taught Zhang about teams and ramp-up
Leading WeWork through layoffs taught Zhang empathy. She spent her first six months growing her team across the US, Asia and Europe, and the second half working out what to do with all those people. She calls it a crash course and says people skills matter as much as knowing the market, customers and strategy.
She joined WeWork because Airbnb had not dialed in operations and WeWork had.
She now gates hiring on milestones and results. WeWork's operations were excellent, but the tech team was hired beyond what the product needed, and layoffs followed. Her rule is clear gates: hit these results, then hiring opens in set ways.
"we hired beyond our skis on the tech side". Laying off half a team you just hired is a terrible feeling.
Her hardest call was choosing between her own job and a teammate's. In her first trimester she could keep a role with guaranteed maternity leave, or put herself on the layoff list and give it to someone else. She gave the role away, then joined Webflow at the start of her third trimester, 90 days before her son was born.
She had hired a teammate on a visa, and a layoff would leave that person few days to find a new job. She reasoned she would have more time and freedom to find her next role.
She built context at Webflow with 40 to 50 conversations in the first weeks. Her direct team and the leadership team came to about 25 people, and a couple of contacts per function brought the total to 40 to 50. For each function she wanted the leader plus someone closer to the work, including long-tenured engineers on what was hard in the tech stack.
Done back to back and synthesized, the conversations gave a good picture of what was going on.
She left a plan naming what to keep, research and decide. The plan assigned owners to the research so data would be ready for go or no-go decisions on her return. She wanted the leadership team, founders and board to see gaps such as engineering hiring, and asked other executives to be accountable.
She presented to a board meeting the day before her checkup, where she was told she was in labor.
8How Zhang hires and tunes team process
She hires PMs for how they structure a path through ambiguity. She asks behavioral questions about ambiguous and hard situations, since the PM job is hard to describe on paper. Good candidates seek input and name small milestones that show whether the path is working.
A first path is rarely the right one, so she wants to see people adjust decisions as results come in. A weak answer just says we're swimming in ambiguity.
Webflow engineers run a tech spike at the start of a project. Features interact across a complex platform, so the spike gauges difficulty and unknowns before the team commits to a path that does not make sense.
At another company the bigger fix might be a kickoff meeting with cross-functional partners. She thinks about small process tweaks every day, matched to the company's biggest problem.
She plans to cut Webflow's learning curve by teaching inside the product. Webflow is a professional tool, so power came with a steep learning curve. Webflow University and AI will merge so users learn in context, and users could prompt Webflow to take actions for them.
Some of it is in alpha and beta, built with users to see if it gets them over the activation hump.
Building minimum lovable products, stories from WeWork & Airbnb, and thriving as a PM | Jiaona Zhang
Product leadership lessons from Dropbox, Airbnb, WeWork and Webflow: build minimum lovable products, roadmap with stories instead of spreadsheets, set ambitious OKRs, and double down on why people love you. It also covers why Airbnb Plus failed on solution-first thinking and unit economics, and how to run a first 90 days.
Zhang has led product at five companies across consumer and platform. She is SVP of Product at Webflow and teaches a product management course at Stanford. Before that she was senior director of product at WeWork, a long-time product leader at Airbnb, and a PM at Dropbox and at the gaming company Pocket Gems.
She came from consulting into gaming with no CS or design background.
She built her name on one strength, then changed how she used it. At Pocket Gems she became known for analyzing data, then for keeping many plates spinning across the largest studio, and she took that to Dropbox. There she delivered a launch across several platforms with brittle APIs, a very small team and a tight deadline, which brought more responsibility.
Once you manage people, being the best executor no longer wins the most responsibility. At Airbnb and WeWork she flexed the same strength in new ways.
Zhang tells PMs to get really good at one thing and be known for it. It could be shepherding the most complex launches, taking on the most technically complex problems, or regulatory-heavy work. You crush those projects and build a reputation that earns more.
In her words: "people tend to flock and give responsibility to the people that are known for being excellent at something".
Fear of managed competitors pushed Airbnb into a solution too early. Managed rivals such as Sonder had the company asking what to do about them, and the answer was to inspect and manage inventory more. The goal was sound, since not everyone trusted a platform where homes are not hotels.
The real problem was that guests wanted to know what they were getting into, so the answer was better representation of homes.
Zhang says Plus ran outside Airbnb's strengths and the economics never worked. Airbnb was a marketplace and weak in operations, and asking teams to build that muscle from the ground up is really difficult. She personally doesn't think the unit economics ever would have worked, and says the team should have dug into that at the very beginning.
She describes the trap as "magical thinking around unit economics", the belief that it all works out at scale.
She saw cheaper, targeted fixes than sending inspectors to every home. Guest reviews are essentially free and are the right way for a platform to signal quality. Other options were a lockbox for everyone, partnering with local cleaners with the cost built into the fee, and more granular questions to hosts at upload that technology can automate.
"it is actually cheaper to go send everyone a lock box than to deploy an inspector". Her rule: find the best fix for the problem on this listing, not one blunt instrument for all.
Zhang trains new PMs to ignore the solution they want to build. Students arrive saying they want to build X startup, or bring research from their own field. She tells them to study real people and their problems first, and only then ask whether there is an opportunity.
She calls jumping to solutions the hardest habit to untrain, and says every human has it.
She argues a lovable minimum is the new viable minimum. With many options available, a product that barely meets the bar loses. She prefers five things done really well over fifteen done clunkily.
"minimal lovable in five areas as opposed to minimal viable in 15 areas".
Zhang sets the polish bar by what the user does today. If the alternative is a spreadsheet or manual workflow, the bar can sit lower. A designer expects a much higher bar than someone on a finance or IT team, who are used to doing around 15 things by hand.
She adds pixie dust in only a few chosen places. Lovable mostly means plainly good, not janky and not weird to use, plus small touches such as Webflow's keyboard shortcuts for power users. In Airbnb's mobile app revamp, templates came pre-populated from content users already had.
Pixie dust costs time, staffing and scope, and more of it pushes out the launch date, so she picks a few areas and goes a bit beyond what users expect.
At Webflow she weighed shipping short of lovable and letting the ecosystem finish. On memberships and logic, the team could reach viable but doubted it could reach lovable. The choice was to keep polishing into diminishing returns, or release and let the ecosystem add the lovable piece.
Releasing is not putting it out and hoping. The team needs a firm view on viable, lovable or in between, and must say whether the company will close the gap itself.
Zhang dreams big but runs the dream in named phases. She names the phase, what the team will learn in it over three or six months, and a go or no-go at each quarter-long step. For Plus, that meant signals on host communication or on listings run by hosts with multiple properties.
Unscalable things are fine while prototyping, as long as everyone knows that is the phase. It guards against sunk cost: "I invested a quarter in it but I didn't invest two years".
She writes roadmaps as a story of themes, not scored projects. Themes name the biggest levers to pull and why, and the team works out the projects and the how. A spreadsheet of RICE scores is not prioritization, because people want to know why they are doing the work.
A crisp story lets new learning change the plan, such as finding more power users or more non-technical users. Her ask of a team: "you're telling a story so what I want from you is I want themes".
Her roadmap is a doc that links to the live systems. Decks need a voiceover, which is hard in remote and hybrid teams, and writing prose forces granularity. Linking to Jira keeps the roadmap from becoming an outdated snapshot.
She edits the themes only when the team learns something major.
Zhang starts OKRs by defining in words what a great quarter looks like. She asks what would make you say you really crushed it, then draws the line from the input metric to the outcome users and the business should feel. Without that, a team can hit every OKR while users feel nothing different, which she calls the worst outcome.
She prefers red or yellow OKRs with lessons over all green, which signals goals that were not ambitious. Fear of missing leads to sandbagging and late numbers.
She pairs ambitious OKRs with a milestone path and does not punish misses. She expects the PM to state the north star, say it can't be hit in one quarter, and lay out about five milestones across quarters with the first one explained. Performance is judged on whether the story and path made sense.
She would rather someone aim for the moon without a full path than aim low. "your job is to dream big and also have a plan to go tackle it".
Zhang found the same rule at Dropbox, Airbnb, WeWork and Webflow. Find why people love you, invest there first, and build the rest around it. She asks "what is your alpha", meaning why people come to you in the first place.
A company is not a one-trick pony, but each new product should leverage the core advantage in an adjacent area or as an add-on.
At Dropbox she saw files and sync as the core, not a Slack rival. Dropbox considered a Slack competitor when people loved its simplicity and fast syncing. For a period it underinvested in client performance, though sync time is a big part of the experience.
Her view is that the best collaboration experience for Dropbox centers on files, not just conversation.
At Airbnb she would have invested in knowing what is inside a home. Airbnb's edge is real people's homes, but experiences and transportation pulled attention away from the core. She names host onboarding, discovery and guest booking journeys as better investments, so guests are not surprised.
Spreading thin left things that sort of worked but not quite.
She read WeWork's edge as its inventory and Webflow's as the designer. WeWork's edge was its inventory, not a tech team or a clever key card. At Webflow the designer is the core and the CMS adds to it, because with the CMS you can design with data, so she wants deep investment there.
She pushes back only when she has conviction, not while still learning. Mike Lewis, head of product for another new bet at Airbnb, realized he was the person who should say no. Zhang's test is whether you have total conviction or are still learning; with total conviction, saying no is the job.
It was hard because the founder, Brian, was very into the idea and everyone was rallying behind it.
Zhang restates the founder's goal and brings better options backed by data. She aligns on what the founder is trying to achieve for the user and the business, then returns with a better path. Smart, motivated people rarely still want a failing solution once a much better one is shown with data.
She moved off the Plus team to evolve the review system, the scalable route to the same goal.
She says trust works like a bank: deposit before you withdraw. In her first 90 days at Webflow the time limit made her push for change too hard, too early. Her fix is to gain trust first and then spend it on change, and she notes most people do not have only 90 days.
She chose team context over product context and paid for it in trust. Webflow is complex and her team already held deep product knowledge, so she spent early time on how functions worked together. She did not use the product enough to say she knew how things worked firsthand.
That earned trust on the discipline but not on product fundamentals. Without a deadline she would go deep on the product first.
Zhang asks for help as a leader and tells her team when she doesn't know. She asks partners, peers and mentors, and has pushed herself to do this since she started managing people. For Webflow's three-year product strategy she asks founders, outside experts and engineers what is changing in AI, since she is not an AI expert.
"be honest about what you know and what you don't know and ask for help when you don't know something".
Leading WeWork through layoffs taught Zhang empathy. She spent her first six months growing her team across the US, Asia and Europe, and the second half working out what to do with all those people. She calls it a crash course and says people skills matter as much as knowing the market, customers and strategy.
She joined WeWork because Airbnb had not dialed in operations and WeWork had.
She now gates hiring on milestones and results. WeWork's operations were excellent, but the tech team was hired beyond what the product needed, and layoffs followed. Her rule is clear gates: hit these results, then hiring opens in set ways.
"we hired beyond our skis on the tech side". Laying off half a team you just hired is a terrible feeling.
Her hardest call was choosing between her own job and a teammate's. In her first trimester she could keep a role with guaranteed maternity leave, or put herself on the layoff list and give it to someone else. She gave the role away, then joined Webflow at the start of her third trimester, 90 days before her son was born.
She had hired a teammate on a visa, and a layoff would leave that person few days to find a new job. She reasoned she would have more time and freedom to find her next role.
She built context at Webflow with 40 to 50 conversations in the first weeks. Her direct team and the leadership team came to about 25 people, and a couple of contacts per function brought the total to 40 to 50. For each function she wanted the leader plus someone closer to the work, including long-tenured engineers on what was hard in the tech stack.
Done back to back and synthesized, the conversations gave a good picture of what was going on.
She left a plan naming what to keep, research and decide. The plan assigned owners to the research so data would be ready for go or no-go decisions on her return. She wanted the leadership team, founders and board to see gaps such as engineering hiring, and asked other executives to be accountable.
She presented to a board meeting the day before her checkup, where she was told she was in labor.
She hires PMs for how they structure a path through ambiguity. She asks behavioral questions about ambiguous and hard situations, since the PM job is hard to describe on paper. Good candidates seek input and name small milestones that show whether the path is working.
A first path is rarely the right one, so she wants to see people adjust decisions as results come in. A weak answer just says we're swimming in ambiguity.
Webflow engineers run a tech spike at the start of a project. Features interact across a complex platform, so the spike gauges difficulty and unknowns before the team commits to a path that does not make sense.
At another company the bigger fix might be a kickoff meeting with cross-functional partners. She thinks about small process tweaks every day, matched to the company's biggest problem.
She plans to cut Webflow's learning curve by teaching inside the product. Webflow is a professional tool, so power came with a steep learning curve. Webflow University and AI will merge so users learn in context, and users could prompt Webflow to take actions for them.
Some of it is in alpha and beta, built with users to see if it gets them over the activation hump.