From sales engineer to product manager: what to know and how to get there

Why I am writing this#

I have been a Sales Engineer for over five years. I like the job. I like the technical conversations, the demos that land, and the moment a customer realises a product can solve their problem.

But the part I enjoy most is not the close. It is the conversation after the demo, when someone says "it would be great if it could do X" and I think: that is a good idea, and I wish I could be the one deciding whether we build it.

I want to shape the direction of a product. That is what pulled me towards product management, and it is why I have been working out what the move actually involves.

I put this together with the help of AI to organise my research and pressure test my thinking, and I am publishing it for anyone else sat in a pre-sales seat wondering the same thing. Treat it as a map, not gospel. The best advice will always come from product managers who have done the job.

What a product manager actually does#

Strip away the job title mythology and product management comes down to a few questions, asked over and over:

• Who are we building this for?
• What problem do they have, and how do we know it is real?
• Is it worth solving, compared with everything else we could do?
• What is the smallest thing we can ship to find out if we are right?
• Did it work?

Marty Cagan, whose book Inspired is a staple of the field, frames the job as discovering products that customers love and that also work for the business. Atlassian's product management guide gives a more practical overview of the day to day: setting the vision, defining strategy, prioritising the backlog, and working with design, engineering, marketing and sales to get things out.

The key point is that a PM is accountable for the outcome without having authority over the people doing the work. You do not manage the engineers. You earn their trust by being clear about the problem and honest about the trade-offs. That is a different muscle from winning a deal, even if it feels related.

Why sales engineering is a strong starting point#

If you are a Sales Engineer, you are probably further along than you think. Here is what you already have.

You talk to customers constantly. Many aspiring PMs fight to get customer access. You have it every week, across different industries, sizes and maturity levels. You hear objections, not just feature requests, which is where the real insight lives.

You understand the product deeply. You have probably broken it in a demo, worked around its gaps, and explained its limits to an unimpressed technical buyer. That honest knowledge of strengths and weaknesses is hard to fake.

You know the competitive landscape. You see why you win and, more importantly, why you lose. Most PMs read about competitors. You hear about them from the buyer.

You translate between technical and non-technical people. Explaining complex things to a CFO in the morning and an architect in the afternoon is the same skill as explaining a customer problem to an engineering team.

You already influence without authority. Pulling a solution architect, a legal team and a product specialist into a deal you do not own is a good rehearsal for pulling a team towards a roadmap you do not control.

You understand how revenue works. You know what sales cycles look like, what makes a deal stall, and how pricing and packaging change behaviour. A lot of PMs have to learn this on the job.

What changes, and what you need to learn#

This is the honest part. The move is not a promotion in the same ladder. It is a change of discipline, and there are gaps to close.

1. From the loudest customer to the real pattern#

In sales engineering, the customer in front of you is the most important customer in the world. In product, they are one data point.

A PM has to separate the feature a prospect demanded to close a deal from the problem that affects a hundred customers. Teresa Torres's Continuous Discovery Habits and her opportunity solution tree are a good way into this. The idea is to keep a steady rhythm of customer conversations and map customer needs to the outcome you are trying to drive, rather than collecting a list of requests.

The shift in mindset: a customer request is a symptom, not a specification. Your job is to find the problem behind it.

2. From "yes, and" to "no, because"#

Sales is about finding a path to yes. Product is about choosing what not to do, and saying no to good ideas because there are better ones.

Prioritisation frameworks help you make that call defensibly. A simple one to start with is RICE, which scores ideas on reach, impact, confidence and effort. Intercom, who created it, explain it in RICE: simple prioritisation for product managers. No framework replaces judgement, but they make your reasoning visible, which is half the battle when someone senior disagrees with you.

3. From features to outcomes#

It is very easy to become a PM who is just a ticket writer for a feature list. Melissa Perri calls this the build trap: organisations measure success by what they ship, not by whether it changed anything for the customer or the business.

Practise writing things in terms of outcomes. Not "we will build a dashboard", but "admins spend less time finding out what changed, and we know because support tickets about audit questions fall."

4. Roadmaps are about strategy, not dates#

Customers and sales teams love dates. Product teams that promise dates tend to ship the wrong thing, late. A good roadmap communicates direction, themes and the reasoning behind them. ProductPlan's roadmap guide is a decent primer on how roadmaps are built and used.

You will notice that as an SE you probably asked product for dates. As a PM you will be on the receiving end of that question, and you will need a good answer that is honest without being evasive.

5. Working with data#

Most PM roles expect you to be comfortable with product analytics: funnels, retention, adoption, and the difference between a metric that moves and a metric that matters. You do not need to be a data scientist, but you should be able to ask a precise question, find or request the data, and understand what it does and does not tell you.

If you have never written a SQL query, learn the basics. It is one of the best returns on time you can get as an aspiring PM.

6. Writing as a core skill#

PMs write a lot: problem statements, product requirement documents, release notes, strategy memos, and updates for people who were not in the room. Writing clearly is how you scale yourself.

A good habit to start now: write a one-page document for a problem you have seen in the field. Cover who has it, what evidence you have, what happens if nobody fixes it, and what a good outcome looks like. Do not describe a solution first.

7. Technical depth, but a different kind#

SEs usually have more technical depth than most PMs. The trap is using it. A PM who dictates solutions to engineers stops getting their best ideas. Use your technical background to ask better questions and spot unrealistic estimates, not to design the implementation.

How to get there#

You do not need permission to start. Most of the preparation can happen in your current role.

Start doing product work where you are#

1. Log customer feedback properly. Do not just mention it in Slack. Capture the problem, the customer context, the impact on the deal or account, and what they do today. Track recurring themes and bring them to product with evidence.
2. Build a relationship with your product team. Ask to join feature review calls, beta programmes, or customer advisory sessions. Offer to bring customers to them.
3. Write something small. A one-pager on a customer problem, a competitive teardown, or a proposal for how a demo flow could be better. Anything that shows you can structure a problem.
4. Run a mini-project. Own something with an outcome: a new demo environment, a pre-sales playbook, a proof of concept template. Measure whether it helped, and write up what you learned.
5. Ask for the numbers. Find out how adoption, win rates and churn are measured at your company, and what the product team looks at each week.

Fill the knowledge gaps deliberately#

• Read. Inspired by Marty Cagan, Escaping the Build Trap by Melissa Perri, and Continuous Discovery Habits by Teresa Torres cover most of the modern thinking between them.
• Follow practitioners. Mind the Product and Lenny's Newsletter are good places to see how working PMs think and what different companies expect.
• Learn a lightweight method for testing ideas. The Google Ventures design sprint is one way to take a problem to a tested prototype in a week.
• Get comfortable with the tools. Jira or Linear, a roadmapping tool, a product analytics tool, and a way to build quick wireframes. You can do this in a few evenings.

Courses and certifications can help structure your learning and give hiring managers a signal, but they are a supplement to real work, not a replacement for it.

Choose your route in#

There are a few common routes, and they carry different trade-offs.

• Internal move. Often the easiest. People already trust you and you know the product. Tell your manager early, find a product leader who will sponsor you, and ask what they would need to see.
• Technical product manager or solutions-focused PM roles. These value exactly the background an SE has, particularly in developer tools, security, infrastructure and API products.
• Product owner, product operations or associate PM roles. A step sideways can be a pragmatic way in, especially if you have no formal product title yet.
• External move to a company in a domain you know. Domain expertise is a real advantage. A PM role in the industry you have sold into for five years is far easier to land than a generic one.

Be ready for the possibility that the first role is a lateral move, or even a small step back in seniority or pay, in exchange for the change of discipline. That is common, and it usually closes faster than people fear if you perform well.

Tell the story well#

When you interview, you will be asked to prove that you can do product work, not that you can sell. Reframe your experience in product terms.

• Instead of "I supported deals worth X", talk about a pattern you spotted, how you validated it, who you took it to, and what changed as a result.
• Have two or three stories ready about a time you changed someone's mind with evidence, a time you said no to something, and a time something you recommended did not work and what you learned.
• Prepare to talk through a product you use: who it is for, what problem it solves, what you would change, and what you would measure.
• Expect product sense, prioritisation, and execution questions. Practise structuring your thinking out loud.

Mistakes to avoid#

• Treating the move as a way to escape sales. Product still involves selling: ideas, trade-offs and priorities, internally and to customers. The audience just changes.
• Arriving with a solution. Leading with "we should build X" is the fastest way to lose an engineer's trust. Lead with the problem and the evidence.
• Being the voice of one customer. The loudest account is not the market.
• Ignoring the business side. Product management sits at the intersection of customer value, technical feasibility and commercial viability. You need all three.
• Expecting to be in charge. A PM leads through clarity and credibility, not authority.

Is it right for you?#

It is worth asking honestly what you are drawn to. The parts of the job people tend to enjoy are shaping direction, solving real customer problems, and working across teams. The parts they find hard are the ambiguity, the constant trade-offs, being accountable for results you do not fully control, and having a lot of people who want different things from you.

If the idea of making hard decisions with incomplete information, and living with them, sounds fun rather than draining, that is a good sign.

A plan you can start this month#

For anyone who wants a starting point, this is the order I would work through it in:

1. Start capturing customer problems properly, with evidence, and share them with product.
2. Read the three core books and follow a couple of working PMs.
3. Write a one-page problem brief for something you have seen repeatedly in the field.
4. Ask to be involved in product discussions, betas and customer feedback sessions.
5. Take on one small project with a measurable outcome.
6. Talk to people who made this exact move and ask what they would do differently.

Five years in sales engineering is not time spent away from product. It is five years of unusually close contact with the people the product exists for. The job is to turn that into the habit of deciding what to build, and why.

If you have made this move, I would like to hear what worked and what you wish you had known.

References#

Sources and further reading for the claims above.

• Silicon Valley Product Group, Marty Cagan
• Atlassian, Product management guide
• Product Talk, Continuous Discovery Habits
• Product Talk, Opportunity solution tree
• Melissa Perri, Escaping the Build Trap
• Intercom, RICE: simple prioritisation for product managers
• ProductPlan, Product roadmap guide
• Google Ventures, The design sprint
• Mind the Product
• Lenny's Newsletter