You've sent a hundred cold emails. You've had a handful of coffee chats. You've done the research, asked the right questions, and networked your way into conversations with people working in roles you actually want.
But here's the problem: so has everyone else. Every other economics student at LSE has cold emailed a banker at Goldman Sachs. Every other computer science graduate at UCL has told a recruiter at DeepMind that they're "passionate about AI." The talking points are identical. The positioning is indistinguishable.
What separates you from the person sitting in the seat you want is not what you say you can do. It is what you have actually built.
— the gap between interest and credibility
There is a difference between sounding interested in something and proving you understand it. Anyone can tell a hiring manager they want to work in venture capital. But how many have actually built a financial model for a startup? How many have looked at unit economics or churn or CAC payback and had to make sense of what they mean in real terms?
The companies hiring you are not betting on your passion. They are betting on your judgment. Can you see around corners? Can you spot what's broken before it becomes obvious? Can you think like a founder or an operator, not like a candidate?
Projects do what interviews cannot. They compress what you would learn in six months on the job into something you can show on day one.
— recreating the product you want to work on
Let me be specific about what I mean by this. If you want to break into product management at a fintech company, do not just use their app like a normal user. Become the person who has to solve their problems.
Rebuild their core feature from scratch. Not the whole thing, pick the most critical user journey or the one that feels most broken. Then:
- Map out what the current product does, step by step
- Identify where it fails, where it fricts, where it loses users
- Design a better version, knowing what you now know about their constraints
- Actually build a prototype or wireframe that proves your solution works
The moment you do this, you have moved from consumer to operator. You are no longer someone who used their product. You are someone who understands how to build it.
When you get on a call with their PM, you can say: "I rebuilt your onboarding flow and here's where I think you're losing early-stage users. Here's how I'd fix it."
That is not a hypothetical. That is evidence.
— why this works
When you recreate a product, three things happen.
You discover what you don't know. Theory tells you nothing about constraints. You will hit a wall, maybe it's the technical complexity you underestimated, maybe it's a UX decision that made no sense until you tried to implement it. Every dead end teaches you something the founder already knows.
You think like a maker, not a consumer. Normal users see features. Makers see tradeoffs. You start asking: Why did they choose this approach over that one? What's the business model built into this interaction? What's the hidden incentive? You're no longer criticizing from outside; you're reasoning from the inside.
You have something to show. A PDF deck is forgettable. A GitHub repo, a Figma file, a prototype that actually works is not. It sits there as proof that you did the work, that you thought deeply, that you care enough to spend weeks on something with no guarantee of payoff.
Let's say you want to work at an insights platform like inroad that matches students with insider leads. Don't just browse the app. Build a simplified version of the matching algorithm yourself. What data would you need? How would you score a good match vs a bad one? Can you recreate even a basic version of what they do?
Then write up: "Here's how I would approach this problem, here's my data model, and here's where I think the current matching could break down." You now have something to show, not just something to say.
— how to pick the right project
Not every project is worth building. Pick one that is:
- Narrow.
Do not try to rebuild the entire product. Pick one user flow, one feature, one core problem that company solves. - Honest about your constraints.
If you're not a designer, don't pretend. If you can't code it, build a prototype. The specificity matters more than the polish. - Connected to the role you actually want.
If you want to be a PM, focus on the user side, what breaks, what you'd change, why. If you want to be on the growth team, focus on the funnel and where people drop. Make the project speak to the job. - Something you can articulate.
You will get asked about it. Know why you made each choice, what you learned, where you'd go next.
— the signal you're sending
When a hiring manager sees that you've actually built something related to their space, they are not impressed by the execution. They are impressed by what your behavior says:
- You care enough to spend time on something that doesn't pay you.
- You don't need someone to assign you a problem to go find one.
- You can tolerate not knowing something and figure it out anyway.
- You think like an operator, not a spectator.
These are the actual patterns that predict someone will succeed in early career roles. Not GPA. Not "passion." Not how well you interview.
It is whether you have already started doing the work before anyone paid you to do it.
— what's next
The cold emails still matter. The coffee chats still matter. But both of those are easier to execute now. You're not walking in with questions that anyone could ask. You're walking in with a project that proves you've thought deeply about their world.
You are now worth their time because you've already spent yours.