Transitioning from a "Dev" to a "Product" person...

It's been over 90 days since I joined WalmartLabs as Principal Product Manager for IaaS and, so far, it has been an interesting journey.

Since the company (like any other company) has issues with me talking too much about what I do, I'll focus this post on how I did my transition in an effort to help a myriad women engineers who have reached out to me both internally and externally on how, they too, can transition into a product role.

This post is specifically targeted towards software developers who have a significant history and tenure in the industry doing software dev and might have also done engineering management in their career.  It is targeted for engineers who have greater than 7-10 years of experience doing software development and are pretty good at it.

Here are some advice/learnings/thoughts:

Key Role: You are the Swiss Army Knife of the organization.  And that is a very hard job to do.

1. Product management (PM) is a variety of skillsets, mindsets and deliverables rolled into one nebulous title.  No two product managers do the same thing.  They might have similar products they are managing, but their approach might have to be vastly different since one of the key tenets of  PM is to get things done without having any direct reporting structure to you, i.e., the people whom you manage do not report to you and may have their own agendas/trajectory.  
2. Product Mgmt. is vastly different from Project Mgmt. which is different from Program Mgmt.  Know and understand the differences.  You might have to dabble in all 3 but make sure you are doing more of Product than Project/Program.  Some companies don't make any distinction and will give you a title of a Product M. and will expect you to only do Project or Program.  Get the hell out if that happens - those places are deadends.  You will lose valuable time and technical skills will get rusty.
3. You have to know and understand what "influence" means.  As an engineer, I had very little knowledge or exposure to this concept and, practically, no experience in "influencing".  As a founder and ED for a non-profit where everyone involved is a volunteer, I got some extreme, doses of reality over the last 9 years on how to get people motivated, committed (as much as I could) and get volunteers to deliver on tasks without having any direct reporting structure and no money.  This was the biggest lesson that I transferred from my work with CodeChix into my current PM role.  To be frank, most managers in industry become managers in order to "control" and "dictate" and set up a power structure in order to get work done by employees reporting to them so that said managers can deliver and look good and get promoted.  This is the antithesis of a good PM.  The first rule is to be able to sacrifice your own ego and anything related to it in order to help and showcase your team in every way possible.  If I had not learned some crucial lessons the hard way through my work with CodeChix, I would have been an utter failure as a PM.  I now know how valuable those lessons were - regardless of how abominably painful they were. Note that you need to keep a good record of all of your accomplishments and these are what you use in your performance evaluation with your manager.  THAT is where you scream about how many great things you did and how you delivered on things.  THAT is the ONLY time you get to bring out a saxophone and play your best tune.  Other than that, EVERYTHING is about the dev team and you are only there to help them in whatever way you can so they can achieve their best.  Their success is your success.
4. Hold your own with the Engineering team - their respect is the foundation of your success.  Without it you are dead.   You have been an engineer - you know how to do this.   And you know how important it is to keep up your technical skills, so DON'T be LAZY and FORGET to do this!!  It is a critical skill that will give you an edge over most other PM's in the industry.  Learn the tools, techniques and high-level concepts for the languages, tools, techniques and go to as many technical seminars you can in your personal time.  Yes, most companies will not give you time to do this as part of your day job which SUCKS.  But, c'est la vie.  Look for a place that might have a better balance of what you think you can live with.
5. List of resources - I'll post this soon.  Ran out of time.
6. Prioritize like there is no tomorrow - I cannot stress this enough. Every single day - take a look at the list of high-level tasks/stories/whatever you have for the team, think about direction, strategy, alignment, fit, ROI, and prioritize, prioritize and repeat.  Then share, share, share with the team and the dev manager and stakeholders (if needed).  They will not like it - heck, when you were an engineer, you didn't like it when the PM tried to drill this into your brain either.  So, now that you're on the other side of the fence, guess what, you're going to get some flak when you do this.  Suck it up and keep at it.  This will save your a** later.  Trust me.  Caveat: Don't change high-level direction too frequently otherwise chaos and mutiny will ensue.  Deep and long term thinking are key here - develop both. Read books, go through YouTube videos, get your company to pay for Udemy and Pluralsight accounts and use them - there are lots of resources.  Pick the ones that address your need and discard the rest until you need them.  You have limited time, make the best use of it.
7. Time management - become a master executioner - without this skill, you will burn out and die and slink into bed and not come out until next year.  On a daily basis, you will be pulled in at least 3-4 different directions where you will have to wear 3-4 different hats and talk to different audiences (upper management, your PM team, your dev team/s, external dev and PM teams etc.).  The context switching is pretty high so get used to that.  Prepare for it mentally, emotionally and physically.  PM is a role that can completely drain you and burn you out like a light if you let it.  Be in charge of this and guard your personal time like a dragon.  And if you're called names for it, tough.  Just do it - it will save you in the end.  But do it nicely and explain the why to everyone.
8.  Politics is everywhere - get used to it.  Get good at it and develop a special part of your brain to operate at this level.  This will probably be the most difficult thing for engineers to learn.

I will post more as I have time - ties back to #7 :).