Product manager: can you get in without experience?

What the job is

Deciding what to build and why. Not "having ideas" but establishing which user problem is worth solving and proving it will pay off for the business.

Ordinary work: talking to users, analysing data, forming hypotheses, prioritising, specifying work for the team, assessing the result after release.

The key word is prioritising. There are always more ideas than hands. A product manager's job is to pick, from twenty possible things, the three that will do the most.

Why direct entry is hard

Context is required. To decide what to build you must understand users, the market, the team's constraints and the economics. All of it comes from experience.

Mistakes are expensive. A wrongly chosen direction costs months of a team's work. Companies don't hand such decisions to beginners.

There are almost no entry-level roles. They exist but are rare and heavily contested.

Honestly: this isn't a profession you enter from nothing after six months of courses. Promises to the contrary deserve scepticism.

Which indirect routes work

Moving within a company. The commonest path. Analysts, testers, developers, support staff already understand the product. They take on some product work and gradually cross over.

From an adjacent field with domain knowledge. Worked in logistics and moving into a logistics product? Your industry knowledge outweighs your lack of product experience.

Through analysis. An analyst who doesn't merely calculate but proposes what to do with the result naturally moves in this direction.

Your own project. Radical but effective: build something, take it to users, learn from real decisions.

What to learn

Working with data. Database queries, metrics, interpretation. A product manager who can't look at the numbers themselves depends on someone else's schedule.

User research. How to talk to people so you get the truth rather than politeness. How to distinguish what someone says from what they do.

Product economics. Acquisition cost, retention, payback. Without it, conversations with the business don't work.

Prioritisation. Various frameworks exist; the principle matters more: compare value against cost rather than choosing by who asks loudest.

Development basics. Not programming, but understanding what makes up a timeline and why "just add a button" sometimes takes two weeks.

What makes an application convincing

Specific decisions with results. Not "participated in developing the product" but "noticed half the people abandon sign-up at step three, proposed removing it, completion rose by this much".

Comfort with numbers. Being able to explain why you consider something important in the language of metrics.

Experience with a team. The ability to turn "I want it like this" into work developers can act on.

The last is the easiest to acquire: take on the product side of any team project. Deciding what to build first, justifying it, then honestly assessing the outcome is exactly the work an interview will ask about.