Where Sales Meets Product by AWS Product Lead

Arturo Hinojosa, AWS Product Lead, had a winding path to Product. He started out as a solution architect and sales engineer before pivoting into Product Marketing, and finally into Product Management. Here’s why SAs and SEs make great product people.

Hello, my name is Arturo Hinojosa and I’m a Principal Product Manager at Amazon Web Services. Today we’re going to talk about making the career transition from pre-sales to Product Management.

A little bit about myself before we get started, so you know why I’m talking on this topic: as I mentioned, I’m a PM at AWS and I work on the non-relational databases team. Today I manage a team of Product Managers and specialists working on our database services. Helping to bring them to market, defining the roadmap, those sorts of things.

I’ve been with AWS since about 2016, but not too long ago, before I PM at AWS, I actually started off my career as a solution architect (SA) and sales engineer (SE). That’s what I did straight out of college, helping customers evaluate, deploy, and integrate software. Working on things such as billing systems and telecommunication software and financial services stuff. Looking for money laundering and all sorts of the financial no-nos. It was a lot of fun.

And I worked as an SE/SA for about six years. I often get the question of, “Hey Arturo, how did you go from being an SA and an SE to a PM?” And that was what Product School invited me here to talk about what that career transition looked like, what was my journey, why I believe technical SAs and SEs make really good Product Managers. As well as some of the lessons learned that I’ve picked up along the way and tips that you can use if you’re also thinking about making that transition yourself. Hopefully you find today’s presentation helpful.

The journey from SA/SE to PM is definitely not a straight line. There are lots of different things I’ve tried along the ways to figure out what I like to do, and what I thought was interesting, and where my skills are at.

At each one of those stops I learned something to help me take the next step. I’ll walk you through my journey to give you a sense of what pushed me along step to step, as well as the skills I picked up along the way that helped ultimately get me to where I am today: a PM Manager at AWS.

As I mentioned earlier, I started off my career out of college working as an SA. I initially was a developer and I thought I was going to be a coder. But then I realized, you know what? Coding is cool, I like it. it’s a lot of fun. But what I really like is working with customers, I like being out in the field. I don’t just want to be behind a desk. I still like to solve technical problems. I like putting things together, I loved Legos as a child. I like the Legos of technology now as an adult.

That’s what led me to being an SA. As you get to really be hands-on with customers, listening to their problems, going very deep with them to help them solve challenges to grow their business.

Over time, I also learned that I like the sales side as I sort of went from an SA to an SE. Because again, I really like the high-pressure situations of trying to win a deal, but I really like sort of building something new for a customer, help them understand the value of what the companies I worked for offered.

I did that for while. And again, it’s a lot of fun, but the better of an SE and SA that I became, the more I did things like working on sales and found myself helping other SEs and SAs on my team whenever we launched new products. Or I found myself often bringing a lot of feedback back to our product teams and engineering because of things that I was seeing as I worked with customers.

I found that I really liked doing that sort of stuff right. Being on more of the strategy side, having more input on the product roadmap, I thought was pretty cool. And that sort of led me from being an SE to a role called Technical Product Marketing. You don’t have them in every company, but basically what tech marketing does is they’re the field side of Product Management and Product Marketing.

It let me be hands-on with customers because in tech marketing, I was able to do things like help customers with new product betas and bringing feedback back to the engineers and then the Product Managers, as well as doing things like giving a roadmap presentation for customers who kind of wanted to know what was coming down the pipe.

And that was a of fun. Then I started of working on this one project and I got exposed to Product Marketing, more traditional Product Marketing, which I really liked. You thought about things like pricing, which I never really thought about. You thought about messaging in a much deeper way.

I got this opportunity when this product I was working on and a peer I was working with in Product Marketing. I raised my hand and said, “I’d like to try that.” So I asked if I could move from tech work into Product Marketing, and it gave me a really cool opportunity to learn things I just had never thought about before.

Being so technical, it gave me a good introduction to the business world. And I liked it, Product Marketing is really, really fun. I found that I really loved doing things like developing messaging and positioning, understanding what the opportunities were for stuff. But it still wasn’t the ownership that I wanted. And that’s really what pushed me eventually to just doing Product Management.

Because one, I wanted to build. I didn’t want to just have influence on what the roadmap looked like. I really wanted to drive that. I wanted to say, “Hey, these are the things that customers really, really need. These are the big problems we should be solving and I want to have more input on how we do these things.”

It really let me leverage my diverse work experience, as going back from being an SA and an SE, even a developer, and technical marketing, I was able to bring all these different facets of my career together. Because as a Product Manager, you really do have sort of 360-degree responsibility for the success of your product and you have to be, very cross-functional and work with all these different teams.

Having that perspective of all these teams has made me a pretty successful PM because I’m able to have that empathy with not just my customers, but other stakeholders and other members of the team. And it’s really not that unique of a journey. It’s pretty common I found for a lot of my PMs, and a lot of the great PMs that I work with have sort of a technical SE/SA engineering background.

Some of the best PMs I know have that background, especially when you look at things like technology companies or data companies, analytics. Anything we’re selling to a developer. It requires a very deep understanding of your customer, of the technology, how all those things work.

PMs that have that strong technical background really have an advantage cause you can really empathize with your customer. That’s really what makes SEs and SAs great PMs, right? As a PM, you often find yourself working backwards from the customer. What does the customer need? What is their use case? As an SE/SA, because you spend so much time in the field, sleeves rolled up arm and arm with the customer, working things out, trying to make things work and trying to fill in gaps, whether or maybe some shortcomings is of such deep customer empathy on the realities of how deploying big software products and cloud services work.

And it’s not just that it’s deep. It’s also very practical. I find sometimes that newer PMs they have a challenge because they think “If I build it, they will come, and customers will love it. And everything will just be amazing.”

It takes time to build up their experience to know you have to migrate something a lot of the time to go what you’re using today to go over here or just understand the internal politics of an organization. The fact that the IT guy probably doesn’t know that the whole company has to get buy in from different stakeholders, and there’s budgets and all sort of stuff. That real world practical experience helps you really understand, if I build it, what other stuff do I need to support it?

That’s a perspective that SAs and SEs bring to the Product Management, which is really powerful and and differentiated. The other thing that helps is, technical PMs are really able to earn trust with their engineers. As an engineer, the last thing you want is a PM that tells you to build this crazy thing, or something where the requirements are poorly defined and the use cases are not really clear.

It causes a lot of ambiguity and a lot of churn for engineers, which is the thing they hate the most, right? So if you can go in there and say, “I’ve got the technical credibility because I’ve actually deployed things like this before my previous career, I understand how all these things work and the architectures of the customers and what other tools they’re using and what these integration points are.”

That buys you a lot of credibility. And on top of that, you are able to provide a lot of context around use case, which engineers love. If you’re able to say, “These are the SLAs that customers typically want, these are the performance needs to have, or these are the other tools they use and how those tools interact with the stuff that you build.”

All that really rich context helps them build better products and helps them build better solutions and you help build better products. Those two things, that ability to empathize with the customer and work backwards from their world, and be able to earn trust with your technical stakeholders really is what gives the SEs and SAs a leg up when they make that that PM transition.

But again, it’s not all perfect. There are some things where you have to grow as you make the change. The first is learning to prioritize. As an SE, you are programmed to solve all the customers problems. Because again, you’re trying to win the deal, you’re trying to help them out. So you will look for all these solutions and everything’s very critical.

But when you get to PM land, it’s not that you don’t know these things, but you have to prioritize. Because again, there are 50, there are 500, there are a million things you could work on. So you have to be much more calculating in, “What are the most important things I need to go work on? What are the things that have the biggest impact, both for my customers and results for the business?”

You also have to balance those with the cost of these things. Maybe you could go spend six years building something amazing. And you should do that don’t get me wrong. But oftentimes, if I spend three months doing something, maybe I get a little bit in, and that’s where you get the whole MVP thing.

Making those balancing decisions and thinking about the business side, it takes a while to learn. Because again, SEs/SAs are programmed to help. As a PM, you have to be programmed to prioritize, to understand why.

The other big thing you have to learn is learning to say No, and this is really hard, right? Going back to SAs and SAs, they just want to please the customer. Sometimes the SE/SA have to say No, but when they say No, it’s almost like a “No, because of this other thing that’s out of my control.” Like, “No, I can’t help you do that because we don’t have that feature,” or “No, I can’t help you with that because it’s going to take too long and we have a tight deadline.” All these very good reasons why you have to say No, but you help the customer with a workaround.

When you say No as a Product Manager, it’s a different No. It’s a No where you’re saying, “Hey, I understand what you’re trying to say. Yep. It’s totally valid. But for whatever, very probably good reasons I’m choosing not to prioritize it or I’m choosing just not to do it.” Maybe it’s too nichey, there’s an easy work around. Or this may not be the direction I want to grow the product, or it’s not strategic.

And those sorts of No sting customers a little bit more, because it then feels like you’re not listening to them. You have to be more careful about saying that No. Oftentimes bringing in an SA to help them with a workaround.

But it’s kind of like, “heavy as the head that wears the crown.” The fact that you are sort of pushing back and challenging customers in a new way is something you just aren’t a pro at as an SE. And it takes a little while to learn that what is the right amount of backbone. How do you negotiate those situations?

And then also, who can and help? As an SE/SA, you often are the last person on the line, it’s up to you. You gotta get it done to win the deal, or get the deployment or meet the timelines. That’s not true as a PM. There are other resources you have to learn to tap. You have to learn to delegate. You have to leverage your stakeholders, like bringing in an SA or bringing in a pro-serve person, or providing a work-around or an alternative. It’s much more strategic, it’s a little more tactful, and it takes a little time to learn how to develop that muscle.

With that, let me talk about some of the lessons learned, that I’ve sort of picked up along my journey here, and hopefully they’ll help you apply them to your own career.

When you first start off, you have to learn how to ask a lot of Why questions. And this is really the key thing that you have to pick up as a PM, is, “If we’re going to do something as a company, why are we doing it? Why is it important? Why does the customer need this? Why is this a big opportunity?”

Because again, you could do 50 million things, but it’s about prioritization. It’s about understanding the context behind the things that you do. So you have to start thinking much bigger than you did as an SA. Because you have to go ask and influence and spend a lot of resources. A lot of cycles building something, or you have to go convince your leadership that, “Hey, I need engineering resources to build this thing because there’s a big opportunity here.”

You have to articulate all of these things, and these are sort of conversations you just don’t have as an SE or SA, because again, you’re so focused on unblocking something, you’re not often thinking back about, “Well, why am I unblocking it? Why is this the right thing to go unblock? What other things could I be unblocking instead or working on instead?”

So again, this is really where developing that strategy muscle takes time. And the best way to do that is just practice and asking deep probing questions that always challenge our assumptions, play your own devil’s advocate. These are the things that really help you sort of become a much more athletic PM.

It’s also because at some point you’re also going to have to probably do things where you’re leaving your domain expertise. You have to just be a good PM athlete, and ask probing questions no matter the discipline, no matter what the product you’re working on. This just makes you a better PM and a better part of the team, because you’re able to help the team, make trade-offs and make really good decisions.

The other thing you have to learn to learn to be is relentlessly data driven. And this is something at AWS, we take like to the 1 millionth degree. But it’s so true, because it’s so valuable. You have to listen to the data. You can’t let things like a single customer experience, completely influence your judgment.

And I see this a lot with newer PMs and engineers who don’t spend a lot of time in the field who have one conversation with a customer or a couple conversations. They think they’re soulmates. They really think this is the the true North Star of all their decision making, but it’s just one or two conversations.

You have to really develop a mechanism. You get and analyze trends across lots of customers. Is that one conversation even the right customer? Or are they just not in your target customer segment, because you think the opportunity is over here.

So you have to really understand, “How am I going to talk to tens, dozens, hundreds of customers without actually talking to them, whether that’s leveraging your field teams, setting up feedback sessions, developing mechanisms for people that like record feature requests and contact on this feature request.

What you really wanted be able to say, “Hey, it’s not that I talked to one customer, two customers, I talked to a dozen, two dozen, 15,” whatever makes sense given the problem you’re trying to solve. “But I have a lot of data, diverse opinions that help me inform. And I can challenge my assumptions, I can challenge the decisions because I have data that proves to me and I can use to prove to others.”

These are the right things to go do. You really have to be relentlessly data driven and you have to use that data even past the decision—you have to use the data to then also validate that was that the right decision, because that can influence future decisions.

So again, you have to really learn, to measure your performance using metrics. Are you measuring adoption? Are you measuring revenue? Are you measuring something like a customer satisfaction score? You want to start developing and use these North Star metric stuff?

You’d say, “Hey, we think that the right thing to do is this, and to validate that we’re going to measure this and then we’re going to track that measurement over time to see they’re doing the right thing.” And you also want to make sure you’re grading that performance against your expectations.

One of the biggest learning moments for me is, I was sitting in on this presentation to our executives and this other team talking about the thing they just built and launched, and they were super excited about it. They were rattling off all these stats, and one the guys was like, “We’ve got, hundreds of big customers in this thing already.”

And the senior executive sort of looked at them with a quasi-blank stare. And they kind of were expecting this clapping and cheering, but the executives kind of sat there, and was like, “I don’t know what that means. Were you expecting tens of customers at this point or thousands of big customers at this point, because your answer is going to change how I feel about you telling me you have hundreds of customers at this point. Either you’re massively overperforming or you’re underperforming.”

So being able to develop these models and develop expectations, which then you can measure against your own metrics, this is what makes a fantastic PM that can really then influence and share metrics up and sort of say, “Hey, this is how we’re doing. Things are going well, I know they’re going well, they’re better than we expected.” Or “Things aren’t going as well as we expected, we have to pivot, we have to make a change, we have to reevaluate something.” Having this sort of data metrics is really important.

And again, these are things that you never really had to do as an SA before. It’s sort of like. “Win the deal! Yeah, awesome, high-five.” But now you’re sort of like, did I win the right deal? Did I win the deal enough? It’s a whole different mentality. It takes a little bit of time to learn how to measure stuff. It’s one of the things that will help you quickly become a much better PM.

What are some tips you can use to pick up these skills? One is you have to sort of really capitalize on the overlap between the SA and PM roles. I purposely peppered some of these examples earlier as I was going through my career story. There are lots of places where the PM job and the SA job intersect, and this is going to give you a foot in the door.

If you are about making that change to go validate for yourself that, “Hey, this is the stuff I really want to go do.” And it also is a good way to network with the PM team if you do want to make the change. This is often how we source SAs/SEs into our PMT.

One, you want to set up and drive technical enablement. This is probably the easiest thing you can do as an SA, if you want to get more strategic. Because it gives you exposure to the strategy side, you’re sitting with the PMs, and the PMMs that are working on these decks with you, and making sure that you have the right messaging and positioning, and there’s the competitive analysis. All that stuff that goes into technical enablement. If you like doing that sort of stuff, that is a good sign that maybe you could do Product Management long term. This is probably the most PMish part of the SA role.

The other thing you can do is do things like support new product launches. When I was in tech marketing, this is for really my first foray into the roadmap side of stuff as you work on these beta programs, you work on previews, you’re out there with the customers, you’re capturing feedback, you’re bringing that back to the product team. You’re iterating, they ask more questions, you look back.

You just sort of learned what are the right sort of discovery questions, not just for winning a deal, but for building a product. If I did this, what would you do? Or how would you like this to work? The different questions that you asked in during a discovery where you’re trying to qualify a customer, when you sort of start asking these beta preview questions, you’re really building a rapport with a customer to understand how the product should work, and what are the trade-offs that customers are willing to make? These are the whole different new set of questions.

And also expose you to working a cross-functional team, and seeing how a roadmap is developed. It was really cool when I was working on beta programs, you work with the PMMs to build the deck to educate a customer and what the beta does and why they should try it. You work with the PM on that sort of stuff.

You might work with marking to set up the email mechanism that sort of captures feedback. It really gives you opportunity to work with those teams that work on the product and strategy side and go to market side a lot more than you would’ve as an SA.

And then finally, you want to get yourself involved in interjecting into the roadmap planning process. Every company has its own way that it does this, but essentially every PM wants to put on what they should be building next. What are the challenges customers have with the product today?

So if you can provide that input you know, with one on one meeting with their PM or, joining the PM meeting, or even better yet, aggregating feedback from across the fuel teams to share with the PMs, that’s a great way to sort of get yourself interjected into the roadmap planning process and really start getting a lot more strategic.

The second tip I’ll offer is, you want to leverage your network. And by leverage your network, that sort of means looking for internal openings on familiar product. Like today, if you work on some product or service and the PM team is deciding to grow, and they’re looking for a new PM, that’ll be your best first PM job, because you’re able to leverage your technical expertise about the product to help you build a gap on stuff you can work on as you ramp up on the other core PM skills.

That way you’re not walking in totally like, “What do I do.” At least you know you can contribute by doing some field work or working on a new feature, capturing feedback. This just gives you something where you can feel like you’re adding value until you learn how to do things like pricing, which is like totally left field, or something that might be new to you.

You also want to make sure you’re setting yourself up for success by looking for teams with PM leaders who either have a similar background or have a successful track record of training SEs and SAs. It’s one of those things where you’re going to need a little bit of mentorship to make the change. Like anything, practice makes perfect.

It’s something you’ve never done before. So you want to make sure you’re working with a manager and a team that is on board with helping you make the transition to make the change. I find some folks on the PM side, especially if they come more with a traditional PM background, the MBA from a fancy school, they want to build a lot of frameworks. Those often might not be the best first time PM manager, unless they’re really into the idea of developing technical talent.

It’s just something where you want to make sure there’s someone that’s going to help you out and have your back as you’re making the change. Another thing to think about is you want to look for your network connections and for opportunities working on really highly technical products.

This is the best place to get started. Because if you’re working on product and data analytics, or something that’s working for developers, those companies want a really technical PM. They want folks that can talk with engineers and developers who are customers, data scientists, and roll up their sleeves and get deep with them. If you can bring that technical background it’s a leg up.

Oftentimes I know we have these new types of rules. I’m more than willing to help someone develop their messaging if they can at least go out there and like get deep with a customer on the technology side, understand use cases and challenge. Because that background takes a long time to build up.

I’ll leave you with one final tip, right? You also want to be accepting and do something about your blind spots. Doing new things is hard and it’s uncomfortable at first because it’s something you’ve never done before. But you have to keep at it and you have to be willing to learn and to be taught to get good at something new.

Most of your areas for growth, if you’re sort of making that change from the SA/SE side to PM is going to be on the business side. Odds are, you’ve never developed pricing before as an SA or an SE and that’s hard, it’s not trivial. It takes skill. It takes practice. You have to understand what are the decision points that come into that, how should you frame valued cogs and market segments, all this other stuff, how these things fit together. It takes practice and a lot of time to learn how do that stuff.

Being able to do things like size and opportunity. The worst feeling you have is when an executive asks, “How big is that market segment, or how big is the opportunity there?” You have to be able to have a number. And that’s your job as the PM. You have to understand that the executive, he, or she’s making the tradeoff, like, “Do we fund this project or that project, which has the biggest opportunity for us, which can we service more?” Things like dress the market, serviceable markets, all the business school stuff. You just want to have a basic understanding of what they mean and how to use them, not quantify them and explain them, especially as you’re talking to your leadership.

And also being able to do things like opportunity segmentation. When you are thinking about the opportunity, if you can break it down into pieces, then you can ask, “Should we focus on this piece first or that piece, first? We know about the whole pie, but which piece should we bite off first?”

These are new skills, something you really haven’t had as an SA or SE. You may have seen it, you may be the consumer of the information during the enablement session and stuff like that, but developing it, doing the math, understanding what resources to use, how to do estimation, what’s credible top-down analysis, bottoms up analysis, all these things are new and that’s okay.

We grow, we learn, but you have to keep an open mind. You can’t go in there and say, “Hey, I know how this thing works and this stuff doesn’t matter.” You have to really be willing to be taught. And to do that, find a mentor.

There are lots of folks out there and in tech and working in companies that again, have that SA/SE background or an engineering background or just a technical background or didn’t go to business school. Those folks make great mentors. They understand the practical challenges you’re going through. They’re sympathetic. And everyone like to see people like them succeed. Any time I find out that another SE want to make that transition I’m like “Heck yeah, I’ll spend an hour with you.”

To figure out why you like it, what do you want to do, do you really want to be a Product Manager? Or do you really want to be a Product Marketing Manager? Do you want to be a tech marketing manager? Do you want to do something, you want to be marketing, helping you work through all that stuff.

Finding a mentor, someone you can sort tap whenever you have a question then also give you honest feedback. If you’re working on messaging for a new product, “Hey, can you give me your thoughts on this? How did this look for the stuff I was working a year ago? Am I learning stuff?”

All those things help, getting that feedback. I’m one taking advantage of education resource, like watching these sessions of Product School. There’s also tons of books on business strategy and Product Management case studies from this and that read, read as much as you can.

You want to make sure that you’re not stuck in a position where you only learn a lesson when you go through it. That is a very expensive way to learn stuff. You can stand on the shoulders of giants, learn what others have done learn techniques for messaging, how that works, learning different pricing and all that stuff. Like all that stuff’s been written in books ad nausea. So read the books, I’m sure there’s book lists out there, read all the VC books. Like all those do pretty good job of talking about Product Management challenges, growing a company, growing a business, growing on opportunity. Reading is a really fast way to learn because you’re able to digest a lot of other really good experience very quickly and apply it.

In summary, SEs and SAs make great PMs because they have that technical background and deep customer empathy. It’s a great transition for anyone that wants be more strategic in their career. Have more ownership, have more sort of insight or have more influence on the product direction and strategy, that sort of nature. It’s a lot of fun. There is a learning curve, but it’s manageable. Like I said, you have to be willing to learn and willing to do work to ramp up on the skill that you are going to fill in the gap for. But there’s lots of opportunities to do that, right. Again, you can start off by just overdoing some more strategic stuff in your current role. See if there’s resources online and in books there’s lots of ways to sort of learn that stuff.

You can reach out to me on LinkedIn or on Twitter. We’re always looking for Product Managers at AWS, not just on my team, but across all of our database services team.