The Product Manager title is rarely the starting line. I watched a smart operator spend weeks sending out generic applications, each resume polished just enough to be ignored, while the people getting interviews had something subtler, a trail of product judgment. That's the pattern most career guides miss when they explain how to become a product manager.
When this path is handled badly, people collect certificates, copy resume templates, and wait for permission. Then they hit the same wall, no proof of customer understanding, no evidence of tradeoffs, no sign they can define success metrics or coordinate across functions. A hiring manager doesn't need another enthusiastic applicant, they need someone who can translate messy needs into real decisions.
The path opens up when you stop chasing the title and start building product thinking in adjacent work. That's where the practical options come in, and it's why I'm going to map the most believable routes, the skills they transfer, and the portfolio artifacts that help you get past the first screen. A strong guide to writing a PM resume can help with presentation, but the substance has to come from your work.
Why the best Product Manager candidates already think in products
A good Product Manager is already doing the job before the title appears. Atlassian describes the role as defining strategy, roadmap, features, customer needs, business alignment, success criteria, and team execution, which is why hiring managers look for proof of judgment, not just interest in the role (Atlassian). If you're still waiting for a formal Product Manager role to start practicing, you're losing time.
I've seen this most clearly in people who sit next to product work without owning it. An engineer writes the design doc, a designer frames the flow, a support lead hears the pain, and an ops lead spots the bottleneck. The people who move fastest into Product Manager roles are the ones who start turning those observations into decisions.
Practical rule: your first Product Manager artifact should show how you choose, not just what you know.
That's the basic gist of the transition. Hiring teams don't need a perfect identity story, they need evidence that you can handle ambiguity, prioritize tradeoffs, and rally other people around a direction. Coursera notes that Product Managers typically need at least a bachelor's degree and often come from business, marketing, computer science, or engineering, while Forbes points out that an MBA isn't required because relevant experience and technical know-how matter more, which is another way of saying the path is broader than people think (Masters in Data Science).
The important zoom-out is this, product hiring is increasingly proof-based. That changes the economics of career switching. Credentials still matter, but visible artifacts carry more weight because they lower the hiring manager's risk before the interview even starts. If you can show product judgment in a portfolio, you're not asking to be believed, you're making belief easier.
The engineering path rewards technical credibility and product judgment
Engineers have one of the clearest paths into Product Manager work because they already understand feasibility, architecture, and implementation tradeoffs. I've watched software engineers move into product by becoming the person in the room who can say what is possible, what is expensive, and what is likely to break later. That kind of judgment matters long before you own a roadmap.
A strong engineering candidate already knows how systems behave under pressure. The shift is learning to translate that knowledge into customer-facing choices, company priorities, and language that non-technical stakeholders can use. That means writing for product decisions, not just for the engineering team in Slack.
A strong engineering-to-product portfolio usually includes:
A short PRD or product brief: Show how you framed the problem, not just the implementation.
A tradeoff memo: Explain what you cut, what you kept, and why.
A customer interview summary: Demonstrate that you can listen, synthesize, and prioritize.
A release decision note: Tie the decision back to success criteria, not personal preference.
The signal is not that you can build fast. It is that you can reduce uncertainty before the team commits. A product manager keeps asking which risk matters most, what can wait, and what evidence is strong enough to move forward. Engineers who make that shift stand out because they already have the technical credibility to challenge assumptions and the judgment to avoid overbuilding.
I've seen this change the way hiring teams react. A friend at a Series C company said the first time he was taken seriously as a Product Manager candidate was when he stopped describing his work as “I built X” and started describing it as “I reduced uncertainty around Y.” That language tells teams you understand the function, not just the toolchain.
For this path, the most useful bridge is a product requirements document guide that shows how to frame intent, edge cases, and handoff language. I'd pair that with Figr's PRD and docs workflow if you want to see how context can turn into structured product artifacts faster. Figr's value here is simple, it helps teams start from real product context, not a blank page.
If you want a second artifact that shows product judgment, use collecting feedback for product growth as a model for turning scattered input into a decision-ready summary. Engineers who can do that are rarely just seen as builders. They become people who can shape the direction of the work.
The outcome you want is credibility plus range. Technical depth gets you into the conversation. Product judgment keeps you there.
Designers become Product Managers by turning empathy into decisions
Designers already know how users struggle, where flows break, and why polished screens still fail in the world. That's why designer-to-Product Manager transitions are often stronger than they look on paper. The leap happens when you stop optimizing the interface in isolation and start defending the business and product consequences of each choice.
Where the gap actually is
The gap isn't taste, and it isn't visual craft. It's scope. Designers often have strong instincts about the user experience, but Product Manager work asks for broader ownership, especially when a feature has to satisfy customer needs, engineering limits, and company objectives at the same time. That's where your portfolio needs to prove strategic thinking, not just interface quality.
A practical designer-to-product portfolio can include:
A research synthesis: Summarize what changed after interviews or observation.
A flow decision: Show why one path was chosen over another.
A metrics note: Connect the design choice to a business or product outcome.
A stakeholder review artifact: Demonstrate how you handled disagreement.
I've seen designers struggle when they keep presenting beautiful work without business context. The teams that trust them as Product Manager candidates are the ones who can hear a sales objection, a support escalation, or a roadmap conflict and translate it into a product choice.
If you want a useful reference point, the UX design process steps article is a good reminder that design already moves through problem framing, validation, and iteration. Pair that with the Figr gallery to study how structured product context shows up in real output, then ask whether your own portfolio shows the same kind of decision trail. It doesn't need to be flashy. It needs to be legible.
What works here is empathy plus restraint. Designers who become strong Product Managers know when to say no to a delightful idea that doesn't support the strategy. Isn't that the actual job, deciding what not to ship?
Sales to Product Manager means turning customer noise into pattern recognition
Sales professionals often know the customer better than the product team does, because they hear objections, buying triggers, and deal friction in real time. That gives this path a clear advantage, especially in enterprise software where buying behavior and product value are tightly linked. The challenge is learning to synthesize what you hear instead of repeating it back as anecdote.
From deal talk to product signal
A strong sales-to-product transition starts when you stop treating every request as equally important. Some feedback reflects one account's pressure, some reflects a recurring market need, and some is just a workaround disguised as a feature ask. Product Manager candidates from sales have to prove they can tell the difference.
That's where collecting feedback for product growth becomes more than a support task. It becomes a discipline. The habit to build is simple, capture the quote, classify the pattern, and show how the signal would change the roadmap.
I've watched sales leaders earn Product Manager trust by bringing a crisp feedback loop into product reviews. They don't just say, “Customers want this.” They say, “This objection keeps recurring in late-stage deals, it points to a specific workflow gap, and here's the evidence trail.” That language changes the room.
A useful portfolio of thinking for this path includes:
A customer pain map: Group objections by theme, not by account.
A deal-to-feature memo: Explain how product changes could reduce friction.
A retention or expansion note: Show how product usage connects to buying behavior.
A prioritization rationale: Make the tradeoff visible, not hidden.
A strong citation point here is Lenny's Newsletter, especially on product strategy and metrics, because sales-to-product candidates need to sharpen their analytical lens as much as their customer intuition. The point isn't to become less customer-focused. It's to become more useful to the roadmap.
Customer intelligence with structure is the outcome. That's what helps you move from “great at selling” to “trusted with product decisions.”
Analytics and data science paths work when you can pair evidence with empathy
People with analytics or data science backgrounds often have the cleanest grip on measurement, experimentation, and uncertainty. They know how to spot a trend, validate a hypothesis, and challenge a weak conclusion. But data alone doesn't make a Product Manager candidate. You also need to understand why the metric moved, who it affected, and what users were trying to do.
What data people need to add
The weak version of this transition is staying in dashboard mode. The stronger version is learning to ask what behavior sits underneath the chart. Product Manager work needs both. That's why the most useful portfolio artifacts from this path show how a data insight turned into a product decision.
A practical portfolio could include:
A metric narrative: Explain what changed and what you think caused it.
A cohort summary: Show how you read behavior over time.
A hypothesis memo: Connect an observed issue to a product fix.
A research bridge: Show how user interviews changed your interpretation of the data.
Masters in Data Science reports a median annual salary of $142,170 in 2019 for Product Managers, and it also recommends coursework in business, economics, finance, computer science, mathematics, and statistics for people considering the role (Masters in Data Science). That combination matters because the job rewards both quantitative fluency and product judgment.
Practical rule: if your story only explains the chart, it's not yet a Product Manager story.
I've seen data professionals do well when they learn to sit in customer interviews and support calls, not just in notebooks. They start hearing the context behind the numbers, and that changes how they think about scope. The most credible analytics-to-product candidates can explain why a funnel broke, then propose a fix that a designer and engineer can ship.
For a deeper product analytics lens, behavioral analytics for product teams is useful because it shows how behavior is interpreted inside product work, not just reported. That's also where Figr fits naturally, since its workflow can ingest analytics context alongside live product screens and docs, which helps teams ground product artifacts in the same evidence they're already using.
The outcome here is sharper product intuition. Data gives you confidence. Product experience gives you judgment.
Customer success candidates win when they can turn retention pain into roadmap clarity
Customer success teams sit closest to churn, renewal pressure, and expansion work. They see where implementation breaks, where adoption stalls, and where customers stop trusting the product. That makes this one of the most practical routes into Product Manager work, because the customer outcomes are already visible in your day-to-day work.
Why retention experience transfers so well
The main advantage is proximity to consequences. Customer success teams know what happens when a workflow is confusing or a feature is missing, and they know which complaints are one-offs versus signs of a deeper product gap. That insight matters only when it becomes a roadmap argument that product, design, and engineering can act on.
The strongest portfolio for this path is tied to outcomes, not anecdotes. Focus on customer segments, recurring blockers, and the product changes that would reduce friction. A strong artifact might show how you grouped churn risk themes, proposed a product fix, and explained the success criteria in language a Product Manager would use.
A useful set of artifacts includes:
A churn themes brief: Group the reasons customers leave or stall.
A roadmap influence memo: Show how escalation patterns shaped priority.
A renewal risk analysis: Tie product usage to business outcomes.
A customer interview guide: Show how you ask sharper questions.
A cited reference that fits this mindset is Mind the Product, especially because product strategy articles there often connect discovery and delivery in a way that resonates with customer-facing operators. The core lesson is straightforward, retention work gives you strong signal, but Product Manager work asks you to turn signal into structure.
I've seen customer success leaders make this shift when they stop speaking only for the customer and start speaking for the product system. That requires a different kind of judgment. It means understanding not just what would help one account, but what would scale across the segment.
That same instinct also matters for churn analysis and retention diagnosis. If you want a practical way to connect support pain to product decisions, AI to reduce user churn shows how teams translate recurring drop-off patterns into product action.
The outcome is a candidate who can talk about customer pain with precision and product decisions with discipline.
Marketing to Product Manager requires positioning instincts plus a stronger product lens
Marketing professionals often understand messaging, positioning, and demand better than anyone else in the building. They know what resonates, what confuses buyers, and what makes a product feel credible in the market. That gives them a useful starting point, but the transition only works when they move beyond campaign thinking.
The gap between messaging and product ownership
Product Manager work is broader than positioning. It includes what the product should do, how it should behave, and what tradeoffs the team should accept to ship it. That means marketing candidates need to show they can think in product outcomes, not just awareness or pipeline outcomes.
A good portfolio for this path might include:
A positioning-to-product memo: Show how messaging insights changed a feature decision.
A customer research summary: Translate market language into product priorities.
A launch postmortem: Explain what happened after the release and why.
A metric note: Connect product changes to user behavior, not just campaign performance.
I've seen this path work best for people who have already influenced product roadmap through product marketing, demand generation, or marketing operations. They're not starting from zero. They're just formalizing the thinking they've already been doing.
For this group, Lenny's Newsletter is a solid external reference because the strategy and metrics discussions sharpen the move from positioning to product judgment. The bigger point is that marketing instinct is useful, but it's only one slice of the job.
What works is when a marketing candidate can say, “This message resonates because the product solves this pain,” and then prove it with research or usage data. That's the difference between being close to product and being trusted with product decisions.
Operations experience gives you systems thinking, but you still need customer empathy
Operations people are often the best at seeing the machine. They know where processes stall, which teams create bottlenecks, and how to keep work moving across functions. That makes operations-to-Product Manager transitions especially credible in products where workflows, dependencies, and handoffs matter.
Systems thinking is useful, but it isn't enough
The risk in this path is over-optimizing for internal efficiency. Product Manager work needs that systems perspective, but it also needs customer-centered framing. A process can be efficient and still be wrong for the user. That's a hard lesson for many operations leaders, because their instincts are built around scaling the business.
A good portfolio artifact here might show:
A bottleneck analysis: Explain where the product or workflow slows people down.
A cross-functional decision note: Show how you balanced competing priorities.
A user research summary: Prove you talked to the people affected by the process.
A workflow redesign brief: Connect operational insight to product change.
I've seen operations candidates do well when they pair process discipline with customer observation. They don't just map the workflow, they go talk to users and ask where the process fails them in practice. That's what turns an operations profile into a Product Manager profile.
A strong fit for this path is Mind the Product, because the best product discovery writing there reinforces the gap between internal efficiency and user value. The outcome you want is not a cleaner process diagram. It's a clearer argument for how the product should change.
If you've built a system that helps the business run better, that's a useful starting point. If you can explain how it helps the customer too, you're much closer to Product Manager territory.
Bootcamp graduates need proof, not just structure
Bootcamps and certificate programs can be useful because they organize product concepts, but they don't substitute for product evidence. That's the part people underestimate. Product management is not a theory exam. It's a judgment job, and the hiring manager wants to see whether you can make decisions with imperfect information.
What a credible switcher portfolio looks like
People coming from nonprofit, education, government, consulting, or an unrelated corporate role need to build a visible trail. That usually means artifacts that show how they think through a product problem from scratch. The strongest candidates don't wait for a title to start practicing.
A useful portfolio of thinking here includes:
A mock PRD: Keep it grounded in a real user problem.
A user flow: Show how someone would move through the experience.
A research synthesis: Demonstrate what you learned and what changed.
A prioritization note: Explain why one solution won.
A credible transition usually also includes direct conversations with working Product Managers. Yale's transition guide says aspiring Product Managers should gain experience through their current role or side projects, network with working Product Managers, and tailor resumes and interviews carefully, which matches what I've seen in practice (Yale SOM CDO). Indeed also recommends side projects and a portfolio that documents milestones, which is the kind of visible evidence hiring teams trust (Indeed).
If you're using formal learning, product management certification content should be treated as support, not proof. The proof is the artifact, the conversation, and the way you explain your choices. That's also where Figr's workflow can help, because it turns live context, docs, and product evidence into materials that look and feel closer to real PM work.
The outcome here is simple. If you can't yet claim Product Manager experience, you can still build Product Manager evidence.
How to choose the right path and build a portfolio of thinking
The fastest route into product management is the one that matches your current evidence. If you already know code, take the engineering path. If you already know users, take the design or customer success path. If you already know numbers, take the analytics path. If you already know the market, take the marketing path. Why make the leap harder than it needs to be?
Build one artifact that proves product judgment
You don't need a giant portfolio. You need one strong artifact that shows how you think under uncertainty. That could be a PRD, a customer interview synthesis, a tradeoff memo, a user flow, or a prioritization brief. The point is to show a hiring manager that you can move from observation to decision.
Use this filter:
What problem did I see?
What options did I consider?
What evidence changed my mind?
What outcome would I expect if this shipped?
That sequence maps cleanly to how real Product Managers work. It also keeps you from building projects that look polished but say nothing about judgment. I've reviewed plenty of candidate work that looked nice and answered no hard questions. That's the trap.
A useful external signal for this kind of thinking is Lenny's Newsletter, because it rewards the habit of articulating why a decision was made, not just what the decision was. For a product team artifact workflow, Figr's questions workflow and Figr's planning workflow are relevant because they reflect the same discipline, gather context, ask better questions, then shape the work before execution.
The basic gist is this, the title comes after the evidence. Build the evidence first.
The Visual Context Graph explains why strong Product Manager work starts with context
The Visual Context Graph is Figr's core idea, and it maps cleanly to Product Manager work because good product decisions are only as strong as the context behind them. The five layers are visual context, behavioral context, design system context, product knowledge context, and implementation context. If one of those layers is missing, the decision usually gets weaker.
Why all five layers matter
A Product Manager doesn't need to draw every screen, but they do need to know what the product looks like, how people behave inside it, what rules the system already follows, what the business knows, and what engineering can realistically ship. That's the same logic Figr uses when it ingests live screens, design systems, docs, and analytics. It gives the team a richer starting point than a blank canvas.
Here's the practical benefit for someone learning how to become a product manager. If you're building a portfolio artifact, you can use the same mental model.
Visual context keeps your proposal grounded in the current experience.
Behavioral context helps you explain where users drop off or hesitate.
Design system context keeps your recommendation consistent with existing patterns.
Product knowledge context reminds you of the roadmap, strategy, and constraints.
Implementation context forces you to respect engineering reality.
I've seen candidates get stronger the moment they stop submitting abstract ideas and start showing context-rich thinking. That's where Figr's product management best practices topic becomes relevant, because the best PM work is never just about ideas. It's about fitting those ideas into the product that already exists.
If you want a practical way to ground your own portfolio, the Figr solution for research and PRD work is a good example of how context can move into artifact generation without flattening judgment. That matters here because the transition into product management is not about making pretty output. It's about showing how you think with the actual product in view.
The deeper takeaway is that context is the primary advantage. People can learn frameworks. They can't fake judgment very long.
Your next play is to pick one path and build one artifact
The cleanest answer to how to become a product manager is also the least glamorous one. Pick the path that matches the work you already do, then build one artifact that proves you can think like a Product Manager. Not a certificate. Not a slogan. An artifact.
A good artifact makes your next interview easier because it gives you something concrete to discuss. It also helps you see whether you enjoy the work. If writing tradeoffs, talking to users, and defending priorities feels energizing, you're probably on the right track. If it feels fake, that's useful information too.
I'd start with one of these:
An engineering candidate: write a PRD or tradeoff memo.
A designer candidate: document a research-backed feature decision.
A sales or customer success candidate: synthesize feedback into a roadmap brief.
An analytics candidate: turn a metric change into a product hypothesis.
A bootcamp switcher: create a full product case study from problem to validation.
If you do that in the next 30 days, you'll have something better than motivation. You'll have evidence. That's what hiring managers trust, and it's what makes the move from adjacent work into Product Manager work feel real.
For more perspective, explore the latest posts and compare your artifact against how real product teams talk about discovery, handoff, and decision-making. The goal isn't to sound like everyone else. It's to sound like someone who can be trusted with product decisions.
In short, the path into product management is less about entering the field and more about making your thinking visible. Choose the route that fits your background, build one artifact, and let the evidence do the heavy lifting.
Figr helps product teams turn real product context into PRDs, flows, edge-case notes, and high-fidelity prototypes that match the product they already have. If you're building a Product Manager portfolio or trying to think more clearly about tradeoffs, visit Figr and see how context changes the quality of the work.
8 Paths to Product Management, Quick Comparison
Engineering → Product Management
The technical credibility path
Implementation complexity: Moderate. Engineers already understand technical constraints, but they must develop stronger customer, business, prioritization, and communication skills.
Resources required: Three to five years of engineering experience, product mentorship, and exposure to design, customer research, sales, and go-to-market teams.
Expected outcomes: Technically realistic roadmaps, faster collaboration with engineering teams, and more credible decisions around scope, architecture, and trade-offs.
Best suited for: Infrastructure products, developer tools, technical platforms, and early-stage startups where feasibility significantly shapes product decisions.
Key advantages: Deep technical credibility, strong system-level thinking, and the ability to evaluate technical risks without relying entirely on engineering teams.
Design → Product Management
The user-centred empathy path
Implementation complexity: Moderate. Designers must expand beyond user experience and visual decisions into business strategy, metrics, prioritization, and commercial outcomes.
Resources required: A portfolio demonstrating product outcomes, experience conducting user research, and regular collaboration with engineering, analytics, marketing, and leadership teams.
Expected outcomes: More user-centred roadmaps, stronger UX-led prioritization, and product decisions grounded in customer behaviour and usability.
Best suited for: Consumer applications, UX-led SaaS products, design systems, and products where interaction quality is a major differentiator.
Key advantages: Strong user empathy, visual storytelling ability, product intuition, and a refined understanding of how users interact with digital experiences.
Sales → Product Management
The customer intelligence path
Implementation complexity: Medium to high. Sales professionals must shift from closing individual deals to identifying patterns, balancing customer requests, and making long-term product decisions.
Resources required: Five to seven years of sales experience, strong customer relationships, a structured process for synthesizing feedback, and training in analytics and product discovery.
Expected outcomes: Features that support revenue growth, stronger pricing and packaging decisions, and roadmaps informed by recurring customer needs rather than isolated requests.
Best suited for: Enterprise software, B2B SaaS, sales-led products, and businesses where product decisions are closely tied to revenue and procurement cycles.
Key advantages: Direct access to customer feedback, strong commercial awareness, deep knowledge of objections, and an understanding of how products are bought and sold.
Analytics or Data Science → Product Management
The hypothesis-driven path
Implementation complexity: Moderate. Data professionals must add qualitative research, product judgment, and customer empathy to their quantitative strengths.
Resources required: Three to five years of analytics or data science experience, access to experimentation platforms, and mentorship in product discovery and user research.
Expected outcomes: Hypothesis-driven experiments, measurable prioritization, stronger metric ownership, and product improvements backed by behavioural evidence.
Best suited for: Growth teams, data-led startups, analytics products, experimentation platforms, and products with high volumes of measurable user behaviour.
Key advantages: Strong quantitative credibility, experimentation discipline, analytical rigour, and the ability to distinguish meaningful signals from noisy data.
Customer Success → Product Management
The retention and expansion path
Implementation complexity: Medium to high. Customer success professionals must move from solving immediate customer problems to identifying scalable product opportunities.
Resources required: Four to six years of customer success experience, familiarity with retention and expansion metrics, participation in customer advisory boards, and strong cross-functional relationships.
Expected outcomes: Features that improve retention, reduce churn, support account expansion, and solve recurring problems across the customer lifecycle.
Best suited for: Enterprise SaaS, subscription products, and businesses where renewals, adoption, and account growth are central to success.
Key advantages: Deep knowledge of customer outcomes, implementation challenges, adoption barriers, and the factors that influence retention and expansion.
Marketing → Product Management
The demand and positioning path
Implementation complexity: Medium. Marketers must extend their understanding of audiences and messaging into product discovery, prioritization, delivery, and validation.
Resources required: Five to seven years of marketing or product marketing experience, strong market-research skills, and close alignment with product, sales, analytics, and go-to-market teams.
Expected outcomes: Clearer product positioning, roadmaps aligned with market demand, and more effective product launches.
Best suited for: B2B SaaS, launch-heavy products, new-category products, and situations where positioning and product-market fit are still evolving.
Key advantages: Strong messaging and positioning skills, market awareness, audience understanding, and close familiarity with go-to-market strategy.
Operations → Product Management
The systems-thinking path
Implementation complexity: Medium. Operations professionals must translate internal process improvement into customer-facing product decisions.
Resources required: Five to seven years of operations experience, knowledge of process-design frameworks, and extensive experience coordinating stakeholders across teams.
Expected outcomes: Scalable and operationally feasible features, smoother workflows, and fewer organizational or process bottlenecks.
Best suited for: Internal tools, enterprise workflows, marketplaces, logistics products, and complex systems involving several teams or stakeholders.
Key advantages: Strong systems thinking, process discipline, operational awareness, and the ability to coordinate complex cross-functional initiatives.
Bootcamp or Career Switcher → Product Management
The structured learning path
Implementation complexity: High. Career switchers must build credibility, domain knowledge, and practical shipping experience from the ground up.
Resources required: Formal product-management training, a strong portfolio, access to mentors, and opportunities such as associate product manager roles, internships, or early-stage startup positions.
Expected outcomes: Framework-driven product thinking, a portfolio of product artifacts, and fresh perspectives shaped by experience outside traditional product roles.
Best suited for: Early-stage companies, associate product manager programmes, and organizations that actively hire candidates from diverse professional backgrounds.
Key advantages: Structured knowledge of product frameworks, a beginner’s mindset, adaptability, and perspectives that may be missing from conventional product teams.
FAQ
How do I become a Product Manager with no experience?
I'd start by choosing the path closest to your current role, then build one artifact that shows product judgment. A PRD, user flow, or decision memo is enough to begin.
Do I need a Product Management certification?
No, not as a requirement. Certifications can help you learn the vocabulary, but hiring teams care more about evidence that you can make and explain product decisions.
Which background is easiest to transition from?
Engineering, design, sales, customer success, analytics, marketing, and operations all transfer well when you can show the right product artifacts. The best path is usually the one where you already have the strongest evidence.
What should be in a Product Manager portfolio?
I'd keep it to a few clear artifacts, a PRD, a prioritization memo, a user research synthesis, and one case study that shows how you think through tradeoffs. Quality matters more than volume.
How do I get past the first screen?
Make your resume and portfolio read like a product story, not a job history. Show the problem, the decision, and the result, then tie it to customer needs and business outcomes.