Conrad Challenge: build the venture, not just the prototype

Editorial overview

The Conrad Foundation founded the Conrad Challenge to honour Apollo 12 astronaut Charles ‘Pete’ Conrad and to place students inside an innovation and entrepreneurship process. The current season marks the Challenge’s twentieth year of operation. That history explains why the competition does not stop at invention: teams are expected to connect a real problem, a working idea and a credible case for adoption.

Official project records show that successful entries can connect technical evidence with a defined user and market: BeeGuard combined computer vision, acoustic analysis and behavioural tracking with field validation and a subscription model. The example is revealing because none of those parts stands alone. The technology identifies bee health risks, field work tests whether the system is useful, and the commercial model asks how beekeepers could continue using it.

CompeteMap sees the Challenge as a strong fit for committed teams that enjoy moving between engineering, research and enterprise. Its long format gives an idea time to improve, but the workload is real: a team that treats the business plan as an appendix or begins pitching before it has evidence will struggle to make the project coherent. The international format widens the range of problems teams can bring, while making disciplined collaboration even more important.

Quick Facts

For current dates, eligibility and registration details, see the Conrad Challenge (Innovation & Entrepreneurship) competition page.

This guide was checked on 3 October 2026.

Review Evaluation

Rated Advanced. The long, multi-stage process combines research, prototyping, market thinking, written planning, video communication and a live pitch for selected finalists.

A prototype is only one promise

Teams have two to five students aged 13-18 and one adult coach aged at least 18. Teams may enter from anywhere in the world. That flexibility makes it possible to combine different strengths, but it can also hide a weak division of labour. One student should not own the technology while another invents a market story at the end. Every major design choice should have a user reason, and every user claim should be tested against what the prototype can actually do.

Begin with three linked statements: who has the problem, what changes if the innovation works, and what evidence would show that change. A prototype then becomes a way to answer a question rather than a display object. If the team is building a sensor, for example, the first test is not whether its enclosure looks finished. It is whether the measurement is reliable enough to support the decision the user needs to make.

Keep a decision log from the beginning. Record the assumption, the test, the result and what changed. This gives the business plan and pitch an honest backbone. It also prevents a familiar problem in long competitions: a team remembers the finished design but loses the reasoning that made the design credible.

Make the business case testable

A business case is not a prediction that millions of people will buy the product. It is a set of assumptions that can be investigated. Who experiences the problem often enough to care? What do they use now? Who decides whether to adopt a new solution? What cost or behaviour change would make adoption unrealistic?

The BeeGuard example is useful here. Its technical system was paired with field validation and a subscription model, so the judges could see not only what the product detected but also how it might fit into beekeeping practice. A student team does not need a finished company. It does need to show that the proposed user, delivery model and value are more than decoration around the engineering.

Interview evidence should therefore influence the product. If prospective users describe a constraint that the design ignores, the team should either revise the design or explain why it chose not to. A polished survey chart is less valuable than one uncomfortable finding that led to a better decision.

Treat the pitch as due diligence

Innovation-stage submissions include an investor pitch, team video, team photo, business plan, and required supporting materials in English. The useful way to prepare them is as one evidence system. The pitch states the case, the business plan carries the detail, the video shows the team and product clearly, and the supporting material lets a reviewer check the claims.

Write the pitch after the evidence map, not before it. For each major claim, identify the supporting test, source or user finding. Then identify the strongest limitation. Teams often fear that acknowledging a limitation will weaken the presentation, but a precise boundary usually makes the rest of the case more believable.

AI tools may be used only with proper citation under the official rules. That makes source control part of the project rather than a last-minute formatting task. Keep research notes, tool use and outside components traceable, and make sure the students can explain every claim and design choice in their own words.

Pete Conrad Scholar is an official Challenge distinction. Teams should not organise the project around the label, though. A more useful standard is whether an informed reviewer can move from the problem to the evidence, product, user and next step without encountering a gap that the presentation tries to hide.

Use the long season deliberately

The competition moves through the Activation Stage, Innovation Stage and Innovation Summit. Each stage should change the project. Activation is the moment to narrow the problem and expose weak assumptions. Innovation work should produce test results and revisions, not just more slides. Summit preparation, for finalists, should turn the written case into a conversation the team can defend.

A practical rhythm is to alternate building weeks with evidence weeks. Build or model one change, then test what the change was meant to improve. Review the user and venture assumptions at the same time. This avoids two parallel projects—an engineering project and a business project—that only meet when the submission is assembled.

The adult coach can protect this rhythm by asking for decisions and evidence rather than supplying answers. The most useful checkpoint is simple: what did the team believe last month, what has it learned, and what is different now? If the answer is only that the slides look better, the project has not progressed enough.

Key Takeaways

• Conrad is a venture-building challenge, not a prototype showcase with a business plan attached.
• Choose a precise user problem and make every technical claim testable.
• Develop adoption logic alongside the product; do not leave market thinking until the submission stage.
• Use the pitch, video and plan as connected evidence, and state limitations honestly.
• The long season rewards teams that can document learning and revise decisions together.

Sources checked

• https://conrad.spacecenter.org/
• https://conrad.spacecenter.org/the-challenge/
• https://conrad.spacecenter.org/the-challenge/rules-and-regulations/
• https://conrad.spacecenter.org/about-challenge/
• https://conrad.spacecenter.org/2026-awards/