Skip to content

100 Job Strategies · 26 of 100

Customer First

"I've used this for eight months and here's what I'd change" is the strongest opening line in hiring.

2 viewsMedium effortPays off in 3-8 monthsProduct rolesSupport and successDesignersCareer switchers
Share

In short

Becoming a genuine user of a company's product before applying gives you something no other candidate has: months of real experience with the thing they spend every day building. It converts a generic application into a conversation between people who care about the same product, and it is available to anyone willing to spend a few months paying attention.

The situation

A product manager reads through applications for an open role. Every one of them says some version of I'm passionate about your mission and I've long admired what you're building.

Then one opens differently: I've been on your Pro plan since February. The thing I keep running into is that bulk export silently drops custom fields — I've worked around it with a script, but it's the reason two people on my team went back to spreadsheets.

That candidate is no longer applying. They are having a conversation the product manager has been wanting to have.

Why this works

Companies are built by people who think about their product constantly and rarely get to talk to anyone who has thought about it nearly as hard. Most candidates arrive having skimmed the website that morning.

Being a real user inverts that completely. You arrive with months of accumulated, specific observation — the friction nobody documented, the feature that does not behave as advertised, the workflow that is genuinely excellent. None of it is researchable. It only comes from use.

That specificity does three things at once. It proves effort in a way that cannot be faked, because nobody can manufacture eight months of usage in an afternoon. It demonstrates judgement, since what you noticed reveals how you think. And it makes you immediately useful — you are already a source of the customer insight the team is paid to gather.

There is a structural advantage too. Product, support, marketing and design roles all involve reasoning about users. Being one is a working demonstration of the core skill rather than a claim about it. And interviews stop being interrogations and become discussions between two people who know the same product, which is a far better environment for you.

The cost is patience. This works because it takes months, which is exactly why very few candidates do it.

How to run it

  1. 1

    Use it properly, not once

    Sign up, pay if you can afford the tier, and use it for real work over months. A weekend of clicking around produces observations anyone could make.

  2. 2

    Keep a running log of friction

    Every time something confuses or blocks you, write it down with the date and context. In six months that file is the most valuable document in your application.

  3. 3

    Notice what is genuinely good too

    A list of only complaints reads as hostile. Naming what works shows judgement and tells them you understand the trade-offs behind their decisions.

  4. 4

    Talk to other users

    Their community, forum or subreddit tells you which frictions are widespread and which are yours alone. That distinction is what separates an opinion from insight.

  5. 5

    Lead the application with the usage

    First line: how long you have used it, on what plan, for what. Everything else in your application is read differently once that is established.

  6. 6

    Bring the log to the interview

    Not as a list of grievances, but as evidence of how you think. Pick two or three items and explain what you would investigate before changing anything.

What to say

Copy, then make it yours
Hi Nadia, I'm applying for the product manager role. Before anything else: I've been a paying user since February, on the Team plan, using it to run editorial planning for a six-person content team. Three things I've observed in that time, for whatever they're worth: • Bulk export drops custom fields without warning. We lost a week of taxonomy work to it before I noticed. • The approval flow is genuinely the best I've used — it's the reason we moved off our previous tool. • Every new person on my team has asked the same question in week one, about the difference between archived and closed. I'd rather talk about the product than about myself, honestly. My CV is attached for the formalities. — Joon-ho

When it does not work

  • Turning it into a complaint list. Arriving with only criticism reads as someone who will be difficult. Balance is what makes it sound like judgement rather than grievance.
  • Pretending to be a user you are not. A week of trial usage described as months collapses the moment anyone asks a specific question. This only works if it is true.
  • Assuming your use case is universal. The friction that bothers you may affect four customers. Checking against the community before presenting it as a priority prevents an embarrassing correction.
  • Products you genuinely cannot afford. Some tools are enterprise-priced and inaccessible to individuals. Free tiers, trials and open-source alternatives sometimes work; sometimes this strategy is simply unavailable.
  • Explaining their own product back to them. The team knows their roadmap. Presenting a known issue as a discovery lands poorly — ask whether they are aware rather than announcing it.
The takeaway

Everyone claims to admire the product. Almost nobody has actually used it — and eight months of real usage cannot be manufactured the night before.

Questions

How long do I need to use the product for this to work?

Long enough to have observations that could not come from a demo, which in practice means at least two to three months of genuine use. The specificity is the whole point: noticing that a feature breaks under a particular condition, or that every new team member asks the same question in week one, requires accumulated exposure. A weekend of exploration produces the kind of surface-level comment any candidate could make after reading the marketing site.

What if I cannot afford the product?

Free tiers and trial periods are often enough, particularly for consumer and small-business tools, and using a free tier honestly described as such is perfectly credible. For genuinely enterprise-priced software this strategy may simply be unavailable to you, and that is worth accepting rather than faking. In those cases, the adjacent move is using a competitor seriously and applying with comparative insight, which is less powerful but still far better than nothing.

Should I lead with criticism or praise?

Both, deliberately balanced, with the praise doing real work rather than functioning as flattery. A message containing only problems reads as someone who will be exhausting to work with, while one containing only compliments contains no information. Naming what genuinely works demonstrates that you understand the trade-offs behind their decisions, which makes your criticisms land as considered judgement rather than as a list of things that annoyed you.

Does this work for engineering roles?

It works well for anything user-facing and reasonably for engineering, though the emphasis shifts. For engineers the useful version is technical: how their API behaves under load, where the documentation is wrong, what breaks at scale, how their open-source components are maintained. That is closer to genuine technical evaluation than to product feedback, and it demonstrates exactly the judgement the role requires.

Build your free Drivetube Profile
Share

More from 100 Job Strategies

See all 50 in this series