Four days to make a navigation idea tangible
We had four days to turn a navigation direction into something people could try. I focused on development; Ankit PMed the work and helped us decide what fit the time.
In June 2025, Ankit and I had four days to make a navigation exploration tangible. We were looking at a pane that had grown into a collection of destinations, tools, and ongoing work. The challenge was to make it easier to find things without trying to solve every navigation problem at once.
A four-day build
I focused on development: restructuring the navigation and adding most recently used (MRU) logic for agents, so the pane could bring useful work back into view. Ankit PMed the effort, worked through priorities with partner teams, and helped turn a broad set of ideas into a buildable plan.
Over those four days, I was heads-down in the code while Ankit handled planning and the conversations that kept the work pointed at a useful problem. We were pairing across technical UX and product management, and that changed how I thought about implementation. A feature can be interesting and still be the wrong thing to spend the next day building.
Choosing what not to build
We made explicit decisions about what would not fit. We left drag-and-drop reordering for pinned agents and notebooks out of the prototype. We also deferred the full install-an-agent, ask it something, and find it later flow, plus MRU behavior for notebooks. Each was a reasonable next step; none was essential to demonstrate the navigation structure we were trying to evaluate. Keeping that boundary clear was part of the design work.
A partnership that kept moving
When I was out for two days, Ankit stepped in and continued working on the prototype so it could support a follow-up presentation. Knowing someone had the context and could carry the work forward was generous, and it made the collaboration feel like more than a handoff between roles.
From prototype to public rollout
Later that year, Microsoft began publicly rolling out an updated navigation experience for the Microsoft 365 Copilot web app. It brought agents, notebooks, and recent chats into the navigation pane—areas we had explored in our prototype. The product has evolved since, but it was exciting to see a related direction reach people. The rollout was documented by Topedia.
What I learned
The project taught me that good technical execution starts before the code. I learned to ask more about the audience, the purpose, and what a review needed to answer; to negotiate scope around those answers; and to accept that a convincing prototype is often a deliberate slice, not a complete product. Four days was short, but it was enough to learn how much better the work gets when the tradeoffs are part of the conversation.
