Firebase Studio: Chat Unification
Product Manager 2 · Google · Mar–Sep 2025
An open-ended charter turned into a clear product strategy, a two-phase roadmap, three shipped milestones, and a more efficient architecture for carrying context across conversations.
The Question
What does "unify the chat experience" actually mean, precisely enough to build?
Context
The charter arrived genuinely open-ended: make the experience feel more seamless, without a defined scope, sequence, or even a shared definition of what "unified" meant. There was a product to improve, but the first problem was figuring out what the problem actually was.
The Constraint
"Unify the experience" sounded simple. It wasn't. The UX problem was only one layer. Underneath it was an architectural question: how do we make context move across conversations without making every new conversation carry the full weight of everything that came before? The existing IDX architecture and the newer Firebase Studio architecture had different assumptions around how the development environment and VM were loaded, which made context, memory usage, and token consumption part of the product problem, not just implementation details.
My Hypothesis
I initially treated chat unification as one problem. It wasn't. There were two distinct product problems: unification (making the chat experience itself feel like one coherent product) and context sharing (letting useful context travel with the developer as they moved between conversations and tasks). But context sharing couldn't simply mean "send everything everywhere." We had to be deliberate about what context was worth carrying, what could be reconstructed, and what should stay behind, balancing continuity with memory and token efficiency.
What I Tried
The experience and the architecture had to evolve together. The existing IDX approach and the Firebase Studio approach differed in how the underlying development environment and VM were loaded, which affected when information was available, what could be kept in memory, and how much context could be passed into a model. So the product question became: "How do we make the experience feel continuous without making the system carry unnecessary context?" That led us to think about context as something to selectively retrieve and pass forward, rather than blindly preserving entire conversations. The goal wasn't maximum context. It was the right context.
The Decision
Scope before building. Rather than let the scope emerge through implementation, I turned the ambiguity into a sequence of buildable milestones: Phase 1, Unification, to create one coherent chat experience, then Phase 2, Context Sharing, to carry relevant context across conversations and tasks. This sequencing mattered: it gave the team a smaller problem to solve first, created a foundation for the next phase, and made progress measurable instead of subjective. It also let us separate the UX problem from the deeper context and architecture problem rather than trying to solve everything simultaneously.
The Build
A two-phase roadmap spanning three milestones. Phase 1, Unification, brought the different chat experiences into one coherent interaction model. Phase 2, Context Sharing, made relevant context available across conversations without unnecessarily duplicating conversation history, consuming memory, or inflating model tokens. The work meant thinking across three layers at once: user experience (what should feel continuous to the developer), system architecture (where that context should live and how it should move), and AI efficiency (the minimum useful context needed to produce a good response). I also turned the work into something other people could use: a technical session at the I/O Watchstream, a GDG Mumbai session reaching 1,200 developers, and a hands-on workshop for about 50 PMs at Cloud PM Summit India 2025.
The Evidence
Both phases, Unification then Context Sharing, delivered across three shipped milestones. The work reached over 1,200 developers through one GDG Mumbai session, and about 50 product managers through a workshop at Cloud PM Summit India 2025.
What Changed
A sentence that started as "unify the chat experience" became two concrete product problems, a sequenced roadmap, three shipped milestones, and an architecture designed around selective context rather than indiscriminate history. The important outcome wasn't just what we built. It was turning ambiguity into something the team could execute against, while making the underlying system more thoughtful about memory and model context.
What I Learned
Ambiguity is often a product problem before it is a product constraint. And in AI products, UX decisions don't stop at the interface. A seemingly simple request like "remember what happened in the previous conversation" quickly becomes a question about architecture, memory, tokens, latency, and what information is actually worth carrying forward. The best product decisions happen when those layers are considered together. And teaching the result is a surprisingly good test: if you can't explain the product simply to 1,200 developers or a room of PMs, you probably haven't understood it simply enough yourself.