EP2. What Does a PRD Mean to a Service Planner? : Sharing Air Cloud’s PRD
- Aieev
- Jul 7
- 4 min read
Updated: Aug 17
Hello! 🐥I’m Yuna, a service planner on AIEEV’s Business Team, continuing to grow through hands-on project experience.
In the previous post, I shared the starting point of Air Cloud’s planning journey and how we defined its core functions.
Today, I’d like to talk about the next stage: service concretization and the actual process of writing a PRD (Product Requirements Document).
“Is this really the feature customers want?” “Can we implement this now? But if we don’t, the service won’t work...”
These are worries that every planner experiences at least once. I was no exception. In this post, I’ll share how I worked through these questions and the solutions we reached.
I hope this story offers reference points and empathy to startup practitioners building and applying AI models, as well as planners designing service flows. From here, let me take you through the planning journey of how Air Cloud became a real, functioning product. 🙂
1. Service Concretization: How Will Users Actually Use This Platform?
As shared in Episode 1, Air Cloud began as a response to the GPU cloud pain points faced by early-stage AI startups, SMEs, and developers. After defining personas and identifying core functions, the next big question was: “How will users actually use this platform?”
Based on insights from customer interviews, our goal was to design a usage flow with the lowest possible entry barrier—so that even those with little DevOps experience or limited familiarity with cloud settings could use the platform with ease.
So in our initial planning meetings, we centered discussions around questions like:
What information should we show first when a user logs in?
How many steps should the GPU container deployment process have so it doesn’t feel overwhelming?
Where and how should billing-related information be displayed?
From this, we derived an overall scenario of Onboarding → Container Setup → Deployment Completion → Monitoring. For each step, we defined the required UI elements and core functions. After multiple rounds of feedback with the development and business teams, we finalized the structure as follows.
The final information architecture was documented so it could be applied directly in development, with detailed functions and information defined at each page depth.
From there, to enable smooth communication between planners and developers, we refined the format of our handoff documents and officially began drafting the PRD.
Writing the PRD
A PRD is a functional definition document for service development. Our goal was to ensure that planning intent and technical requirements were communicated clearly.
One particularly useful reference was:
Since Air Cloud itself was born not just from listing functions, but from addressing GPU users’ questions around cost efficiency and convenience, we found the template structure (Overview → Problem → Requirements → Success Metrics) directly applicable to our PRD writing.
We classified each function according to implementation priority:
P0: Must-have core features (e.g., GPU container deployment, Auto-Scaling configuration, real-time monitoring)
P1: Features that significantly improve usability (e.g., team invitations, project management tools)
P2: Features excluded for now but considered for future updates (e.g., multi-region settings, API key encryption)
P?: Features with flexible implementation or experimental scope
Based on the information architecture (IA) defined earlier, we organized the detailed functions for each page unit according to this priority system. IA was not just about menu structure—it focused on which functions and information needed to be placed on each page. Using this, we collaborated closely with planning, development, and design teams.
To support planner–designer–developer communication, we used Figma and Notion together, adding comments at the screen level to clearly convey planning intent.
Red: Requested changes
Green: Reflected/Completed
By visually marking feedback this way, we continuously improved screen flows and layouts for features defined in the PRD.
During PRD writing, my biggest internal debate was: “Do we really need this feature right now?”
At the start of planning, I wanted to include as many functions as possible. But with limited development resources, decisions had to be made about what to build now and what to postpone.
For example:
Real-time monitoring was essential, but overly customized UI was assigned to P2.
GPU Saving Plan was fully designed, but since the policy wasn’t finalized, it was reserved as P?.
The reason I could make these decisions quickly was that customer interview insights were clear. Once again, I realized that a PRD must start with the customer’s words and context in order to become a truly “living document.”
3. Conclusion: What Does Air Cloud Offer Today?
Through this process, the launched version of Air Cloud includes the following flows:
Minimized entry barrier: After sign-up, basic settings are completed immediately → GPU container creation
5-step deployment: Image selection → Environment variable input → Auto-scaling configuration → Repository linking → Deployment
Serving URL provided: Automatic generation of URLs for external API integration
Real-time dashboard: Visualization of GPU usage, billing forecasts, and performance metrics
Thanks to this, even early-stage AI startups with limited technical staff can deploy AI models without DevOps experience and manage both performance and costs in a stable way.
After four months of trial and error, Air Cloud’s planning process was finally complete. I hope sharing this journey provides some help to planners facing similar challenges and to startup practitioners preparing AI services.
Air Cloud will continue to evolve by incorporating diverse customer feedback. Both the product and I will keep growing step by step, and I’ll keep striving to deliver even better outcomes 💪.
For those interested in trying out Air Cloud, the service I participated in planning, we are offering a special promotion: two weeks of free PoC validation, plus cloud optimization consulting and training.
If you sign up within 10 seconds here 👉 https://www.aieev.com/contact, we’ll reach out individually within one day.
Edited by Biz & Strategy Team
Author: Yuna
Comments