How to Become a Product Manager | #94
The best route into Product Management is through adjacent roles. This blog covers what to focus on, how to build product sense, and the mindset you need in order to pave your path into a PM role.
Someone recently asked me if entry-level PM roles are disappearing. It’s a fair question.
The truth is, they’ve always been rare.
Product management has never had the same volume of entry-level roles as engineering or design. That hasn’t changed. What has changed is how people break in.
These days, the most reliable path is lateral: start in a stakeholder- or customer-facing role within a company that already has a well-established product org, then work your way in from there.
That’s how I got in.
Internal networking works.
Practising product methods in your current scope (even when it’s not asked of you) works.
And telling every PM who'll listen that you want to move into product?
That works best of all.
Even in tough markets, companies with solid PM structures don’t simply abandon them. If you can demonstrate leadership and product sense in your current role, you might actually be the best candidate - more cost-effective, already onboarded, and faster to ramp than an external hire.
AI can help you simulate some product work, but it can’t teach you product sense for your company. That only comes from doing the work, close to the customer.
What is Product Sense?
It’s the ability to understand what makes a product valuable, usable, and feasible—and being able to apply that lens within your specific context. It’s part customer empathy, part business acumen, part intuition. You notice friction points. You ask better questions. You sense when a feature feels off before the data catches up. And most importantly, you learn how to prioritise not just what could be built—but what should be built.
Why Adjacent Roles Are a Goldmine
If you're in support, implementation, or customer success, you’re already closer to product than you think. These roles offer an underrated advantage: they immerse you in real customer pain, over and over again.
I’ve mentored folks who broke into PM roles without CS degrees or MBAs.
The common thread? They proactively embedded themselves in product work. Whether by documenting themes in support tickets, mapping workflows, or identifying friction points in onboarding, they added value and made it visible.
At Toast, I advised a support team member to run lightweight discovery on recurring customer issues. They started grouping themes, sharing findings with PMs, using internal templates like opportunity trees and AI to sharpen the output. That kind of initiative gets noticed.
You don’t need permission to think like a PM. You need curiosity, a bias for action, and a way to make your thinking visible.
Support roles offer incredible variety. They give you exposure to the messiness of real operations - a mix of edge cases, system gaps, and unfiltered customer frustration. That context is powerful. The key is shifting your focus from output (solving one-off problems) to outcomes (solving them at scale). That’s when people start to take notice.
And while some roles may sound similar to product - like design or business analysis - they often follow different tracks. I’ve had to be honest with mentees: design roles today are highly competitive, increasingly affected by AI, and require a depth of craft that takes years to build. Product is a different path, and support can be a far better stepping stone.
The Missing Skill is Often Discovery
Discovery is where a lot of new PMs struggle - and for good reason. Many people enter product from roles that never required it. In many companies (including almost every company I have worked at), product owners were simply retitled as PMs without ever being intensively trained on discovery. That leads to an execution-first mindset (explained in more detail here), where building fast is prioritised over understanding what’s worth building at all.
That’s why over the past few years I have started creating and sharing these discovery templates: opportunity trees, PRD scaffolds, structured problem definitions, and how to use Atlassian products to boost your outputs. They’re not just for PMs. They’re for anyone trying to do better discovery, even unofficially.
Sometimes the cost of skipping discovery isn’t obvious until months or years later. Maybe a compliance need was missed. Maybe a workflow was poorly scoped. These things compound - and future teams pay the price.
If you document clearly and structure your learnings, you’re not just helping now - you’re protecting your team in the long run.
If you work in support or ops, you already have access to high-signal pain points. Document them. Group them. Tie them to user outcomes. That kind of thinking doesn’t just help the product team - it helps you become more effective in your own role.
How to Be a PM Before You’re a PM
One of the best ways to prepare for a product role is to start behaving like a PM in the role you already have. Don’t be afraid you might overstep your mark or impede on the product team, you will be contributing structured insights, solving team-wide problems, and making your thinking visible. This kind of context in an AI landscape is incredibly important.
Start with discovery. Look at repeated customer pain points. Group them into themes. Use frameworks like Reach x Impact (check the notes section of my Miro template linked above to prioritise them. Visualise them in Miro or track them in Jira. You can even build a mini discovery board for yourself - call it the "Becoming a PM" board. It helps you define what gaps you need to close to move into product.
Copy my board. Then start small - documenting your customer problems and workflows.
Support is an excellent place to practice this. Every support interaction is a mini signal. When grouped and structured, they tell a story about what’s broken and what could be fixed. By sharing these stories with PMs, you're not just shadowing. You're shaping.
Even if you never make the move into product, these skills will make you better in your current role. You’ll be more strategic, more focused, and more respected across teams.
Don't Wait for the Role to Come to You.
Roles don’t always need to exist before you grow into them. I’ve seen this first-hand. If you’re solving real problems that are not just in your own lane, but across teams - and you make that work visible, opportunities tend to reshape around you.
Maybe instead of hiring one senior PM, a team hires two associates because that’s what the work calls for. Maybe you create such a useful structure for your team that leadership rethinks how support and product collaborate entirely. Roles aren’t fixed - they’re just stories we tell about where someone fits. Change the story, and you can change the role.
But if you never speak up? No one will know.
Be vocal about what you want. That’s product work at its core - clear communication, stakeholder alignment, and driving outcomes. If you haven’t told anyone in the product org that you want to move into product, how can they consider you when the moment arrives?
Telling your manager is a good start - but remember, your career is your responsibility. In modern tech, managers are stretched thin. They may not fully grasp the relevance or value of the PM-style work you're doing on the side, and they likely can’t (or won’t) advocate for you in rooms you’re not in.
Sometimes, your manager may even see this extra work as a distraction - especially if you're a strong contributor in support. It’s natural for team leads to prioritise team performance over individual ambition.
This is where you’ll need to rely on your own judgment. If your manager is supportive, go all in - as long as your core work doesn't slip. But if they’re hesitant, find subtle ways to build credibility with the product team directly. The key is to keep moving forward while being pragmatic about the context you’re in.
Why AI Is Non-Negotiable Now
Almost every task a product manager does can be enhanced by AI. User story drafting, PRD writing, idea validation, competitor research, stakeholder communication, journey mapping - AI can support all of it.
But only if you learn how to prompt it well.
My approach is simple: use AI wherever you find friction. Too many thoughts in your head? Ask ChatGPT to help structure them. Unclear on a problem space? Feed your notes into Gemini and ask what’s missing. Need examples of KPIs or OKRs? Ask for five variations.
Then iterate.
AI can help you get unblocked, polish your thinking, or simply accelerate tedious steps. But it’s only powerful if you give it structure. I spend a lot of time feeding it labelled inputs and real content from my different projects. Then I let it react, reframe, and spark better outputs.
I encourage everyone I mentor to get a personal ChatGPT subscription. Not because it makes you a product manager - but because it erases the friction between you and the skills you need to learn.
Want to write a PRD? Ask ChatGPT to help based on a flow you draw in Miro.
Want to draft OKRs? Feed in your goal and let it propose options.
Want to understand how Reach x Impact works? Ask it to explain, then ask again for five examples.
AI doesn’t (and shouldn’t) replace your thinking, but it does supercharge it. Especially if you’re coming from an adjacent background, it closes the gap between your intent and your execution.
You Don’t Need a Title to Build a Track Record
You can start building your product portfolio now. No permission needed.
Spin up your own Jira instance. Run a discovery project on something in your current team. Document a pattern you’ve seen in support tickets and outline potential solutions. Share it internally. Build visibility.
I’ve seen people do this and get tapped for internal PM roles without ever applying. Why? Because they were already doing the job - just unofficially.
This isn’t theoretical work. It’s practice. And practice builds trust.
Closing Thought
If you’ve made it this far, you’re probably wondering where to start. I’ve included a curated list of resources at the bottom - roughly in priority order. These guides, templates, and examples reflect how real product managers work, and they’re all easily adoptable by anyone ready to step into that mindset.
Breaking into product has always required initiative. It’s not a career that hands out clear ladders or neat checklists. But if you’re in an adjacent role, are curious, and are willing to learn by doing - the path is still there.
You don’t need a PM title to start doing product work. You just need to start.
