A plain-English wiki to the people who imagine, design, and ship software products — Product Managers, UX Researchers, Designers, Writers, and the operators who hold it all together. Built for the recruiter who has never opened Figma or written a user story.
Before we list job titles, let's demystify the work. "Product Development" in a software company means the entire chain of people who turn a vague idea — "we should help small businesses do their taxes" — into a real, usable app on a phone or website. It is part research, part craft, part construction project. The people you'll meet in this guide do not all write code. Most of them spend their days in conversations, sticky notes, spreadsheets, and a tool called Figma — figuring out what to build, why, and what it should look like.
Product Development is a team sport. Engineers build. But before a single line of code is written, a Product Manager has decided what to build, a Researcher has confirmed users actually want it, and a Designer has drawn what it will look like. These non-engineering roles are what this guide focuses on.
At a software product company, the product is the business. Slack, Notion, Figma, Canva — these companies don't sell consulting hours; they sell access to a tool. That means the product team has enormous influence: a small UX change can shift millions in revenue.
This is the surprise for many recruiters: a strong Product Manager doesn't have to know how to code. A great Designer doesn't either. What they need is curiosity, empathy for users, taste, and the ability to write clearly. Don't screen them out for missing programming skills — most jobs don't require any.
Every product company runs some version of this five-stage cycle. Different roles "own" different stages. Understanding which stage a candidate has experience in is the single most useful filter you can apply when evaluating their resume.
Talk to users. Find a problem worth solving. Owned by: UX Researchers, Product Managers, Product Marketing.
Decide what we'll build and why. Write the brief. Owned by: Product Managers, Product Owners, Business Analysts.
Draw the screens. Test prototypes. Pick the colours and words. Owned by: Product Designers, UX Writers, Design Systems.
Write the code. Run the sprints. Ship feature flags. Owned by: Engineering Managers, Scrum Masters, QA, Engineers.
Launch. Watch the data. Iterate. Owned by: Product Analysts, Growth PMs, Product Marketing, Customer Success.
The Product Manager (PM) is the person responsible for figuring out what the team should build next, and convincing everyone — engineers, designers, executives, customers — that it's the right choice. They don't have a team that reports to them. Their power comes from influence: they spend their days in meetings, writing documents, talking to customers, looking at usage data, and deciding which 5 things (out of 500 ideas) the team will actually work on this quarter.
Communication first. Strong writing is non-negotiable — PMs live in documents (PRDs, specs, strategy memos). Look for candidates who can summarise complex things in one paragraph.
Data literacy. They don't need to write code, but they need to be comfortable in a spreadsheet, read a dashboard, and write a basic SQL query. Mentions of Mixpanel, Amplitude, Looker, Tableau, or SQL on a resume is a strong signal.
Customer empathy. Look for evidence they have actually talked to users — past roles in support, sales, or research are gold.
Prioritisation frameworks. Bonus points for mentions of RICE, MoSCoW, Kano, or OKRs.
A Product Owner is closely related to a Product Manager, but with a tighter focus. The PO works inside an engineering team (a "scrum team") and is responsible for keeping the team's backlog (the to-do list) clean, prioritised, and full of well-written tickets. They tend to operate on a 2–4 week horizon, while a PM operates on a 6–12 month horizon. In some companies the two titles are used interchangeably; in larger enterprises (banks, telco, big SaaS) they are distinct.
Agile certifications — CSPO (Certified Scrum Product Owner), PSPO (Professional Scrum Product Owner), or SAFe POPM are common. Don't reject a candidate without one, but it's a strong positive signal.
User-story writing — they should be fluent in the "As a…, I want…, so that…" format and the concept of acceptance criteria.
Backlog grooming & sprint planning — daily standups, sprint reviews, retrospectives.
Tools: Jira (essential), Confluence, Azure DevOps in Microsoft shops.
The Product Marketing Manager is the storyteller. While the PM decides what to build, the PMM decides how to tell the world about it. They write the launch announcement, design the landing page, brief the sales team, run the press strategy, and own positioning ("we're the easy alternative to X"). They sit between the product team and the marketing/sales orgs.
Writing. Their portfolio is usually public — blog posts, product launch pages, video scripts. Always ask for samples.
Positioning & messaging frameworks. April Dunford's "Obviously Awesome" methodology is a standard reference.
Customer research & competitive intelligence. They run win/loss interviews and analyse competitors.
Sales enablement. They build pitch decks, battle cards, and demo scripts.
Tools: Highspot, Gong, HubSpot, Marketo, Webflow, Figma, Notion.
The Product Designer is the person who draws the screens. They take a problem the PM has defined, sketch out solutions, build interactive prototypes (clickable mock-ups), test those prototypes with real users, and then hand off polished designs to engineering. The modern title "Product Designer" is a merger of two older titles — "UX Designer" (focus on flows and logic) and "UI Designer" (focus on visuals and pixels). Most product designers today do both.
Figma is essential. Sketch and Adobe XD are legacy tools — most candidates should now list Figma as their primary tool. If a senior designer has not used Figma, that's a yellow flag.
A portfolio is mandatory. Always click through to it. Look for case studies that explain why they made decisions, not just pretty screenshots.
Interaction design & prototyping — building clickable flows, micro-interactions, motion.
Usability principles — Hick's Law, Fitts' Law, Gestalt principles. Bonus points for accessibility (WCAG, screen reader testing).
Design systems. Mentions of "design tokens," "component library," or naming systems like Material, Polaris, Carbon, or Atlassian Design System indicate maturity.
The UX Researcher is the team's professional listener. Their job is to talk to users — through interviews, surveys, usability tests, diary studies — and bring back insight that the team can act on. There are two main flavours: generative research (broad, exploratory: "what should we build?") and evaluative research (narrow, validating: "does this prototype work?"). Many candidates have backgrounds in psychology, anthropology, sociology, or HCI.
Research methods. Mentions of contextual inquiry, diary studies, card sorting, tree testing, usability testing, ethnographic observation are all positive signals.
Quantitative skills. Strong UXRs can run a survey, calculate statistical significance, and read regression output. Mentions of SPSS, R, Python, or SUS scores indicate quant chops.
Synthesis & storytelling. Can take 20 messy interviews and turn them into 3 actionable insights.
Tools: UserTesting, Lookback, Dovetail, Maze, Optimal Workshop, Qualtrics, SurveyMonkey.
Education: Often (not always) advanced degrees in HCI, psychology, anthropology, cognitive science.
UX Writers (or Content Designers — most teams have moved to that title) are responsible for every word in a product. Button labels, error messages, onboarding emails, empty states ("Nothing here yet — add your first project"), and tooltips are all their work. The role exists because words are interface: a confusing button label can hurt adoption more than a bad colour choice.
Writing portfolio. Public examples of microcopy, voice/tone guidelines, content patterns. Beware: a "writing portfolio" of essays is not the same as a content design portfolio.
Voice & tone frameworks. Mentions of Mailchimp Voice & Tone or "Plain English" / Plain Language guidelines.
Localisation awareness — content that translates well, doesn't rely on idioms.
Tools: Figma, Ditto, Frontitude, Lokalise, Strapi, Contentful.
A Design Systems Designer maintains the company's "design system" — a library of reusable buttons, forms, colors, fonts, and patterns that all the other designers use to build screens. Famous examples: Google's Material, Adobe's Spectrum, Atlassian's Atlassian Design System, Shopify's Polaris, IBM's Carbon. Their work is rarely seen by users directly, but it makes the entire company's product feel consistent and ship faster.
Component library architecture — variants, properties, slots, auto-layout in Figma.
Design tokens — colours, spacing, typography expressed as variables that map to code.
Documentation skills — they write a lot. Often have a public Storybook or ZeroHeight site.
Some technical familiarity — not coding, but understanding of HTML, CSS, React component props, accessibility (WCAG 2.1 AA).
The Scrum Master is the team's process coach. They run the daily standup (15-minute morning check-in), facilitate sprint planning and retrospectives, remove "blockers" (anything stopping the team from making progress), and protect the team from being interrupted mid-sprint. The role originated in Scrum, an agile methodology, and has evolved into "Delivery Manager" or "Iteration Manager" titles in many modern companies.
Certifications — CSM (Certified Scrum Master), PSM (Professional Scrum Master), SAFe SM, ICP-ACC. Many candidates hold several.
Facilitation skills — they run a lot of meetings and need to keep them focused.
Comfort with metrics — velocity, burndown charts, cycle time, lead time. Bonus for DORA metrics (deployment frequency, change failure rate).
Tools: Jira (essential), Azure DevOps, Miro, Confluence.
Soft skills: coaching, conflict resolution, servant leadership.
The Business Analyst is the requirements specialist. They sit with stakeholders (sales, finance, operations, customers), document what the business actually needs, and translate it into precise specs that engineers and PMs can act on. The BA role is most common in larger enterprises — banks, insurance companies, healthcare, government — where rules and compliance are complex. In modern startups, the PM often absorbs the BA's work.
Process modelling — BPMN, UML, flowcharts. Visio or Lucidchart skills.
Requirements documentation — Functional Requirements Documents (FRDs), Business Requirements Documents (BRDs), use cases, user stories.
SQL fluency — strong BAs can pull data themselves, not wait for analysts.
Domain expertise — banks want banking BAs, healthcare wants HIPAA-aware BAs.
Certifications: CBAP (Certified Business Analysis Professional), CCBA, IIBA-AAC, PMI-PBA.
Product Operations is a relatively new role. As product teams scale to 10, 50, or 200 PMs, someone needs to manage the system the product team uses to make decisions: which tools, which templates, which rituals. Product Ops standardises the PM playbook, manages tooling (Jira, Productboard, dashboards), runs quarterly planning, and handles the customer-feedback pipeline so PMs can focus on strategy.
Operational mindset — past roles in ops, chief-of-staff, or program management.
Tooling fluency — admin-level knowledge of Jira, Productboard, Pendo, Mixpanel, Notion.
Data + analytics — building dashboards, automating reports, SQL skills.
Process design — quarterly planning, OKR rollouts, customer feedback loops.
A QA Engineer's job is to find problems before users do. There are two main flavours: Manual QA (clicks through every screen, follows test plans, reports bugs) and QA Automation / SDET (writes code that automatically tests every version of the product before it ships). Modern product teams increasingly hire SDETs (Software Development Engineer in Test), who write automated test suites in code.
Manual QA: test plan writing, bug reporting, regression testing, TestRail, Zephyr.
Automation QA: Selenium, Playwright, Cypress, Appium (for mobile), Postman (for APIs), some Python or JavaScript. Familiarity with CI/CD (Jenkins, GitHub Actions).
Performance & load testing: JMeter, k6, Gatling.
ISTQB certification is common in larger orgs.
The Product Analyst is the PM's partner in numbers. They build dashboards that show how the product is being used, design and analyse A/B tests (experiments where users are randomly shown one of two versions of a feature), find unexpected patterns in usage data, and tell the team whether what they shipped actually moved the needle. They report to the data org but spend most of their time embedded with a product team.
SQL is non-negotiable. Strong analysts can write complex queries in their sleep.
Statistics: A/B test design, p-values, confidence intervals, sample sizing, statistical power. Look for mentions of "statistical significance," "Bayesian methods," "novelty effects."
BI tools: Looker, Tableau, Mode, Hex, Amplitude, Mixpanel.
Programming: Python (Pandas, NumPy) or R, especially for senior roles.
Storytelling: the analyst's findings have to influence decisions. Communication skills matter as much as math.
The Engineering Manager (EM) is the leader of an engineering "squad" — typically 5–10 engineers. They hire and develop their team, manage performance, set technical direction (often together with a Tech Lead), and pair with the Product Manager to plan and execute the roadmap. Many EMs are former senior engineers who decided they enjoy growing people more than writing code. The PM:EM partnership is the most important relationship in modern product teams.
Engineering background — most EMs were once senior ICs (individual contributors).
People management — 1:1s, performance reviews, hiring loops, career-pathing.
Project planning — quarterly planning, capacity modelling, dependency mapping.
Stakeholder management — partnering with PM, design, executives.
Technical depth — varies by company. Some EMs still code (10–20% of the time); others are full-time managers.
When you see these names on a résumé, you'll know what they mean, what they're used for, and which roles touch them. Each tool below has hand-picked tutorial videos so you can build a faster, sharper mental picture before your next intake call.
Figma is the digital whiteboard where the product is drawn before it gets built. Designers use it to mock up screens, run live brainstorms, and click through interactive prototypes. It runs in a browser, so the whole team can be in the same file at once — like Google Docs but for design.
What to look for on a résumé: "Figma," "FigJam" (their whiteboard tool), "Auto Layout," "Variants," "Components," "Design Systems in Figma."
Jira is where the work lives. Every feature, bug, and task is a "ticket" in Jira. Teams group those tickets into sprints (usually two-week chunks of work), drag them across columns labelled To Do · In Progress · Done, and run reports off the data. Made by Atlassian.
What to look for on a résumé: "Jira," "Confluence" (the matching wiki tool), "Atlassian," "JQL" (Jira's query language — a senior signal), "Scrum / Kanban in Jira."
Notion is part Google Doc, part wiki, part database. PMs write product specs in it. Designers post research findings. Ops teams track OKRs and onboarding checklists. Many startups use Notion instead of Confluence because it's simpler and prettier.
What to look for on a résumé: "Notion," "Notion databases," "PRD in Notion," "wiki / knowledge base management."
These three tools all do the same job: track what users do inside a product. They count things like "how many people clicked Sign Up," "how many finished onboarding," and "how often do paying users come back each week." PMs use them to decide what to build next; Analysts use them to find drop-off points in the user journey.
What to look for on a résumé: "Mixpanel," "Amplitude," "Heap," "Pendo," "funnels," "cohort analysis," "retention curves," "event tracking."
SQL (pronounced "sequel") is how you ask a database a question. Instead of clicking through a dashboard, the analyst writes a few lines that say "give me every user who signed up last month and made a purchase." It is the most common technical skill outside of engineering, and the bar for "knows SQL" is lower than people think.
What to look for on a résumé: "SQL," "BigQuery," "Snowflake," "Redshift," "Postgres," "joins," "window functions" (a senior signal), "dbt" (data engineering adjacent).
These are infinite digital whiteboards covered in sticky notes. Teams use them for brainstorming, customer journey maps, retrospective meetings, and any kind of workshop where you'd normally fill a wall with Post-its. Researchers and Designers live in these.
What to look for on a résumé: "Miro," "FigJam," "Mural," "facilitation," "design sprints," "journey mapping," "affinity diagramming."
Linear is what teams pick when they think Jira is too heavy. Same idea — tickets, sprints, projects — but stripped down and keyboard-fast. If a candidate mentions Linear, it's a small signal they've worked at a startup or a design-conscious team.
What to look for on a résumé: "Linear," "cycles" (Linear's word for sprints), "triage."
These tools help PMs collect feature requests from sales, support, and customers, then score and prioritize them into a public-facing roadmap. They sit one layer above Jira: Productboard answers "what should we build?", Jira answers "how is the build going?"
What to look for on a résumé: "Productboard," "Aha!," "Roadmunk," "feature prioritization," "roadmap ownership," "RICE / WSJF" (scoring frameworks).
These platforms help teams talk to real users. UserTesting recruits participants and records them using your product. Lookback hosts the live interview. Dovetail is where researchers tag, organize, and synthesize all the recorded clips into themes the team can act on.
What to look for on a résumé: "UserTesting," "Lookback," "Dovetail," "Maze" (unmoderated testing), "thematic analysis," "research repository."
These tools take rows of database data and turn them into charts and dashboards anyone can read. Where Mixpanel/Amplitude focus on user-event data, BI tools handle everything — finance, support tickets, supply chain, sales pipeline. Most companies use one of these three.
What to look for on a résumé: "Looker," "LookML" (its modeling language — a strong signal), "Tableau," "Power BI," "data visualization," "dashboarding."
Storybook is a living catalogue of every reusable UI piece a product uses — every button, dropdown, modal — shown in isolation so teams can see, test, and document them. If a candidate mentions Storybook, they've probably worked closely with engineers on a real design system, not just mockups in Figma.
What to look for on a résumé: "Storybook," "design system documentation," "component library," "design tokens."
Confluence is the document side of the Atlassian world — Jira's quieter sibling. Companies use it for product specs, engineering RFCs, runbooks, and onboarding docs. If you see "Jira + Confluence" together, it almost always means an enterprise environment.
What to look for on a résumé: "Confluence," "PRDs in Confluence," "RFC author," "wiki ownership."
All product names, logos, channel names, and trademarks referenced above are the property of their respective owners. YouTube channel links and subscriber estimates are provided for educational reference only. No endorsement, affiliation, or sponsorship is implied. Subscriber counts may have changed since this guide was published.
LinkedIn is fine for first-pass searches, but the strongest candidates often live in communities. The platforms below are where product people read, post, and prove their work. Each entry includes how to actually search there — not just what it is.
Use Google site search: site:github.com "product manager" "PRD" · site:github.com "design system" location:london. Also browse Trending repositories for currently-hot projects, then look at top contributors. For UX work, search for repos containing words like "component-library," "storybook," or "design-tokens."
Filter by availability for hire and location. Hiring filter is the single most useful tool here. Search by tag — SaaS, Mobile App, Dashboard — to find designers in your specific product space. Cross-check candidates' Dribbble profiles against their portfolio site for depth.
Filter by creative field (UI/UX, Web Design, Mobile) and tools used (Figma, Sketch, Adobe XD). Use the "available for hire" toggle. Behance projects show a process arc — that's better evidence than a polished dribbble shot.
Browse top creators. Search for files in your domain — fintech ui kit, design tokens, onboarding flow. Click the creator profile, then their personal site or LinkedIn from there. Many Figma plugin authors are mid-to-senior designers with deep system thinking.
Use Google: site:read.cv "product designer" "design system". Search by city: site:read.cv "based in Berlin" designer. The platform's profiles list past companies clearly, so this becomes a useful enumeration source.
Browse by school (Carnegie Mellon, RISD, ArtCenter, NID, etc.) and by company offer. The site filters by where students went after graduation — so you can find candidates with similar offer trajectories to roles you're filling.
Browse the Discussions tab and the leaderboard for recent competitions. "Kaggle Master" and "Grandmaster" badges are objective skill signals. Click into a notebook, then to the author's profile, then to their LinkedIn or portfolio link.
Browse Spaces for live demos and find their authors. The Models page lists trending uploads — top contributors there are deeply technical. For AI-PM roles, look in their forums and discussion tabs for non-engineer participants who clearly understand the field.
Search the article archive for authors writing on topics relevant to your role (e.g., "B2B onboarding" or "product-led growth"). Authors often link to their LinkedIn. The free Slack workspace has channels by region and seniority — good for warm-intro sourcing.
The job board itself ("Lenny's Talent Collective") is a closed network — applicants pre-vet themselves. Reading interview guests on the podcast also tells you exactly who the senior PM thought leaders are at any moment.
Browse Top of the Day / Week / Month and look at the Maker profile of each launch. Many makers list themselves as available for hire, advisory roles, or consulting. Particularly strong for product-marketing and 0-to-1 PM hires.
Use Twitter advanced search: ("product manager" OR "PM") "looking for" min_faves:20. Follow conference hashtags (#mtpcon, #configdesign). Lists curated by respected PMs (e.g., "PMs I trust") are gold mines.
Use Google: site:reddit.com r/userexperience portfolio review. The "Portfolio Review" weekly threads on r/UXDesign let you see real candidates posting work for critique. You can DM contributors whose portfolios stand out.
Use the third-party search at hnhiring.com. Filter by remote, by skill ("React"/"Figma"/"product"), and by geography. The "who wants to be hired" thread is reverse-recruiting — candidates self-describe ideal roles, which is rare gold.
Search top product publications: UX Collective, Product Coalition, The Product Manager's Toolkit. On Substack, look at "Recommended by" sections — Substack writers cross-promote others in their niche, which surfaces a tight network of similar voices.
Join Designer Hangout (UX), Friends of Figma (city-by-city design chapters), Mind the Product Slack (PMs by region), Research Ops Community (researchers). Most have #jobs and #introductions channels. Focus on the latter — recently introduced members are the warmest leads.
Search by tag (sql, tableau, product-management) plus location. High-reputation users in your tech stack are often quietly open to product-adjacent moves.
All platform names, logos, and trademarks above are the property of their respective owners and are referenced for educational and informational purposes only. No endorsement, partnership, or sponsorship by any platform is implied.
Each method below tests a different muscle. Knowing which one to suggest to a hiring manager — and what a good answer looks like before the loop — is what separates a fast recruiter from a great one.
Best for: Product Designer, UX Researcher, UX Writer, Design Systems Designer, Product Marketing Manager.
Candidate walks the panel through 1–3 past projects in 45 minutes. The work itself is the artifact under review.
What to look for: Story arc — problem, exploration, decisions, outcome. Self-awareness about what didn't work. Evidence of collaboration (engineers, PMs, researchers named). Numbers if possible — "increased completion rate from 41% to 67%."
Red flag: Only finished, polished pixels with no process; cannot answer "what would you change now?"; uses "we" without distinguishing personal contribution.
Best for: Product Designer, Product Manager, Product Analyst.
Candidate gets a brief (1–4 hours of work) and produces a deliverable — a redesign, a PRD, a metrics dashboard, an A/B test plan.
What to look for: How they framed the problem (or pushed back on it). Trade-offs explicitly named. Constraints respected. Documentation of assumptions. Polish appropriate to the time given — over-polish suggests poor scoping; under-polish suggests low investment.
Red flag: Take-homes that look outsourced or AI-generated; no trace of personal voice; missing the actual question and answering an easier adjacent one.
Best for: Product Designer, UX Researcher, PM (Design-fluent).
"Open Spotify (or any app). Walk us through what's working, what's not, and what you'd change first." 30–45 minutes, live.
What to look for: Empathy with non-power-users. Awareness of business model (a free-tier user critique is different from a paid-tier critique). Distinguishes opinion ("I personally don't like this") from evidence-based concern ("this hides the cancellation flow, which probably hurts trust"). Suggests which to fix first and why.
Red flag: Pure aesthetic complaints. Missing accessibility, no mention of users different from themselves. Doesn't distinguish symptom from cause.
Best for: All product roles, especially management (EM, Group PM, Director).
Set list of behavioural questions ("tell me about a time you …") asked the same way to every candidate, scored against a rubric. Reduces bias and makes candidates comparable.
What to look for: Specificity — names, dates, numbers. The STAR pattern (Situation, Task, Action, Result) is fine but not a requirement. Self-reflection on what they'd do differently. Stories where they were not the hero.
Red flag: Vague stories ("we did a thing and it worked"). Stories where they're always right and others are always wrong. Inability to give a story for a question — usually means they haven't done the work.
Best for: Product Manager, Group PM, Product Marketing Manager.
Open-ended live problem: "Design a product for X user. Walk me through how you'd think about it." 45 minutes of structured improvisation.
What to look for: Clarifies scope first ("when you say 'design,' do you mean an MVP or a full product line?"). Names a target user before naming features. Picks one path and goes deep instead of listing 10 ideas shallowly. Sanity-checks for business viability and edge cases.
Red flag: Jumps straight to features. Cannot pick a user persona. Lists ideas without prioritizing them. Ignores trade-offs.
Best for: Product Analyst, Data PM, Growth PM.
Either a SQL test (write a query that answers a business question) or a metrics-design problem ("our retention dropped 8% — what would you investigate first?").
What to look for: Asks for context before writing code. States their assumptions out loud. Builds intuition before precision — sketches the answer, then writes the query. Knows what a sensible result looks like, so they spot bad data before reporting it.
Red flag: Goes straight to syntax without asking what the question means. Cannot defend why a metric matters. Confuses correlation with causation in their answer.
Best for: Engineering Manager, Scrum Master, Product Operations Manager, TPM.
"Design the on-call process for a 12-engineer team across three time zones." Or "Walk us through how you'd run a quarterly planning cycle for 50 engineers." Whiteboard or doc-based.
What to look for: Starts with goals, not tools. Names the trade-offs (e.g., "fewer rotations means fairer rest but slower response"). Considers humans, not just process. Acknowledges what they'd monitor after launching the process to know if it's working.
Red flag: Recites a methodology by name without adapting it. No mention of communication, escalation, or what happens when the process breaks.
Best for: Every role above mid-level. Often skipped or done poorly.
Talk to two former managers and two former direct reports/peers. 20 minutes each, structured questions.
What to look for: Behavioural specifics ("can you describe a time when …?"). Pattern-match across references — if three out of four mention the same blind spot, it's real. Comparative framing — "How would you rank them in your top tier of PMs / Designers you've managed?"
Red flag: Reference is over-rehearsed; volunteers only marketing language. Reference mentions the candidate would not let them be contacted by certain past managers. Vague answers to specific behavioural questions.
If you've ever nodded along in an intake call wondering what "MVP" or "JTBD" actually means, this section is for you. These are the twenty-two terms most likely to appear in a job description for any product role.
All product names, brand logos, company names, and trademarks referenced in this guide — including but not limited to Adobe, Figma, FigJam, Atlassian, Jira, Confluence, Notion, Linear, Productboard, Aha!, Mixpanel, Amplitude, Heap, Pendo, Looker, Tableau, Power BI, Storybook, UserTesting, Dovetail, Lookback, Maze, Miro, Mural, GitHub, Dribbble, Behance, Read.cv, Cofolios, Kaggle, Hugging Face, Mind the Product, Lenny's Newsletter, Product Hunt, Hacker News, Y Combinator, Stack Overflow, Reddit, Medium, Substack, Discord, Slack, X / Twitter, YouTube, and Google — are the property of their respective owners and are used here strictly for educational, descriptive, and reference purposes.
YouTube channel names, links, and approximate subscriber counts referenced in the Tools Showcase are provided for educational reference only. Subscriber counts are estimates at the time of writing and are subject to change. This guide is not affiliated with, endorsed by, or sponsored by any of the channels, creators, platforms, or companies named. All linked YouTube content remains the property of the respective creators and platform.
The screening questions, sourcing strategies, and Boolean templates included in this guide are original recruiter-craft material. You are welcome to adapt them for your own work. Please do not republish or sell this guide commercially without permission. For questions, corrections, or suggestions, reach out to the author on LinkedIn at linkedin.com/in/jollypaily.
This guide is provided "as is" with no warranties of any kind. Salary ranges, role definitions, and tool popularity all change quickly in this field — treat this volume as a starting point, not a final answer. Always validate your understanding with the hiring manager and current candidates in your market.