Storytelling is your PM superpower

I was recently reflecting on the following quote:

“Don’t ask yourself what the world needs; ask yourself what makes you come alive. And then go do that. Because what the world needs is people who have come alive.”

-Howard Thurman

The first thing that came to my mind was, languages. I’ve had some of the richest experiences by being able to communicate with people in their native language. For example, traveling around Japan in 2009. I want to continue having such experiences.

It takes a very long time and effort to get to fluency in a language. The rewards, however, are immense.

If you talk to a man in a language he understands, that goes to his head. If you talk to him in his language, that goes to his heart.

-Nelson Mandela

Language is a strong unifying force, and when two people speak the same language, it helps them build bridges, build rapport, and accomplish much more than we can imagine.

What does this means for product management?

Someone recently asked, as a Product Manager do you ever find ourselves wanting to learn more about design?

My answer, unsurprisingly after this preamble, is “absolutely, 100% yes.”

As a product manager, you are trying to speak many languages on a daily basis. The language of marketing, the language of engineering, the language of design, the language of partnerships. You bounce from team to team and, as you do so, you translate ideas, thoughts and feelings from one language to the other. The success of your product depends in large part on your ability to coherently bring these ideas together into a coherent strategy.

You will never become quite as fluent in any of those languages as your counterparts who are immersed in that discipline. Languages rapidly evolve and your colleagues will be fully immersed in the latest slang for their group, while you’ll dabble in it for a few hours here and there. However, to the extent possible, try to speak to your counterparts heart by speaking their language. And never stop learning about the various disciplines’ languages.

One caveat: remain humble. Don’t lose sight of where your limits are. When having a difference in opinion about design with someone who’s much more fluent than you in design, be careful not to overly push your point of view simply because you’ve passed the beginner phase in design knowledge. Propose ideas and explore alternatives together. When at an impasse, suggest getting additional input from users and/or other team members. Resist the urge of contributing too much to disciplines outside of your core language. For engineers turned into PMs, don’t try to dictate your engineering team’s technical design when writing your PRD.

Your core language

There is one language in which you should have primary command of and hone the most: the language of storytelling.

Human beings are able to organize and accomplish amazing things when they all believe in a story that is worth pursuing. You should work the hardest at figuring out why is it that your product matters and tell that story. What will the future look like with your great product initiative implemented? How will your users benefit? Tell that story day after day.

Everyone should understand that picture. Everyone in your team should be able to listen to it, understand why it matters, and be inspired to show up every day to help make that vision into reality.

As a PM, that’s your primary job. It is also your responsibility to drive towards the accomplishment of that vision by doing whatever you can to contribute to the story, as a core believer and participant in it.

Continuously refine the story as the world around you changes, your users change and your product evolves. Don’t forget to evolve your product story, or soon you will find yourself driving towards a vision that’s no longer needed in the world. You will be driving towards irrelevance.

Lastly, you should build an instinct for how your users will react to your product. Speak their language as much as possible and represent your users in your daily conversations. And remember, not all of your users speak the same language, so learn more and more about their language as you go and represent them throughout your company in all of your meetings.

Bringing it all together

I consider communication a PM’s superpower. As someone often seeking to drive initiatives forward through influence rather than authority, having a compelling story to tell and being able to distill it and translate it into what matters most to different audiences is crucial.

Time spent honing a compelling story, figuring out how to best communicate it, translating it for your various audiences, refining it, and lastly driving towards accomplishing it, is never wasted time.

Do this, and allow your teams to contribute their talents and skills towards helping you refine and accomplish that great story, and you’ll delight your users with a great product only a great story could have inspired.

How to ramp up as a Product Manager. Gain context before you try to change things.

I always remember a song I heard as a child by Guatemalan singer Ricardo Arjona. It said (with a profanity substituted) “aquí no es bueno el que ayuda, sino el que no [molesta], acuérdese.” This translates to “here the good are not those who help, but those who don’t [bother], remember that.”

Having recently completed my first 3 months as a PM at Google, I’d say that this is good advice to keep in mind in the beginning of a new job. Instead of having a grandiose plan to make a big difference and impact, start by learning as much as you can without disturbing others.

Here are the things that I’d keep in mind as you ramp up on a new product or team.

Admit that you’re in a learning phase

As a new PM to an existing product, your focus must be in learning. Even when there is an improvement that seems obvious to you, a product idea or process tweak, you should abstain from trying to make your ‘quick win’ or contribution too hastily.

Consider that:

  • You lack context. Your new colleagues have been working on the product area for months, maybe years. They have tried many ideas that failed, talked to many customers, and learned a lot in the process. Try to gain that context quickly.
  • You have zero reputation. You can only go far if your team actually cares about what you have to say. You can quickly tarnish your reputation if you babble ideas or decisions before thoughtfully thinking through problems and considering all aspects of a problem.

So, focus on learning. How do you get started? Instead of trying to revolutionize the team’s dynamic, I suggest that you pick a small project or initiative and use that to prove yourself.

Picking up a few small initiatives

The most important thing I’ve done while ramping up on a new product or area has always been to dive in and pick up a small, non-critical project. It doesn’t matter how small or uninspiring the project might be. What matters is that it is an initiative with the various phases that a typical project will go through.

Your goal is not to amaze everyone by how well you did on this first project. Your goal is to maximize learning by getting through a full cycle of contribution. You will learn many of the quirks of working with your new team.

Going through a small initiative end-to-end will help you figure out the many tactical things that will later on make you much more productive:

  • What template should you use to write product requirements?
  • Who should you consult in the process?
  • How do you communicate impacts to other teams?
  • How do you break down your requirements into stories? Where do you file bugs?
  • Will you have help from other teams (design, eng, user research, etc.)? If so, how much?
  • How often do you need your manager’s input while working through the initiative?
  • Do you need to get approvals or reviews by other teams? Which ones?

Going through the process will help you see gaps in knowledge that prevent you from moving a project forward. Try to maximize the number of times you go through this cycle in your first few months by picking many small, tiny initiatives and owning them. It doesn’t matter if the initiative is ultimately built or makes a big difference.

As you go through the initiatives, just remember that you’re trying to learn, so look for learning opportunities. As why things are the way they are, but don’t try to offer solutions or change things. What you’re looking for is opportunities to learn what’s effective and to tune yourself to make a bigger contribution within your team’s established processes.

Which brings me to my next point.

Tweak your habits, not your team’s process.

It is easy to look at any process and find ways to improve it. There’s a reason that’s the case, most processes just need to be ‘good enough’ to allow the team to work effectively. Constantly tweaking processes so they are ‘better’ is often more distracting than it is worth.

As such, instead of trying to change how your team does things, first accept their processes and tools and use them. Give them a genuine try and, as you do so, observe the pros and cons of sticking with them. Often I’ve seen new PMs reject a team’s way of working, just to come around months later to admit that it’s the easiest ‘quick and dirty’ way to get it done and not worth changing. Prioritizing using a simple Google Doc may feel inefficient when all your requests are in JIRA (or some other tool), but if that’s what your team does, try it out.

Unless something is an impending disaster, wait a few months before trying to change existing team tools and processes.

If and when you do try to change something, make sure it’s something that is worth trying to change. It must be a pain point that’s frequently observed and big. Also, since your change may fail, look for solution that is easily reversible if it doesn’t work out for your team.

Meeting your team

You will need a lot of help over the coming months and years from the people you are meeting now. Meet them as people. Try to learn about their personalities, what they are interested in, what they like and dislike about their job.

You will soon find yourself in meetings and discussions where decisions will be made that will impact the work your team does. You may be working with the engineering lead to decide how to distribute work among the team. Or in a meeting where an initiative is about to get killed or swapped by another one. Knowing your team will help you weigh their feelings and likes/dislikes into the process. It may not change the outcome, but it can surely help you make the process smoother for everyone and provide the right amount of context.

One thing I like to do when meeting people for the first time is to let them know that I’m here to help. “I don’t know anything right now, but if there’s something that you think I can be helpful on, just let me know.” It’s simple, recognizing that you are unlikely to be helpful, but shows your willingness to step up and assist others.

Remember, you’re a PM. You’re not the CEO of your product. You are not here to issue commands or speak of visions for the team to execute. You probably won’t be hiring or firing anyone. You’re here to collaborate with your team to come up with a direction that will make the product awesome. You should be very involved and willing to help your team’s life easier. Make it clear to them that you’re here to do that.

Ask your manager and coworkers for ‘braindumps’

When ramping up, my manager and I lovingly started to use the term ‘braindumps’ for many of our conversations or exchanges. These would be sessions in which she would give me a ton of information and context and I’d just soak it all up while asking clarifying questions. These sessions would be unstructured and we would often jump from one topic to the next.

The idea during these sessions was to surface all sorts of information that may be helpful later. Information such as:

  • How does the product work?
  • How does the product initiative fit within the overall product and company strategy?
  • What are the known issues with a given feature?
  • Why hasn’t an important issue been fixed?
  • Why do these two parts of the product feel so disjointed?
  • What did the team try and succeeded with? How did they start down that path?
  • Who are the players involved in making your product area a success?

Keep these sessions flexible. They are best in person, but often we’d do these asynchronously by using a Google Doc. My manager would type up a bunch of thoughts about an area or topic I needed context around. We’d then discuss.

During these braindump discussions you will have many ideas, thoughts, and potential solutions. Don’t jump into looking for solutions. Remain focused on surfacing issues and tidbits of knowledge.

What you’re after is building a foundation of knowledge around the team and product. At first, all the information that you’ll gather will be in a disarray. That’s OK. You will then take time on your own to organize all this new information in a way that’s useful to you. As you do, try to explain in your own words the things that you’ve learned. Ask “why” until you’ve hit on a point that is easily understandable and actionable.

For example, consider that your note says that your product feature A has stability issues. Ask why? Is it due to a component of the system that it leverages? If so, what are your options to rewrite/substitute/improve that component? How much effort would it take? Why hasn’t it been done? Processing your notes from your braindumps, asking why, and finding the answer to those questions should take several times longer than the braindumps themselves.

The biggest benefit I find of getting ‘braindumps’ from co-workers is that they will naturally gravitate towards talking about things that are currently or were recently relevant to them and the rest of the team. This will make your learning process more focused, since you will quickly uncover the substance of the various discussions that your team has been having over the past 6-12 months, which will allow you to more easily understand what’s going on as you join team meetings and work on new initiatives. This is much more helpful than reading an internal documentation portal with information that hasn’t been updated in 3 years because no one cares about that topic any longer.

Observe your users

I could, and probably will at some point, write an entire article about the importance of getting first-hand exposure to your users. You can learn a lot from talking to your coworkers. But, ultimately, your goal is to build a product for your users. Deeply empathise with those users. Observe them. Talk to them. Find ways to watch them in action. The more you can identify with your users and understand their real goals and needs, the better of a product that you’ll be able to build.

Bringing it all together

Your first few months as a PM can be quite unsettling. You are brand new, want to make a contribution, may have a lot of relevant experience to bring to the table, yet have little to no knowledge or context about your new team and product area. There are major gaps in your understanding that will prevent you from making a large contribution. Thus, focus on learning by picking up many small initiatives, assimilating your team’s processes and tools, asking your co-workers for braindumps, digging deep into the ‘why’ behind what you’re told, and observing your users. After a few months consistently doing this you’ll be ready to take on larger initiatives and will be much more effective at helping your team.

Google Product Management Interview process and preparation

I get asked this question a lot. How’s the Google PM interview process? How do you prepare?

I must admit, it is a lengthy and convoluted process. Below I distilled everything that I learned about the process before becoming an employee or going through the process myself. This is all information found online in generally available sources (e.g., Quora) so nothing I learned while under an NDA.

NOTE: if all you’re looking for is very concrete steps on how to prepare for the phone interview or onsite interviews (steps 3 and 4 below) you can just go straight to crackingthepminterview.com and buy their book. I don’t know the authors, nor get any compensation from sharing their book. But, I honestly believe that it’s the single best resource I’ve come across on how to prepare for the interview and well worth the $10 investment for the Kindle edition. 

First, an overview of the Google PM interview process as of 2017.

  1. Submit your resume (or get referred).
  2. 30-minute phone screening with a recruiter.
  3. 45-minute phone interview with a Product Manager.
  4. 5-hour on-site at Google offices.
  5. Hiring committee review
  6. Team matching process
  7. Pre-review Committee
  8. SVP review

That’s a whole lot of steps. Here are the interesting bits on each of those.

Step 1. Submit your resume / Get referred

A few articles mentions that Google receives over 2 million resumes each year [1], maybe as high as 3 million in 2014 [2].

So, how do you cut through the noise? Get a friend already working at Google to refer you. It’s the easiest way. Also, make sure your resume is sharp by following pro tips. [3]

One thing that I’ll stress is this tip: ” If you’re applying through an ATS, keep to the standard formatting without any bells and whistles so the computer can read it effectively.”

You’d be surprised at how many resumes are never looked at just because a computer system wasn’t able to parse out the information properly.

Step 2. 30-minute phone screening with a recruiter. 

If you’re resume is selected as a candidate, you’ll get an email from a Google recruiter to schedule a 30-minute review of your background and ask some high-level questions. The recruiter will try to match you to an open position for which you may be a good fit.

Preparation for the recruiter screening

Be ready to discuss your background, skillset, and anything that’s on your resume. The recruiter may screen you out if they don’t think that you have the right skills for a position or the right attitude.

Consider this, the recruiter is trying to get a quick sense of whether you have a shot at getting hired. They speak to about a hundred people before they come across one person that will successfully make it through the process. As such, be prepared to give them a reason to ‘bet’ on you and put you through the process.

Step 3. 45-minute phone interview with a Product Manager.

Assuming that the recruiter thinks that you’re a good candidate for PM, the next step is a 45-minute phone interview with a current PM.

Preparation for the PM phone interview

The interview questions can vary a lot. I recommend that you read over the book “Cracking the PM Interview” [4] as it was an amazing resource to me.

Google loves seeing how you think about problems in action. Most interviews focus on working through a problem or hypothetical situation. The critical piece here is to talk through your reasoning. Write down each step and describe it out loud to your interviewer so that they can follow. Practice is important, in particular having reference frameworks for different product types. I picked a few practice questions from each area within the “Cracking the PM Interview” book and worked through them simulating an interview (speaking out loud as I went through the problem.) I also had a friend quiz me on these and give me feedback.

Tip: you want to be mindful of time, but it is more important to explain your reasoning and write it out clearly as you work through situations and problems. Your interviewer will nudge you if you’re taking too long, and will help you move along. This is OK and far better than your interviewing not understanding how you reached a solution.

Step 4. Onsite interview at a Google office.

This is the most difficult step in the process, but the preparation for it is pretty much the same as for step 3 (the phone interview). The one additional consideration is to ensure that you review all of your computer science fundamentals if you haven’t yet, since you’ll have one technical interview with a Google engineer. During the technical interview, it will be crucial for you to show your understanding of data structures, software design, system architecture, and more.

Outside of the technical interview, the rest of the interviews are pretty much a deeper view into aspects that might have been covered during the phone call (analytics, product design, marketing, etc.) You will also have lunch with a Googler. The lunch is more relaxed and not an interview, but your lunch buddy may submit feedback that may be factored in the overall decision.

Step 5. Hiring Committee review

You don’t do anything here. You just wait to hear back. The hiring committee is in charge of reviewing all of the feedback from your interviews so far and providing a hire/no hire recommendation. The way this works is as follows:

  • Each of your interviewers submits a report detailing what was covered during your interview. This includes a summary of the questions they asked, your answers, and their evaluation of your thought process and answers. They also give a recommendation based on this. Your interviewers submit this information independently, that is, they don’t talk to each other about you at all.
  • Each member of the hiring committee reviews all of the feedback from the interviewers and give an overall score to your application. This ranges from 1 (no hire) to 4 (hire). A score of 2 is a hesitant no hire, while a 3 is a hesitant hire.
  • During the hiring committee review, the committee approves those candidates that got mostly 4s and no 1s or 2s. Rejects those that got 1s and 2s. And discusses those in the middle (maybe a 4 and a mix of 2s and 3s, etc.) The higher the spread in the reviewers ratings, the more likely it is that it will be discussed.

Getting the hire recommendation from the hiring committee is a feat in and of itself, but it’s not the end of the process.

Based on various answers by prior hiring committee members and recruiters, about 10-20% of people that make it to hiring committee review get approved to move forward. [5]

If you do get the thumbs up from the hiring committee, it looks like you have about a 90% chance of getting the final offer. At this point, you don’t yet have a Google offer. [6]

Step 6. Team matching process

After the hiring committee approves your job application, you become a candidate to meet managers to get matched to a team. Your recruiter will talk to you about your interests first, if they haven’t already. The recuiter reaches out to managers with PM openings in their teams if they align with your interests. The managers get your resume and interview feedback. For those managers interested in talking to you, the recruiter will set up a few meetings (typically a 30-minute phone conversation).

These meetings with potential managers are not interviews. You shouldn’t be asked to answer difficult questions, but you’re speaking with your potential future boss, so keep that in mind. Also, the manager needs to want you on their team if you want to work for them. The calls tend to be 30 minutes of informal conversation. Managers with openings are often eager to find a candidate that made it past step 5, so it’s often more of an opportunity for you to rank the teams you’re interested in and ask them questions that give you a good sense on whether you’ll enjoy working with that team.

With luck, that manager will also want you in their team and your team will be chosen. Then things move quickly to the final 2 steps.

NOTE: if you don’t get matched to any team with an open position, you won’t get an offer. It is important to keep that in mind.

7. Pre-review Committee

Once you’ve been matched to a team, the recruiter puts together the review packet for approval by the pre-review committee.

The function of the pre-review committee is to calibrate the hiring bar across the many hiring committees. There are 100s of hiring committees, but only a few pre-review committees who help bring consistency across the many hiring committees. [4]

In addition, the pre-review committee helps discuss your compensation. Pre-review committees are composed or very senior Google employees and are thus in a better position to review and discuss your compensation and calibrate it.

8. SVP review

This is the final step. The Google SVP group reviews every candidate that passes through all of the steps before it. They are the final offer approvers. They do company-wide calibration. It is only after this step that you get your official Google offer.

Additional notes

Looking at the overall funnel and the stats I’ve found, it seems that here are the odds of getting an offer are 0.3-0.5% overall. This means that the process is going to be quite rigorous.

If you’re curious, I estimated based on some online research the percentage of folks that get an offer at Google by interview stage. That’s all based on a ton of estimates, and thus not super helpful, but I found it helpful to keep things in perspective as I went through the process. It was a good reminder to prepare hard, hope for the best, but be prepared for a bad outcome.

The process is optimized to minimize false positives, thus many people apply and interview multiple times before getting an offer. That’s both the good and bad news. If you think that you can succeed at Google, and at first get rejected for a role, you should apply again after some buffer time (discuss this with your recruiter), since many folks I’ve met have gotten a job offer only after applying 2-3 times.

Stats (mostly quoted above)

  • Google gets about 3M resumes a year (as of 2014 [2])
  • Google added about 9k employees to its headcount between 2014 and 2015 [7]
  • A 0.3% to 0.5% overall hiring rate would yield between 9-15k hires out of 3M applicants. That range seems about right based on attrition and offers rescinded.

This breaks down roughly as follows, by stage:

  • Resume screening: based on the overall yield of 0.3% to 0.5% and pass rates used below, it seems that about 35% of applicants pass this step. That’s ~1M per year that pass this step, ~1.3% of which will ultimately get an offer.
  • Got a phone interview: 10% pass this step [8], that’s ~100k per year, ~13% of which will get an offer.
  • Onsite interview/Hiring committee approval: 10-20% pass this step, ~15k per year, 90% of which will get an offer.
  • Pre-review and SVP review: 90% pass these steps (~13.5k per year final offers estimated)

References

[1] https://www.forbes.com/sites/stanphelps/2014/08/05/cracking-into-google-the-15-reasons-why-over-2-million-people-apply-each-year/

[2] About Sept 2013 to Sept 2014, “The year Bacon was there, he says that Google received about 3 million resumes.” https://www.fastcompany.com/3052371/a-former-google-recruiter-reveals-the-biggest-resume-mistakes

[3] https://www.themuse.com/advice/43-resume-tips-that-will-help-you-get-hired

[4] http://www.crackingthepminterview.com/

[5] https://www.quora.com/What-happens-in-the-pre-review-and-svp-review-steps-of-the-Google-software-engineering-application-processhttps://www.quora.com/What-percentage-of-applicants-that-make-it-to-Googles-hiring-committee-get-approved

[6] “…generally about 10-12% are not extended offers.” https://www.quora.com/My-Google-recruiter-has-asked-me-about-my-current-compensation-and-external-references-Whats-the-probability-of-not-getting-an-offer-from-this-point/answer/Bob-See

[7] From quarterly earnings reports, March 31 2014 headcount (46,170) vs March 31 2015 (55,419) headcount, a 9,249 increase. https://www.quora.com/How-many-employees-does-Google-have/answer/Kelvin-Ho

[8] Re: the phone interview, “About 1/10 candidates pass this step…” https://www.reddit.com/r/cscareerquestions/comments/1z97rx/from_a_googler_the_google_interview_process/

Resources when transitioning into Product Management

A reader was curious as to what resources I found most helpful while transitioning into Product Management from a non-technical background [1]. Below is a list of things that I have found both helpful and rewarding, which are mostly about Product Management related topics. Most of the online resources are free. I’ll update this with new resources later on as I learn more.

Note: Product Management is done quite differently in different companies, but the resources below are applicable across a wide range of companies and roles.

General Management

Design

Agile

Technical knowledge

Entrepreneurship & Product Strategy


[1] Post inspired by a question a reader submitted via Medium on https://omareduardo.com/2017/05/21/my-transition-into-product-management-from-a-non-technical-background/

My transition into Product Management from a ‘non-technical’ background 

It will soon be 3 years since I transitioned into Product Management full-time. Prior to that, here is what my résumé included.

  • Bachelor’s in Chemical Engineering
  • Healthcare Consulting (3 years)
  • Customer Success Management (1 year)

I then transitioned into Enterprise Software Product Management at BloomReach, a Software-as-a-Service (SaaS) company. It was particularly important to me to do Product Management (PM) at a company in which Software is the core product.

In my specific case, the opportunity to transition was a mix of preparation and luck. In this article, I want to highlight some of the more practical aspects of my transition. I want to offer it as one sample journey that didn’t involve going back to school for either Computer Science training nor an MBA.

Personal awareness and setting a goal.

The first step to transition into PM was being clear in what I wanted to do. Without this clarity of mind, I doubt that the transition would have ever happened. The reason I quit consulting to join a Silicon Valley startup was to learn how to lead in a startup environment. In particular, it was important to me to gain skills that would be relevant when building and growing a new company.

With three years of consulting experience and working in a Customer Success role at a technology startup, I had a great set of skills that helped me engage successfully with enterprise customers. I understood my customers’ businesses and could effectively position our product so that the customer crisply understood our value. I was fluent in business talk — talking to an executive about ROI, year-over-year growth, market trends, opportunity cost, etc. became second nature to me. Given this level of comfort, I decided that it was time for the next phase in my quest to build skills relevant to building and growing a new company.

At the recommendation of a mentor, I wrote down what I wanted to be able to deliver over the next year. My keen interest, I realized, was to gain the necessary skills to understand and influence the core product. As a software company, it is the product that carries the most weight in the success of the company. A PM is best equipped to influence the product and, I realized, the gap between my skillset at the skillset I needed for a PM job was centered around product design and technical understanding. Developing those skills was within my power — there are many great online resources for this. Also, working at a technology startup in Silicon Valley I was surrounded by brilliant minds that could assist me in the process.

Communicating my intent unambiguously.

Having clarity was crucial as a first step. The next step was more important. I communicated clearly and unambiguously my intent. I told my boss that I wasn’t interested in moving up the ladder within my current team, the logical next step in my career. Instead, I wanted to spend any of my discretionary time at work on projects that would allow me to transition into Product Management.

Some people within upper management were surprised by how candid I was on this point — it isn’t every day that an ambitious millennial comes to their manager refusing a potential promotion. I will admit, there was risk taking this step — I could end up not getting promoted within my team nor able to transition into Product Management. I considered this. However, if being clear on this point could aid, even in the slightest, my chances of moving into PM it was worth it.

Preparing for the next step through a project.

At the time, this wasn’t as clear to me as it is now. However, the most important next step was getting involved in the right project. Doing that wouldn’t have been possible, however, if I hadn’t spent my time closing some of my knowledge gaps on product and technology.

I spoke to other Product Managers and read up on the job. I also asked a lot of questions about how our product worked. A nice engineer gave me a quick overview of Hadoop and MapReduce. An Integrations guy taught me how to see in the web-browser when our JavaScript tracking pixel ‘fired’ and see if there was anything wrong with it. A product manager taught me how she worked with the design and engineering teams to define a new feature and sequence its execution. Our data analysts helped me get SQL Workbench setup on my computer and taught me basic SQL scripting to get data off of our analytics databases. Yet some other nice person taught me what an API call was, what it looked like, how it was executed, and how the customer would work with the response. Someone explained to me that the Cloud I spoke of was just a bunch of servers on Amazon Web Services (AWS). In my spare time, I did a few programming exercises in HTML, CSS, JavaScript and jQuery to better understand what the hell was going on when I browsed to a website.

All in all, this was a time of just learning the basics of many technologies so that I could build a baseline framework in my head of how our cloud product worked. This made me feel more comfortable talking about the product to customers and developers integrating our product.

I also found it helpful to learn about the software development process. Learning about Agile Development, scrums, PRDs and design tools was helpful in this regard.

I will be perfectly candid here, I was searching for a clear list of things to learn. I wanted something titled “The perfect guide to all things technical that you must learn to become a Product Manager.” I never came across such a guide. If you are looking for something similar, I find the following exercise to be more helpful. Just pick any service that seems interesting and learn about the components that were used to build it. For example, a simple search about how was Facebook built yields answers such as this and this. Also, kind folks over at Quora answer just about any question people have.

A project to showcase readiness.

The next step is where readiness and luck both played a role. A few months after I explicitly asked to spend my discretionary time on Product Management activities, an initiative with a top client came up. It was an initiative that required a mix of customer success, integrations, and product management skills. It also happened to be related to our new product, which I had spent my spare time learning about.

An executive within the company endorsed the idea of having me as the ‘glue’ between the customer and engineering for that initiative. The other Product Managers didn’t have the time to do this so I would work directly with the executive in charge of the product to deliver this initiative.

This wouldn’t have happened if I hadn’t been clear with my boss about my intent to focus on Product Management. It also wouldn’t have happened if I hadn’t done well at my primary function in Customer Success.

Ship and wait for the next opportunity.

Once on this project, it was a matter of dedicating all that I had to ensure that it was successful. I had to work with the customer to understand requirements and clarify prioritization, worked with engineering to design the product functionality, and do a lot of project management to ensure things were done on time. The project was executed smoothly and it showcased well.

Once this had been completed, the timing was on my side. The Product Management team had a few openings and it was only natural for me to transition into a junior role within the team.

A helpful framework

Many things could have been different in my story. I may not have gotten an opportunity within BloomReach to transition into PM, in which case I would have had to look elsewhere. Or maybe it could have taken longer. But, there were a few crucial steps that I strongly believed can help you also maximize your chances of a transition into Product Management.

Be clear on why you want to transition into Product Management and communicate it. Everything else is much easier if you have clarity of purpose on this. Be willing to give up other tempting opportunities to focus on what truly matters to you.

Take the risk and put in the time and effort. When I started learning more about the product, a Product Manager at BloomReach candidly told me that it was possible that an opportunity within BloomReach may never arise for me to transition into Product Management. However, not letting that deter me was key to continue focusing on learning and growing into what would eventually become my opportunity to move into a Product Management role.

Find a logical adjacent move to make. My journey into Product Management is filled with adjacent moves. From a bachelor’s in Chemical Engineering, I went into Technology Consulting. I had strong analytical skills but needed to learn business and project management. From there I moved into Management Consulting. I had good general business skills and financial acumen but could improve in Strategy and Business Transformation processes. This then opened the door to join a Customer Success team in a technology startup where I could contribute broad business skills and learn about technology and Silicon Valley. Finally, with this broad knowledge of business and diving deep into the product, the next adjacent step for me was the PM role.

Learn, learn and learn. All of these adjacent transitions were enabled by doing a ton of learning. I personally read up a ton about our products and the technologies that we used. A popular option in Silicon Valley is to build your own website or app. You can partner with someone who’s more technically or business savvy, depending on your skillset, and build a simple app or web browser plug-in. The process of figuring out what to build, what features to prioritize, how to build it, etc. will start giving you an idea of the product management process. You can also read other books or online sources. Here are a few I used.

Volunteer your time to help on your area of interest. This is how you find sponsors! Every transition I’ve made within a company, whether a company such as Accenture with over 200k employees or BloomReach with less than 150 at the time, came after a more established senior person endorsed my transition. When I moved from System Integrations consulting into Management Consulting at Accenture it was thanks to the endorsement of a Senior Manager I helped on my spare time. Moving into Product Management required the endorsement of my boss, an executive I worked with, and our CTO whom I had a chance to interact with thanks to the project I mentioned above.

I hope that this helps you in your journey. If it does, I’d love to hear from you!

Don’t defend your product prioritization. Instead, show how you got there.

A critical part of a product manager’s job is prioritizing what to build. You must decide what to build now in order to make your product successful in the long term. More importantly, you decide what not to build.

This will always draw plenty of opinions. Your colleagues have an example of clients that loved a particular feature idea. Your clients ask for certain features to accomplish their current goals. The customer success teams need you to simplify the product’s integration and usability. Engineering needs time for innovation, cool features, and infrastructure improvements. The sales team request the features that your competition is touting. The marketing team needs you to deliver the future.

As a product manager, it is your job to assimilate many inputs to help create a full picture of the pressures that your product faces. You must use this knowledge to make a recommendation of what must be built over the next 3, 6, or 12 months. How do you do this?

Start with company priorities

If your company’s executive team is worth their pay, they’ve established a clear set of goals for everyone to rally after. You must start your prioritization with these goals in mind. How does your product fit into these company initiatives? What is the key metrics that your company is seeking to improve? Are there any specific markets that must be pursued? Are there certain users that you must prioritize? Make sure that these are the key factors in your prioritization.

If this is not immediately clear to you, clarify it with your company’s management team. You will fail as a product manager if you optimize for your own vanity metrics rather than the company’s goals.

Build a framework to evaluate requests

Evaluating features or initiatives must be a mix of data and judgment. As a product manager, you are trying to factor in a large number of factors: impact on new customer acquisition, customer retention, cost to build, cost to support, differentiation from the competition, etc. For some of these factors, you will have clear information or forecasts. For others, though, you will need to make a judgment call.

You can simplify your prioritization by defining a framework to score each theme and feature. The goal of this framework is to help make it easier to surface the initiatives that will have the biggest impact in the areas that matter the most.

I use a simple spreadsheet. The first column lists all initiatives being considered. The next set of columns contain the various factors identified as important. Each initiative will have a score for each factor based on the overall impact to that factor. There should be a clear definition of what it would take for the initiative to get a 1, 5 or a 10. In the next column, add a blended score for the feature. If you care most about one factor than the rest, you can multiply that factor’s score by some number (2, 3, 5) for the overall blended score. Finally, a column for notes to add any special considerations that went into that initiative’s scoring.

This process is not meant to replace your human judgment or “visionary” work. Instead, it is a way to remove some of the complexity in coming up with an answer. It brings clarity by forcing you to score each factor independently for the initiative. You can then focus your discussions with others on whether the impact to a particular factor or KPI is overstated, understated, or whether the factor should be weighed more heavily than others. Those discussions are more focused than a generic conversation about all the ways in which feature A may be better than feature B. Yes, feature A may be awesome, but if it doesn’t help me improve customer engagement and that’s my core goal, it may lose to Feature B in my prioritization.

Communicate and show your work

This brings back memories from math class back in elementary school. My teacher would always ask me to “show my work.” It wasn’t enough, she said, to write down the right solution. Show the steps and the logic behind the answer. Similarly, it is important for product managers to show how they arrived at a given conclusion. This is critical since there is no one “right” answer that everyone can agree on. Your colleagues can see your work and argue on the logic of prioritization rather than the answer.

Showing your work could take the form of a beautiful spreadsheet (as I described before). Or it could be a presentation succinctly discussing the core factors at play. It could be a write-up. It could be anything. But have something that anyone in your company can take a look at and get a sense of (1) what you prioritized and (2) what else you considered that didn’t meet the cut, and (3) why. Otherwise, be ready to get stuck defending and revisiting your prioritization an insufferable number of times throughout the quarter.

Whatever you do, keep it transparent

Your approach to prioritizing features will invariably be a mix of researching information coupled with a final judgment call. Once a quarter, you sit down and write out 10 things that you must build next in order for your product to be successful. You will have plenty of discussions and considerations that lead you to a certain prioritization. Don’t make the mistake of keeping this information in your head. Take the time to write this information out. Keep the prioritization criteria somewhere that’s transparent to everyone in the organization. Whenever someone has a question as to why something is or isn’t being built, point them to the document and be there to answer questions.

Assuming that your colleagues are trying to accomplish the same goal you have, to make your company successful, this should smooth out conversations. Give your colleagues the proper context and, just maybe, they might agree with you and support you. If they don’t, you can have a healthy and focused debate on what matters for prioritization without getting invested in specific initiative or feature arguments.

Liked this article? Follow the blog to get notifications of new ones as we publish them. 
Interested in continuing the discussion? Write a comment below! 

Non-technical PMs don’t need to study CS, but must be technically curious to be effective.

Originally answered in QuoraWhat core CS concepts should someone with a non technical background study if they want to break into product management?

I focused on this question as I tried to transition into Product Management. Here is my experience.

1. You will not get hired into Product Management because of your Computer Science skills. Your understanding of CS concepts will be a small part of your role as a PM. Your engineering counterpart will own technology and implementation decisions. Or any other decision that need a good understanding of CS concepts. A caveat, each company has a different recruiting process and some require you to be able to ship code. If your background is not technical, you’ll be at a huge disadvantage going for a Product role in such a company. I’d look for opportunities in companies where the Product role doesn’t include shipping code.

2. Yet, understanding CS concepts will make you a more effective Product Manager. It will also help you build better relationships with engineering. Some situations when it helps to understand the product include:

  • During feature design. You will often work with a designer and an engineer to define a user interaction. It helps if you understand the tradeoffs between user experience and the cost to build.
  • Debugging issues. You will often be asked why a product isn’t working as expected for a customer. It is helpful to know what is wrong without distracting engineering from development. Understanding the components of the system can help you do this. You can often reframe the “issue” reported as a feature request or user error. This can reduce the pressure to ship a ‘fix’ immediately.
  • External discussions. A PM is often asked to talk to potential customers of their product. This is particularly the case in enterprise products. These conversations will often include technical questions. Answering the questions without bringing in an engineer can help the PMs credibility. It can also speed up the sales or integration process.

Now, what you’ll realize with each of those scenarios is that the knowledge that you need is varied. As such, I’d recommend that you approach the problem with general curiosity. Start learning about a technology used in the type of product that you’re interested in managing. If you don’t have a particular desire, pick a few of the most common technologies to start learning. Here are a few examples of things that helped me.

  • HTML, CSS, and JavaScript/jQuery. Understanding the power and limitation of HTML, CSS, and JS/jQuery will be helpful for any web product. Codecademy teaches you through building a simple site using these technologies. This will help you in conversations about client-side vs server-side, performance implications, etc.
  • Product’s infrastructure components. It is critical to understand the technology components that power your product. At BloomReach, we use many technologies to build our product. Amazon Web Services (AWS) cloud infrastructure. SolrCloud for our search engine. Cassandra for our database. We’ve built our codebase in Java and Python. Our dashboards may use the Play framework, AngularJS, or ReactJS. Each technology has limitations that you should understand as a product manager. They will guide what efforts you may need to focus on to improve the system. Understand them at a high level. What can you use this technology for? What are its limitations? How does using it help/hinder the product development? What are the implications in product performance? How does it impact the user’s interaction with our product? We developed foreign language capabilities last year. At the time, we had to evaluate whether to use pre-packaged components or build brand new ones. As a PM, I collaborated with engineering to make a decision based on the pros and cons of each approach. The cost to build and impact to potential roadmap features was a key consideration.
  • Do simple programming exercises. If you’ve never programmed, take a simple course in Python and Java or C programming. Writing a few lines of code and having it execute well will start giving you a sense of how a computer works.
  • Learn the vocabulary of your area of interest. Each product area has a lingo. Learn what things mean. Machine learning may sound intimidating until you’ve read a bit about it. What is a “cloud” product? Is it better than an on-premise product? Why or why not?
  • Potential exercise, build an app with a friend. I find that in Silicon Valley building your own app on the side gets you good street cred for a PM role. I have my hesitations about how effective that is in helping you develop the skills necessary to be an effective PM in a larger organization. But, it’s a great way to gain experience prioritizing what to build when. You’ll learn to evaluate benefits relative to development cost. You’ll also learn to define the spec for a developer to build.

In general, I’d suggest that you are technically curious. Your PM job will be about a lot more than technical expertise, but being technically curious will make you more effective. It will also help you build credibility, both with your engineering counterparts and your customers. Don’t be afraid to ask questions and read up on things in your spare time.

Follow omareduardo.com for other posts like these.