How to Run an Innovation Challenge That Doesn't End With a Trophy

There is something deeply ironic about the way many organisations approach innovation.

They identify a problem, announce an innovation challenge, invite entrepreneurs and students to submit ideas, organise a hackathon, assemble a panel of judges and award prizes to the most promising teams.

There are photographs, presentations, certificates and enthusiastic speeches about the future.

Then everyone goes home.

Six months later, the winning idea is still sitting in a presentation deck. The prototype has not been tested in a real environment. The organisation has not committed resources to implementation. The participants have moved on to other projects.

The challenge is declared a success, but the original problem remains.

This is one of the most persistent weaknesses in institutional innovation: confusing the organisation of an innovation event with the delivery of innovation.

An innovation challenge should not be measured by how many people attended, how many applications were received or how impressive the final presentations looked. Those are measures of participation and activity. They tell us very little about whether anything changed.

The more important question is what happens after the winner is announced.

If there is no credible pathway from an idea to a real-world test, an innovation challenge risks becoming an expensive exercise in presentation rather than a serious instrument for solving problems.

For universities, banks, government ministries, development organisations and corporations, the opportunity is to rethink how these programmes are designed.

The objective should not simply be to discover good ideas. It should be to create the conditions in which good ideas can be tested, improved, funded and adopted.

1. Start With a Problem, Not an Event

One of the first mistakes organisations make is beginning with the format rather than the problem.

The conversation often starts with questions such as:

• Should we organise a hackathon?
• How many participants should we invite?
• What prizes should we offer?
• Which speakers should we bring in?
• Where should we host the event?

These are operational questions. They are not the starting point of an innovation programme.

The first question should be: What problem are we trying to solve, and why have existing approaches failed to solve it?

Consider a financial institution experiencing low adoption of its digital banking services.

It could announce a fintech innovation challenge and invite participants to develop new banking applications. That might generate interesting ideas, but it may completely miss the underlying problem.

Perhaps customers do not trust digital transactions. Perhaps the onboarding process is too complicated. Perhaps the institution's internal systems are fragmented. Perhaps customers lack reliable access to the internet.

Each of these problems requires a different intervention.

A challenge that begins with the assumption that the solution must be a new application may attract technically impressive submissions while overlooking the actual source of the difficulty.

Before launching a challenge, an organisation should conduct sufficient discovery to understand the problem, its context, the people affected and the constraints surrounding it.

This means engaging the people who experience the problem, reviewing available data, examining existing processes and identifying what has already been attempted.

A useful problem statement should establish:

• The problem: What specifically is not working?
• The affected population: Who experiences the problem?
• The evidence: What information demonstrates that the problem exists?
• The constraints: What technical, financial, regulatory or operational limitations must be considered?
• The desired outcome: What would meaningful improvement look like?

The distinction matters.

A vague invitation to develop innovative solutions to improve healthcare is likely to produce a wide range of disconnected ideas.

A more focused challenge might ask:

How might district health facilities reduce the time required to identify and refer high-risk patients using existing staff, infrastructure and available data?

The second question gives innovators something concrete to investigate without prescribing the solution.

A well-designed challenge does not tell participants what to build. It gives them a sufficiently clear problem to solve.

2. Write a Challenge Brief That People Can Actually Work With

Once the problem has been established, it needs to be translated into a challenge brief.

The brief is arguably the most important document in the entire programme. It establishes the boundaries of the competition, communicates expectations and provides a common understanding of what success looks like.

A poorly written brief creates confusion. Participants develop solutions based on different interpretations of the problem, judges evaluate submissions against inconsistent expectations, and organisers struggle to explain why one proposal was selected over another.

A strong challenge brief should contain five essential elements.

1. Context

Explain the problem, why it matters and what evidence supports the need for intervention.

2. Challenge question

State the specific question participants are expected to address.

3. Scope and constraints

Clarify what is within the scope of the challenge, what is outside it and what limitations participants must consider.

4. Expected deliverables

Explain what participants must submit. This could include a problem analysis, proposed solution, prototype, implementation plan, budget and evidence of user feedback.

5. Intended outcome

Describe what the organisation hopes to achieve after the challenge. Is it seeking a pilot, a new service, an operational improvement, a technology prototype or a policy recommendation?

The final element is particularly important.

Participants should understand from the beginning whether they are competing for recognition, funding, access to an institutional testing environment or an opportunity to implement their solution.

These are very different incentives, and they attract different types of participation.

3. Design Evaluation Criteria Around Real-World Value

Innovation competitions often reward the most impressive presentation.

A team with a sophisticated prototype, confident presenters and an attractive interface can easily outperform a team with a less polished but more practical solution.

This creates a problem: presentation quality becomes a substitute for implementation potential.

The evaluation framework should therefore be established before applications open and communicated clearly to every participant.

A useful starting point is to evaluate solutions across five dimensions:

Evaluation dimension	Suggested weighting
Problem relevance and understanding	20%
Potential impact and user value	25%
Technical and operational feasibility	20%
Sustainability and scalability	20%
Quality of evidence and testing	15%
Total	100%

These weightings are illustrative and should be adapted to the objectives of each challenge.

For example, a challenge focused on public service delivery may place greater emphasis on accessibility, institutional compatibility and implementation feasibility. A challenge designed to identify early-stage technologies may give more weight to technical performance and commercial potential.

The important principle is that evaluation criteria must reflect the outcome the organisation actually wants.

A useful question for judges is not simply whether a solution is innovative, but whether it is likely to work in the environment where it is intended to be used.

Can the organisation afford it?

Can existing infrastructure support it?

Will the intended users adopt it?

Does it comply with relevant regulations?

Can it be maintained after the initial funding ends?

An idea can be technically impressive and still be institutionally impractical.

Good evaluation makes that distinction visible.

4. Avoid the Hackathon Trap

Hackathons have become one of the most popular ways to organise innovation activities.

They can be valuable. They bring people together, encourage collaboration, create opportunities for rapid experimentation and allow participants to explore ideas in a relatively short period.

But a hackathon is a format, not an innovation strategy.

The problem emerges when organisations expect participants to solve complex institutional challenges over a weekend.

A team may be able to develop a working demonstration in 48 hours. It cannot necessarily establish whether the solution is secure, scalable, legally compliant, commercially viable or compatible with an organisation's existing systems in that time.

A prototype is evidence that something can be demonstrated. It is not evidence that something is ready to be deployed.

The distinction is especially important in sectors such as healthcare, financial services, education and public administration, where solutions must operate within complex regulatory and institutional environments.

Rather than treating the hackathon as the entire programme, organisations should consider using it as one stage within a longer innovation process.

For example:

Before the event: Participants receive the challenge brief, access to relevant information, mentorship and opportunities to engage with problem owners.

During the event: Teams develop initial concepts, test assumptions, build prototypes and receive feedback from technical and domain experts.

After the event: Selected teams receive structured support to improve their solutions, conduct user testing and prepare for implementation.

The hackathon becomes a starting point for experimentation rather than the final destination.

The objective is not to eliminate hackathons. It is to stop expecting a short event to do the work of an entire innovation programme.

5. Make the Organisation Part of the Solution

There is another problem that often receives insufficient attention: the institution organising the challenge may not be ready to implement the solutions it is asking others to develop.

This is an important distinction.

Innovation is rarely just a technical exercise. It often requires changes to processes, budgets, institutional incentives, procurement arrangements, internal capabilities and organisational behaviour.

Imagine a university inviting students to develop an AI-powered academic support platform.

The winning team produces a promising prototype. However, the university has no clear policy on AI use, no designated department responsible for implementation and no budget for ongoing maintenance.

The solution may be technically sound, but the institutional conditions required to adopt it do not exist.

This is why challenge organisers must participate in the innovation process rather than simply act as judges.

Before launching a challenge, the organisation should identify:

• The internal department that owns the problem.
• The senior decision-maker who can authorise implementation.
• The technical personnel who can assess and support the proposed solution.
• The operational teams who will eventually use it.
• The resources available for testing and implementation.
• The regulatory, procurement and data governance requirements that must be addressed.

This creates institutional ownership.

It also ensures that the challenge is connected to the organisation's actual priorities rather than becoming an isolated corporate social responsibility or public relations activity.

The organisation should be prepared to change something itself.

Sometimes the most important innovation emerging from a challenge is not the technology developed by participants, but a change in how the institution understands and approaches its own problem.

6. Build a Funded Pilot Into the Design

This is where the difference between an ordinary competition and a serious innovation programme becomes most visible.

Every challenge should have a defined pathway from selection to testing.

If an organisation knows that it wants to identify solutions that could improve its operations, it should establish a pilot mechanism before inviting applications.

A pilot is a controlled opportunity to test whether a proposed solution works under real or representative conditions.

It allows the organisation to move beyond presentations and assumptions and begin collecting evidence.

A pilot should have:

A defined scope: What exactly will be tested, and what will not be included?

A real testing environment: Where will the solution be deployed, and who will use it?

A responsible owner: Who within the institution is accountable for the pilot?

A budget: What resources are available for development, testing, training and support?

A timeline: How long will the pilot run?

Success measures: What evidence will determine whether the pilot has worked?

A decision point: What happens when the pilot ends?

The funding does not necessarily need to cover a full-scale deployment. It should, however, be sufficient to move the selected solution beyond a demonstration and into meaningful testing.

For instance, a bank running a challenge to improve customer onboarding could commit funding to test the winning solution in a single branch or customer segment.

A municipality could support a pilot of a proposed waste-management intervention in one neighbourhood before considering wider implementation.

A university could fund the testing of a student-developed learning tool within a selected department.

These approaches reduce the risk of large-scale investment in unproven solutions while creating a practical route towards adoption.

Importantly, organisations should not assume that the winner must automatically receive a full implementation contract. The pilot exists to establish whether the solution works, what needs improvement and whether further investment is justified.

The prize should open the door to implementation, not become a substitute for it.

7. Use a Stage-Gated Approach Instead of a Single Winner-Takes-All Event

Not every idea will be ready for implementation at the same time.

Some proposals will have strong potential but require additional research. Others may be technically promising but need a different team or implementation partner. Some may fail early testing but reveal useful insights.

A single final competition makes it difficult to accommodate these differences.

A stage-gated approach allows solutions to progress through successive levels of development, with support and evaluation at each stage.

A practical structure could look like this:

Stage 1: Discovery and problem understanding

Participants investigate the challenge, engage with relevant stakeholders and identify opportunities for intervention.

Output: A clearly articulated problem analysis and proposed approach.

Stage 2: Concept development

Selected teams develop their ideas, assess feasibility and explain how their proposed solutions will create value.

Output: A solution concept, preliminary implementation plan and initial feasibility assessment.

Stage 3: Prototyping and validation

Shortlisted teams receive mentorship, technical support and access to relevant users or environments to test their assumptions.

Output: A prototype or tested proof of concept supported by evidence.

Stage 4: Pilot selection and funding

The most promising solutions are selected for funded pilots. Teams work with the sponsoring organisation to establish scope, responsibilities, timelines and success measures.

Output: A funded pilot with a clear implementation agreement.

Stage 5: Evaluation and scale

The pilot is evaluated against agreed objectives. The organisation decides whether to adopt, improve, expand or discontinue the solution.

Output: An evidence-based decision and a pathway for the next phase.

This structure is more demanding than organising a single event, but it produces a much stronger pipeline of potential solutions.

It also creates opportunities for participants who may not win the final prize but develop ideas that could be valuable in other contexts.

8. Measure What Happens After the Applause

One of the most important questions in innovation programme design is how success will be measured.

Many organisers focus heavily on immediate outputs:

• Number of participants.
• Number of applications.
• Number of ideas submitted.
• Number of prototypes developed.
• Number of winners selected.

These indicators are useful for understanding programme activity. They do not necessarily demonstrate impact.

A more meaningful evaluation framework should distinguish between three levels of results.

Programme outputs

What did the challenge produce?

Examples include prototypes, research, partnerships, new ideas and participating teams.

Implementation outcomes

What happened to the selected solutions?

Examples include pilots launched, solutions tested with real users, processes redesigned and technologies integrated into existing systems.

Institutional impact

What changed as a result?

Examples include reduced operating costs, improved service delivery, increased productivity, better access to services, new revenue opportunities or improved user experiences.

For example, a challenge designed to improve municipal service delivery should not be declared successful simply because ten prototypes were produced.

It should be evaluated on whether the resulting interventions improved the delivery of municipal services.

This requires baseline measurements before implementation and follow-up assessments after the pilot.

It also requires the willingness to acknowledge when something does not work.

A pilot that demonstrates that an idea is ineffective can still be valuable if it prevents an organisation from making a much larger investment in the wrong solution.

Innovation is not about ensuring that every experiment succeeds. It is about creating a disciplined process for learning what works, what does not and what should happen next.

9. Establish Clear Ownership of the Solutions

An often-overlooked issue is what happens to the intellectual property, technology and relationships developed during an innovation challenge.

Participants may invest considerable time and resources developing solutions. Organisations may contribute data, facilities, mentorship and funding.

Without clear agreements, disagreements can emerge over ownership, licensing, commercialisation and future use.

These questions should be addressed before the challenge begins.

The rules should clarify:

• Who owns the intellectual property created by participants.
• What rights the sponsoring organisation receives.
• Whether participants retain the right to commercialise their solutions.
• How confidential institutional information and personal data will be handled.
• What happens to prototypes and other deliverables after the competition.
• Whether the organisation has an option to negotiate further development or licensing agreements.

The default should not be that participating in a competition means automatically surrendering ownership of an idea.

Fair and transparent arrangements help attract serious innovators, protect institutional interests and create the conditions for longer-term collaboration.

A challenge should be designed to create partnerships, not disputes.

10. The Real Deliverable Is an Innovation Pipeline

Perhaps the greatest opportunity is to stop viewing innovation challenges as isolated events.

An organisation that runs one competition and then returns to business as usual is unlikely to build lasting innovation capacity.

A better approach is to use each challenge as part of a broader institutional innovation pipeline.

Over time, this pipeline can help an organisation:

• Identify emerging problems and opportunities.
• Engage external innovators, researchers and entrepreneurs.
• Test technologies and alternative approaches.
• Develop relationships with universities and research institutions.
• Identify promising startups and potential suppliers.
• Build internal capabilities for experimentation.
• Create a portfolio of tested solutions that can be adopted or scaled.

For a bank, this could become a mechanism for identifying new financial technologies and improving customer experiences.

For a university, it could connect research outputs with real-world applications and entrepreneurial opportunities.

For a government ministry, it could create a structured way to engage citizens, researchers, technology companies and other institutions in solving public service challenges.

For a development organisation, it could provide a mechanism for testing interventions before committing resources to wider programmes.

The value is not limited to the solutions produced by individual competitions.

It lies in developing an organisational capability to continuously discover, test and implement better ways of working.

That is a much more valuable institutional asset than a collection of trophies.

---

A Practical Framework: From Challenge to Implementation

For organisations considering their next innovation challenge, the following questions provide a useful starting point.

Design question	What a strong programme should establish
Problem	Is there a clearly defined, evidence-based problem?
Challenge brief	Do participants understand what they are being asked to solve?
Evaluation	Are criteria transparent and connected to real-world value?
Participation	Are the right people, skills and perspectives represented?
Institutional ownership	Is there a department and decision-maker responsible for the problem?
Pilot funding	Is there a credible budget for testing selected solutions?
Implementation	Is there a real environment in which solutions can be tested?
Measurement	Are success indicators and baseline measures established?
Continuity	Is there a decision-making process for adoption, improvement or scaling?

If an organisation cannot answer these questions before launching its challenge, it may not yet be ready to run one.

That is not necessarily a reason to abandon the idea. It is a reason to invest more time in designing the programme.

Conclusion: Stop Organising Competitions. Start Building Solutions.

Innovation challenges can be powerful instruments for institutional transformation.

They can connect organisations with talent they would otherwise never encounter, expose institutions to new ways of thinking, surface technologies and approaches that would not emerge through conventional processes, and create opportunities for collaboration across sectors.

But these benefits do not happen automatically.

They require thoughtful problem definition, clear programme design, credible evaluation, institutional ownership and, above all, a pathway to implementation.

The measure of an innovation challenge should not be how impressive its final event looks.

It should be what remains six months after the event has ended.

Has a solution been tested? Has an institution changed how it works? Has a service improved? Has a promising idea received the support it needs to develop further?

If the answer is no, perhaps the programme was never really designed to deliver innovation in the first place.

At u.lab Works, we believe that good ideas should be treated as hypotheses until they meet reality. The work of innovation is not simply generating possibilities. It is understanding problems, testing assumptions, learning from evidence and building solutions that work.

The objective is not to produce more winners. It is to produce more solutions worth implementing.

---

Are you planning an innovation challenge, hackathon or institutional innovation programme? u.lab Works helps organisations define problems, design experimentation programmes and translate promising ideas into practical solutions.

Bring us the problem.

Explore u.lab Works | Contact: problems@ulabworks.co.zw