Proven, Better, New: When Better Changes
The Proven, Better, New framework explains how products win, but not what happens when "Better" means different things to the buyer and the user. DingTalk won an entire market with one definition, then got trapped by it.
Published: 2026-07-22
A Popular Framework Meets Its Challenge
Two things I read recently started arguing with each other in my head.
The first was Zynga's founder Mark Pincus, on Lenny's Podcast last month, condensing his product framework into three words: Proven, Better, New. The PBN framework tells founders to build from a product, behavior, or mechanic that people already pay for or spend time on, make it convincingly better so that ten out of ten existing users would say yes, and then add whatever makes the product distinctive.
Pincus uses Words With Friends as his canonical example. It began with an already proven product: Scrabble. Mobile and asynchronous play made the experience better by allowing a game to stretch across a day in two-minute turns, while the social layer added a distinctive new contribution by turning every match into an invitation. The sequence matters. Pincus warns founders that they most often go wrong by jumping straight to "New."
The second was a video by ICLAB about the rise and strategic constraint of DingTalk, Alibaba's enterprise communication platform. The video had been prompted by a recent leadership change at DingTalk, but what held my attention was its longer product history: how a team built a genuinely good product for a real problem, won decisively with it, and then found that the product decisions behind the win made the next move harder.
The underlying logic felt familiar to me before Pincus gave it a name. I sat with the two pieces for about a week before I realized they were pointing at the same gap:
Pincus's "ten out of ten users would say yes" test is anchored on a singular persona, and his examples are consumer games where the person choosing the product and the person using it daily are usually the same. In enterprise software, that split is the default, not the edge case. The framework can explain how DingTalk won. It does not explain what happens when a company tries to serve a customer who defines "Better" differently.
PBN in Action: Two Definitions of Better
How DingTalk Built on What Was Already Proven
For U.S. readers unfamiliar with it: DingTalk is Alibaba's workplace platform, launched in early 2015 and aimed at small and mid-sized businesses across China.
DingTalk's founder, Chen Hang, spent months in 2014 doing field research at hundreds of small companies throughout China, including factories, trading firms, retail chains, and construction contractors. Many were scaling from a handful of employees to dozens or hundreds with little operational infrastructure underneath. Chen found the same pain points everywhere. Owners could not tell whether their instructions had been received, attendance was disputed daily, and approvals happened by shouting down a hallway or waiting for someone to pick up the phone. Most of these companies had never had basic managerial visibility, and they were growing fast enough that the gap was becoming urgent.
The product Chen's team shipped was a direct answer to that problem. Read receipts told managers whether a message had been opened. The DING escalation system could push an unread message to SMS and then to a phone call. Geolocation-based clock-in replaced paper sign-in sheets. Digital approval flows replaced hallway negotiations. Together, these features gave business owners visibility they had previously lacked: confirmation that a message had been opened, visibility into whether an employee had responded, and a clear record of where an approval or attendance process stood.
DingTalk did not invent every component of this system. Enterprise messaging, OA workflows, attendance tracking, and phone- and SMS-based delivery had all existed in China before it. But these capabilities were often fragmented across separate products or built for organizations with dedicated IT budgets. DingTalk recombined them into a free, mobile-first product that a small-business owner could deploy without an IT department.
Pincus's framework maps onto DingTalk at the level of components rather than a single product copied wholesale.
- The Proven elements were capabilities already established in enterprise software: messaging, attendance tracking, approval workflows, and message-delivery mechanisms.
- The Better was the package and delivery model. DingTalk made those capabilities free, mobile-first, integrated through one organizational identity, and accessible to small companies without dedicated IT teams.
- The distinctive New was the responsibility loop DingTalk built across them. Read status, DING escalation, organizational identity, geolocation-based attendance, and approval tracking reinforced one another.
These features made DingTalk one of China's most talked-about and frequently criticized workplace products. DingTalk's most hated features were precise answers to the buyer's pain. They were sharp by design. The ICLAB video draws a direct line between DingTalk's product philosophy and Chen Hang's own management style: both emphasized control, execution, and the precise transmission of responsibility.
The cost showed up in how employees talked about the product. DingTalk's read receipts and DING escalation became widely known as "read terrorism" among Chinese workers. When the COVID-19 pandemic forced millions of students onto DingTalk for remote learning in 2020, they flooded app stores with one-star reviews, and DingTalk's rating collapsed from 4.9 to 1.4. The company released a video begging users for better ratings. This was the buyer-user split in action: the product had solved the buyer's problem precisely, and the people required to live inside it made that frustration visible. In enterprise software, that gap shapes which customers the company can serve next.
Lark Chose a Different Definition of Better
Lark, known as Feishu in China, is ByteDance's workplace suite, built initially as an internal tool and commercialized later.
DingTalk's dominant product thesis was that organizational efficiency came from managerial visibility, control, and execution. Its features reflected that focus: attendance tracking, read receipts, approval workflows, and organizational management tools.
By contrast, Lark was built for relatively self-directed knowledge workers inside organizations that believed efficiency came from shared context. Its underlying product thesis was that the purpose of a tool is to help people do the work, with management and governance supporting that work from behind. That did not mean eliminating administrative controls. Lark still included permissions, approvals, and enterprise governance, but those functions supported collaboration rather than defining the product's center of gravity.
A Chinese enterprise-software analyst described the contrast as "transmission of responsibility" versus "flow of context." Feishu's own marketing slogan captured the orientation: "advanced teams use Feishu first." These two products were optimized for different customers.
PBN applies to Lark too, with a different customer and work model at the center.
- The Proven elements were already established categories: enterprise messaging, collaborative documents, meetings, calendars, knowledge bases, and structured workflow tools. ByteDance's explosive growth provided internal proof that these capabilities needed to work as one connected system rather than as separate applications.
- The Better was continuity across tools, going beyond simple consolidation. Chat, documents, meetings, calendar, wiki, and Base (a lightweight database-and-workflow tool) lived in one system, reducing handoffs and preserving context as work moved between them.
- The distinctive New was the depth of the integration: live collaborative documents inside chat threads, a native knowledge base, and structured data linked to conversation and documentation. That degree of first-party integration differentiated Lark in the Chinese market.
Lark's customer roster came to include established tech companies and manufacturers such as Xiaomi, Anker, and Ecovacs, where complex, cross-functional work is coordinated across distributed teams. These were organizations with paid enterprise contracts, not the free-tier SMBs that formed DingTalk's initial base. Lark reported ARR approaching $300 million by 2024, according to CEO Xie Xin, offering evidence of substantial willingness to pay. Its definition of Better helped shape the customers it attracted and the economics it could support.
The Blind Spot in the PBN Framework
The Struggle to Commercialize
DingTalk started as a small team project inside Alibaba and grew into one of China's largest workplace platforms within two years, operating with significant autonomy under Chen Hang. DingTalk had been free for six years, enormously successful in user adoption but with no clear path to monetization.
In 2020, Alibaba folded DingTalk into its cloud division and pushed it toward commercialization. Chen Hang was moved out of DingTalk's operating leadership and left the company the following year. DingTalk's strategic focus shifted from serving small business owners to winning large enterprise customers and generating revenue for the cloud business.
By then, Lark had been commercialized since 2019, was gaining traction with exactly the kind of organizations DingTalk now needed, and had crossed $100 million in ARR by 2022. DingTalk became a package add-on in Alibaba Cloud deals, losing its independent product identity. In 2023, the commercialization strategy was reversed and DingTalk was separated from Cloud again.
The resistance ran deeper than product features. One venture investor told EqualOcean that DingTalk was so tailored to Chinese SMB management culture that none of the foreign companies operating in China had adopted it. In larger organizations where employees had a voice in tool selection, DingTalk's reputation worked against it.
When a Winning Position Hardens
The customers DingTalk pursued wanted what Lark was already built to provide: collaboration tools, shared context, and knowledge flows across distributed teams. DingTalk's core value proposition was management visibility and control, and larger, more operationally mature organizations were less likely to see that as their primary reason to adopt a workplace platform.
Each obvious path forward carried a real cost. Preserving DingTalk's identity meant accepting the economics of its existing customer base. Softening the management features meant alienating the buyers who had adopted the product for those features and built their own operational processes around them. Adding collaboration tools would broaden the product without changing the management-and-control logic at its center. Competing directly on Lark's terms meant entering dimensions where the challenger had accumulated years of product, customer, and organizational advantage.
DingTalk's upmarket struggle had many causes: pricing, sales execution, competitive timing. But the product thesis shaped how each of those played out. DingTalk's team had spent years prioritizing management workflows and solving visibility problems for small business owners. Its distribution attracted SMBs who expected free tools. Its installed base created pressure to preserve the features customers already relied on. Culture, customer identity, and internal assumptions about what the product was for all reflected the original definition of Better, and those are the layers an org chart cannot easily reach.
DingTalk was trapped by the specificity of its success.
Zynga: A Similar Arc
Mark Pincus's own history at Zynga also demonstrated how early success became a constraint.
Zynga's early success was inseparable from Facebook's social graph and distribution system; in its IPO filing, the company warned that it generated substantially all of its revenue and players through Facebook. When Facebook changed the mechanics that had powered social-game growth, Zynga faced a difficult and prolonged transition to mobile. Zynga's advantage on Facebook compounded into a dependency the company spent years trying to escape.
This is the moment the two source materials clicked together for me. The YouTube video treats DingTalk's constraint as a story about one company and its choices. Pincus's PBN framework treats product wins as a replicable pattern. Between them, I could see something neither one described on its own: winning with one definition of Better makes it genuinely hard to adopt another.
What PBN Misses
PBN has two blind spots that the DingTalk story exposes.
The first is the buyer-user split. This is very common in enterprise software: one group selects and signs the contract, another administers the system, and a third frontline group uses it every day. Pincus's ten-out-of-ten test works when those roles collapse into one person. When they separate, "Better" fractures. DingTalk's buyer wanted certainty, visibility, and control. Its daily user absorbed the weight of design decisions: the traceability of their every action, the accountability attached to every unread message. This helps explain the natural pushback from its end users and the resistance DingTalk encountered as it moved toward larger organizations.
The second is that PBN is a snapshot. The framework helps identify a winning product thesis for a given customer, but it does not tell you when to re-examine that position as your customers and market change. DingTalk's shift from SMBs to enterprise customers was exactly this kind of transition. Everything the company had learned to build, every customer it had attracted, every metric it had optimized, all reflected the original definition. By the time DingTalk needed a new segment to see it differently, its product, team, distribution, and installed base had all been shaped by years of serving SMB owners who wanted management control.
Final Takeaway
What I want to keep from this is not another letter, but a habit: treat every definition of Better as temporary. Ask who it serves, and revisit the answer before the market forces you to.
PBN can help a product find a winning position. It cannot tell you when that position has become a constraint.