Case Study · MoVA Realities · 2025
Defining the MVP for an AI-powered XR platform
I led product strategy, user research, and feature prioritization for MoVA Realities, turning a broad "Canva for XR" vision into a structured, engineering-ready MVP.
Context
The product we were planning was an AI-powered augmented reality platform.
MoVA Realities is building a no-code platform for creating and deploying immersive AR experiences, described by the team as "Canva for augmented reality." The target users are non-technical professionals: marketers building branded event activations, educators creating interactive lessons, and small business owners wanting to stand out at trade shows without hiring an AR developer.
The goal wasn't to ship code, it was to define the foundation: which features belong in the MVP, how they should be prioritized, what the system architecture needs to look like, and what the platform should feel like for a first-time user who's never touched AR tools before.
I worked on a cross-functional team of four, where I owned product strategy, user research, feature specification, and UX design.
The problem
A compelling product vision with no clear MVP definition.
The long-term Figma prototype for MoVA had everything: a dashboard, template library, drag-and-drop experience builder, analytics, deployment tools, a help hub, AI guidance, version control, real-time collaboration. It was an ambitious and well-considered vision.
But ambitious visions without a clear MVP scope create real engineering risk. Which features are actually necessary to launch? Which ones can wait? How do you sequence a build when almost everything feels important? And how do you keep the product grounded in user needs when you're building in a domain that most target users have never worked with before?
The team needed someone to translate the vision into a prioritized, engineering-ready plan. That was my job.
Discovery
Start with who, not what.
Before touching a single feature, I mapped the platform's real users. I identified three primary personas based on MoVA's target market, each with distinct goals, pain points, and product needs that would determine which features were essential versus aspirational.
Fast, branded, measurable
No coding skills. Tight timelines. Needs to run the same experience across multiple event locations and show ROI to stakeholders after.
Key needs: quick branding customization, one-click deployment, and engagement metrics.
Low barrier, high engagement
Limited time and tech skills. Needs to keep learners engaged without expensive hardware or a development team.
Key needs: pre-built training templates, drag-and-drop editing, QR/link access with no app required.
Professional quality, zero learning curve
No design budget or marketing team. Wants to compete with larger brands at trade shows without looking like they built it themselves.
Key needs: polished templates, self-serve customization, no technical prerequisites.
The pattern across all three was the same: these are competent professionals who will abandon the platform the moment it feels like it requires technical expertise. That single insight anchored every feature and priority decision that followed.
Approach
A prioritization framework, then scoping.
With user needs mapped, I built and applied a three-tier prioritization framework across all 20+ features the team had brainstormed. The goal was to separate what MoVA had to ship, what would make it better, and what could wait, and to have user evidence behind each call.
MVP cannot function without it
These features had to ship first. Examples: experience builder (drag-and-drop), template library, XR onboarding tutorial, basic analytics summary, deployment via QR/link, AI chatbot.
Improves usability, not required to launch
High value but not launch-blocking. Examples: recent projects carousel, AI-powered template suggestions, help & support hub, experience comparison panel in analytics.
Revisit post-MVP
Valuable long-term but expensive to build early. Examples: real-time collaboration, version control, AI preview generation, Magic Animate. High complexity, low initial user unlock.
I then authored the Requirements Analysis Report, detailing all functional and non-functional requirements required for each feature.
Alongside requirements, I created low-fidelity wireframes in Figma covering updated designs for the dashboard, template library, and experience builder, translating written requirements into layout references that the engineering team could actually react to.
Key decisions
The judgment calls that shaped the MVP.
Keep analytics in the MVP — but scope it hard.
Analytics wasn't an obvious MVP include. But when I looked at the primary users, marketers and educators who need to show ROI to stakeholders and clients, a basic metrics view wasn't a nice-to-have. It was the thing that would make the platform credible after launch. I advocated to keep it as P1, scoped tightly to project-level summary only: total views, average session duration, completion rate. The comparison panel could wait.
Elevate the onboarding tutorial from "nice-to-have" to P1.
Several teammates assumed the video walkthrough was a polish feature. I pushed back: for a non-technical audience building AR for the first time, a good first experience is the difference between activation and abandonment. First-time users who feel lost don't ask for help. They leave. I advocated to make the onboarding tutorial a launch requirement, scoped to a 1–2 min skippable video accessible directly from the homepage.
Reframe the AI chatbot as a platform hub, not a feature.
The chatbot was initially specced as a standalone help feature. When I built out the system architecture map, it became clear the chatbot touched template recommendations, help documentation, analytics interpretation, and onboarding. It was a cross-cutting concern, not a sidebar widget. I reframed it accordingly and flagged the integration dependencies for engineering to plan around before sequencing the build.
Defer real-time collaboration to P3.
Collaboration was technically compelling, but the complexity was disproportionate to early user value. The primary personas were solo creators, not teams. The cost of building it early was high; the unlock for MVP users was low. I recommended deferring it with a clear note to revisit once the core builder was stable and adoption patterns were clearer.
Tradeoffs & constraints
The messy parts that shaped the plan.
One of the harder parts of this project was balancing completeness and focus. MoVA's long-term vision was well-developed, which made it tempting to include features that felt important but weren't actually launch-critical. Keeping scope honest required consistently asking: does this serve a P1 user need, or does it serve a future state we haven't validated yet?
Another challenge was working across a team with different technical backgrounds and feature opinions. Prioritization decisions that seemed obvious from a user research perspective weren't always obvious to teammates who were thinking more about technical interest or product vision. Writing requirements for every feature helped make the tradeoff logic legible. When you can point to a specific user and their specific need, it's harder to argue for including something that doesn't serve them.
The system architecture work also surfaced complexity I hadn't anticipated. Features that seemed independent had more dependencies than the initial spec implied. Mapping those connections early changed the timelines of the roadmap and helped the team avoid planning a build order that would have created blockers mid development.
Impact
What we handed off.
This was a framework project, not a production launch. Success was measured by the quality of the planning artifacts and whether an engineering team could actually build from them. Here's what shipped:
Beyond the report, the team delivered low-fidelity Figma wireframes for the core user flows, a system architecture diagram mapping module dependencies, a feature analysis document with technical complexity estimates and dev time projections, and a prioritized development roadmap sequenced by tier and dependency order.
Reflection
Key learnings from 0→1 product work.
User stories are a prioritization tool, not just a format.
Writing requirements as user stories forced every feature conversation back to user value. "As a marketer preparing for a trade show, I want to publish my experience via QR code in one click, so I can set up on-site without needing a developer." That framing made it much harder for scope creep to sneak in disguised as good ideas.
Map dependencies before you set the roadmap.
I initially underestimated how interconnected the platform features were. The system architecture work surfaced dependencies I hadn't anticipated: the AI chatbot touching template recommendations and help docs, version control intersecting with persistent scenes and real-time collaboration. Catching those early changed the sequencing in ways that prevented planning mistakes. Next time, I'd do this mapping at the very start, not midway through.
Research gives you conviction in priority debates.
The hardest conversations on this project were about what not to build. The ones I felt most confident in were the ones where I had persona data and user need evidence to point to. Research gives you something to stand behind when priorities are being contested in the room.