How do you build an internal product for 14 diverse departments?

Building a shared scheduling system across an institution that ran on spreadsheets, email chains, and fourteen different mental models of the same process.

The Whitney coordinates more than 1,500 events annually across 30+ spaces. Scheduling relied on a patchwork of spreadsheets, email chains, Outlook calendars, and department-specific workflows. While everyone participated in the same operational process, each department understood that process differently.

The museum needed a unified scheduling platform. Before building software, however, we first needed to understand how work actually moved through the organization.

I helped define the MVP, map operational workflows, author the roadmap and requirements, and align stakeholders and engineers around a shared vision for the platform.

Different teams held different mental models of the scheduling process. Before deciding what to build, we needed a shared understanding of how scheduling should work across the organization.

• Define the MVP around a real workflow

  Rather than starting with feature requests, I mapped the end-to-end lifecycle of a Free Friday Night event—one of the museum's most operationally complex recurring programs. Using a real event allowed us to identify what functionality was truly necessary for launch and avoid building for edge cases too early.

• Build shared understanding before building features

  I created workflow diagrams and system maps that translated operational processes into a format stakeholders and engineers could both understand. These artifacts became a shared language across teams and reduced ambiguity throughout development.

  Fig. 01

  

• Prioritize dependencies over requests

  Not all requested features were equally foundational. I mapped technical and operational dependencies across the system and used them to sequence development work, ensuring that critical infrastructure was established before dependent workflows.

  Fig. 02

  

• Design adoption into the product process

  During my final product presentation, the CIO asked a question that every PM eventually faces: "How are you going to get people to adopt this?" My answer was that adoption had started months earlier. Rather than designing the platform in isolation, I involved stakeholders to co-create throughout discovery, workflow mapping, prioritization, and user acceptance testing. By hosting dozens of conversations and prototype reviews, stakeholders became active contributors to the product rather than passive recipients of enforced change.

  I also used AI-powered prototyping tools to rapidly visualize ideas and workflows, making abstract concepts tangible and allowing stakeholders to react to something concrete much earlier in the process.

  By the time the MVP was ready, many users no longer viewed MUSE as a new system being imposed on them, but a system they helped create that they were eager for.

  Fig. 03

  

MUSE is actively supporting museum scheduling operations and serves as the foundation for future workflow automation and event management capabilities.

Perhaps the strongest validation came from stakeholders themselves. After participating in the design process, many expressed surprise that the museum had ever managed scheduling without a unified platform.

Co-creation makes life easier.