REA Reverse: The Art of Reverse Engineering

REA Reverse: The Art of Reverse Engineering

How to extract innovative inspiration from existing products

Most product managers stare at the release pages of competing products and see "collaboration has been added","offline support has been provided" and "editor has been rewritten." What people who really understand REA see is that they replaced CRDT with self-developed Yjs fork in order to achieve real-time collaboration, refactored the write path of IndexedDB three times to offline, and threw away the virtual DOM for editor performance. Instead, they used canvas to render directly. The former is copying operations, and the latter is dismantling the engine.

REA (Reverse Engineer Anything) is not a tool, but a thinking framework that restores a "finished product" to a "decision chain." Regular competitive analysis stops at the function list: what does the other party have, do I have, and whether to follow up. REA digs three more layers: What are the architectural constraints behind this feature? * Why is the data model designed this way? The most critical thing-what compromises did the business model force them to make? Notion's block editor looks elegant, but from the perspective of REA, it is reversed by the "everything is block" data model: in order to allow databases, kanban, and calendars to share the same set of storage, the editor state has to be flattened into a flat tree, at the expense of locking the performance cap in complex nested scenarios. Obsidian does not follow this path, giving priority to local Markdown files, in exchange for the barbaric growth of the plug-in ecosystem and a commercial moat of synchronized services. The same "notes" track, two sets of structural decisions, and two business destinies.

Figma's multi-person collaboration was not copied from Google Docs. When the Dylan Field team did REA in 2016, they discovered that Docs 'Operational Transformation (OT) relied on centralized servers for authoritative sequencing, which was delay-sensitive, poor scalable, and almost unusable offline. They gambled on the company's destiny for four years: WebGL over Electron, CRDT over OT, WASM over Rust core over pure JS. In the past four years, no user-visible features have been released. It is all architectural reverse engineering-the product requirement of "real-time collaboration" has been disassembled into the technical decision tree of "conflict free copy data types + deterministic rendering pipelines + local priority synchronization protocol." When it was launched in 2020, Figma's median collaboration delay was 50ms, and Docs's was 200ms+ during the same period. This is not functional imitation, it is turning the "must-have" of competing products into one's "don't need".

The opposition will say: Isn't this an enhanced version of competing product analysis? Textbooks have long included "dismantling competitive product value propositions" and "benchmarking core user journeys". The difference lies in granularity and causal chain . The output of competitive product analysis is "They have collaboration, and we have to do it too"; the output of REA is "They use CRDT to solve collaboration, at the expense of tripling memory usage, 2 seconds of initialization delay, and the mobile terminal needs to be preloaded. Our team has 5 people, 80% of users are mobile, and the budget is not enough to buy large-memory models, so we don't do full CRDT, but instead use a lightweight merge based on operation logs, and accept a 5% conflict rate to be resolved manually." The former is a wish list, and the latter is an executable engineering contract . I have seen too many teams write "Figma has collaboration" into the PRD, and finally create a half-baked function that delays 3 seconds and loses all data in conflicts, which will be rewritten three months after it goes online. REA forces you to calculate the "price" before you start writing.

There is a startup that makes online whiteboards and its founder is a former Figma employee. They REA Miro, FigJam, and Excalidraw, and found a counter-intuitive commonality: the canvas rendering layers of all header products finally converged to "off-screen Canvas + dirty rectangle incremental update + WebWorker decoding pictures." Not because this technology is the coolest, but because of the browser's hard upper limit on the number of DOM nodes (~ 1.5 million) and the 16ms budget for the main thread, which is physically unavoidable. Instead of copying this stack, they asked: If we only serve a single scene of "conference room whiteboard", with a peak number of users of 20 people, canvas elements of < 5000, no need for infinite zooming, and no need to export PDF, can we change it to a simpler architecture? The answer is: Just use SVG + requestAnimationFrame, saving three months of engineering investment to polish voice transcription and action playback in "conference mode". Half a year after launch, the ARR ranged from US$0 to US$2 million, with a team of 4 people. REA does not let you build stronger engines, it lets you clearly see the terrain before deciding whether to build a car or ride a horse.

The most ruthless part of this methodology is not the technology, but the people. PM who are accustomed to using the "competitive product analysis template" have grown into "finding gaps → filling in pits". If you use REA for a long time, your muscles will grow into "looking for constraints → choosing trade-offs." The former turns the products into functional supermarkets, and the latter turns the products into optimal solutions under specific constraints. I know a PM who worked on REA review for two years. Later, he moved to a large factory to bring new business. At the demand review meeting, he no longer asked,"Does competing products have this button?" Instead, he asked,"If we don't make this button, users will use it. What stupid way to get around it? How much does that stupid method cost? How many engineering days are we willing to spend to reduce this cost?" This is how tools reshape users: REA turns "copying homework" into "doing problems" and turns "followers" into "finding shortcuts in holes dug by others."

So don't think of REA as "how to copy it more like". It is a scalpel that cuts through the compromises and costs under the shiny release page, allowing you to know before starting work: Can the foundation of this bridge withstand my motorcade? Figma spent four years building the foundation, and you might only need a temporary bridge-but only if you first steal their foundation drawings and understand row by row why each steel bar is tied there. Innovation never grows out of thin air. It is by standing on other people's shoulders and seeing clearly what mud they are stepping on before they dare to step more steadily.