Project Submission

Name the people who would use the product or service most often. Try to describe a narrow group by role, age or stage, context, and the situation where they need your solution.

Identify who would approve, buy, sponsor, or budget for the solution. Sometimes the daily user is not the payer, so explain the decision maker separately when that matters.

Describe what makes this user group distinct. Useful details include habits, constraints, skill level, budget, urgency, access to tools, and how they make decisions.

Explain what users do today before your solution exists. This could be a manual workaround, a competing product, a habit, a spreadsheet, a group chat, or simply ignoring the problem.

Describe the main reason users would switch from their current behavior to your solution. Strong answers connect adoption to a clear benefit such as speed, trust, lower effort, better results, or reduced risk.

Name the industry, category, or field where your project belongs. If the project sits between categories, explain the main market first and then mention the related market.

Estimate how many people, schools, organizations, or buyers could realistically need this solution. If you have numbers, include the source or basic calculation; if not, describe the scope carefully instead of guessing a huge market.

Explain whether demand is increasing, stable, or shrinking. You can support this with user behavior, school or industry changes, technology adoption, news, reports, or patterns you observed.

List outside changes that make the project more relevant now. Good answers connect the trend back to your user, instead of naming a broad trend without explaining why it matters.

Name direct competitors, indirect alternatives, and manual workarounds users rely on today. Even if there is no identical product, there is almost always another way users are trying to solve the problem.

Describe the product, service, or system you are building. Focus on the concrete thing users interact with, not only the mission or long-term vision.

Explain the basic workflow from start to finish. A strong answer makes clear what the user provides, what the product does, and what result the user receives.

List the main functions that make the solution valuable. Prioritize features that directly solve the user problem, and avoid adding nice-to-have features that do not change the outcome.

Describe what a user does step by step when using your solution. This helps readers picture whether the product is simple, realistic, and useful in the user's normal routine.

Explain why users would prefer your solution over existing alternatives. Compare on a meaningful basis such as accuracy, cost, speed, trust, convenience, personalization, or quality of outcome.

Describe the main way the project could make money or sustain itself. You can mention sales, subscriptions, licensing, service fees, sponsorship, grants, or another model that fits the customer.

Explain the value the buyer receives in exchange for payment or support. Strong answers connect payment to a specific outcome, such as saved time, reduced risk, better performance, or access to users.

Describe how pricing would be structured, even if you do not know the final price yet. For example, it might be per user, per school, per project, monthly, annually, freemium, or usage-based.

List the biggest resources needed to build and operate the project. Consider materials, software, labor, testing, marketing, partnerships, operations, compliance, and customer support.

Explain how the project can grow to serve more users or customers over time. The key is to show what can be repeated, automated, partnered, or distributed without costs rising at the same speed.

Describe the next concrete goal that would prove progress. A good milestone has a clear result, a rough timeline, and a way to tell whether it was completed.

Name the first assumption you need to validate. This could be about user demand, technical feasibility, willingness to pay, accuracy, safety, usability, or whether the solution actually improves the outcome.

List organizations or people who could help the project move faster. Partnerships might provide users, data, testing sites, credibility, distribution, expert advice, or funding access.

Identify the biggest things that could stop the project from working or being adopted. Include technical, user, market, legal, safety, trust, cost, or execution risks where relevant.

Describe what the project could become if the next stages succeed. Keep it ambitious but connected to the current solution, users, and problem you are solving now.

Introduce the people currently working on the project. Include names or roles, and clarify whether they are founders, classmates, advisors, mentors, or outside contributors.

Explain who owns each part of the work. Clear responsibility makes the project more credible because reviewers can see how research, product, testing, design, and outreach are actually being handled.

List the abilities that help your team execute this project. These can include technical skills, design, research, operations, sales, communication, domain knowledge, or access to the target users.

Mention past work that makes the team more believable. This might include interviews, prototypes, competitions, internships, coursework, personal experience with the problem, or early testing.

Be honest about skills or support the team still needs. Reviewers usually trust teams more when they understand their gaps and have a realistic plan to fill them.

Choose the kind of support that would help the project most right now. This should connect to the next milestone, not just a general wish for more resources.

Enter the amount of money needed for the next stage if you have a realistic estimate. If the number is uncertain, explain the range or leave it for later rather than presenting a random amount.

Explain what the money or resources would pay for. Strong answers break the use into categories such as prototype materials, testing, software, user research, manufacturing, legal review, or outreach.

Name the expert help that would most improve the project. Be specific about the topic, such as technical review, user testing, pricing, market entry, legal safety, manufacturing, or pitch feedback.

State the next measurable result the team is trying to reach. Include a target, a test, a deliverable, or a decision point so reviewers can understand what progress would look like.