Experience-Led Product
Overview:
I collaborated with peer leaders to define new ways of working that prioritized inclusivity, transparency, and putting user experience at the forefront. I also worked to integrate academic product design and software development processes in ways that were accessible to all stakeholders and my colleagues on the product team.
The idea of software design and development was new at the university. However, in previous years, they had established ways of doing things, rules, and workflows for creating new academic offerings and related experiences. As a newly formed organization responsible for both software and academic offerings in higher education, we realized the importance of finding new ways of working that would include and be accessible to both groups of experts. We also wanted to be open and clear with stakeholders who didn't have much experience in software development.
Through early user research with academic teams, we discovered that the existing academic development process was isolated and inflexible. Even though individual team members wanted to explore new and innovative ways of working, the university was going through a major technology transition, which made it challenging to make significant changes to the existing systems and processes.
When we spoke with individual team members from various academic departments, we learned that despite feeling stuck in the current system, they were still thinking about ways to make things better in the future. Whether they had written it down or not, they had put a lot of thought into what their ideal systems and processes should look like down the road.
The Opportunity & Solutions
My Challenge:
To collaboratively design and establish new ways of working that enabled effective software development, while being inclusive of academic teams, transparent with the larger university, putting the experiences of our learners first, and generating a shared vision for the future.
Narrative-led Development
While many of the teams used different terminology and processes - from engineering to academics - we identified storytelling as the common thread between all. By generating a shared experience vision through a narrative story, we would be able to ensure that all teams and stakeholders shared the same vision for the end result in their minds. Parts of the story would help engineering and design teams chunk work into epics and requirements, while character arcs and flows would help academic teams define processes and workflows. Releases could be defined by smaller, more focused “chapters” in the larger narrative of the ecosystem, helping all stakeholders understand how the release fit in the larger picture.
Experience First
Many product teams today have catch phrases to describe how they work (eg: “the product manager is CEO of the product”, or “we’re design-led”) but each of these is problematic because they emphasize one group of people above others. In turn, this can cause tension on a team and disrupts the balance between product, engineering, and design - difficulties our team struggled with in the beginning.
To counter this effect, we focused on processes that were “experience first”, meaning the experience of the user was most critical in design & development decisions. By making user experience everyone’s responsibility, we were able to unite teams around a common mission and purpose and build more effective products.
Pods, Squads, and New Processes
To establish collaborative, cross-disciplinary ways of working we piloted several iterations of pods and squads. At first, pods were cross-disciplinary groups that were intended to research and build recommendations around feature sets or functions of the future ecosystem, but we found that the scope was too open ended. Later iterations of pods focused on specific questions like “AI for content creation” that directly informed sticky problems in ecosystem design.
Squads, on the other hand, were focused on iterative releases in the larger ecosystem. These cross-disciplinary teams of product and academic leads moved releases through problem definition, concept development, epic and requirements writing, and into architecture.
Finally, the design and learning design teams picked up those epics and delivered iterative work in collaboration with the squad to design solutions to identified needs. Through this layered process, we were able to open doors to participation at many levels of the org and ensure equal ownership of the product across teams while delivering work that was experience-first.
Results & Outcomes
My work on strategic communication assets ensured product leaders and individual contributors from across the full organization were deeply engaged in the discovery and planning work of ecosystem releases, resulting in higher engagement and vision alignment between different teams with different expertise.
I led initiatives to ensure experts outside of the product org had transparency into our work and clearly defined avenues through which they could participate and lend their expertise. I established strong relationships beyond the product team and actively sought external perspectives into my work.
Through my efforts, academic and product colleagues were able to establish a common language and ways of working that made each of their spaces and processes accessible and understood by the other. This generated work that considered more holistic solutions, better user experiences, and accounted for the complexities of academic governance and regulation without slowing innovation.