Product and Business Analysis
Deciding what should be built and why. The main route into tech for people who are analytical but do not want to write code all day.
Last reviewed 6 August 2026.
What the job is actually like
Talking to people, mostly. Understanding what users are struggling with, working out which problems are worth solving, writing it down precisely enough that engineers can build it, and then saying no to the many other things people want. A lot of the job is holding a clear picture of the goal while everyone around you optimises for their own part of it. Very little of it is inventing features in a room alone.
This suits you if
- You ask "why" more than "how", and keep asking after the first answer
- You can hold an unpopular position without becoming difficult about it
- You write clearly — ambiguity in a spec becomes a bug later
Probably not, if
- You want clear technical ownership; the responsibility here is diffuse
- Being accountable for outcomes you cannot directly control would frustrate you
A roadmap
Lengths are what this typically takes alongside other commitments, not a promise. The "prove it" line matters more than the timeline — that is what someone hiring will look at.
-
Learn to interrogate a problem
Distinguishing what someone asks for from what they actually need. Practising this on any process near you — a college society, a family business, a part-time job — is real experience, whatever your degree was.
-
Data literacy
Enough SQL to answer your own questions without waiting for someone else, plus enough statistics to avoid drawing confident conclusions from noise.
-
Enough technical grounding to be credible
APIs, databases, what makes something expensive to build. You do not need to code professionally, but you must understand why an engineer says something is hard.
-
Writing
Specifications, decision documents, summaries that busy people read. This is the single most underrated skill on this path and the one most visible in an interview.
-
Ship something with other people
Any project where you were responsible for what got built rather than for building it. Scope and constraints are the lesson.
What AI has changed
Drafting, summarising and first-pass user research synthesis are much faster now, which compresses the busywork this role used to carry. Building software has also got cheaper, and that has a counterintuitive effect: when building is cheap, deciding what to build correctly matters more, because the cost of confidently building the wrong thing has not fallen at all. The parts that have not been automated are the ones requiring accountability — sitting with a frustrated customer, making a call under genuine uncertainty, and owning it when that call was wrong.
Common mistakes
- Treating it as a role for people who like meetings. The good ones reduce meetings.
- Writing wishlists instead of specifications, then blaming engineering for the result.
- Chasing the job title straight from graduation; many arrive via support, analysis, QA or engineering.
- Deciding by opinion when the data was available and you did not look.
- Saying yes to everything, which is the fastest way to build something incoherent.
This is the most common destination for graduates who are analytical, organised and communicative but do not want to spend their days in code — including people from commerce, economics and humanities backgrounds.
The trap is that it is rarely a first job. The realistic route is to enter adjacent — support, operations, analysis, testing — become the person who understands why things are the way they are, and move across. That path is unglamorous, well trodden, and works.
Career advice is opinion shaped by a moment in time, and this page says which moment. Weigh it against people actually doing the job now — their account of the last six months is worth more than any guide.