Scoping and pitching

Every challenge has a final deliverable — a deck, a report, a piece of code, a design. But before you produce that deliverable, you move through two milestones that mirror how real professionals scope a project: scoping and pitching.

These two milestones are where most strong submissions are won. Skipping them is a tell — reviewers can spot a submission that jumped straight to "doing the work" without first thinking about which work.

Scoping — defining the problem before solving it

When you accept a challenge, your first task is to write a short scoping document — typically one to two pages. The scoping document answers four questions:

1. What is the real problem?

A brief gives you the surface — the symptom. Scoping forces you to read past it. A market-entry brief might say "evaluate whether to enter Spain" but actually be asking "do we have the operational capacity to enter Spain right now?" Naming the real question changes the answer.

2. What are you in scope on, and what are you out of scope on?

Real projects are bounded. Scope creep is the single biggest reason challenge submissions fail to land. Write down what you will not be addressing — and why. Reviewers reward clarity here, not coverage.

3. What's your approach?

Not the answer — the approach. The decomposition. "I'll start by mapping the three competitors operating in the target market, sizing each, then layering on regulatory cost." That's enough at this stage.

4. What might go wrong?

Risk-flag your approach. The strongest scoping documents name the assumption that, if it's wrong, would change the whole conclusion. Reviewers know this and look for it.

A good scoping document is short. It's not the final report. It's the contract you make with yourself (and reviewers) about what you're actually doing.

Pitching — getting feedback early

Once the scoping document is accepted, you produce a pitch — typically a five-to-ten-minute walkthrough of your direction. Some challenges run live pitch sessions; others ask for a recorded video or a slide deck with speaker notes.

The pitch is not the final submission. It's an early-stage solution direction. The goal is to let reviewers flag dead-ends before you sink time into them.

A good pitch covers:

1. The question — what you understood the challenge to be asking.
2. Your direction — the shape of your answer, not the answer itself.
3. The evidence you'll need — what data, research, or experiments are still ahead of you.
4. The risks — what would change your answer.

Tip: A pitch that says "here's my approach, here's what I'm uncertain about" almost always lands better than one that says "here's my answer, here's why I'm right." Working professionals do not pitch certainty too early.

Common mistakes

These are the patterns we see most often, in roughly the order of how much they hurt your submission:

• Skipping scoping entirely. Going straight to the deliverable is the single fastest way to produce a thin submission. Don't.
• Treating scoping as administrative. It's not paperwork — it's where you do most of the thinking. Five hours of scoping saves twenty hours of redoing work.
• Pitching the final answer. The pitch is for direction, not conclusions. Save the conclusions for the final submission.
• Ignoring reviewer feedback on the pitch. If reviewers flag a dead-end, change direction. Stubborn pitches that ignore the feedback don't get accepted at the final submission stage.
• Confusing thoroughness with quality. A tight, well-bounded scope produces a better deliverable than a sprawling one. Reviewers prefer focused over comprehensive.

What's next

After scoping and pitching, you're into actual production — the work that becomes your final deliverable. If you're on the challenge with others, the next page is for you: Teams and collaboration.

Otherwise, jump to Final submission for what "done" looks like.