Plan a Phone Version of Word With Live Co-Editing, Offline Sync and Conflict Merging

As a product manager at Microsoft, you are asked to design a mobile (phone) version of Word and to make sure several people can edit the same document together, in real time, from inside the app. Treat this as a technical product question: cover both the product decisions and a sound explanation of how real-time collaboration would work and stay reliable on phones. ### Clarifying Questions - Is the phone app meant to be a full editor, or mainly for reading, reviewing and light edits, and must it open every document the desktop app can? - Does "real time" mean everyone sees each other's changes within moments, and can collaborators include people outside the author's organization? - Must the app keep working offline, for example on a flight, and merge the edits when it reconnects? - Where do documents live: only on the device, or in cloud storage that the phone app and the desktop version can both reach? ### Part 1 — Shape the mobile Word experience Decide who the phone app is for, what they need to accomplish on a small screen, and which capabilities make the first version. ```hint Phones change the job Think about the moments when someone reaches for Word on a phone instead of a laptop, and what the screen, keyboard and connection make hard. Let those moments decide what to cut. ``` #### What This Part Should Cover - A target user and the specific moments they use Word on a phone. - Mobile constraints (screen, input, connectivity, battery, storage) and how they shape the feature set. - A prioritized first-version scope, including what is deliberately left out. ### Part 2 — Make real-time collaboration work Explain how simultaneous editing works end to end: how changes from different people are combined, how collaborators see one another, what happens on a weak or lost connection, and how you would know the system is healthy. ```hint Two people, one sentence Picture two collaborators typing into the same paragraph at the same instant while one of them loses signal. Your design has to define what each of them sees afterward. ``` #### What This Part Should Cover - A method for merging concurrent edits without losing anyone's work, compared with simpler options. - The architecture at the level a PM must be able to defend: clients, the service that orders edits, storage, presence and permissions. - Offline and reconnect behavior, failure handling, and the metrics that show collaboration is working. ### What a Strong Answer Covers - A phone product built around specific user moments rather than a shrunken desktop app. - A correct, plain-language explanation of concurrent editing and conflict resolution. - Handling of phone realities: unreliable networks, the operating system suspending background apps, battery and data use. - Security and access control for shared documents, including outside collaborators if they are in scope. - Success metrics with guardrails such as lost edits and document corruption. ### Follow-up Questions - Two collaborators edit the same table cell while one of them has been offline for an hour. What does each see when the offline person reconnects? - How would you roll out real-time co-editing safely across a huge base of existing documents? - Usage data shows most phone sessions are read-only. Does that change your roadmap?