Narrowing down the topic

Project Development and Management

“An app for connecting people with their communities” is not a project idea. It's a mission statement, and you can't put a mission statement in a sprint plan.

A huge number of student teams lose their first month circling a topic that's technically agreed on but never actually scoped. Everyone nods along to the big idea, then each person quietly imagines a completely different version of it, and the disagreements only surface once code has already been written in three incompatible directions.

Why broad topics are a trap

Broad topics feel safe because they're hard to disagree with — who could object to "helping students manage their time better"? But that safety is an illusion. A broad topic can't be estimated, can't be tested against real requirements, and gives every team member room to silently build a different project in their head. The disagreement doesn't go away; it just gets delayed until it's expensive to resolve.

Why is this important?

Time spent narrowing a topic properly is some of the highest-leverage time in the entire project. It's far cheaper to argue about scope in week one over a whiteboard than to discover in week ten that half the team assumed the project included a mobile app and the other half didn't. A narrow, well-defined topic also makes every later step easier — stakeholder analysis and requirement analysis both go faster and produce sharper results once you're not also trying to figure out what the project even is.

The narrowing funnel

Work from broad to specific in stages, and don't let yourself skip ahead:

Domain — the general area. "Student productivity."
Problem — a specific, real pain point inside that domain, ideally one you've observed or heard about directly, not guessed. "Students in shared project modules struggle to see who's actually behind on their part until it's too late."
User — exactly who experiences this problem. Not "students" in general — "a team lead in a 4–6 person coursework group, partway through a multi-week project."
Solution shape — roughly what kind of thing would help. A dashboard? A notification system? A weekly check-in form? Don't lock in the exact feature list yet, just the rough shape.
Scope boundary — what you are explicitly not building. This step gets skipped constantly and is arguably the most valuable one. Write down the tempting features you've decided are out of scope, and why.

By the end of this funnel you should be able to state your project in one sentence that a stranger could understand and that couldn't apply equally well to five other projects.

Use your constraints on purpose

Time, team size, and skills aren't just limitations to complain about — they're one of the fastest ways to narrow a topic. A team of four with three months and no mobile development experience should not be scoping a cross-platform mobile app with real-time sync as their MVP, no matter how good the idea sounds. Ask directly: given exactly what we have, what's the smallest version of this idea that would still be genuinely useful to someone? That question does most of the narrowing work for you.

A quick sanity test

Before you commit to a topic, try to write it as a single user story (see User Stories & Use Cases): "As a <specific user>, I want <specific goal>, so that <specific benefit>." If you can't fill that in without using the word "everyone," "students," or "people" on its own, the topic isn't narrow enough yet.

Tips

Write your one-sentence scope statement somewhere visible and refer back to it whenever a new feature idea comes up mid-project. If it doesn't serve that sentence, it's probably scope creep.
Get an outside pair of eyes (a supervisor, a friend outside the team) to read your scoped topic back to you in their own words. If their summary doesn't match what you meant, your topic still isn't narrow enough.
It's fine, and often correct, to start broader in your very first brainstorm and narrow aggressively afterward. The mistake is stopping the process before you've actually narrowed anything.
Revisit your scope boundary list occasionally — not to expand it under pressure, but to make sure everyone still agrees with what's out.

References

Nielsen Norman Group — Design Thinking 101 (the Define stage covers narrowing a problem statement in more depth)