I'm a PM on an AR project for a real estate developer. Stakeholders keep asking for features like "real-time lighting from the sun" and "hyper-realistic textures" that aren't feasible on mobile. How do I manage expectations and keep the project within the original Agile sprint goals?
3 answers
This is a classic "expectation vs. reality" gap in emerging tech. You need to show, not tell. Create a "Technical Constraints" document that compares what they see in high-budget movies vs. what a mobile processor can actually render at 60fps. I recommend setting up a "Visual Prototype" early in the first sprint. When they see the frame rate drop as you add those "hyper-realistic" textures, they usually understand the trade-off. Use your Sprint Demos to educate them on "Performance Budgets"—if they want a new feature, they have to decide what to take out to keep the app running smoothly.
Barbara, that's a good approach, but what if the stakeholder insists that a competitor has a "better-looking" app? How do you explain the difference between a "Pre-rendered 360 Video" (which looks great but isn't interactive) and "Real-time AR" without getting too deep into the weeds?
I always include a "Technical Feasibility Study" as the very first milestone in the project charter. It gives me a legal and professional baseline to point back to when the "Sci-Fi" requests start.
That’s a lifesaver, Nancy. Having that signed document during a steering committee meeting is the best way to shut down unrealistic scope creep before it derails the team.
Steven, I use the "Video Game vs. Movie" analogy. A movie (pre-rendered) can look perfect because it’s a fixed path, but a video game (AR) has to calculate every movement in real-time. I literally show them a 3D model in a viewer vs. the same model in the AR environment. Seeing the "Real-time" shadows move as they move the phone usually makes the lightbulb go off for them.