How to start a research project when you've never done one

Getting Started · 4 min read

Most guides tell you to "find a gap in the literature." That is the output of the first month, not the first step. If you sit down with an empty document and try to think of a gap, you will produce either something already done or something nobody needs. Here is the sequence that actually works.

1. Pick a question you can answer, not a topic you like

"Machine learning for healthcare" is a topic. "Does model X, trained on dataset Y, keep its accuracy when the hospital changes?" is a question. A question has an answer that could come out either way, and you can tell when you have it.

Test your question against three things:

• Falsifiable. You can describe a result that would prove you wrong.
• Bounded. You can name the data, the method, and roughly how long it takes.
• Yours. You have — or can realistically get — the data, equipment, or access it needs.

If any of the three fails, you do not have a project yet. You have a reading list.

2. Read backwards from the newest work, not forwards from the classics

The instinct is to start with the foundational 1987 paper and read forward. Don't. Start with the three or four most recent papers that are close to your question, and mine their related-work sections. Those authors already did the historical reading for you, and they did it with the field's current framing.

Read each paper in this order: abstract, figures, conclusion, then methods if it still matters. Most papers can be dismissed in four minutes. Protect your time for the ten that cannot.

Keep a running file with one line per paper: what they did, what they found, and what they left open. That file becomes your related-work section later, and the "left open" column becomes your gap.

3. Find the gap by looking for disagreements, not silences

Beginners look for a topic nobody has written about. That silence is usually there for a reason — it's hard, it's been tried and failed, or nobody cares.

The productive gaps look like this:

• Two papers report opposite results and nobody has reconciled them.
• A method works on a benchmark that does not resemble the real setting.
• Everyone cites one dataset, and that dataset has a known flaw.
• A technique from a neighbouring field has obviously not been tried here yet.

Each of these gives you a defensible sentence for your introduction: "X and Y report conflicting results; we show the difference is explained by Z." That sentence is the paper.

4. Write the abstract before you do the work

This feels backwards and it is the single highest-leverage habit in research. Write the 200-word abstract of the paper you hope to publish — including a made-up result. Then look at it.

If the fake abstract is boring even when the result comes out perfectly, the project is not worth doing. Better to learn that in an hour than in eight months. If it's exciting, you now have a target: every experiment either supports that abstract or is a distraction.

5. Scope it to one result

A first project should produce one defensible claim. Not a framework, not a survey, not a system with six components. One claim, supported properly.

The most common failure mode in a first project is not being wrong — it's being unfinished. Three half-answered questions cannot be published. One fully-answered small question can.

6. Set the deadline from a real venue

Pick a conference or journal with a real submission date and work backwards. Deadlines are what turn a project into a paper. Without one, "a bit more analysis" expands to fill all available time.

Work backwards from the deadline in this order: two weeks for writing and revision, one week for figures and tables, and everything before that for the work itself. Almost everyone underestimates the first two.

The traps

Reading forever. Reading feels productive and carries no risk of failure. At some point — a month, not a year — you have to stop and run something.

Building infrastructure first. The elaborate pipeline you build before knowing what you need is the code you throw away. Get an ugly result end-to-end, then clean up.

Not writing anything down until the end. Write the introduction and methods as you go. They will be wrong, and fixing something wrong is far easier than starting from a blank page in week 30 when you can no longer remember why you chose that sample size.

Waiting for your supervisor to hand you a question. Bring them a bad question and let them correct it. Correcting is fast; generating from nothing is slow, and they're busy.

What "done" looks like for month one

You should have: a one-sentence question, a file of 20–40 papers with one line each, a named gap, a fake abstract, and a target venue with a date. That's it. That's the whole first month, and it's enough to carry the next six.