The First Decade of Research · Part 2 of 3

Recognizing Good Problems

Pranav Rajpurkar · December 2025

I recently hit an i10 index of 100—meaning 100 of my papers have been cited at least 10 times each. What that represents isn't just output. It's reps. A hundred times watching an idea go from concept to paper to seeing whether it lands.

After enough reps, something shifts. I've developed intuitions about which directions feel promising—and which ones probably won't pan out. That's taste.

But here's the thing: you don't have to write a hundred papers to develop it. If you're mindful about the process—if you pay attention to what works and why—you can get there much faster.


You can execute perfectly on the wrong problem. Execution gets the work done, but problem selection determines if it matters.

Execution is necessary. Problem selection is decisive.

So how do you learn which problems matter? You can learn to code from courses. Learning which problems matter requires reading and experience. Lots of both.

Some colleagues spend the first two hours of every morning reading before touching code. Every morning, for years. The math: 2 hours a day, 5 days a week, about 5-7 papers per week. That's 250-350 papers per year. After 2-3 years, they'd read 500-1000 papers. They see connections others miss.

One of my mentors told me something specific: read 10-20 papers deeply on a topic, and ideas start generating automatically. Below that threshold, you're guessing. Above it, patterns emerge.

This advice compressed years into a heuristic. It only worked because my mentor had earned it through experience. They had taste for what mattered. I benefited from their taste before developing my own.

Find mentors with taste. It's the highest-leverage thing you can do early in your career.

How do you find them? Look for people whose work compounds—whose papers generate follow-up work, whose students succeed, whose ideas others adopt. Then find ways to contribute—good mentorship relationships are mutual.

Mentorship works both ways. I run the Medical AI Bootcamp—a program that brings together students from Harvard, Stanford, and doctors worldwide. The bootcamp creates a structure for people to work on meaningful projects with complementary expertise and close mentorship. Watching students go from their first paper to building research programs has reinforced these lessons about how taste develops. Creating vehicles that enable collaboration matters.

Beyond mentors, you need systems that force you to keep reading. For a while, I ran a weekly newsletter on AI and health. Every week, I had to find 5-7 papers to highlight. The newsletter itself didn't matter—readership was tiny. What mattered: it created a forcing function. I had to read even when I didn't feel like it.

Writing summaries reinforced understanding. Months later, I'd remember "there was a paper about X" and find it in my notes. This compounds. Create external commitments that force the behavior you want. Newsletter, reading group, blog—whatever makes reading mandatory.

The progression is visible. Early: you're trying to understand what they did. Slow and necessary. Middle stage: you start critiquing. Later: synthesis emerges. Connections appear automatically. Reading gets faster with practice.

When students ask "what should I work on?", I usually ask back: "what have you read?" Often that's a sign there's more to explore first. Good ideas require inputs. Reading provides them.

For each paper: What problem did they solve? What's new? What's missing? Could I build on this? These questions help me know if I've really engaged with a paper.

Some of my best ideas came from reading outside my immediate area. Reading purely in your domain gives you depth. Cross-domain reading reveals opportunities others miss.

The "why now" question is everything. Can this be solved today but couldn't two years ago? What threshold just crossed?

That question is the ultimate filter for good problems. And recognizing which problems pass through—developing taste for what matters—comes from reading, mentors, and time.

Good problems need good framing. Otherwise, no one notices. That's the third capability—and where we go in Part 3.

Last updated: 12/17/2025