Write the problem before the solution
State the customer problem and why it matters in plain language before proposing any specific feature — forcing the team to agree on the problem first catches wrong solutions before anyone writes code.
Product Manager · Decides what a company should build next, and why — turning customer needs, business goals and engineering limits into one shared plan nobody else fully owns.
Darker cells mean a higher score for this topic on that metric.
LessMore
Last reviewed Sources & creditsMedia creditsMethodology
Far less building than the title suggests. A typical day mixes reviewing usage data, talking to customers or sales teams about what they need, writing or refining a specification for engineers, and sitting in planning meetings to decide what gets built next and what gets cut. Very little of the day involves writing code, drawing a screen, or shipping anything personally.
No, though it helps in software-heavy roles. Many product managers come from engineering, but plenty arrive from design, marketing, consulting or customer support instead. What matters more than a specific degree is being able to read data, write clearly, and hold your own in a room with engineers without needing to write the code yourself.
No, despite the similar title. A project manager tracks whether work is on schedule and on budget, coordinating timelines across a team. A product manager decides what should be built in the first place and why, owning the underlying business and customer reasoning. Many companies blur the two roles in practice, especially at smaller organisations, but the core question each answers is different.
No. Product managers almost never have engineers, designers or anyone else reporting to them directly — the job is often described as leading through influence rather than authority. A product manager sets priorities and the reasoning behind them, but an engineering manager or team lead usually decides how the work actually gets done and by whom.
It varies enormously by country and company. In the United States, total compensation at a large technology company commonly runs well into six figures once bonus and stock are included, while in India or much of Latin America the equivalent role pays a fraction of that. Base salary alone, without stock, is typically closer to a senior engineer's pay at the same company.
Parts of the job that involve summarising data, drafting a first version of a specification, or synthesising customer feedback are already faster with AI tools. What remains hard to automate is deciding which idea is worth pursuing at all, negotiating trade-offs among people who disagree, and being accountable when a bet does not pay off — judgment calls a model cannot be held responsible for.
The image of a product manager sketching a bold vision on a whiteboard is mostly wrong. Most of the job is unglamorous synthesis: reading survey and analytics data, writing a document precise enough that an engineer cannot misread it, and sitting through meetings where the real work is getting several disagreeing people to commit to one plan.
The craft passed down inside the discipline is less about a single tool and more about habits: how to say no to a good idea because it is the wrong idea right now, how to write a specification that survives contact with an actual engineer, and when to trust what a customer does over what they say they prefer.
Deciding what not to build is the single most consequential daily decision — a roadmap is mostly a long list of good ideas a product manager chose to say no to.
A specification, a roadmap update or a post-mortem has to be precise enough that people who were not in the room can act on it correctly.
Getting engineering, design, sales and executives to commit to the same plan with almost no formal authority over any of them — often summarized as 'leading without power'.
Reading usage data and experiment results well enough to tell a real signal from noise, and to know when a metric is being gamed rather than genuinely improved.
Talking directly to customers and watching them use a product, rather than relying only on what a survey or a sales team's secondhand account says they want.
Understanding enough about how the underlying system works to have a real conversation about trade-offs with engineers, without necessarily being able to build it themselves.
Catching up on messages and checking overnight dashboards for anything that broke or moved unexpectedly before the day's meetings start.
A daily standup with the immediate product team, plus recurring meetings with design, engineering leads or a dependent team to unblock work and resolve disagreements.
The best-protected block of the day, spent writing or revising a specification, analyzing an experiment's results, or preparing a document for an upcoming decision.
A genuine break on a good day; on a bad one it disappears into back-to-back meetings that ran long.
The heaviest meeting block of the day: roadmap reviews, design critiques, sales or customer calls, and the negotiations that decide what actually ships next quarter.
Personal time, though a launch week or an urgent customer escalation can pull a product manager back in over Slack well after the workday officially ends.
Craft knowledge practitioners actually pass on — not motivation.
State the customer problem and why it matters in plain language before proposing any specific feature — forcing the team to agree on the problem first catches wrong solutions before anyone writes code.
A survey tells you what people say they want; watching someone actually try to use a product, in person or over a screen share, reveals the friction they never thought to mention.
Before building a full feature, cut it down to the smallest version that tests the assumption most likely to be wrong — sometimes a single button that measures clicks before anything behind it exists.
Set direction and make the final call when people disagree, but earn that authority through preparation and judgment rather than assuming it comes with the title — a product manager with no organizational power has to be right more often than a manager who can simply give an order.
Rejecting a feature request quietly breeds resentment; writing one sentence explaining the trade-off — why this, not that, this quarter — turns a no into a decision people can actually argue with or accept.
If a proposed success metric hasn't visibly changed after multiple past efforts to move it, question whether it is really the right measure before betting a quarter's roadmap on shifting it.
Tools like Amplitude, Mixpanel or an internal dashboard turn raw usage logs into funnels and cohorts a product manager can actually reason about.
Jira, Linear or a similar tool turns a list of ideas into a prioritized, visible backlog that engineering, design and leadership can all see at once.
A structured document format — problem, goal, requirements, edge cases, success metric — that keeps a specification legible enough for an engineer to build against without guessing.
Tools like Optimizely or an internal experimentation framework let a team ship two versions of a feature to different users and measure which one actually performs better.
Tools like ChatGPT or Claude increasingly draft a first version of a specification, summarize user interviews or synthesize survey responses, shifting the job toward editing and judgment rather than typing from a blank page.
Measuring success by how many features shipped rather than whether any of them solved a real problem, which produces a busy roadmap and a product that doesn't actually improve.
Treating one vocal customer's specific feature request as a representative need, rather than checking whether it reflects a problem shared by a meaningful share of users.
Writing a detailed list of requirements without explaining the underlying problem or goal leaves engineers unable to make good judgment calls once reality inevitably diverges from the plan.
Closest neighbours on the six-score profile — not the same field only.
Finds patterns and builds predictive models from data — a 2008 job title built on three centuries of counting, testing and visualizing evidence.
AI-resistant 38 🔎Studies how people use products, turning observed behavior, needs and frustrations into evidence teams can design around.
AI-resistant 69 📣The professional who creates demand — from Pompeii's painted walls and P&G's 1931 brand-man memo to the auction-driven feeds of the digital era.
AI-resistant 38 🎮The architect of play — the person who decides what a game asks of its players, from Senet's ancient board to Tetris and today's three-billion-player industry.
AI-resistant 65 🧾The keeper of the books: heir to a craft so old it invented writing itself, now negotiating with the software built to automate it.
AI-resistant 35 💻Writes, tests and maintains the code that runs modern life — and is one of the first professions watching AI automate its own daily work.
AI-resistant 35The person who starts the company — spotting the gap, bearing the risk and answering for payroll, from Assyrian caravan financiers to venture-backed founders.
AI-resistant 88 💹The dealmaker who prices companies and moves capital — a trade running from Medici Florence to today's pitch decks, paid for trust when billions change hands.
AI-resistant 42 🧾The keeper of the books: heir to a craft so old it invented writing itself, now negotiating with the software built to automate it.
AI-resistant 35 📣The professional who creates demand — from Pompeii's painted walls and P&G's 1931 brand-man memo to the auction-driven feeds of the digital era.
AI-resistant 38 💱The scholar of scarcity — from Adam Smith's pin factory to the central-bank decision room, still asked to predict what no model fully captures.
AI-resistant 62 🌿Leads the strategy, measurement and reporting that helps organizations reduce environmental and social harm while meeting business obligations.
AI-resistant 66