Aviation Web Learning Lab
EN / ID
Theme

Module 1 - Day 3 of 3

Gemini Web Chat

Day 3: Refining Your PRD

Welcome to Day 3, the final day of PRD Writing! You have come a long way in just two days. Yesterday was the detailed route planning; today is the final flight planning review before the actual flight begins in Module 2. You will define the exact data fields for your database table, clearly separate what is in scope from what is out of scope, assemble all your sections into one complete document, and perform a build-readiness check to make sure a developer could actually build your app from this PRD. You will also review the complete PRD with Gemini for feedback and make final improvements. By the end of today, your PRD will be complete, polished, and ready for the Laravel build module. A developer should be able to read your PRD and know exactly what to build, with no ambiguity or missing sections. Open Gemini Web Chat and let's finish strong.

Step 1

Define the data fields for your database table

Concept

A paper maintenance log form has columns for date, aircraft registration, work performed, technician name, and sign-off. Your database table needs similar columns, but they are called "fields" or "columns" in database terms. Think of each field as one column on that paper form. Today you will define every field your maintenance_logs table needs, what type of data each field stores, and what it is used for.

Apply

Use Gemini to define the data fields for your maintenance_logs table. Copy the table into your PRD document.

Prompt

I am writing the Data Fields section of my PRD. I need to define the fields for a database table called "maintenance_logs". Please list these exact fields in a table: | Field Name | Data Type | Description | |------------|-----------|-------------| | id | integer (auto-increment) | Unique identifier for each log entry (primary key) | | aircraft_id | text | Which aircraft (e.g., registration number like "PK-ABC") | | date | date | When the maintenance was performed | | maintenance_type | text | Type: "routine", "corrective", or "inspection" | | description | text (long) | Detailed description of what maintenance was done | | technician_name | text | Name of the technician who performed the work | | status | text | Current status: "pending", "in-progress", or "completed" | | created_at | timestamp | When this log entry was created (automatic) | | updated_at | timestamp | When this log entry was last modified (automatic) | Please format this as a clean table. Do NOT add foreign keys, user references, or relationship fields. This is a single standalone table.

Expected Result

Your PRD should have a Data Fields table listing all 9 fields for the maintenance_logs table with their data types and descriptions. No foreign keys or relationship fields.

Troubleshooting

  • • If Gemini suggests adding foreign keys, user ID references, or relationship fields (like linking to a users table or aircraft table), do not include them. Your project uses a single standalone table with no relationships.
  • • Keep field names simple and beginner-friendly. "aircraft_id" is fine even though it is not technically a foreign key in this project -- it just stores the aircraft registration as text.
Step 2

Clearly separate what is in scope and what is out of scope

Concept

Every aircraft has a flight envelope -- clear boundaries for safe operation. Your project has boundaries too: things inside the envelope (in-scope) are what you WILL build, and things outside the envelope (out-of-scope) are things you deliberately will NOT build. This separation is crucial because it prevents feature creep -- the tendency to keep adding "just one more thing" until the project becomes too big to finish.

Apply

Use Gemini to create clear in-scope and out-of-scope lists for your PRD. Copy them into your PRD document.

Prompt

I am writing the Scope section of my PRD for the "Aircraft Maintenance Log" app. Please create two clear lists: **IN-SCOPE** (what I WILL build): - Create a new maintenance log entry - View a list of all maintenance logs - Update an existing maintenance log entry - Delete a maintenance log entry - Single database table (maintenance_logs) - Simple web interface with forms and tables - Basic form validation (required fields) **OUT-OF-SCOPE** (what I will NOT build -- even though they would be nice to have): - User authentication or login system - Multiple database tables or relationships - File uploads (photos, documents, attachments) - Search or filter functionality - Email or push notifications - API endpoints for external access - User roles or permissions - Dashboard with charts or analytics - Export to PDF or Excel - Mobile application Format as two clear sections with headings. Add a brief note explaining why the out-of-scope items are excluded (keep it simple: the project is for learning and must stay small).

Expected Result

Your PRD should have clear In-Scope and Out-of-Scope sections. The in-scope list has CRUD operations and basic features. The out-of-scope list clearly excludes authentication, multiple tables, file uploads, search, notifications, and more.

Troubleshooting

  • • If you feel the out-of-scope list is too restrictive, remember: this is intentional. A small, complete project you can be proud of is better than a large, incomplete project. Module 2 gives you 5 days -- every extra feature means less time to make the core work well.
  • • Do not move items from out-of-scope to in-scope. The scope was carefully designed to be achievable by beginners in the available time.
Step 3

Put all PRD sections together into one complete document

Concept

Before a flight, the pilot assembles all planning documents into one organized flight folder: the flight plan, weather report, NOTAMs (Notices to Airmen), and passenger manifest all go into one place. Now you will do the same with your PRD. Gather all the sections you wrote over the past 3 days and organize them into one complete, well-structured document.

Apply

Use Gemini to help you organize all PRD sections into a complete document. Make sure nothing is missing.

Prompt

I have been writing a PRD over 3 days. I now need to assemble all sections into one complete document. Please create a PRD document outline with these sections in a logical order: 1. Disclaimer (learning-only) 2. Product Summary 3. Target User 4. Problem Statement 5. Feature List 6. User Stories with Acceptance Criteria (4 stories: Create, Read, Update, Delete) 7. Page List 8. Data Fields (maintenance_logs table) 9. In-Scope 10. Out-of-Scope Please review this outline and tell me: - Is the order logical? Would you suggest a different order? - Is any important section missing from this list? - What would make this PRD easier for a developer to read? Do not rewrite my content. Just help me organize and check the structure.

Expected Result

You should have all 10 PRD sections organized into one complete document. The order should be logical and easy to follow for a developer reading the PRD.

Troubleshooting

  • • The order of sections can vary -- there is no single correct order. The key is that all sections are present and organized logically so a developer can read through them in sequence.
  • • Do not let Gemini add new sections that were not covered in the course. Your PRD should have exactly the 10 sections listed above.
Step 4

Verify your PRD has everything a developer would need to build the app

Concept

Before a flight, the pilot walks around the aircraft performing a final pre-flight inspection, checking every item on the checklist: fuel, oil, tires, control surfaces, instruments. Before building your app, you need to do the same with your PRD. A build-readiness check verifies that your PRD has everything a developer would need. If something is missing, the build cannot proceed safely -- just like a pilot would not take off with a missing checklist item.

Apply

Use Gemini to perform a build-readiness check on your complete PRD.

Prompt

Please perform a build-readiness check on my PRD. Review the complete document and check: 1. Is the application name and purpose clear? 2. Are all 4 CRUD features listed (Create, Read, Update, Delete)? 3. Does each feature have a user story? 4. Does each user story have testable acceptance criteria? 5. Are data fields defined for the maintenance_logs table? 6. Is scope clearly bounded (in-scope vs out-of-scope)? 7. Is there a learning disclaimer? Rate the PRD as either: - "Build Ready" -- all items above are present and clear - "Needs Work" -- list specific items that need to be fixed or added Be honest but encouraging. If something needs improvement, explain exactly what to fix.

Expected Result

Your PRD should pass the build-readiness check with all sections complete. If rated "Needs Work," fix the specific items before moving on.

Troubleshooting

  • • If your PRD is rated "Needs Work," focus on the specific items Gemini flags. Common issues: missing acceptance criteria for a user story, vague feature descriptions, or scope that is not clearly bounded.
  • • Do not add new sections or features to fix issues. Fix what you have -- make it clearer and more complete rather than bigger.
Step 5

Get a final review of your complete PRD

Concept

Before a student pilot's first solo flight, a senior instructor reviews the flight plan one more time. A fresh pair of eyes can catch things you missed because you have been looking at the same document for 3 days. Gemini can be that reviewer. Copy your entire PRD into Gemini and ask for constructive feedback.

Apply

Copy your complete PRD into Gemini and ask for a final review. Note any useful feedback.

Prompt

Please review my complete PRD as a helpful teacher. The PRD is for a beginner web development project called "Aircraft Maintenance Log." Here is my complete PRD: [PASTE YOUR COMPLETE PRD HERE] Please review and answer: 1. What is good about this PRD? What did I do well? 2. What could be improved? Be specific. 3. Are there any inconsistencies or contradictions? 4. Is anything important missing? 5. Overall, is this PRD ready for a developer to start building from? Keep feedback constructive and specific. Focus on clarity and completeness, not on adding more features.

Expected Result

You should receive constructive feedback on your PRD highlighting strengths and areas for improvement. This feedback will guide your final polish in the next step.

Troubleshooting

  • • Do not implement every suggestion Gemini makes. If it suggests adding features, pages, or expanding scope, politely decline -- your scope is intentionally small. Focus on clarity and completeness of your existing sections.
  • • If Gemini says the PRD is "too simple," that is actually a compliment for this project. A clear, simple PRD is exactly what we want.
Step 6

Make final improvements based on review feedback

Concept

This is the final checklist review before closing the flight plan folder. Just like a pilot makes last corrections to the flight plan based on the instructor's feedback, you will make final improvements to your PRD based on Gemini's review. Focus on clarity, consistent formatting, and fixing any issues the review found. Once this is done, your flight plan is complete and you are ready for the actual flight in Module 2.

Apply

Make any final edits to your PRD based on the review feedback. Ask Gemini to help with formatting and polishing if needed.

Prompt

I have my complete PRD for the "Aircraft Maintenance Log" project. I received some review feedback and made improvements. Please help me do a final polish: 1. Check that all headings are consistent (use ## for section headings) 2. Make sure there are no contradictory statements 3. Ensure formatting is clean and professional 4. Verify that all 10 sections are present and complete Here is my updated PRD: [PASTE YOUR UPDATED PRD HERE] Tell me if anything still needs fixing. If it looks good, say "Your PRD is polished and ready for Module 2."

Expected Result

Your PRD is complete, polished, and ready for Module 2 (Laravel Build). It has all 10 sections, consistent formatting, and no contradictions. A developer could read this PRD and know exactly what to build.

Troubleshooting

  • • If you are unsure about any section, go back to the relevant day and re-do that step. It is better to take extra time now than to start Module 2 with an unclear PRD.
  • • The PRD does not need to be perfect. It needs to be clear enough that a developer could build from it. Simple, clear, and complete is the goal.

Self-Check

Quiz