Rift S: Launch Readiness

CONTEXT

Rift S was a new VR headset requiring evaluation of both hardware and system experiences ahead of launch. The team needed a structured way to assess readiness across the end-to-end experience and identify remaining user risks prior to release.

PROBLEM

How do we determine whether the Rift S experience is ready to launch, and what UX issues must be addressed before release?

MY ROLE

Led UX research for Rift S, owning the end-to-end software experience and coordinating closely with the Rift S hardware research team. Partnered with a quantitative researcher to develop the measurement framework and led its application in product readiness reviews.

APPROACH

IMPACT

Decision Support

Outcomes

Portal for Business: Product Strategy

CONTEXT

Portal was expanding beyond consumer video calling into business use cases. Multiple teams were exploring overlapping opportunities without a clearly defined product direction or shared understanding of the problem space.

PROBLEM

What role should Portal play in business environments, and how should the organization prioritize product development across competing opportunities?

MY ROLE

Led research to define the problem space, align cross-functional teams, and inform product strategy for Portal for Business.

APPROACH

Define the problem space

Align the organization

Prioritize and execute research

Example: Understanding the role of secondary screens in remote work environments

Activate insights into strategy

IMPACT

Established product direction

Aligned cross-functional teams

Scaled research as a function

Outcomes

VR System UI Redesign: UX Metrics Evaluation

CONTEXT

The system interface for Oculus was redesigned to help users access content more quickly and support future capabilities like multitasking. Early usability testing identified friction, but the expectation was that these challenges would diminish as users adapted to the new interface over time.

PROBLEM

Were early usability issues simply a function of unfamiliarity, or did the redesigned system introduce persistent usability challenges that would impact long-term experience?

MY ROLE

Led the evaluation of the redesigned system interface and developed a UX metrics framework to assess performance across key dimensions.

APPROACH

KEY FINDINGS

Usability challenges persisted beyond initial exposure. Core issues observed in early usability testing (e.g., getting lost, difficulty navigating) remained after extended use
Redesigned system underperformed relative to the original. All UX metrics for the redesigned system lagged behind the original interface benchmarks
Navigation was the primary driver of experience breakdown. Ease of navigation strongly correlated with: ability to find content, confidence using the system, and frequency of feeling lost
Directional signal vs. long-term potential. Despite friction, most still viewed the redesign positively, as a step in the right direction

IMPACT

De-risked full release of the redesigned system. Surfaced critical UX gaps, informing the decision to continue iteration before expanding to all usersChallenged a critical product assumption. Demonstrated that usability issues were not solely due to novelty and did not resolve with timePrioritized core system improvements. Identified navigation and information architecture as key areas requiring refinement which informed follow-up design sprintsEstablished a scalable evaluation framework Provided a structured approach for ongoing system measurement and iteration

Focus Areas

UX Metric Design • Mixed Methods • Launch Readiness • Product Decision-Making • Risk Communication • Stakeholder Alignment • Change Management

Context

Shortly after joining Oculus, one of the first initiatives I worked on was helping develop a UX Metrics framework for VR products. We wanted to move beyond qualitative summaries and provide product teams with a structured way to think about launch readiness.

The challenge was that there was no playbook. These interactions had never really existed before, so there were no industry benchmarks or established UX metrics to point to.
We built a mixed-method framework that combined observational research with survey metrics across 35–50 participants—much more rigorous than a typical usability study so we could build greater confidence in the results —and translated those findings into a launch readiness signal.

Our first version relied heavily on composite survey scores. Observations were documented alongside them, but the overall recommendation was largely driven by how participants rated the experience.

At the time, it felt like the right approach. Stakeholders wanted a clear signal, and we gave them one.

Implementing the UX Metrics Framework for a New Experience

The framework had worked well across several products before I applied it to a completely new input experience.

Unlike many of the other products I had evaluated, I conducted the metrics study for the new input mechanism before software was launch-ready. But the lab spaces were booked, recruiting was complete, and this would be our only opportunity to capture UX metrics before the product review. Product and eng acknowledged there were known technical issues but also noted they would be resolved before launch, and some signal would be better than no signal from UXR.

During the study, we observed people struggling with parts of the experience. At the time, it was difficult to separate friction caused by temporary technical limitations from friction caused by the interaction design itself. When evaluating launch readiness, the team reiterated that the remaining issues would likely be addressed before launch with technical refinements and moved forward with a launch-ready recommendation.
Then the product launched.

Post-Release Blowback

Not long afterward, leadership asked a difficult question.

"How did UX approve this?"

Reddit users and industry feedback indicated the performance was inconsistent, unreliable, difficult.

My stomach dropped.

We spend so much time building trust in UX research and trying to integrate it into product decisions. Hearing that question made me feel like I'd let the team down. So I went back to the data.

What stood out to me wasn't that we'd missed the problems. We'd documented many of them. The problem was that we couldn't accurately attribute the issues to user error or technical issues, and our framework communicated more confidence than the evidence supported.

Participants in our UX metrics study loved the potential of the experience. That optimism showed up in the survey scores. At the same time, our observations showed failures, workarounds, and confusion.

By collapsing those signals into a single composite score based on the survey data, we unintentionally allowed excitement to outweigh observed friction. Thus, we were measuring product quality as much as we were measuring a combination of optimism and novelty.

Rethinking the Framework

Rather than defending the framework, I wanted to understand where it had broken down.

I stepped back and reviewed our UX framework alongside the other readiness signals already being used by the organization. QA communicated launch health using clear red, yellow, and green indicators. Engineering readiness was evaluated independently. UX, meanwhile, was asking stakeholders to interpret a composite score while also reading pages of observational findings. The more I looked at it, the more I realized we weren't speaking the same language as the rest of the product organization.

So I redesigned the framework.

Survey scores stayed because they were still valuable. They provided us with a metric to benchmark and track over time, and allowed us to compare any change in data patterns between pre-launch metrics and post-launch metrics. Large deviations between patterns in pre/post metrics became an indicator that something unexpected had happened during or after release.

But the survey scores alone stopped being the headline. Behavioral observations received their own health indicator based on pass/fail scores, and considerations for issue severity. If someone couldn't complete a critical task, that could be enough to put that part of the experience in the red.

Instead of producing one overall score, survey and observation each received their own health indicator. When those signals disagreed, we didn't average them together—we made the disagreement visible and the overall product health indicator deferred to the lowest health score between survey and observational metrics

The goal wasn't to create a better score. It was to make sure the most important UX risks couldn't get averaged away.

Putting It Into Practice

Before rolling out the updated framework more broadly, I re-ran previous studies using the new methodology and then applied it to the next round of launch readiness work for the new input .

Survey scores changed only modestly, even when observational research showed that participants were completing tasks more successfully and with fewer breakdowns. The surveys weren't wrong, but they understated the magnitude of improvement we could see in users' behavior.

As usability issues were resolved, the overall UX health of the product improved. Our health indicators moved from red to yellow to green, not because every survey score increased dramatically, but because the highest-risk barriers to launch had been reduced. The framework reflected both user perception and observed behavior, giving us a more accurate picture of launch readiness.

The framework became a little more complicated for researchers during analysis, but much easier for product teams to understand. I spent time walking researchers through the new methodology, discussing why we had changed it, and helping stakeholders understand how to interpret the new health indicators.

Those conversations helped rebuild confidence that UX research wasn't just producing metrics. It was providing a more faithful picture of product readiness.

Reflection

Looking back, I'm proud of this work not because we got the framework right the first time, but because we were willing to improve it.

It's uncomfortable to have your work questioned, especially when that work influences product decisions across multiple teams. Instead of leading with defensiveness over the methodology, I treated the feedback as a design problem: if our metrics weren't reflecting the experience we were observing, they needed to improve.

Good research doesn't end with collecting evidence. It also requires representing that evidence in ways that accurately support the decisions teams need to make. Sometimes that means collecting better data. Sometimes it means building better ways to interpret the data you already have.

Want to Develop Your Own UX Metrics?

These are the principles I now use when designing UX measurement frameworks. Feel free to adopt or amend them as you see fit!

Focus Areas

Research Strategy • Product Discovery • Design Thinking • Workshop Facilitation • Assumption Mapping • Research Roadmapping • Stakeholder Alignment • Product Decision-Making

Context

The final team I joined at Meta was tasked with building a feature intended to increase awareness of the metaverse (yes, I know...). I'd chosen to join this team because I could already see the product risk. This was a top-down business initiative, and based on the research I'd previously conducted with VR owners and platform consumers, I wasn't convinced the strategy would resonate across the audiences we hoped to reach. I was always quick to join a 0→1 space. I found these kinds of product bets fascinating – high uncertainty, big assumptions, and no clear playbook.

I was met with a seemingly-straightforward research request: measure whether the new feature increased awareness of the metaverse.

I was immediately uncomfortable with the request. If awareness increased, what would that actually tell us? If it decreased, what would we learn? Neither outcome explained whether the feature created value, why people engaged with it, or what customer need we were actually solving.

A feature isn't a strategy, and measuring awareness alone wasn't going to help us understand whether we were building the right experience.

Challenging the Research Request

I shared those concerns with the product manager and continued raising them during team discussions by probing assumptions and encouraging the group to think beyond awareness as the sole research objective. The response surprised me. Our product manager assumed my concerns stemmed from not knowing how to measure awareness and offered to connect me with someone who could teach me. As someone who absolutely knew how to measure awareness, I found those conversations frustrating.

It became clear the product manager and I were talking past each other. She believed our disagreement was about methodology. I believed it was about whether we were asking the right question in the first place. She wanted to know whether the feature would move a business metric. I wanted to understand the assumptions connecting the feature to that outcome. Without understanding those assumptions, even a successful awareness study wouldn't tell us what to build next.

Rather than continuing to debate the research request, I took a "yes, and..." approach and suggested we step back to expand our research strategy.

Broadening the Conversation

Whenever I join a new product team, one of my first priorities is assimilating everything the organization already knows before collecting new data. Having previously worked across Instagram, Facebook, and Reality Labs, I was able to bring together existing knowledge about the different audiences this work could affect. I also invited researchers from established VR teams so assumptions that felt obvious to experienced VR researchers weren't invisible to the rest of the team.

The workshop wasn't designed to brainstorm solutions or force alignment around a feature. My goal wasn't to leave with answers—it was to leave with better questions.

Together, we stepped back and thought more broadly about the people we were designing for (and those who we weren't designing for but who would be impacted by our work all the same), the problems we were trying to solve, and the assumptions connecting our feature to the business outcome we wanted. We documented assumptions, identified hypotheses, and aligned on our unknowns.

Building the Research Strategy

The biggest outcome wasn't the workshop or even the research roadmap. It was creating space for the team to think differently before committing to a research strategy.

Instead of building a research plan around awareness, I built a learning plan around the assumptions carrying the greatest product risk. Measuring awareness remained part of the strategy, but it became only one piece of a much broader learning agenda. Over the following month, I investigated why people shared VR experiences, what information made shared content meaningful, how different audiences discovered experiences, and where our assumptions about customer behavior weren't supported by evidence.

Those studies immediately began shaping the roadmap. They influenced design concepts, exposed gaps between our business goals and customer expectations, and changed how we thought about the product's value proposition.

For example, we learned that short-form video wasn't always the sharing mechanism people wanted. Stories, communities, and richer contextual information better supported how existing VR users discovered and shared experiences. Rather than asking how to increase awareness, we started asking how to create more rewarding sharing experiences while exploring how to make VR content more meaningful for people outside the headset.

And in a great twist of fate, we never were able to execute the original awareness study. As it turned out, we couldn't create the experimental conditions needed to measure awareness. If awareness had remained our only research strategy, we would have had very little to guide the team's next decisions. Instead, we already had documented hypotheses, customer insights, and a roadmap grounded in the problems people were actually trying to solve.

Reflection

At times, questioning whether we should simply measure awareness felt like I was slowing the team's progress or introducing uncertainty that worked against an already established direction. In new product spaces, though, we're often building the plane while flying it. That requires a willingness to execute while continually questioning the assumptions behind the work and whether the product strategy itself still reflects what we're learning. As a researcher, you may be asked to evaluate a specific experience, but some of your greatest contributions come from helping teams refine strategic direction and future vision by grounding decisions in both business goals and human needs.

We started with one research request: Did this feature increase awareness? We left with documented hypotheses, prioritized learning goals, and a much richer understanding of the customer problems we needed to solve. Even when the original awareness study became impossible to execute, the work still provided a roadmap for what the team needed to learn next.

Those conversations weren't always easy. Product teams are often expected to execute quickly, particularly in new product spaces where momentum matters. Making room to question assumptions can feel at odds with that pace. In this case, taking the time to step back resulted in a stronger research strategy, a more durable roadmap, and clearer priorities for what the team needed to learn next.

Sometimes the highest-impact research isn't answering the original research request. It's expanding the conversation so teams can make better-informed decisions about what to build next.

Considerations for Developing a Discovery Mindset in New Product Teams

Focus Areas

Research Planning • Study Design • Product Strategy • Decision Making • Information Architecture • Card Sorting • Appropriate Rigor

Background

This is much less about a card sort and more about everything that happened before it.

At the time, I was supporting seven software workstreams across the Oculus system experience. I was technically embedded within the organization, but I still operated much more like an agency researcher, balancing multiple teams, research roadmaps, and stakeholder requests at the same time.

That model was atypical for our org but had real advantages. Working across so many teams helped me spot patterns, identify where strategies were beginning to diverge, and connect work happening across the organization. Some of the most valuable work I did during that time came from having visibility across the organization rather than deep visibility into one product area.

The tradeoff was context.

With so many workstreams moving at once, I wasn't always part of the conversations where product questions were first being defined. Sometimes I was brought in after a team had already aligned around what they wanted to explore.

One request kept resurfacing around redesigning the Settings experience for an upcoming headset launch. Compared to everything else on my plate, it didn't feel like the highest-risk product question, but it mattered to the team and continued to come up despite my pushback. Eventually I agreed to take it on.

Since it was my first large-scale card sort, I wanted to do it well. I talked with other researchers, read about best practices, and tried to anticipate where participants might struggle. Once I committed to the study, I wanted to execute it as thoughtfully as I could.

The Settings menu itself was highly technical, so I added plain-language definitions to the back of every card. The goal was twofold: help participants sort settings based on their intended purpose rather than unfamiliar terminology, while also collecting feedback that could improve the language itself. Rather than becoming just a card sort, the study also became an opportunity to evaluate taxonomy and content design.

I also chose to include the full set of settings rather than a simplified subset. As sessions progressed and participants struggled with the volume of information, I experimented with a more structured card sort to see whether clearer organizational patterns would emerge. By the end of the study, we were asking participants to reason through dozens of highly technical settings while simultaneously evaluating the language itself.

The study still produced useful findings, but looking back, the most valuable lessons had very little to do with card sorting.

Lesson 1: Your operating model shapes your research

Working across multiple teams gave me organizational perspective that I wouldn't have had as a deeply embedded researcher. It also made me more likely to respond to research requests than spend time helping shape them.

Had I been closer to the day-to-day conversations, I probably would have spent more time understanding what the team was actually trying to decide. Were we redesigning the information architecture? Improving labels? Solving a navigation problem? Those are very different research questions, even if they all begin with "improve Settings."

One of the biggest advantages researchers can bring isn't selecting the right method - it's helping teams better define the problem before selecting one.

Lesson 2: Scope the opportunity before you scope the study

The research inherited the ambiguity of the original request, and I responded by designing a study that tried to answer all of it. We wanted to improve information architecture, validate category structures, evaluate terminology, inform content design, and better understand participants' mental models—all within a single exercise.

Today, I probably would have challenged the request more strongly before designing the research plan. At the time, Settings wasn't one of the highest-risk launch questions, and the opportunity cost of spending several weeks answering a "nice to have" question across seven active workstreams was significant.

If the work still felt worthwhile, I'd start much smaller. I'd look at behavioral data, support issues, and key user tasks before investing in a larger information architecture exercise. A lightweight tree test or focused task evaluation likely would have narrowed the opportunity before asking participants to reorganize an entire system.

The lesson wasn't that card sorting was the wrong methodology. It was that a better-defined opportunity would probably have led to a better-scoped study.

Lesson 3: Every layer of complexity in study design should earn its place

Looking back, I don't think any of the individual design decisions were mistakes. Adding definitions helped participants interpret highly technical settings while also creating an opportunity to evaluate the language itself. Including the full set of settings reflected the team's desire to evaluate the information architecture as a whole. When participants struggled with the task, adapting the study design was a reasonable response to what we were observing.

The challenge wasn't any one decision. It was their cumulative effect.

Each addition increased participant effort, cognitive load, analysis time, and implementation complexity. But because the original opportunity hadn't been narrowly defined, there was no natural point to stop adding. The study continued to grow as we tried to solve each new problem we encountered along the way.

But, as a researcher, the goal isn't to design the simplest study possible or the most methodologically complete one. It's to find the point where additional complexity is unlikely to meaningfully change what the team learns or decides.

Reflection

The most important research decisions often happen before a methodology is selected. Framing the opportunity, understanding the decision a team is trying to make, and right-sizing the scope of the work often have a greater impact than choosing between one method or another.

Sometimes the best research decision isn't choosing a different method. It's reframing the opportunity before selecting one.

Focus Areas

Research Strategy • Pattern Recognition • Product Discovery • Thought Leadership

Context

Alongside developing launch readiness metrics for Rift S (the follow-up headset to Oculus Rift), I conducted longitudinal research into the first-month owner experience with a VR headset. The work combined pre-purchase discovery, Day 0 unboxing interviews, usability evaluations, diary moments, and follow-up conversations to better understand how people discovered content, learned the platform, and developed habits during their earliest experiences.

The research delivered what the team needed. We identified onboarding challenges, usability issues, friction points, and opportunities to improve the first-month experience. Those findings informed product priorities and created a clearer path for improving how new users entered VR.

As I spent more time with the research, one thread continued to stand out.

Across research touchpoints, participants consistently talked about Reddit, YouTube, Twitch, Discord, and other third-party communities. At first, those comments felt like useful context. People described where they researched headsets before purchasing, how they decided which games were worth buying, who they trusted for recommendations, and where they found people with similar interests.

The more I revisited those conversations, the more I realized community wasn't just influencing one part of the customer journey. It was present before purchase, shaped how people evaluated content, influenced who they trusted, and continued to affect how they discovered games and built relationships after they entered VR.

Because I've always been interested in the relationship between technology and human connection, I decided to pull at that thread a bit more. I pulled together evidence from across the research program and developed a separate point-of-view piece titled From Peripheral to Integral: How Building Community via 2D Apps Can Elevate Oculus Platform Value. (NB: very proud of this title - the year was 2018 and AI couldn't dream of this title. 😂)

The piece explored an opportunity that had surfaced throughout the research but hadn't been the focus of any individual research objective.

At the time, I was responsible for systems software and the platform experience. Community wasn't part of the team's charter, and there wasn't yet a dedicated social organization focused on this space. Even so, the work provided an end-to-end perspective on how off-platform communities influenced onboarding, discovery, purchasing decisions, and long-term engagement. It informed iterative improvements to the Oculus companion app while also giving newly forming social teams a customer-centered framework for thinking about community as part of the broader VR journey rather than as a collection of individual features.

Reflection

What I loved most about this work was that it represented my own perspective on something our team wasn't even talking about yet.

We align research roadmaps to product priorities, establish timelines and deliverables, and define clear research objectives. Those objectives matter. They create focus, help teams make decisions, and ensure research addresses meaningful business questions. The first-month research accomplished exactly that, and those recommendations moved the work forward.

At the same time, I think researchers occasionally need to give themselves permission to follow an interesting thread that emerges beyond the original brief.

Most recurring themes reinforce the story you're already telling. Every once in a while, one suggests there's another story worth exploring. Those opportunities rarely arrive as feature requests or roadmap items. More often, they begin as contextual details that continue to surface until someone decides they're worth exploring.

No one asked me to write the community point of view. It wasn't part of the research plan or my team's charter. It was simply an idea I felt was grounded strongly enough in customer evidence that it deserved another week or two of thinking. Strapped with a full workload of projects, it's something I felt passionately enough to make time for all while knowing that it could have gone nowhere or could have landed at the wrong time. In this case, it became a useful framework that other teams could build from as the organization expanded its investment in social experiences.

Lesson: Thought leadership doesn't always start with a blank page. Sometimes it grows naturally out of delivery work when researchers give themselves permission to keep asking questions after the original ones have been answered.

Looking Ahead

I hope this remains part of how we think about research as a field. It doesn't require another research project or weeks of additional work. More often, it's about building small moments of reflection into an existing practice.

Sometimes that means reviewing completed studies together rather than in isolation. Sometimes it's revisiting edge cases or contradictory findings that didn't fit neatly within the original objectives. Other times it's carving out a few exploratory questions alongside an evaluative study, maintaining a running list of recurring themes worth revisiting, or simply asking whether a pattern has appeared often enough to deserve a closer look.

As AI becomes part of more research workflows, I also think there's an opportunity to use it differently. Rather than relying on it to expedite a single study, I wonder what happens when we periodically step back and use it (blank slate without feeding it any context) to explore themes across months of work, challenge our own thinking, or identify observations that extend beyond the original research brief.

The goal isn't to outsource curiosity. It's to create more opportunities for it.

The roadmap should define where research begins. It doesn't have to define where curiosity ends.

Focus Areas

Foresight • Foundational Research • Systems Thinking • Organizational Alignment • Product Strategy

Context

Product spaces are constantly evolving. This is especially true in 0→1 environments, where teams are often building while simultaneously discovering what the product should become. (We often talk about building the plane while flying it but it’s more like drawing the map and building the plane while flying it.)

During my time in Meta Reality Labs, an organizational strategy emerged to evolve immersive platforms (VR in this case) from a gaming-centric platform into a general computing platform. There were many reasons this direction made sense. The technology was advancing, capabilities were expanding, and remaining focused exclusively on gaming would limit the platform to a specific market segment. Additionally, VR makes an excellent test bed for future AR experiences and AR/wearables would arguably be a more pragmatic form factor than gaming for VR. General computing felt like a natural extension of the value immersive technology might eventually provide.

VR product teams were already making thoughtful progress across the system experience, each focused on advancing its own part of the roadmap. References to the longer-term ambition of general computing would pop-up informally, but the individual roadmaps had not necessarily been developed from a shared understanding of what it all meant.

Working across seven different system workstreams gave me a unique vantage point. I began noticing that many product conversations referenced existing computing platforms as inspiration. Some teams looked to smartphones. Others referenced desktop operating systems, televisions, or gaming consoles. Each comparison made sense within its own context, but each was also based on assumptions shaped by different hardware, input methods, and use cases.

Supporting these workstreams allowed me to see something that none of the individual teams could. Not because their work was incomplete, but because no single roadmap showed how all of the decisions fit together.
What felt missing wasn't another feature study. It was a shared understanding of the relationship between computing needs, hardware form factors, input mechanisms, and the use cases people chose different devices to accomplish.

Rather than asking what VR should look like, I wanted to understand which computing needs were enduring and which interaction patterns were products of existing technology. If we could triangulate human needs, hardware capabilities, and input methods, we could make more intentional decisions about where immersive technology should follow established patterns and where it needed to develop new ones.

This wasn't an obvious research investment. I was already spread thin across the numerous teams, and the study I envisioned sat well outside of my immediate research roadmap. Also, besides one designer, there wasn't broad demand for this type of work because teams were understandably focused on their own features and the next iteration of the current platform.

The lack of support for the foundational research I envisioned was disappointing, but not surprising. I couldn't guarantee the research would influence the organization the way I hoped. I couldn't point to a business metric that would justify the investment in advance. I only knew that I could see a missing layer of shared understanding, and I believed in both the work and my ability to make something valuable from it.

I took the endorsement of my one stakeholder and presented the research plan to our head of research. I acknowledged that taking it on was my own risk. If the study distracted from my existing commitments or failed to create value, I would accept responsibility for that decision but I REALLY believed in this research and wanted to find a way to get it done.

The research was approved.

The impact was immediate and enduring. Why?

Strategic research creates shared frameworks that connect long-term vision to day-to-day execution.

On paper, this wasn't an especially remarkable study. It was a digital ethnography (or, less glamorously, a diary study and interviews) exploring how people moved between different computing devices throughout their day. The lasting value came from what I developed from those observations: a framework that helped the organization reason more consistently about the future of computing.

Few of the individual observations were particularly surprising. Most people intuitively understand that smartphones prioritize convenience and portability, computers enable greater precision and complexity, and different devices and input mechanisms are better suited to different tasks.

The value wasn't uncovering a hidden truth. It was organizing those observations into a shared framework that could be applied across decisions and organizational levels.

At the leadership and portfolio level, the framework supported conversations about the future direction of AR and VR, where the organization should invest, which input mechanisms should accompany future hardware, and what progress toward general computing could realistically look like within current technical constraints.

At the product-team level, the same framework could inform more immediate decisions. Teams could evaluate whether a proposed interaction aligned with the form factor, input mechanism, and customer need rather than simply recreating a pattern that worked on another platform.

The framework connected ambitious long-term vision to the product decisions teams were making every day. It didn't prescribe a single future for immersive computing. It gave the organization a more consistent way to evaluate different possibilities as the technology continued to evolve.

Foundational understanding remains valuable after execution begins.

In an ideal world, organizations would develop a shared understanding before investing heavily in solutions. In my experience working in 0→1 spaces, that is never how product development happens.

Teams are already building. Capabilities are emerging. Roadmaps reflect a possible future, even while the organization is still developing a stronger understanding of what that future should become. Strong beliefs, loosely held as we would say.

The framework wouldn’t replace the work already underway, but become the connective tissue between it. It gave our efforts a common foundation. Individual decisions could still reflect the needs and constraints of each workstream while contributing to a more coherent system overall.

Some questions deserve dedicated strategic attention.

Sometimes when I wax poetic about the importance of generative / foundational / strategic research, it’s questioned as “but can Courtney actually do the tactical and evaluative work we need?” As I’ve mentioned previously, I’m a strong believer that strategic insights can emerge from tactical research over time. Researchers can and should look across usability studies, evaluative work, and ongoing product research for patterns that extend beyond the original questions being studied.

But, there are also times when a foundational question deserves focused attention.

When an organization is entering a new product category, defining an emerging platform, or making decisions that will shape multiple workstreams, waiting for a strategic framework to emerge incrementally may be less efficient and less comprehensive. A dedicated study can examine the relationships across products, customers, technologies, and decisions directly.

The distinction isn't between tactical research and more prestigious strategic work. It is about recognizing what the organization needs. Sometimes the highest-value contribution is helping one team make its next decision. Other times, it is creating the shared understanding that connects decisions across an entire product portfolio.

Those are lessons from the research itself. But on a personal note, I also want to emphasize:

At times, you will have to be your strongest advocate.

One of the most challenging aspects of this work was advocating for research where I couldn't guarantee value in advance.

Again, the external concerns around my focus on this research were reasonable. I was already spread across seven workstreams. Teams had immediate execution needs. The study could have consumed time and vendor resources without influencing the organization in the way I believed it might.

In this case, I believed in the work, and I believed in my ability to make something meaningful from it. I couldn't allow the absence of guaranteed impact to prevent me from exploring an opportunity I thought would help the organization think and operate more coherently.

Looking back, I don't think every organization needs a dedicated strategic research initiative. But I do think every organization benefits from periodically asking whether it's solving individual problems, or building a coherent system.

In a time when our research timelines become more compressed, and tools to expedite become more abundant, I hope you still find space to integrate more strategic, foundational research initiatives where you can. Below are a few helpful thought starters to identify where this type of research could be most helpful (and, no, you don’t need to be overseeing research for an unsustainable number of product teams to identify the opportunity for this type of research - just talking to stakeholders and fellow researchers is enough!).

Signs your organization may benefit from foundational research