Problem to Pitch

Problem to Pitch is a talk for students getting ready for their next ideathon or hackathon, first given at ITE Day 2026. Below are the slides, with the ideas behind each one written out so you can read them at your own pace.

If you try the three short exercises along the way, you finish with three things: a real problem, one screen, and a first sentence. That is enough to walk into your next hackathon ready.

Before anything else

Two roommates, one sink, the same fight

Picture two roommates, Ana and Mika. Every week, the same fight over the dishes.

They try everything. A washing schedule. Arguing over the sink. They buy a dishwasher. They put money in a pot for every dish washed. The dishes still stack up, and the fight repeats.

So what is the real problem?

Paper plates. The problem was never the dishes. It was washing them. Take the washing away, and the fight is gone. Every fix they tried made washing easier. Nobody asked if they needed to wash at all.

If you can't solve a problem, make it bigger.

Bigger does not mean a bigger app. It means stepping back to see the whole thing, then asking: what one change would fix everything else? Most hackathon teams build a better dishwasher. The ones who stand out find the paper plates.

The idea behind the hour

A hackathon and a startup begin the same way

Someone notices a problem. They guess at a fix. Then they have to convince other people it is worth building. That is a hackathon. That is also a startup.

A startup is a company built around a problem, looking for a fix that can grow fast. Not a small shop that stays the same size on purpose. A startup wants to grow big, and fast.

Facebook, Netflix and Google all began this way: one problem and one small team, before anyone knew the name.

A startup team usually covers four jobs: someone who designs, someone who builds, someone who sells, and someone who talks to users to find out what they actually need.

The only difference is time. A hackathon gives you a day, maybe a weekend. A startup gives you a few years. The work in the middle is the same.

The thing nobody tells you

You are not losing to the other teams

When a team loses a hackathon, it is rarely because another team was smarter. Most teams lose to the clock. They pick an idea too big to finish. They split the work so that three people wait on one. They spend the last hour fixing a screen the judges were never going to see.

The six moves below are how you beat the clock.

Move 1 · Coming up with ideas

A real problem, not an interesting one

Ideas come in two kinds, and when one hits you out of nowhere, say over your morning coffee, they feel exactly the same.

An interesting problem sounds impressive when you describe it, but nobody around you actually has it. A real problem already has someone working around it, badly: with a spreadsheet, a group chat, or a long queue.

So ask one question: who is annoyed enough to switch? If you cannot name a person, pick again.

Equality gives everyone the same box, and some still cannot see over the fence. Equity gives each person the box that gets them over. Build for the person who is still stuck. That is what a real problem asks of you.

Move 1 · Where to look

Look where you already are

You do not need a new industry. You need a problem you have seen with your own eyes: the enrolment line, the org that runs its money through a chat thread, the office that still does it all on paper.

You do not need the next big platform either. A tool that fixes one block, one org, or one line is enough to enter, and enough to win. Small and finished beats big and broken.

Try it · 3 minutes

Write one problem as one sentence: who is annoyed, and at what. Name a person you have actually seen, like a freshman, your org treasurer, or your mother. Not "students."

A shortcut: scratch your own itch. What has been bugging you every single week? That is usually the fastest problem to find.

No solutions yet. If your sentence already names an app, you skipped the step that matters. Ana and Mika jumped straight to a dishwasher. Do not buy the dishwasher yet.

Move 1 · Cut it down

Now cut it to one screen

A hackathon does not fit a product. It fits one screen that proves the idea. Not the sign-up page, not the settings, not the admin panel. The one screen where the annoying thing stops being annoying. If you cannot name that screen, you cannot build it in time.

Think of Tony Stark's first suit, built in a cave with a box of scraps. It was ugly and heavy, and it did one job: get him out of the cave. Your one screen is your Mark 1. The shiny suits come later.

Try it · 2 minutes 30

Finish this sentence: "They open it, they see ___, and now they do not have to ___."

"They open it, they see whose turn it is to wash, and now they do not have to argue about it."

"They open it, they see who owes who this month, and now they do not have to chase it in the group chat."

Your sentence is your screen. And your screen is your demo.

Move 2 · Working as a team

Split by screen, not by layer

Most teams still split by layer: one on backend, one on frontend, one on design. That is how three people end up waiting on one.

The game changed. We have AI now. Tony never built alone; he had Jarvis. The old excuse, "I do not know backend" or "I cannot design," is gone. One person can own one screen from front to back, with AI covering whatever they are weakest at. You still make the calls. Jarvis does the heavy lifting.

So split by screen. If a person finishes, their screen works, even if nothing else does. And one person owns the demo, from hour one.

Moves 3 and 4 · Developing and prototyping

Build the demo path. Mock the rest.

Before you write any code, write down the exact clicks you will make on stage. That list of clicks is your scope. Build for real only what is on that path, plus the part you claim is hard. Mock everything else: logins, payments, email, admin panels.

Mocking is only cheating if you lie about it. So say it out loud: "The payment is mocked for now. The matching is real." That tells a judge you know which part was hard.

Move 5 · Managing time

The last two hours are not for code

Plan backwards from when you present. With two hours left, freeze the code. No new features. Run the demo from start to finish, then run it again, because the first run is when something breaks. Then say your pitch out loud once.

A small demo you can explain beats a big one you cannot.

Move 6 · Pitching

How you say it matters

Here is why this part is worth your time. Researchers at Yale studied more than 1,100 pitch videos that founders sent to a startup accelerator. Teams with above-average delivery, meaning how they said it and not what they built, were 35% more likely to get funded.

The same study found those startups did worse later, on average. Delivery gets you in the door. The product still has to carry you after. But on pitch day, judges are people too.

So keep it simple: open on a person, say what you built in one sentence, show it, and close with who uses it. That is one shape, not the only one. The goal is not how much you say. It is how much they remember. Seventeen features said out loud is zero features remembered.

Move 6 · Pitching

The first sentence decides the rest

Two openers for the same project:

"We built a mobile app that uses AI to optimise student workflows."

"Last enrolment, Maria lined up twice for the same signature. Here is why."

Same project. One of them makes a judge look up. Open with the person, never with the technology.

Newspapers work the same way. The most important line goes first, because most readers never finish the article. Judges do not finish either. They hear one pitch after another, all day. Lead with the line that matters.

Try it · 3 minutes

Build a 60-second pitch: open with the person, then your one screen, then who uses it first. Stuck? Fill in one sentence:

"I help ___ do ___, without ___."
"I help freshmen sign up once, without the second line."

That is already a pitch. Say it out loud, quietly, to yourself. If it does not sound like something you would tell a friend, rewrite it.

In pairs

Then pitch it to one person

In the room, everyone pitched once to the person beside them before anyone stood up in front of the room. The listener had one job: when the pitch ends, say back the one thing they remember. If they cannot remember anything, that is the feedback.

You can do this with any friend. It takes two minutes, and it is the fastest feedback you will ever get.

Share round

Then stand up in front of the room

After the pairs, a few people pitched to the whole room: sixty seconds each, standing up, because standing changes the voice. Open with the person, show the one screen, say who uses it first.

When the clock hits zero, you stop, even mid-sentence. The clock is part of the practice. Then the room answers one question: what is the one thing you remember?

The upgrade protocol

Every Mark 85 started as a Mark 1

Everything you pitch at a hackathon is a Mark 1: ugly, heavy, built with what you had in the time you had. That is exactly right.

Many films later, Tony wears the Mark 85. Same man, many upgrades. He never jumped from one to the other. He built before he felt ready, then kept upgrading, and every Mark fixed what broke in the last one.

The hackathon is your Mark 1. The startup is every upgrade after it. The suit was never the lesson. The upgrading was.

After the prizes

Some of them do not stop

Some hackathon projects do not stop at the prize. A weekend project wins a trophy, then keeps going, upgrade after upgrade, until it becomes a company. That path is open to any team in the room.

It runs on the same six moves you just read:

1. Find a real problem.
2. Split by screen.
3. Build the demo path.
4. Mock the rest, and say so.
5. Stop early and practise.
6. Open with the person.

Those six do not change. Only the deadline does.

Before you forget all this

Start the list tonight

Open a note on your phone. Every time something around you is annoying, write one line. Do not judge it. Do not solve it. Just collect.

When the next hackathon is announced, you will not be brainstorming at midnight. You will already have twenty.

The next competition is going to be won by somebody. Most people entering it will start with nothing. If you did the three exercises, you already have a problem, a screen, and a first sentence. That is your Mark 1. The rest is upgrades.

One more thing. Do not do this just for the hackathon, or just to pass a requirement. Do it because a real problem is bugging you, and you want it gone. The trophy and the grade follow on their own.

And when you get stuck, remember Ana and Mika. Stop washing. Find your paper plates.