How Is Product Management Different from Solution Engineering?

In the previous post, we discussed the role of a technical solutions engineer and the different career paths that lead to it. This post focuses on one possible career path for a solutions engineer. Solution engineering and product management vary from company to company, and from team to team.

How is product management different from solution engineering?

Focus

As a solutions engineer, you focus mainly on prospects, potential buyers or customers. Your goal is to make sure the product, or set of products, is configured and works in a way that gives them value and meets their requirements. You are constantly tweaking, adjusting and extending existing features so the product covers their must-haves and nice-to-haves.

As a product manager, you are less focused on a single deal or customer. Instead, you look holistically at prospects, customers and end users. Your main focus is making sure the product and all of its features solve user pain.

Calls and meetings

As a solutions engineer, you join discovery calls and technical support calls, where you gather the prospect’s requirements and present value propositions. A value proposition explains how your product solves their pain in a way competitors can’t. The value proposition itself comes from the product manager and aligns closely with the company vision.

As a product manager, you attend discovery calls, but also support calls, renewals, solution reviews, focus groups, user experience testing and customer connects. That’s on top of internal meetings. Having a direct connection to your users, so you can ask them about their pains, is important.

Feedback

As a solutions engineer, you give feedback on which features need to be built or improved. As a product manager, you take in feedback from many sources and apply prioritization techniques to get buy-in from every stakeholder in the company on the roadmap.

During a proof of concept (PoC), a solutions engineer or a prospect will spot difficulties or gaps in your product. Some APIs might be missing, poorly written, or incompatible with the use case. The infrastructure or framework they’re deploying your solution on might have limitations. After the PoC, the prospect tests with their users, who quickly see what works, what doesn’t, and whether the UI makes sense and gives a great experience for their use case. During this time, it’s important to capture as much as you can about the product’s gaps, limitations and use cases, and to carry that feedback back to the teams.

Cross-team collaboration

As a solutions engineer, you work mainly with sales, product management and development. You train sales reps, give feedback to product management, and ask developers for technical advice on configuring the solution.

As a product manager, you work with every team:

• You collect feedback from customer-facing teams like sales, support and customer success.
• During sprint planning, you brainstorm and rapidly prototype with design and development.
• You work with development to accept items from the backlog into the sprint and agree on timelines, then clarify and resolve issues during development.
• You work with marketing to clarify value propositions and create content that explains them to the world.
• You work with legal to make sure you comply with all laws and regulations.
• You create sales enablement materials and train solutions engineers and sales.

Performance

A solutions engineer’s performance is usually measured by the volume of deals closed.

A product manager’s performance is trickier to measure. One way I hold myself accountable is to use OKRs (Objectives and Key Results) for every feature or initiative. You set a qualitative objective and come up with quantitative key results. It sounds easy, but it takes time to master writing good objectives and finding ways to measure their success. Part of writing the objective is defining the why behind it: why does it matter? With the OKR framework, it’s easy to track your performance and see whether you’re meeting your key results. I wrote more about this in the Product Manager’s Guide to Writing Great OKRs.

How to transition to product management

Development

Start working closely with the product owner or development team lead, bringing detailed feedback from the customers and prospects you’ve worked with. On your calls, try to understand how a particular feature, or a new one, would solve their pain. Do a competitive analysis to see how competitors solve similar pain. Also look at how others solve a similar problem, even outside your industry. Agree on a feedback framework: how user stories should be worded and what else to capture for each proposed feature.

Design

Join design reviews and give feedback on a feature’s wireframes and designs based on the user’s experience. With enough calls behind you, you can sometimes anticipate user behaviour, but it’s best to mock up the design and have a real user try it. That feedback helps you prototype faster.

Product marketing

Once the feature is in progress, you should be able to explain the why behind it and what pain it solves. Come up with a unique value proposition that sets you apart from competitors. Your competitive analysis should also help with pricing and packaging. Work with marketing on announcing the feature and creating the content customers need to find and learn about it.

Wrap up

Let me know if you’ve been through a similar journey or are planning the move. Stay tuned for more product management content.