Luke – Page 2 – LUKECONGDON

THE PM TRAINING GOLD RUSH

THE RISE OF CREDENTIALING

After 10+ years of solid economic growth and free money, the US is seeing the economy pump the brakes. Over the past decade many product managers benefited from corresponding strong career currents that come with a strong economy. When economic tides shift, however, opportunities become less open. It’s no surprise that universities see higher enrollments in lean times. The opportunity cost of splitting your time and leaning back slightly at work are lowered. I expect many are currently starting to consider if now is the time to go back to school. In recent years I’ve noticed that credential programs and universities have surged forward and are offering a plethora of product management certifications, courses, and degrees. As a PM hiring manager, I recommend choosing additional credentialing programs carefully. Not all are meaningful to hiring managers, and their value may only be comparative when looking at multiple candidates. Further below I include my thoughts on specific PM credential and degree programs I’ve seen in the past few years.

HISTORY REPEATS

Across a long career I’ve seen multiple economic downturns. They didn’t all bruise me personally, but I have memories of those times. I remember the 2008 global housing meltdown, the 9/11 2001 attack, and the year 2000 dot com burst. I even remember black Monday in 1987, though I was barely in high school and wasn’t yet working career jobs. Across all of these, I never lost my job, but I did know many who did and many who struggled, and growth was slow. The last decade+ has been an unprecedented continuous period of economic growth. Times have been good in a macro sense.

Nearly 15 years have passed since the mess of 2007/2008. If you don’t remember that time, the movie The Big Short is a great dramatization of that period. This latest turn in the economy might be a new and shocking experience for you. With that lens, I can see why the state of the current economy may have a lot of younger career people nervous and considering what you can do about it.

OPPORTUNITY COST DECREASE

There is inversely some good news when the economy starts shrinking. The opportunity cost of investing in additional education or PM training shrinks. If you had been considering more training this might be the best time to do it. Training takes money and time. In all cases this won’t change. What is different is what you could have otherwise done with your time during this downturn. Previously you may have had better outcomes by working and investing your time in your job. Now that companies are slowing or freezing hiring, you may get better future growth by spending extra effort on training instead. This could include keeping your job while you add training.

I lived this myself in the dot com crash in 2000. I had already started a MBA degree before the crash, but as my employer Yahoo! had started moving teams to lower cost states and offshore, I changed gears to finish my last year and a half full time. With the tech sector in shambles, very little career progress was missed while I worked on this. I believe we’re entering a phase like this time again right now.

While opportunity lost is low, please be careful about who you decide to add training with. If you’re looking to get into product management, consider if you can do this with your current employer. Not all certificates are worth your time, and not all degrees might be aligned to your goals.

THE CREDENTIALING GOLD RUSH

When I first moved into product management in 2005, there were no courses you could take for product management training. At the time, Pragmatic Institute had a good marketing course which PMs would take which addressed some related product topics.Back then most PMs learned on the job. Many also got MBAs which broadened skills, but which didn’t teach product management specifically. Universities weren’t offering PM degrees or specializations, and certificate programs in my experience didn’t exist. Over the past 7+ years I have started to see more groups offering PM training which is a great step forward for the career. The gold rush has begun. Product management is an in-demand career, and many universities and private programs are now offering a wide range of specializations, certificates, and programs. While I am happy to see some formal skill-building programs, people considering these need to do their homework. Hiring managers like me don’t look at them like magic bullets.

MARKETING VS REALITY

Here’s the brutal truth. PM certificate credentials for me don’t add a lot of positive confirmation benefit to a candidate. They are usually short duration certificates which anyone can get with a relatively low time investment. Some that I’ve seen aren’t even taught by people with product management working experience which makes their value suspect. Others do benefit greatly from practitioners who have done the job, founded companies, and written books. Check out Melissa Perri at HBS and Brian Balfour at Reforge.

Conversely, I also don’t think these certificates are bad. They are neutral in most cases. In the absence of PM career experience, demonstrable training shows some level of commitment to the career path. The challenge for a hiring manager therefore becomes, what signal are they providing? For me the signal is verified interest. That’s all. When hiring in practice, I do hear internally and externally from interested people. If they have never done PM before, certificates tell me they are interested enough to put some effort in. The certificate won’t get you the job, but it can put your resume into the, “I’ll consider this one for an entry level candidate pile”. Your work background and other qualifications still need to match the needs of the role.

EVALUATING CREDENTIAL OPTIONS

I am not in a position to decide who has a great education program. I have not taken these courses myself. What I can do it look at the profile of each and suggest how you can think about them. In my view these are some fundamental questions you can apply to any program. Cost matters but I don’t include it as a question. If the quality of the training option is not strong, cost won’t matter. Caveat emptor. This is what I would look for:

What topics and curriculum are they teaching? Is it skills-based? Is it business model-based? Is it practical and hands-on? Are there case studies? Some combination of these seem necessary.
What’s the teaching format? In-person? Pre-recorded video? Interactive? Project-based? Etc. In-person and/or live video I believe provides the highest fidelity experience, but you can also choose the format that works best for you.
Does the teacher of the class have actual product management experience? Is that experience multi-year and multi-level or function? Can they actually teach you and respond with insight to your questions? There are lots of smart people and good teachers, but experience matters.
Bonus: Are there a networking opportunities or career services offered to help you bridge your career into an actual work opportunity? This is a big ask for any program, but if offered it would be a value add.

INTERESTING EXAMPLES

Over the past couple of years I’ve saved references to programs that I came across online. I’ve included these below. There are very likely others I have not included that exist. These come in three flavors which include a certificate program, a boot camp or class, and a university degree.

Note: I am not personally recommending any of these options. Any decision to invest your time or money into a course needs to be evaluated by you. As an aspiring PM, you can use your analysis skills to evaluate, critique, and ask these programs critical questions.

CERTIFICATE PROGRAMS

Northwestern University Professional Certificate in Product Management

Berkeley ExedEd Product Management Studio

Stanford Product Management: Accelerated

Pragmatic Institute Product Management Course: Foundations Online

General Assembly Online Product Management Course

ISB (Indian School of Business) Executive Education Product Management Programme

BOOT CAMPS

Columbia University Columbia Engineering Product Management Boot Camp

Reforge Product Management Foundations

Product School Product Manager Certification

DEGREE PROGRAMS

Carnegie Mellon University Master of Science in Product Management

Technological University Dublin Product Management (PG Dip)

MBA DEGREES

I covered this option in 2019. Read “Does your Silicon Valley Career Need a MBA?”. In brief, my recommendation is ‘maybe, your mileage may vary’. You need to understand what your goal is in getting one, and what you plan to do with it when you’re done. It’s not cheap, and it will take at least two years. Your choice of school also has a significant impact on the perceived value it will add to your profile. Many PMs get MBAs. Many don’t and they are also awesome. Do your homework before taking the plunge.

CHOOSING TO INVEST

In my opinion the value of a PM credential is signaling if you’ve never had a PM role before. Skills matter and these programs do work to teach relevant skills. For me, attitude, a disposition to take action, and eagerness to learn are more important first level criteria. In the absence of any PM work history, a class or a certificate program does show interest to learn and willingness to invest time and resources. When comparing similar candidates, a certificate can help you stand out just a little bit as a first PM role seeker.

Compared to certificates, the boot camps and the degree programs are more interesting to me. They appear to go deeper into training and may have a higher success ratio with helping you get into PM roles. I like the deep attention to skills and the resulting project-related assets you build and can use to build a personal portfolio. This is especially interesting because as a working PM, you won’t be able to show your in-process work. I.e. You can’t post your user stories, PRDs, or functional specs from a private company under NDA. You can only show the final result if it’s publicly visible. Training that creates output assets not only give you practice, they give you an initial work portfolio you can show to prospective employers.

Similar to coding camps from 5-10 years ago, PM training appears to be the new hot area. Provided you get the right results out of any coursework you take, I believe these can be valuable. In my opinion the best outcomes are skills training from qualified and experienced professionals, displayable assets, and training into how to get the job done across many groups. I like the theory and background topics, but I especially like to see training on how the job actually works to make productive and successful new PMs.

ABOUT LUKE

Luke Congdon is a career product manager living and working in Silicon Valley since 2000. His areas of focus include enterprise software, virtualization, and cloud computing. He has built and brought numerous products to market including start-up MVPs and billion-dollar product lines. Luke currently lives in San Francisco. To contact, connect via luke@lukecongdon.com or https://www.linkedin.com/in/lukecongdon/.

by Luke

STAND AND PITCH; BECOMING BULLETPROOF

THE CUSTOMER PITCH

If you’re new to product management, or thinking about getting into this field, you’re likely aware of the immediate responsibilities of a PM. You’re either very focused on a single product or a single feature of a product if the product is large or complex. You will primarily work with engineers, customers, and your peers. As you work with customers and customer proxies (salespeople, sales engineers), you’ll respond to questions about features, timelines, requests for enhancements, bugs, and questions about your feature or product.

In time, you’ll become aware of a different kind of customer engagement where a customer wants you to tell them your overall company and product story. As an entry PM, you probably won’t be asked to do this. You might not even know this goes on since the people that do this in the product organization are your senior team members. These meetings come in a few varieties that I collectively call ‘the pitch’. To grow as a PM, learning how to perform these pitches is a critical skill set. As you reach more senior PM roles, it’s also an expectation of the role. Being able to pitch and represent the company correctly and with confidence, is a door-opener for next-level roles.

ROADMAP VS VISION

Most often I see two different kinds of pitch engagements. The more straightforward of the two is the product roadmap. This is usually the one to one and a half year future view of what you’re going to build. In the context of your own feature or product this should be something you know intimately. As you gain experience, you’ll be asked to present the roadmap for the entire product. If you’re a multi-product company this will take research and study as you may have no operating experience with the other products. It is very useful to know all your products outside your own, even at a superficial level, because your customers don’t know and frankly don’t care where your area of expertise begins and ends. If you’re on a call with a customer as a product leader, you are providing their opportunity to ask questions about anything your company does.

The second engagement type is the story and vision. This is the ‘why do you exist’ and ‘where are you headed’ story. These are almost always combined and are delivered by more senior people. This is due to two reasons. The first is that it can take years to intimately know your product line, then the other products your company offers, or the range of solutions and context in your industry. E.g. Let’s say you just joined a cloud computing company like Microsoft Azure or Amazon AWS. These companies have wide datacenter product lines, many competitors, and a massive ecosystem of other products from other companies which your customers concurrently use together. In addition, customers often have legacy environments they still support. Note: The term ‘Legacy’ is code for old or really old. E.g. 43% of all banks still run on COBOL, a programming language which was designed in 1959. This amount of context takes years to acquire and weave where appropriate into the your story and vision where needed for your customer. Often when a very large Fortune 500 customer wants this update, your CEO or senior executives themselves will handle this part of the engagement.

WHY THE PRODUCT PITCH MATTERS

One thing we didn’t cover yet is, why are we doing this? There’s a quote I like that essentially says, ‘everyone is in sales’. You are supporting the sales function. Customer leads and existing customers want to know the vision of your company and your roadmap because they are making decisions where they will invest potentially hundreds of thousands of dollars. Enterprise products are very expensive. Your customer will be living with this year’s purchase decision for the next four or more years. You also have competition. These customers want to know if you are the real deal. Do you have the features they need? Moreover, are you selling to them today, or are you on the journey together with them for the next five years? The roadmap and the vision pitch are only partially about product details for the most part, they are about conveying confidence to your customer.

The purpose of the pitch therefore, is to get to the next meeting. You do your part to make the customer comfortable so that the account team can get to the next call, and one step closer to a sale. Enterprise sales can sometimes take months, even years to compete from prospect to sale. Your roadmap matters, but you’re not there to teach your customer how your product works in detail. You’re there to leave them feeling confident that you are the right company investment for them. If you succeed, the account team takes the next step closer to making the customer happy and getting to a purchase. By the way, if you perform poorly and lose customer confidence, that sales team will probably make sure you don’t present to their customers again.

OVERCOMING FEAR

When I was in the sixth grade, we were required to recite “The Road Not Taken” from memory in front of the classroom in our English class. Like many, I found it to be a nerve-wracking experience but I managed it. I can still remember a good portion of that poem from memory. I find that many remain terrified of public speaking as a life long phobia. For myself, despite also taking a university level public speaking course, I only became comfortable with it in my mid-30s. To grow in product management, speaking to audiences is an indispensable skill to hone. You will need it frequently as you speak to internal teams, customers, trade shows, are on booth duty, and more.

A few months ago I quipped to a nervous team member that only the first 100 times they presented the roadmap would be bad. I was joking but not by much. As you start to tackle this task, you will never get to an expert level without actually doing it. It’s a bit like dancing. You must get on the floor to improve. Fortunately, there are ways to get better quickly. As a new PM, the existing roadmap will have things you don’t know on it. Ask your colleagues in advance and use Google. You can also practice. If you ask, friendly colleges will also likely sit in a conference room as your audience while you practice live. If public speaking itself is what terrifies you, there are classes and organizations like Toastmasters that can help you.

BECOMING BULLETPROOF

Once in a room in front of customers, it’s your time to shine. If customers come to your office to meet you and the team, you will find yourself in a conference room with your laptop, a dongle to connect to the overhead projector, and a captive audience. In attendance will also be the account manager and the sales engineer. As a PM of a single product, you are probably following another PM or exec on the agenda who also just presented. It is your time to command the room. If you’re lacking in confidence, you may feel that this is a you against them battle. In my view, this is a self-defeating way to think about it. You are a guide leading the customer to safe ground which they are grateful to find. Of course along the way there could be some hard and unexpected questions. Here are some techniques and tricks to succeed and become bulletproof.

Stand up in the front of the room. If you want to command the audience, stand up, face the room from the front with the display screen behind you, and pitch. Look your customers in the eyes. Don’t sit down and hide while you all watch the screen. Standing in front is more engaging for them, keeps you on your feet and alert, and prepares you for bigger rooms and opportunities.
Listen and hear your customer before you launch into your slides. At the start of these sessions following introductions, customers often tell you what they do and what they want to learn. If they don’t you can ask them directly. Listen to them. Most of the time they tell you exactly what concerns them and you can immediately tailor your discussion points making your session land with greater effectiveness.
Know your story arc. Lay out your story in a compelling narrative and keep them engaged. Don’t just read the slides. That will be the death of their attention. Also don’t wing it unless you’re already a pro and have several arcs memorized which you can link into as needed.
Know the details. When presenting the roadmap, know what is on your slide.
Be ’T’-shaped. Customers will ask you anything they want regardless of what you know or what topic you’re presenting. E.g. Is your product compatible with other companies’ products, products that are unrelated to what you work on, and products from competitors. Getting T-shaped means knowing your product deeply and knowing many other related topics broadly but superficially. For questions outside your area of expertise, sometime you only need to know 2-3 sentences about them and move on.
Catch and deflect challenges. Customers have questions. You won’t always know the answer so relax and learn to gracefully handle them. E.g. Ask the SE in the room to see if they know. Ask the customer what they actually need to see what’s behind the question. Sometimes they don’t even need what they are asking about. Call in a colleague if you can. Or, simply say, ‘That’s an interesting question’, and offer to get back to them. If it’s truly important, the account team will add it to their notes and follow up later.
Adjust on the fly. If midway through a presentation you hear about a customer’s real pain point, focus on that and refer to how your product can help them. You don’t really need to hit every point on your slides. You need to let your customer know you hear them and your company and product can help.
Ask them questions. Is there something on the roadmap you’re working on? Ask them for feedback. Don’t just drone on. Make the meeting interactive and keep them engaged. You can also get a validation point for something in flight. If they are really excited about it, ask the account team for a follow-up direct customer meeting. As a PM, always be researching and validating.
Post-meeting, reflect and think about what could have been better. If you were embarrassed about missing a point, look it up and learn it. You will have many opportunities to keep improving.

COME PREPARED BUT UNAFRAID TO SUCK

No one said this was easy, but sharing the roadmap and vision is a privilege. When the company puts you in front of a customer, it’s because they trust you know what to do and can deliver the goods. They want you to do a great job, but good managers know it will take some time to grow that skill. A great way to learn is to shadow your manager and peers. Hear how they do it. Listen to how they absorb and redirect questions. See how they bring it back to the point and recognize customers’ concerns. Shadowing is easily done in person or by a web conference call. No one will bat an eye if they hear another PM is in the back of the room. They will watch the speaker. Take notes, ask questions, repeat. After a few times of this, have your mentor sit in the back of the room while you take the lead. They will cover for you if you get stuck on a challenging question. Don’t fear the possibility of failure. Rest assured it will happen in some small way. Learn from it and keep going.

STEP IN FRONT, STEP AHEAD

Learning something new and stepping out in front of the room can make you a little nervous. It’s uncomfortable to not be the expert you were in a previous role. Doing so, however, will help you learn and grow. And yes, it will suck a little bit before you get good at it. In time, this is also an enabler to grow into more senior roles. When your manager and your executive briefing center team ask you to pitch the roadmap and story to customers, it’s because they need you to do it. Importantly, it’s also because they trust that you can convincingly share the company story, vision and needed details to customers.

This nuanced skill set is a career enabler. I know a lot of people who can do it, but there are a few in my personal experience who are memorable for their command, comfort, and grace who make it look downright conversational. These are a joy to witness. I had the pleasure to watch the elegance and precision of Steve Herrod when he was the CTO of VMware, Sudheesh Nair when he was the head of sales at Nutanix, and Dheeraj Pandey, CEO of Nutanix. As you get better at these, you will find yourself in front of larger customers and larger rooms. With practice you’ll eventually cooly handle rooms with hundreds of people in them.

STARTING FROM ZERO AGAIN

I am much better at speaking today than I was 15 years ago. These days I don’t get palpitations and I feel I’m pretty good at handling an audience. It took time and many opportunities in the front of the room. If you read this and think, ‘It must be nice he has it figured out’, rest assured that any time you learn something new you will reset.

Four years ago I started learning piano as a new, screen-free hobby. I take weekly lessons and fit in practice in my available time. Just last weekend I had my first in-person recital. Despite a lot of practice on the Theme to Swan Lake, I quite embarrassingly made many mistakes in front of a small audience and wanted to sink between the cracks in the floor. It did not feel great. Afterwards, however, with this post in draft on my computer I had to reflect and face the irony of writing about learning new skills. This is just part of the learning process. I will play in front of people again, and it will be better.

ABOUT LUKE

by Luke

WRITING PRODUCT REQUIREMENTS (MRDs, PRDs, User Stories)

As a product manager (PM) your principal job is to get the right product built and delivered to your customers in a manner that meets their needs. The outcome of getting that right means customers buy, adopt, or expand the use of the product you got built. Get it wrong and these things don’t happen. Maybe they don’t buy, don’t grow, or outright reject your product for a competitor. That is not a good outcome for the company.

There is a lot you can say about the many demands on a PM, but one that is critically important is the generation of product requirements documentation for engineering. Requirements docs may be the most important thing you do as a PM. The purpose of requirements is simple, but the way you document them can come in a couple different forms. The PRD is the culmination of your research, customer interviews and discovery, conviction, and direction to engineering on behalf of your customers. The purpose of requirements is to convey to engineering the customer problem to solve. That sounds simple, but there are a set of rules around this. I’m tempted to call it an art, but it’s not an art at all. It’s a craft that when done well, can result in getting what customers need delivered to them effectively.

SOFTWARE DEVELOPMENT METHODOLOGIES

Before launching into what the requirements formats do, let’s first talk about the two big ways to build software. This is not about writing code. It’s about the choice the company makes for the building process. It’s important to PMs because it has a material impact on how you document your requirements.

THE AGILE FAMILY

Just over a decade ago in 2011, Eric Ries wrote a popular book called The Lean Startup which made much more popular a set of concepts also associated with Agile product development. Agile as a concept has gone by many names, each slightly different, including Kanban, Scrum, Scaled Agile, and many more. As a result, in the 2010s many startups and companies pivoted their software development processes to embrace concepts of MVPs (minimum viable products), stand-ups, sprints, and user stories, etc. You’ve probably heard of several of these.

In an over-simplified summary, the Agile/Scrum framework designed for rapid build and rapid release to production (i.e. the live product in customers’ hands). It was a convenient fit for online products like web sites, SaaS products, and phone apps. These are all things that can get updated with or without your personal involvement as a consumer. For example, how often does your Google Maps phone app or Amazon.com update? Do you even notice? This model worked well because these updates don’t need your intervention as a consumer. If the updates have bugs, the app creator can just update it again the same hour or day if needed.

Some products, however, are more complicated and do require your involvement to update. Non-SaaS enterprise products often fall into this category. Operating systems, system software, and firmware, for example, require you the consumer to download and install the software update. The challenge for software companies is this: What if you never do that? What if you do it incorrectly and render it unusable? There is no guarantee that you will ever upgrade the software on something you have to manage yourself. E.g. Have you ever upgraded the software on your microwave? Your car radio or TV? In many cases, you’re not expected to. Enterprise software products are complicated and do require updates to resolve bugs, issues, and critical vulnerabilities (CVEs). In time there will be new features as well which a customer may want to install. Another important motivator is the closing of a support window for a software release. Businesses don’t let enterprise software run without support from the vendor.

WATERFALL

Since enterprise products run your business and other solutions that manage mission-critical applications, the software development process needs to match to ensure uptime and reliability. Here’s why it matters. Let’s say you have a product that manages half the air control towers in your country. Or a software package that monitors post-surgery human vitals in a hospital. Or all the subway system control systems in New York City. The cost of them going offline and breaking is very high. At worst, the cost could be human life. Knowing that it may be a long time before anyone upgrades these systems, as a software vendor you need to ensure to the highest possible degree that your product won’t break. A software development model that fits mission-critical applications is called Waterfall. In short, you sequence the software activities of requirements, analysis, design, coding, testing, and operations. Whatever you build has to be of extremely high quality, and you test the hell out of it over multiple iterations before you release it to ensure it has no severe or high-impact bugs. Following the tsunami of popularity for Agile and MVPs, you might guess that Waterfall isn’t used much anymore. That is not the case. It is very much still around.

SIX SIGMA

Development methodologies, like blue jeans and hairstyles, also have fads and trends that come in waves given enough time. 20 years ago, some software companies were passionately embracing Six Sigma. This was a methodology created for physical manufacturing which employed continuous improvement to endlessly improve quality. In the 2000s, some companies tried to bend Six Sigma to help software development. In 2003 I was at Sun Microsystems who was passionately doing this in their software division. Not to be out-branded, they changed the name to Sun Sigma. Go figure. Overall it was fine, but I did find it pretty heavyweight and definitely not light on process. I think the lean startup trend was a response to that in some ways.

CHOOSING YOUR MODEL

As a PM, you won’t choose the software development model. Your business software needs and your engineering leaders will choose the model. The company should choose the one that is best for customers and the company, in that order. As time has marched on, I don’t see Six Sigma anymore but I’m sure it still exists in hardware manufacturing. Agile and Waterfall are still very common. In many cases, a company chooses one or the other, but even Waterfall has adopted some Agile components like the two week sprint. There’s nothing wrong with that in my view. If you are a Waterfall company, you will still ensure you test the whole thing rigorously before release. This component adoption simply allows for chunk-sized development within the Waterfall framework. By the way, I often ask PM candidates if they know the difference between Agile and Waterfall in interviews. I’m surprised that many don’t know, and can’t even describe Agile in any detail. As PM training courses and degrees increase in popularity, perhaps more will learn these topics.

ANATOMY OF REQUIREMENTS

A requirement is the concise, atomic description of what needs to be accomplished in the product. It states only what needs to be done in order to solve a problem. It does not say more. For example, the coding language to build it is not given. The color of the UI is not given. Why you need it is not given (not here anyway). I say “atomic” because each requirement must stand on its own and ask for only one thing. That prevents confusion and allows engineering to know exactly what to build with exactly which priority. Each atomic requirement must have a priority assigned to it. A requirements document may have many individual, atomic needs defined.

The PRD is the culmination of your research, customer interviews and discovery, conviction, and direction to engineering on behalf of your customers.

REQUIREMENT PRIORITIES

Some needs are more important than others. Smart PMs know the difference and only ask engineering to build what is essential. By assigning priorities per atomic requirement, you are telling engineering what must absolutely ship, what should ship, and what is nice to have. You will build trust with engineering by being honest and ruthless as to what is required, wanted, and nice to have. For what it’s worth, I have included nice-to-have P2 items but I ensure they are described with the right priority. When push comes to shove (figuratively) on time to release, scope, or cost, nice-to-have items get cut, followed by should-ship items.

Most companies I have worked for use the following shorthand:

P0 (priority zero) = Must ship. I.e. This software cannot leave the building until this item is present. I will stand in the way of the door to make sure this happens.
P1 (priority one) = Should ship. I.e. This software should really have this feature, but if we must ship with only the P0s I can live with that. P1s sometimes land in the follow-up release, if ever you get that opportunity. If your customers truly can’t live without a P1, it’s actually a P0.
P2 (priority two) = Nice to have. I.e. If you can include this I would really like it for my customers. Thanks in advance. I understand if you ignore this one. Do you prefer chocolate or vanilla ice cream? I’ll drop it by your desk after lunch.
NOTE: You can define more, but they won’t get built so don’t bother. Your P2s might not get built either.

Caution: A pitfall some early PMs occasionally fall into is building in release schedules into requirements docs. This is a bad idea. How long it takes to build and release something will matter to you, but you are not the project manager. Don’t down-categorize requirements to get something released faster because you’re effectively saying you have a bunch of unimportant requirements that shouldn’t be built. If you mislabel needs that get delayed or not built, you’re doing a disservice to your product and customers. The requirements are the requirements. You may be asked to negotiate phases or scope which you can do, but a P0 requirement is still a P0 if it gets put in a second release. Even if phased, you’re crystal clear on what customers require in your requirements documentation.

THE MRD (Marketing Requirements Doc)

Though the name of this exists, most PMs I have worked with don’t write MRDs as separate documents. For what it’s worth, I have never seen this section written by someone in a marketing team as the name implies. They include this content as the preamble to the product requirements in a single document. To be as concise as possible, the MRD explains the ‘Why’. I.e. Why are you writing up these requirements and presenting them to your business and engineering teams? What is the justification that is relevant to the business outcomes for your product? E.g. How much additional revenue (market) can you win may be your success objective. If the total market is $1B, and the Available market is $100M, perhaps you can claim with data and research that your Obtainable market is $25M over 3 years. See TAM, SAM, SOM as a framework for sizing the market you can actually obtain. Your goal might be revenue, adoption, usage, etc. depending on the key metric you’re driving.

The MRD also describes the customer problem. I like to include sections for background, goals, target use cases, assumptions, and customer user profiles. This sets the stage to describe and defend why the requirements matter to the customer and the business for the reader. Some even include success metrics.

MRDs fit well for net new project initiatives. That could be a whole product or significant new functionality. A minor enhancement to an existing product feature might not need a MRD. In that case, a minor enhancement might just be a JIRA ticket. Minor might include something small enough to be accomplished by one team. E.g. Show more rows in a table before paginating a web page result. That might not need any API work, no new UX, no net new UI development, etc. A dev team might just change the default size of a JSON payload.

If you can’t explain the ‘why’, you will get challenged by engineering and leadership. Failure to understand and convey a meaningful why may result in your feature not getting built. This is an important section.

THE PRD (Product Requirements Doc)

The PRD describes the ‘What’ to build. The PRD is a requirements format closely associated with waterfall development. As it is the start of a full product development cycle, it is intended to be a complete document. It is often a multi page affair including a MRD, a complete set detailed requirements across multiple topics, and related information for an entire product or feature. I.e. Everything you need from a PM perspective to create the product. In theory, you could send this to engineering and get what you want back in a few months. In reality, nothing is ever that simple.

As described, individual product requirements are concise and separately prioritized. You may have many individual requirements to satisfy the product outcome you need. Some PMs stop here, but I strongly advise my teams to include a range of topics relevant to enterprise products which are also important. I like to employ a template to ensure these are captured. These should also use atomic requirements. These sections include:

Platform Requirements. If the functionality of other teams or other product vendors is built on top of your product, you have a platform. Do they have needs to include that you need to add?
Limits and Maximums. Are there minimum or maximum scale considerations? E.g. If you’re making a vehicle, do you need 0, 1, 2, 4, or more seats for people? Is this a race car or a school bus?
Performance. When everything works great this is easy to forget. Does your car need to drive at a maximum speed of 76MPH or 200MPH? How quickly does it need to get to 60MPH? This is easy to think about for a car. How fast do your product API responses need to be? How many concurrent, successful API calls are enough? How much latency is acceptable?
Scalability. Just how much can you use it? My dining room table most often seats two people, but it can scale to eight if needed. Is that enough?
Role-based Access Control. AKA RBAC. Who gets to use this product? When they use it, how much can they see and touch? Some people get everything. Others can just look. The car driver can do nearly everything in a car where the passenger cannot. In both cases they can change the station on the car radio if they are sitting in the front.
Security. This has wide implications. Are you locking your product down preventing customization or changes? Are you ensuring updates? What is needed?
Upgradability. In my world, this is universal. No feature can render a product unable to be upgraded. There can be exceptions however for other products. If you need an exception for an enterprise product, be prepared to defend the reason.
Troubleshooting. This sometimes falls into a topic area of serviceability. Is a user or a support person able to get details on what went wrong? Do they have access to logs? Warnings? Back doors? Troubleshooting shell access?
Guardrails. Are you building in safety measures to prevent customers from creating dangerous conditions? To what extent do you want to go? I.e. Some cars don’t allow you to go over a certain speed limit for your safety. However, no cars prevent you from driving into a lake.
UI/UX. I said earlier that you don’t own the UX but you are still a stakeholder. What do you need? Do you need your product to work well on a computer, a tablet, a phone, and a Tesla car dashboard?
Auditing. I can’t track who uses my microwave. Software with multiple users however do often need to track who is logged in, what they do, when they did it, and what changed. The only thing you truly can’t audit is intent. Did you know that the majority of reported product errors come from user misconfiguration?
Instrumentation/Telemetry. 15-20 years ago companies really debated the customer viability of collecting user details. These days, customers of online solutions know their data at large is collected. Many support systems provide their best service by having access to product inventory and logs. As a PM, what data do you need to include in ‘phone home’ data? This can be the difference between tracking your customer KPIs versus having zero post sale visibility.

With these elements your enterprise product PRD is nearly complete. If sections don’t apply to you, mark them ’N/A’. I prefer to do this versus delete them because it tells the reader that you did consider this topic and didn’t forget it. Lastly, there are some additional topics I recommend my team to include. These are useful because they collect user evidence and trends. Evidence of the customers’ voices and needs are a very useful set of supporting data.

Deals or Customers at risk. Is the lack of a feature causing customers to consider not buying or using your product? Worse, are they considering leaving your product for a competitor? Which customers? How large is that exposure?
Opportunities. How many customer sales opportunities are backlogged on this feature? E.g. Do you have 15 customers each willing to spend over $1M in extra billings based on a need of theirs?
Customer feedback. Sometimes there isn’t money directly on the line but you have heard from influential customers. This provides context you can include.
Support cases. Your support teams use ticketing systems for customer cases. They probably keep track of case counts for unsupported features, or workarounds for missing or weakly supported features. This can be a valuable source of data which connects needs to named customers.
Reference docs. Finally, links to reference docs are useful. After years in large companies that always seem to have at least four competing document systems (Google Docs, Word, Sharepoint, Confluence, Sheets, PowerPoint, wiki, etc.) it can be impossible to find something a year or two later. A link goes a long way. Search doesn’t always work.

USER STORIES

The Lean Startup and Agile wave shaped the documentation of requirements differently than the traditional PRD. In this format, user stories like PRDs also describe the ‘What’ to build. Since Agile uses short sprints for development and release, the way that requirements get written are terse and focused on who wants something, what it is, and why it helps them. Agile dispensed with the idea of a PRD entirely. Requirements, therefore, are written only in the scope of the next sprint, which will get delivered in short order to customers. That process will happen over and over. The idea is that the product is always evolving and you can more deftly respond to needs in short bursts versus waiting several months for the current iteration to ship and for customers to try it. Agile is much more responsive and rapid. An engineering sprint may only have a handful of requirements in them. The format of requirements in this development model is called a User Story. Similar to PRD requirements, these are short and atomic in nature.

The format of a user story follows this convention:

As a <role> I can/want <capability>, so that <receive benefit>

E.g. As a car driver, I want to indicate which lane I’m turning into, so that other cars don’t hit me.

You’ll notice this example doesn’t tell engineering how to solve this. A blinker may be the answer. Maybe a siren or a big red directional arrow in your rear window could have solved it too. There can be multiple solutions. Fast iteration can help you explore this.

I have wondered if some Agile products started with a PRD to get the first iteration out, then converted to Agile. If they didn’t, the first version may have started with a vision statement. I’m not arguing a PRD is required but they can be helpful depending on the overall size and scope of the desired product. Agile can certainly be the only development mode used and well. Each model has trade-offs.

THE AMAZON 6-PAGER

Amazon has their own form of a narrative document used to convey product ideas from PMs to engineering and the rest of the business. This is referred to as the ‘6 Pager’. You the PM have six pages to crisply define the narrative important for you tell the audience the story. What used to be, what is, the direction to be taken, and what the future may look like. Charts and data go in the appendix. How you structure the document is up to you.

If you are accustomed to using a PRD format and slides, you may be surprised at how challenging a six page limit can be. When presented, everyone in the room is silent and reads the entire document before any discussion. Everyone as a result, has the same information to start the discussion from. No exec overrides and derailing tangents after slide 3 of 30. I can’t even give you a number of the number of meetings I’ve attended that never completed the intended slide deck. What I’ve heard is that at Amazon, the audience is very astute and will mark up your printed document and challenge you on individual phrases to precision and clarity.

Amazon has been around a long time and their PMs have migrated over time to many other companies. Often they recommend this format on arrival. I have found that getting everyone is a room to read first silently and fully adopt the process requires executive commitment across the company. This is because this format represents a real change to company culture.

What I don’t see in the various 6-pager summaries I’ve found is what happens on day two. Somehow this narrative needs to get captured in a format engineering can execute against. To be fair, PRDs have this same problem. User stories tend to get written directly into the ticket tool of choice so it has that advantage.

LIBERALLY APPLY FEEDBACK

Perfect is the enemy of the good (even great). Your requirements might never be perfect because you will always learn more when your documented requirements and your product make contact with reality. I say this to save you time. You will spend plenty of time talking to customers, reading, evaluating, and crafting your requirements. Let’s say that, among other things you’ll do as a PM, you took a couple of months to frame out a first PRD for a new initiative. Don’t waste another month or two polishing it next. Get it in front of reviewers and let them comment. They will add lots of comments and this is a great outcome. If you’re new to PM, you may feel attacked. This isn’t the case. The problem is getting attacked so that the result is better overall.

Your reviewers should be your immediate PM peers in the same related area, your manager, engineering leads, architects, support team leads, and passionate sales engineers. SEs are a great resource by the way. They work with customers directly when things go well, and especially when things go badly. They feel customer needs intimately. Reviewers will challenge your assumptions, point out holes, and sometimes outright tell you it’s a bad idea. You should embrace all this because it will help you distill even better requirements and sharper thinking. Update your document as a result.

GREEN FLAG GO

Once your requirements are written, and engineering accepts them, they will get put into the queue for building. The size of your company and the number of products you have may influence how quickly it gets built. As work starts and progresses, you will be very involved working with engineering to ensure clarity of purpose, answer follow-up questions, provide clarifications, and ensure what is built meets the needs of the customers. Good luck!

BONUS 1: THE ERD (ENGINEERING RESPONSE DOCUMENT) aka DESIGN DOC

This document isn’t for you the PM per se, but it does represent the understanding of the lead engineer who is translating your requirements from business language into engineering language with some amount of detail. It may include decisions and trade-offs.

This is a very useful document for PMs to read and ensure you agree with the lead engineer’s understanding of your requirements. If using a collaborative document tool like Google Docs, you should add comments and meet with the lead engineer to ensure you agree on it, or resolve any points of contention including omissions. This is not an opportunity for you to debate their choice of programming language, API design, modularity, etc. You’re not in engineering. I don’t care if you used to be an engineer either. Your job is to ensure the requirements are met and nothing is missing.

BONUS 2: TECHNICAL SPECIFICATION

This one isn’t for you at all; it’s for other engineers who will implement the solution. I wouldn’t bother reading it. It conveys in deep technical detail how the solution will be built on an engineer to engineer level. For the non-engineer, it may not even resemble English. It’s also not important to you. Of course you care that your solution gets built well, is supportable, and meets the requirements. This, however, is not your domain. I include it for completeness. After this comes the actual code, which you will also not read. If your company has a tool like OpenGrok, you could look at the code in a safe, read-only mode, but this is really not a good use of your time. I’m sure you will be busy working with engineering to get your product built, and working on the next set of research and requirements for what comes next.

ABOUT LUKE

by Luke

CONVERTING ATTRITION INTO STRONGER PRODUCT TEAMS

A SEA CHANGE FOR PM TALENT

You may have seen the numerous articles about the great resignation over the past year. At a time when the world is just about to mark two years into the COVID pandemic, in tech we’re seeing much higher than normal attrition in technical knowledge worker roles. That includes product managers (PMs) and engineers among others.

If you’e a PM with three years of experience or less, this period of attrition may counterintuitively be a great time to identify a growth opportunity. If this is you and you’re also someone who is underrepresented in technology, e.g. women, Black/African American, Hispanic/Latinx, this is also a good opportunity. Most technology companies have been focusing on improving diversity numbers. Many managers are searching for PM talent with diversity as a key focus area.

CONCENTRIC, TIGHTENING CIRCLES OF TALENT

A real challenge for finding and replacing tech talent attrition is based on the job to be done and sourcing people that match your requirements. I’m generally not talking about entry level roles. Entry level assumes you trained in a certain area or have a specific skill. E.g. You recently completed an undergraduate accounting or marketing degree. I.e. You may not have worked much yet, but you have a base level of education for the role, and you can perform that level role. Ideally, that company that hires you will train you to improve, or at a bare minimum, give you the opportunity to learn by doing and observing colleagues who are much better at the role than you.

Finding mid-career talent can be quite a bit harder because required skill sets start layering, with each layer resulting in a rapidly declining pool size of candidates. I’ve observed this for years. This is what I mean by concentric circles. Here’s an example: ‘We need to hire PM talent with an understanding of technology, our industry, specific solutions, customers, and business acumen. Years of experience also matter.’ Here’s how a search starts for a mid-career PM role.

DESCENDING SEARCH INTO THE SINGLE DIGITS

Recruiters rely on various professional networking search engines to find candidates. E.g. LinkedIn. Internal ATS tools are also common. Finding people starts with a filtered search. You start with thousands of matches, and within 60 seconds and a couple clicks you are hoping you have any resulting matches to work with. This is the crux of why finding the perfect talent is so hard. Here’s a common set of PM filters I use to demonstrate:

Filter 1: A Computer Science or Engineering degree is required. This is a coarse-grain relevance filter which invokes the sheep skin effect. It gets used because as a tech PM, you need to know some technology. A technical degree attempts to quickly verify this.
Result: This will give you a large pool of technically-educated people.

Weakness: At this point you have tons of people who aren’t PMs and who probably don’t want to be either. You will also filter out some good people in the process who didn’t study STEM. Many companies also add in a short filter list of universities. This will also exclude a lot of smart people who don’t have this exact criteria.
Filter 2: “## years experience in PM required”. This is a two-in-one filter. It verifies that they have they been a PM before, and it verifies that they have a minimum number years of experience.
Result: This is the first major step-down in the candidates list by ~95%. At least now you have a list of technical + PM candidates.

Weakness: This covers PMs with product experiences across every type of product which is still too many. You may also be missing people with non-standard titles. We still don’t know if they’e good for our company, or good at their job.
Filter 3: Keywords for relevant, focused knowledge areas. E.g. ‘Cloud computing’ or ‘hypervisor’. I.e. Do they come pre-trained in a topic area we need?
Result: This is the second major step down by another ~95%. If I want someone who knows virtualization, for example, I’m not looking for someone who is a product expert at A/B testing B2C SaaS personal finance phone app products.

Weakness: A person with strong PM fundamentals should be able to take up any product. PM skills should be fungible, but you’ll have to train someone without your needed product knowledge for your area. More often however, I find that PMs specialize and don’t cross back and forth across vastly different kinds of products.

When it comes to hiring and the great resignation, if you’re a hiring manager you have a great opportunity to move the needle on diversity as you rehire into your teams.

After this, if we add in constraints like location, the pool gets smaller. If we add in requirements like a diverse final list of qualified candidates (which I believe you should), you also have a smaller list. Now you’re ready to contact them and see if they reply with interest. That will also reduce your list. Many great PMs already have great jobs and don’t want to move. If you haven’t reduced the candidate working set to zero yet, you can move to interviews and see if these candidates do indeed have the skills, motivation, intelligence, etc. as they claim and could be a finalist for your role. It is common to restart this search once or twice for a single role. Finding, vetting, and making the final offer is a real challenge that can take months of time investment.

UGLY CANDIDATE TRENDS

In a career spanning a couple decades, I feel that some job seeker platitudes have always been around. E.g. Get multiple offers, negotiate the offer, don’t give the first number, etc. This is all well and good in general assuming you can get multiple offers. Having lived through a few different up/down cycles myself, it’s not always possible. If you have never had the experience of only a single offer, I applaud you and hope that your good fortune keeps up. I remember working post dot com bust, mini-recessions in 2003, the housing bust in 2007/2008. Until two years ago, the last 10 years before that had been more or less up and to the right with everything running without major interruption. The pandemic is the latest cycle impacting careers.

In recent years as a hiring manager, I feel that I’m seeing a new unattractive trend in high tech enterprise hiring. Perhaps the phenomenon also impacts other career segments too. Tech talent in product management, especially in India, is getting cutthroat. I’m seeing professionals young and old optimize uniquely for money and title, while gathering and formally accepting as many offers as they can simply to arbitrage for the best one and ghost unselected employers. ‘Too bad, so sad’ you might say and there is a basis for that. Many job seekers have had the experience of never hearing back after interviews. I personally have been ghosted many times. Also, why wouldn’t you want the highest salary and corresponding title? The ugliness is the accepting of numerous offers. At the point where you verbally accept and sign the offer, the hiring manager and company believe you are joining the company because you told them you are. To no-show or cancel for another offer in my opinion is unethical. This has been on the rise lately. I’m seeing it in India quite a lot, but I may have observation bias since nearly every company in my industry has offices there.

THE INSIDE JOB

If you’re an employee who is debating their options, I suggest asking yourself the following. Why do you want to go? If you’re not being treated well, that’s a good reason. If you are fairly compensated, treated well, and have future prospects to grow, I would suggest staying where you are and continue to develop yourself. If you’re a PM, you already know that PM teams tend to be small since PMs are typically staffed at the rate of 1:15 engineers. Attrition opens opportunities for those who remain. When PMs leave, others get asked to step up to do more. Backfill hiring also occurs but since that takes time, people already in the company have the opportunity to raise their hand first to do something new or enter a new topic area. You may have a stronger opportunity inside your current company versus jumping to a new company with unknown risk. It’s an ROI argument you need to work out for yourself. Just don’t miss the return of where you are as an option.

DIVERSITY IN TECH

Silicon Valley (globally) runs on diversity. I’ve been working for enterprise IT companies for 20+ years. On a daily basis I work with brilliant men and women from many different origins, cultures, and languages. I’m gratified to have broad exposure to people and ideas, and I do believe it does help build better products for customers. What is also true at the same time, is that representation of Black/African American people, Hispanic/Latinx people, and women overall is weak. In some cases, extremely weak. That’s a problem.

When it comes to hiring and the great resignation, if you’re a hiring manager you have a great opportunity to move the needle on diversity as you rehire into your teams. Build diversity into your candidate search pipeline and final candidates sets, and build interviewer teams that include diverse people. Your results will reflect these actions.

There is great PM talent that didn’t go to the top 20 universities. Go find them. It’s not a risk because you’re still going to vet and interview them in the hiring process.

HIRING FOR TEAM STRENGTH

The culture of job applicants may have shifted temporarily or permanently. Perhaps newer careerists are being explicitly taught to do whatever it takes and that accepting all offers is the new norm. I don’t think that’s a great idea since it burns bridges, but regardless I will continue to work on building the best possible teams I can with the best people I can find and hire. Here are my suggestions below. If you have more, please comment or message me. I’d love to incorporate more ideas into my thinking.

Intentionally cultivate and maintain a great company culture. A good culture is an asset. People stay when they like the manager they have, and their coworkers. Work to make sure you can create a high-performance team that also has a great culture which attracts and retains people.
Cultivate team diversity. Diversity can mean several things including gender identity, ethnic origin, career origins, education, and location. A rising attrition trend is an opportunity to build diverse hiring pipelines and diverse teams. Seize the opportunity.
Always be closing (ABC). Talent is a long game. Reach out and introduce yourself to promising people in your network even when you don’t have a role. Don’t misrepresent that you have an open role if you don’t obviously. Get to know people and cultivate professional relationships. They might be your next hire once you have an opening.
Retain your winners. The best way to reduce attrition and hiring is to keep your best people. I find that great people want to work with other great people.
Widen your search filters and remove university filters. Everyone wants to hire from MIT, Stanford, University of California Berkeley, and the other top 10 or 20 schools. I’ve heard it a million times. There is great PM talent that didn’t go to the top 20 universities. Go find them. It’s not a risk because you’re still going to vet and interview them in the hiring process. This is a good way to start removing bias by removing the use of the sheepskin effect for school names.
Consider not using the initial filter on STEM degrees. Or at least, also run a query on people without STEM degrees. STEM degrees are great and often a very relevant background for technical PMs. Take a look for people without them too though. You can still filter down on domain expertise or other criteria like technical certifications. You may be surprised at who you find (and possibly hire).

Attrition is on the rise lately but so is opportunity. Whether it is a temporary trend or not, talented PMs looking for new work options can raise their hands to expand responsibilities or do different and new product work in the gaps that are opening. With diversity programs being increasingly adopted, this is a great time for hiring managers to find motivated overlooked talent as well. If you’re an ambitious PM with a few years under your belt, talk to people where you are to see what opportunities are opening. If you’re a hiring manager, use this time to think about how to build up your stronger team. Unexpected attrition is a tough blow, but you can get the best out of the great resignation by planning for team regrowth early.

ABOUT LUKE

by Luke

12 PRODUCT MANAGEMENT TRAPS TO AVOID

LESSONS LEARNED

In the course of a long career in product management I've seen and experienced many issues that could have been avoided. In this event with the Silicon Valley Product Management Association I shared my 12+ observations and traps for PMs to avoid. I hope this helps you too; especially if you're early in your PM career.

I've been tuning and building products for a long time now and it's a career I really enjoy. In the early years I spent a lot of time just trying to be good and learn the basics. In the middle years I branched out and crossed over into startups that were an entirely new challenge. Over the last several years I've been working on building great products and teams together. In recent years I've enjoyed sharing some of my learnings on this blog.

In early 2021, Debashish Niyogi, Director of Programs, and Tom Gilheany, President, invited me to be a featured speaker at the venerated Silicon Valley Product Management Association. As we discussed options for interesting topics, I suggested a backward-facing review of sticky pitfalls PMs can fall into. These were easy to put together since I've fallen into half of them myself, and observed the others repeatedly in my career.

During the event, we ran two polls among the attendees. Attendance varied from long-time PM veterans to those just trying to get started. 37% of attendees had over 9 years of PM experience! I also asked at the end of the main discussion how many of these issues the attendees had personally run into. 67% reported 3-5, and another 23% reported greater than 6. You can see the detailed poll results at the end of this post.

16 years is a long time, spanning several different kinds of software product companies. I was not a product manager at all in the early years. Following my MBA I got started doing PM by taking a project management role and transitioning over to product management. Since then, I've hit or observed many different types of career traps.
Notably, many of these traps are not specific to product management. Others are more specific. Consider these to help shape your career in the direction you want it to go in.

When I was in school finishing my MBA in 2003, only a little bit of product management was being taught. I remember taking an elective class called Software Product Management that was a fun walk-through of how software is designed conceptually. I recall working on a software product project; defining how to identify, spec and build a product. We did not actually build the product however. This was a formational class for me which really attracted me to actively participating in the software industry.
These traps below are those I felt were never really taught in classes. It's possible that modern management and PM courses do teach more of these examples more often.

I've personally made many of these mistakes myself. You learn by doing; especially when things don't work out for you. Hopefully you can avoid some of these and save yourself some career time and unnecessary strife.
Since there are very few universities offering degrees in product management, most that enter the field self-select and leverage their studies in business, engineering, human computer design/UX, etc. and continue learning on the way. If you can work with a great team of PMs, you can learn even faster. I like to think of PM as a journeyman career. I.e. You start as an apprentice, you level up to journeyman after a few years, and a few years after that you become a master. You will definitely make mistakes along the way.

To debunk old myths, you are not the CEO of your product. However, I strongly believe you should act like the CEO.
Acting like the CEO says you consider the whole picture of the product. E.g. How will sales consume and sell your product? How will finance recognize revenue for it? How will you pitch it to customers? How does it fit the company story? How will an SE demo it?
If you would rather be a CEO, CTO, or salesperson, you could pursue career tracks to those roles too; recognizing that there are not that many C-level roles in total. Product management is a great role. It has elements of all the roles above, but it is still not those positions.

First and foremost, if you work on a product and are empowered to make product development decisions, drive the roadmap, release and iterate on products, you are a product manager.
Some products, however, will help you grow and accelerate your career faster than others. Even at the same company, some products will have more impact and gain more attention from the company and from customers. A simple example is, does your product earn (a lot of) revenue?
At a large enterprise company, for example, there will be a multitude of products in the suite of products and solutions available to customers. Some will be for sale, others available for use, others are internal tools which get tasks done. Those that earn revenue will have a far higher chance of getting investment. That means dollars, headcount, and inquiry and time from executives.
If you work on a product that doesn't earn money, or isn't strategic to the company, your opportunity to grow may be impeded. You could be doing great work, but without revenue or importance you could be stuck treading water. You might need to change products to change that. You can still do good work, but be aware if your growth expectations aren't being met by the product you're working on.

Startups are hard. At the very early stages (seed, series-A) you probably don't even have a product or an MVP yet. This means you and the team are working hard to just figure out if your collective idea can be built and actually sold to paying customers. If you can't sell it, your outlook won't be good as a company.
In those early phases, the actual product manager making all the most important decisions is the founder. That person is the leader and usually the one with the sharpest idea of what the product should be. The first PM hired into a startup is still the second product manager. This can be a tough position if the founder is not ready to hand over the reigns. If they don't you can end up being the founder's errand handler and assistant. Nikhyl Singhal calls this the drunken walk stage of a company. It can be rough.
Company lifecycle can help you identify if the PM job opportunity is real. Is there a product that already sells? Is there already a team? Is there a clear vision for the future?

Did you ever take a public speaking class? Were you terrified to make that first (and second, and third) speech in front of the class? Some PMs view direct customer outreach this way and avoid it.
Speaking with customers is usually not a speech. It's discovery. The truth is, many customers want to speak to you! If they say yes to a meeting, they want to hear from you because they're invested in your product and want it to succeed because it's solving a pain point for them.
Outside of support escalations, and inquiries from sales/SEs, you will have to do your own legwork to find customers. Fortunately, this is usually easier than you might think.
In time you may grow to love it. The voice of the customer is a key source of authority for PMs.
Eventually you will present roadmaps and even speak on a stage at trade shows. This is public speaking. Getting good at these is also a great way to raise your profile and confidence as a PM.

Focus makes a great PM among other things. To that point, some things aren't worth your time.
As a result, some may try to pull you into battles that aren't actually yours to fight. This applies to PMs and many other roles too.
Some decisions, likewise, aren't yours to make in the first place. How a product is built isn't your decision. The attributes and outcome of a product are. E.g. Whether your product is coded in C+ or Java or Go is an engineering decision. If you get asked to make this choice, it may come back to bite you if a future limitation is discovered. "The PM said use C++." can be a dodge for an engineering decision you should not have been involved in anyway.

When you need to get things done, you need to know who to go to. In many cases, executives and leaders have people working for them to get things done they don't do themselves. E.g. Admin, Secretaries, Chiefs of Staff, Subordinates. It will help you to be aware of these people, what they do, and who they work for.
When something requires immediate attention and the person you need doesn't know you, it may take longer to get it done. Forging relationships ahead of time takes a very modest amount of effort. Simply saying, "Hi [name]" when you see them is easy to do. An occasional conversation helps too. If you work remotely, this can be a bit harder. It's simple to make email request kindly and respond with a "Thank You" once done.

It can be a dog eat dog world out there. In business products get reevaluated all the time, and sometimes outright killed. When it's your product, that can be painful.
You can try to avoid this by letting people know the value of your product, making it successful, and internally promoting it. I.e. Don't hide out and hope for the best.
It's also helpful to realize that sometimes it will simply happen. Keep plugged into the company goals, health status, values, etc. and this should not come as a surprise. If it does happen, you can fight for it to live, but that might not change the outcome.
When it comes from the top, you might not have a choice about the outcome, but you can choose how you handle it and get lined up for your next product at the company in a positive fashion.

PMs often enter a product area based on their industry expertise in that area. E.g. If you worked as a sales engineer or customer support for a database company, you might have successfully translated that experience with the technology and direct customers in a product opportunity. That's smart and it opened an opportunity for you. I know many PMs who started this way.
The challenge over time, is substituting your opinion in place of the customers' opinions. More dangerous still, is when you're right a couple times. If you feel validated that you're right, you might stop talking to customers, and then you really lose touch over time. This leads to guesswork and bad data in, which leads to bad product out.
Intuition or prior experience has its place, but in my opinion this comes after you've done discovery, validation, and then are left with a decision to make. If you have two great and validated options, you might make a choice of which to start with.

PMs own product, and by direct proxy, the business related to that product. This is why the "CEO of the product" expression has persisted so long. You won't do everything yourself and outside of an underfunded startup, you probably shouldn't. Many teams contribute including product marketing, SEs, technical marketing, competitive analysis, etc.
New PMs often express that they want to work on strategy. I think this is because business schools teach it a lot. The trouble is that outside of a firm that focuses on strategic work like McKinsey, a new product manager needs to understand the product they own first before they think about strategy. My view is that they need to build up direct product expertise. As you grow you'll learn more about how the industry you're in and how the company itself runs. As you expand your expertise you may be asked to think about strategy. Brand new PMs aren't usually asked to think about strategy in my experience.
That shouldn't stop you per se. You can think about strategy as it pertains to where you are, and perhaps the next level like rings on a tree. I.e. You own a single product? What's next for that product? What about the product family?

Customers do often know what they want, but they don't often think years into the future. Some exceptions apply.
Customers in a competitive product environment usually know your largest competitor's product. They probably used to use it. In fact, they probably still use it since many customers don't like getting locked in on a product solution and keep their options open. When asking customers for product feedback, you will very often hear that they want feature X that your competitor has. This may be because they used and liked it. Or perhaps they didn't use it but they know you don't have it. This is not always the best feedback.
You need to find out what pain actual points your customers have. They aren't the PM and they probably haven't thought about a cutting edge solution to the pain they feel. That's your job. As you speak to lots of customers you can start to aggregate pain points and begin defining a point of view you can validate.

Lots of people in Silicon Valley talk about startups like it's a foregone conclusion that every one of the world's problems will be solved by three people in a garage with an idea and a blind rapture to solve it with a computer.
In my view, startups can be fun, unbounded, and risky. I've done a couple and I can say that they were a learning experience.
If you're trying to get into a PM opportunity, startups are like driving 100mph with no seatbelts. You might get lucky, or you might hit a wall going very fast. Startups can't really offer training to you as a PM. From moment one they are running to succeed (or stay alive). If you already have skills, that's probably why they hired you.
If you need PM training, I believe a large company is much better. They are striving, but already have products that sell, and teams with skills that can help train you. Determine which kind of company works best for you and your ultimate success. The world won't care if you never worked at a startup.

PM is a role with a lot of expectations. It is not a show up and phone it in kind of career. I think it's a great job if you love building, solving problems, and chasing a vision of the future. To do that, you will have to convince people above you, below you, and on different sides that your vision is the best one to follow, and then convince them to help you get to the promised land. When it works it's amazing. It can also be exhausting.
If you love achieving the creation, shipping, and usage/feedback loop of products this is the job for you. Since it's a full-contact career you have to love it to get up every day and go for it.

BUILDING PRODUCTS, BUILDING CAREERS

Being a builder is a great career if you love doing it. Sometimes it's not easy for many reasons, but in my view, that's why succeeding despite the challenges can be so satisfying. Align yourself for personal success to avoid common traps of PMs. E.g. Simply getting attached to the right product can have a huge effect on your career. While working hard on behalf of your customers and your product is a given, not every challenge has to be lived to be appreciated however. Use these recommendations above to avoid common pitfalls and grow your PM career.

PEER PM POLL RESULTS

At the end of the SVPMA presentation we ran a couple informational polls. These results were very interesting to me. We had a nice distribution of young, medium, and older PMs. I initially predicted more future and early PMs; and few seasoned PMs. The self-reporting on number of issues experienced was also illuminating. A select few felt they were doing very well and had hit very few of the traps described. As a virtual event I wasn't able to get a live sense if these corresponded to people in pre or early PM roles.

If you have questions, please reach out on my web site or via LinkedIn.
Thanks!

BONUSES

This presentation event with the SVPMA included a robust Q&A session at the end where attendees asked some great questions. Just before that I also included three bonus pitfalls I felt were less PM-specific but important human traps to avoid. Watch the full recording or skip to the end for these sections.

ABOUT LUKE

by Luke

PRODUCT MANAGEMENT UNDER THE HOOD [PODCAST 2]

This is the second episode in a two-part podcast series with Ashwini Vasanth, an engineer and colleague at Nutanix via the Through the Corporate Glass podcast. You can find episode one here. In the continuation of our conversation, we spoke about transitioning into product management. Ashwini asked me about a presentation topic I gave at Product School in 2019 called "Breaking Into Technical Product Management". She is a great interviewer and I really enjoyed speaking with her. Listen to the episode below.

PRODUCT MANAGEMENT: BREAKING INTO PM (EP. 2)

In the second part of this conversation we discuss getting into a product role. Should you target a large or a small company? What does that mean and why can that drive a different career and learning experience? Listen now to hear our discussion including the following topics.

A framework to think about which first job to take
Internal or external-facing product management? Which one is best for you?
How customer voice builds decision authority and why engineering loves it
How being a remote PM changed during COVID
Adjacent roles to product management which can be pre-PM opportunities

Episode page on Through the Corporate Glass: Breaking Into Product Management

ABOUT LUKE

by Luke

PRODUCT MANAGEMENT UNDER THE HOOD [PODCAST 1]

A few weeks ago I was invited by Ashwini Vasanth, a Staff Engineer at Nutanix, to participate on the Through the Corporate Glass podcast. This podcast focuses on corporate career choices from various angles. I happily agreed and we had a fun conversation about my career in product management. The conversation went long, so she divided it into two episodes. You can listen directly here, but I recommend subscribing to the podcast in your listening app of choice to hear more episodes. Click below to listen now. I hope you enjoy them.

PRODUCT MANAGEMENT: UNDER THE HOOD (EP. 1)

What drives and motivates product managers? What skills do you need? What's involved? Ashwini and I discuss these questions and more in episode one. Listen now to hear our discussion including the following topics.

What is it that customers are actually looking for? What addresses a real pain point for them?
How does a PM connect what they've heard back into their company to get the right impact and outcome?
What's the difference between defining what to build vs how to build it?
What's the right time to use intuition or gut feel? When do you use direct customer discovery?
How much expertise do you need to have in order to be a PM? What else can you do to fit the role?
Are you the CEO, or are you like the CEO?
How did I get into product management? How can wedding web sites lead you to a job in PM?
What would I advise you to do in order to start in product management?

Episode page on Through the Corporate Glass: Product Management: Under the Hood

Continue to episode two where we talk about breaking into product roles and additional product topics.

ABOUT LUKE

by Luke

SHARPENING THE KNIFE; THE PRODUCT OF YOU

I really enjoy cooking both because I enjoy a great meal and because I enjoy learning how things are made. Many a good meal has resulted in me sometime later discovering and deconstructing how to recreate it. Across the years as a result I’ve also come to appreciate the value of a great chef’s knife and keeping it sharp. I routinely use a sharpening steel on knives before I start preparing meals. It only takes a few seconds and the results are noticeable.

People are a bit like knives too. Career skills need sharpening on a semi-regular basis. I most certainly did not know everything I needed to get to where I am today after I finished my undergraduate degree. At that point of time I thought I’d have a marketing career. I moved to New York City, tried a few things, and after a few years began a MBA to add skills and sharpen a bit more. In between I added some extracurricular classes on basic web page coding. These opened a low-paid door to a technical support job at Yahoo! In 2000. Mid-MBA I got another chance to walk in through a door which eventually lead to product management, and so on.

Over the years I’ve taken PMP project management certification courses, Javascript courses, LinkedIn Learning and company-offered courses. I’ve watched hundreds of YouTube videos for learning things from how to make a Genovese pasta sauce (delicious by the way) to Kubernetes. The industry and career articles I’ve read or skimmed probably number over a couple thousand.

This month I completed a week-long executive leadership education course at Harvard Business School designed for people who had reached director-level roles or above and had been working for 20 or more years. It's been 18 years since I finished my MBA at SCU. I felt this was a great opportunity to resharpen my thoughts on leadership, management, and organizations at a leading school. I was quite impressed with the faculty, the students, and the level of preparation that was present. Originally intended as an in-person training week, this was transitioned to online format given the COVID pandemic. Though I was looking forward to an in-person format, the faculty operated Zoom, multiple input formats, chalkboards, breakout rooms, video playback, and polls with ease and polish. After an intense year of online-only work, I was highly impressed at the level of command they had with the tools. It was seamless. As an aside, I’d love to see people in the corporate world use Zoom as fluidly.

One big reason I wanted to take this course was because a lot has evolved in 18 years. I’ve grown across several different companies, 1-2 new generations are now in the work force, and globalization has continued its rapid expand-contract pace. While in MBA school I was not yet building formal teams, not directly managing people, not charting product and business line futures. Those all came with time and growth, which made this program a great way to reassess if there are ways to be a better leader with up-to-date training and experience.

The Product of You

I believe that self-investment is very important for anyone. For PMs in a fast-moving industry, keeping up-to-date can be a challenge. In the high-tech industry so many people are racing to build all kinds of things. Some will win; some will fail; many will just evolve slowly for years doing neither. As a PM you’ll always be the go-to person to answer questions related to your product and things that impact your product. That means the Internet, Wikipedia, product web sites, books and more will be your go-to resources. You’ll always be supplementing what you need to know.

In medical career fields, many types of practitioners are actually required to keep learning in order to remain certified or board-approved. Therefore every few years they have to prove they’ve attended continuing education units (CEUs). This makes perfect sense. After all, would you want to go to a doctor that didn’t learn anything new since the day they graduated 30 years ago? I for one would not.

Over the years I’ve evolved the books, feeds, podcasts, and materials I keep up with. Some sources became less interesting over time, or I’ve added new ones as needed. Ask and listen for recommendations. It’s a great way to discover content.

One ‘hidden’ resource I love is RSS feeds. These are still super useful despite the announcements of its death 10 years ago. Many news and blog web sites still support these even if they don’t advertise it. Feedly is a good, free to use RSS aggregator you can use.

Newsletters are also very good and have been having a resurgence in the past couple years. I subscribe to several venture capital newsletter and industry news feeds. In my view you only need a handful. They tend to repeat one another from similar sources of news and funding announcements.

Build Your Career Team

In addition to finding good mentors, I recommend finding people to help you. Some of them may help you because they like you. In other cases, pay for expertise. These include recruiting experts, consultants, and even the occasional resume writer. You may have to get creative when looking for them, but I feel this isn’t as challenging as it used to be. LinkedIn and task-oriented services sites can help you find them. Perhaps the best manager or recruiter you knew at your last company would help you or offers consulting. I am not a recruiter and I don’t have that expertise, though I’ve learned a lot as a hiring manager. Liz Bronson Consulting is my go-to expert when I want personal career and recruiting guidance, and she’s worth the investment. She and Kat Troyer also have a great podcast called Real Job Talk I enjoy.

I’ve also subscribed for over 10 years to Ramit Sethi’s newsletter. HIs blog marries psychology with personal finance and entrepreneurship. He has a great set of perspectives on identifying the possible in you.

One idea I really like but can’t take any credit for is the unofficial mentor. It’s hard to find an official mentor where you both want, agree, and accept the mentor:mentee relationship. In a book I read about Andy Grove in recent years, I believe it was Ben Horowitz who wrote that Andy was his mentor even though they never met (at that time). He admired Andy from afar and used what he modeled to influence his career. I think that’s a great model. I’ll add that terrible managers can also be helpful by taking note of what you didn’t like. This can help you model the person or professional you don’t want to be and guide your behavior. I’ve had a couple of these myself. Even better, you can have an unlimited number of unofficial mentors.

Caveat: Though I’ve bought services from people referenced above, any career investment decisions you make are purely your own. Choose wisely.

Take-aways:

In the spirit of leaving you with some actionable tips, here are a few recommendations for sharpening your own PM skills.

Invest in your own career, even if your company is unable to subsidize it. This may include a meaningful financial investment depending on the type and depth of training you seek. Depending on your employer, they may or may not help you with this. In my case, I invested in this opportunity I described above myself. For what it’s worth, this applies to secondary education too. E.g. A master’s degree or MBA. Many MOOCs and online content are free or very cost effective.
Don't be afraid to ask for help. During the application for HBS, I reached out directly to my CEO to request his sponsorship. I had spoken to him on a few, but not numerous, occasions while working at Nutanix. He quickly replied that he'd be happy to support me which I greatly appreciated.
Determine which skills you need to hone and go work on those. Prior to the course I took above, I took a career skills self-assessment exam that included participation from 12 of my current reports and peers. On the area of team coaching and mentorship skills I scored well, but I also saw that they scored me lower than my self-assessment. I thought I was doing a better job than they did. This therefore, is a skill for me to invest more time on in order to be more effective and helpful to my team.
Keep reading. I really enjoyed the case study approach that HBS uses. SCU during my MBA also used case studies. Honestly anything you read can be a case study. The success and failure stories in business and beyond can get you thinking. How might they apply to you? What would you have done? What do you do when both options have downsides?
Help someone else as they try getting in or growing in a PM career. In the medical training industry, doctors are taught in a ’See one, Do one, Teach one’ methodology for simple procedures. I’m not a doctor so I can only relate what I’ve heard. I doubt open heart surgery is as quick as this. The point, however, is that you don’t need to study for a year first. Try things out. If you’re in PM, help others by letting them watch you ‘do one’. You can also help simply answer questions and point them to resources like this one.

THIS IS STILL A KNIFE

For what it’s worth, blunt knives do still cut. They’re just less safe in the context of cooking. As far as careers go, if you’re getting started in PM or any career and you could use some sharpening, get started anyway. You can still do great work. With time you’ll get better. With sharpening you’ll get (deadly) good. In my opinion the product career is a journeyman career. You start as an apprentice. That name isn’t used for PMs but the beginner ‘Product Manager’ or occasionally ‘Associate or Junior Product Manager’ title is used. Take that opportunity and run with it. Learn from others around you by being curious and open to learning and training. You can go far.

ABOUT LUKE

by Luke

A DECADE+ OF PRODUCT MANAGER INSIGHTS DISTILLED

Learning Product Excellence From Others

Over the years I’ve read a lot of articles and books about product management and business. These are great resources for honing your craft and for thinking more widely about your career and impact. In my personal email I have a folder called “PM Resources” where I send myself articles and tidbits to keep and refer back to. The oldest saved message in that folder goes back to February 15th, 2008.

I believe you can learn a lot from others so reading is a daily habit for me. Below is a selection of articles spanning the last 10 years as a product manager, plus a mandatory reference to one of the best PM call to action articles of all time from Ben Horowitz and David Weiden. For each I’ve added a short summary and take-aways as I see them.

I hope these help you as much as they’ve helped me form and sharpen my views on product management. If you have a high-value source not included below, please share it in the comments or get in touch.

2020

How To Become a Peak Product Manager

by Ravi Mehta, 2020

At a glance: A fantastic all-around PM skills article for a person entering this profession, and for those who want a refresh.

This is a deep dive article into the many facets of being a PM including skills spanning execution and management. This is a comprehensive view of the full job of a PM I recommend for anyone looking at entering product management, or currently in PM.

Notable take-aways:

PMs do whatever it takes to deliver valuable outcomes to users. You don’t just ship features.
Ravi provides a nice framework for PMs that include Product Execution, Customer Insight, Product Strategy, and Influencing People as a way to understand what makes successful PMs. Note that he doesn’t claim even the best PMs have each and every segment in their toolkit.
Peak PMs execute flawlessly
PMs flock to responsibility and hold themselves accountable

You Are What You Do - Why Product Managers End Up Project Managers

by Matt Grierson, 2020

At a glance: Read to understand that what makes others happy isn't always the job to be done.

When you excel at high-level thinking, organization, motivation, and getting things done, there is an unnatural pull by many organizations to have you focus on that which feels a lot like a program manager. People will love you for it since many are terrible or uninterested in that skill set. The problem with that is, that’s not your job, and you’ll ultimately fail as a product manager if you fall into this trap.

Notable take-aways:

Don’t waste much time on tasks that don’t actually move the product forward. E.g. In a big company, you can spend literally all day answering questions in email and Slack, or organizing other peoples' time; none of which help move your product.
Without you sharing your product vision, every other team will create their own vision.
Don’t mistake effort for progress. If you spend all your time grooming a JIRA backlog, you might be organizing deck chairs on the Titanic.
Obsess over the problem, not the solution. Every problem could have many solutions. E.g. “I’m hungry” has many possible ways to solve it.

2019

Quote: “Hope is not a plan”

by Jennifer Rowland, 2019

At a glance: It takes a lot more than imagining a bright future world.

Jennifer is a master at getting things done. We work on a team together and this is one of my favorite sayings of hers.

Notable take-aways:

Since this is not an article, I’ll add that ideas and good intentions are great, but at some point you need the focus, a plan, and grit to get to the goal.
To paraphrase Josh Elman, you do need to ship the right product to users. PMs motivate ideas into action. A plan is just one important tool to get there successfully.

2018

Five Dangerous Myths about Product Management

by Noah Weiss, 2018

At a glance: Until very recently, and still quite limited, product management was not a degree you can study for. It’s still an apprenticeship career.

Notable take-aways:

No, you’re not the CEO. It’s useful in my opinion, however, to act like the CEO. That means thinking of your product like a company and doing everything possible for it to succeed.
You facilitate and set the pace to the team. At times you get to make decisions and calls, but the job isn’t about about being the chief decision-maker.
You don’t need a technical degree to be a PM. That said, it can help if your product is highly technical. Apply deep curiosity instead and work with your teams to get to the right outcomes.

2017

8 Ways to Accelerate Your Product Manager Growth

by Joanna Beltowska, 2017

At a glance: There is much more in this article, but the part that resonates with me is, you must keep learning.

Notable take-aways:

PM is a deep discipline that requires unending learning.
Keep working out by reading books, and articles, and listening to podcasts.

Product Manager for the Digital World

by Chandra Gnanasambandam, Martin Harrysson, Shivam Srivastava, and Yun Wu, 2017

At a glance: Want to be a CEO one day? These authors posit that being a PM is the new pipeline role for future company leaders.

Notable take-aways:

PMs operate on two speeds at all times. What’s happening now this week, and what is the next 6 mo - 1 year - 2 year roadmap.
The authors present a very interesting set of three PM archetypes which feel very relevant to me in the past 10 years. The Technologist, the Generalist, and The Business-oriented PM. I believe the successful senior PM leader is a combination of two or more of these archetypes.

What kind of person would be a better fit for Product Manager as opposed to software engineer?

by Moisey Uretsky, via Quora 2017

At a glance: Wondering if you might be a fit for product management?

Notable take-aways:

A product manager’s role is about critical thinking.
Take all the information available, make a conjecture, hypothesis, or estimation, then see if if turns out to be true.
The role is about fixing ambiguous problems

2016

Don’t Ship the Org Chart

by Ken Norton, 2016

At a glance: Don't force your users to understand how your company is organized in order to get a viable, working product.

“Don’t Ship the Org” chart is one of my favorite expressions. Your customers don’t care where your area of ownership ends and another begins. When my car fails me I fume at the car maker. I don’t know and don’t care who made each component. The car is a single, whole product to me.

Ken is best known for his phrase, ‘bringing the donuts’, because it’s a great summary for how PMs show up for their teams. Here he digs into PM organization and how it impacts companies. This is a short read but I like it because customers should not care or even know what your org chart is. The product is the product.

Notable take-aways:

Don’t carve up product ownership according to engineering teams that build components. It leads to solutions that stop at the boundary of the team that builds it. Think instead of ownership according to customer experience.
Consider organizing PMs by discrete product mission. This might lead to org changes as each mission is completed, but orgs are never static anyway.

2015

Doers not talkers — What to look for in great PMs

by Deepika Yerragunta, 2015

At a glance: Great salient points on being hands-on and understanding your customer. Short but effective, this post was one of the first to simply say, you must be able to do the actual job, not just talk about it.

Notable take-aways:

PMs must have user empathy in order to do the job.
Can you get the job done personally by rolling up your sleeves to do the work? PMs need to be able to do the on-the-ground work.
Keep reading and keep learning in order to widen your knowledge base.

2013

A Product Manager’s Job

by Josh Elman, 2013

At a glance: A great initial read for beginner PMs. Overall, be helpful to your entire team, but you also need to ship the product. The product may not satisfy every customer, but you also don’t have unlimited time to work on it to polished gold perfection. This is a good summary of the PM’s overall job.

Notable take-aways:

PMs help their team ship the right product to users
You must ship the actual product to your users. Everything before this is just planning. You must understand when it’s good enough, and when to ship.
Listen to feedback all the time, from any source
Josh also formatted this nicely here.

2011

What, Exactly, Is a Product Manager

by Martin Eriksson, 2011

At a glance: Great initial read for beginners. Martin must be proud that his Venn diagram (of UX, Tech, and Business) has been used hundreds of times over in other articles. His point is, PMs cover multiple, concurrent areas of expertise. You need to be conversant in each in order to know what to build, how to do it, and how the customer will experience it. This is a good, basic framework for thinking about PM.

Notable take-aways:

A PM needs to know a relevant amount of multiple disciplines

Working Backwards

by Werner Vogels, 2006

At a glance: Essentially this article says, ‘Start with the end in mind’ from a customer perspective, which is also reminiscent of the 7 Habits of Highly Effective People. By imagining in great detail what the end customer will get and experience, you start with the definition of success well planned out before anything else starts.

Notable take-aways:

Start with the end in mind. This means envision the future, from the perspective of your customer. What does the press release say? The FAQ? The User Manual?
Define the customer experience before you get started in order to reach that future. Many times have I seen projects with unclear future end states start to lean in a direction while inevitable trade-offs and compromises are made. Use the vision of a crystal clear future state to stay on course in the face of prevailing winds.

1997

Good Product Manager, Bad Product Manager

by Ben Horowitz and David Weiden, 1997

At a glance: This is the original PM bible. Read and then re-read once yearly.

Critical reading for PMs of any years of experience to understand. This is a classic because it was one of the first brutally honest assessments of what a PM should do and how they should think. If you look online, you’ll find two versions of this document. One is a summary and one is the no-holds-barred deep dive into how to succeed and fail in the role. I prefer the deep dive even though some references are naturally dated.

The original text can be found on the Khosla Ventures web site at Good Product Manager, Bad Product Manager. A newer, summarized version from 2012 can be found on the Andreessen Horowitz web site. The summarized version is good, but I prefer the original because it pulls no punches. It goes deep on what successful PMs do and how bad PMs fail. It’s a must-read for anyone thinking about product management, or in the role for less than five years. I re-read it about once a year.

Notable take-aways:

You get rewarded for your results, not your intentions, so you act like the CEO of the product which means you have vision and drive outcomes. That doesn’t mean you’re the actual CEO, but you must embrace that your job is that important.
You will face challenges and figure it out anyway. Bad PMs make excuses.
You know the business. I.e. You consider company goals, customer demand, do research, act with certainty, know the competition. And you know what you don’t know. There is more that can be added to this list.
You put your requirements clearly in writing and constantly gather data.
Know what’s important and spend your time on that. Don’t waste time.

ABOUT LUKE

by Luke

CRAFTING STRONG PRODUCT MANAGEMENT TEAMS

YOUR NEW PRODUCT

The transition from an individual PM to a group PM will expose you to new dynamics, and new responsibilities which have less to do with products themselves. If you’ve just made this transition, you’ve just taken the first step away from singular focus on a product you own. Now you have people. As a result, one of your new key objectives is to maintain an effective, productive, and satisfied team. You’re still a builder, but now the team is one of your principal product outputs. This post describes how to think about strengthening and growing your team for long-term success.

MADE FROM PEOPLE

Effective product teams are made up of people. As a product group manager you have responsibility for that team and the people in it. Principally you must build, feed, and grow the following:

Your team
Your product
Your business outcomes

As an individual contributor (IC) product manager, you’re organized on a team of peers with other PMs. Teams are assortments of skills, personalities, strengths, weaknesses, and focus. Each person is different, comes from a different location, work experience, and different areas of expertise.

Your perspective as a team member starts as an individual contributor. Over time, perhaps over several jobs, you form your own impressions of what you think works and doesn’t work managerially based on your personal experiences. As you mature in your PM career, you may grow into a group PM role which manages other PMs. This tends to occur upon mastery of your core skills and product area, when you show the desire and ability to lead others. It’s not for everyone.

Many years back I recall working for a large public company and had a direct manager that refused to acknowledge my presence. He exhibited this behavior to anyone assigned to his team that he didn’t personally hire. This was pretty uncomfortable and I never forgot it. The negative example helped form my opinion to not behave this way as a manager.

Managing a PM team is a new frontier because you now also own the wellbeing, protection, and prosperity of a team of PMs reporting to you. That comes with the familiar product work of building the best product for customers, and more importantly answering the more open-ended question of where is the right product direction to go for the company and your team?

With challenging goals and a big charter, your team is one of the essential elements required to achieve it successfully. Even if you were a stellar IC PM in the past, you won’t be able to perform a teams’ level of output alone. You must build your team to get there. Building can be applied in multiple ways. Even if you can’t add headcount, you must still build your team with respect to skills and enablement. If you are expanding team deliverables and responsibility, additional team members may be required.

CONSTRUCTING YOUR PRODUCT TEAM

Building teams has several challenges. First, it’s rare that you get the opportunity to build a team net new. This is important, because the team you get by your promotion, or being hired, is not always the perfect, machine-precision team you may have envisioned. E.g. Perhaps you were hired to manage an existing team, or you were promoted from within a company to take on team management. That might even be a team you were once a team member of. Either way the team was already in-place when you started as their manager. You get it as it is; the good and bad. You can’t simply expect to blaze a new path and get 10 open reqs (requisitions).

Some exceptions may apply. To build a team from scratch, you’re more likely to be an entrepreneur building your founding team. In that case the founding team is hand-selected by you. Alternatively, you might be an intrapreneur building a new product idea from within a larger company. In this case you may be given the opportunity to choose your team from coworkers. Size constraints may still apply.

STRENGTHENING YOUR TEAM

Now that you have a team, privately evaluate how strong they are individually. Chances are good that each person has areas of strength and opportunity to get stronger in other areas. Don’t forget that you as the manager also have strengths and weaknesses. Use this evaluation as a tool to produce an even better team from the people you already have.

Before your first role in management, you may have a (mis)perception that a team resembles a group of equally-sized, equally-capable, uniform team members. That can lead to poorly-formed expectations from individuals who are all different. It can also lead to poor managerial thinking if they believe that all resources are fungible. In my experience, people don’t like being called fungible. I had a manager that liked to say this a lot about a decade ago and it felt gross.

The uniform resources mentality in my mind can be visualized like a brick wall. I.e. Your team members are homogenous, equally-sized bricks, which uniformly support each other. It sounds attractive, but this analogy doesn’t represent reality.

In my experience, extending the wall analogy, teams are more like a wall with different kinds of brick and stone set in a less organized order, but still creating a solid team unit. Unlike a brick wall, this wall has gaps and rough edges. It might even have open holes that let the light through. Team members come with different sized skills and contribution. Most people have weak spots in some area or another. This is common and not altogether bad; though it could be stronger if you start to fill the holes in.

Unlike when I started in PM 16+ years ago, on-demand training has become remarkably easy to find and attend. These can be in-person or streamed. On my team today, I look for and recommend courses for different team members. Depending on your company benefits, you may already have personal cost-free access to LinkedIn Learning, Udemy, or other learning provider.

To complete the wall analogy, you can strive to achieve the type of wall found in Machu Pichu from the Incan civilization. These are composed of very sturdy, perfectly-fit stones which fit seamlessly together; no holes or gaps present. Each stone is unique and differently sized. This analogy represents an ideal. Since your team members are different, by augmenting their weak spots, you can fill in the gaps in the wall; making the whole stronger. In reality you may never close all the gaps. However, by working on it, you get a stronger wall every year as your team members grow to edge out the gaps.

SHAPE BY DESIGN

Growing a team should first be preceded by some deep thought as to what you want to end up with. PMs should be very familiar with goal-setting. Team design is no different. With limited time in a day or a year, what will you ask your team to spend growth time on in addition to the daily blocking and tackling? Where do you want to be when the year is over? This will be different for every team.

Sometimes the right team design includes pruning out team members. After having tried to grow, fit, advise, mentor, reset, and more, you may find that a team member just isn’t succeeding. You may decide reduction is the right step. Firstly, look in the mirror. Did you hire well? Did you set your employee up for success? Did you enable them? What could you have done to prevent getting to this place? After ensuring you mutually can’t do more, you may have to consider removing someone from the team. This is a failure outcome for the manager and the employee. It can be painful, but it’s better for your team’s health.

PLANNING FOR GROWTH

If you’re a senior executive, something you’re likely to frequently hear in business reviews is, “We need more people.” For many teams, your ability to execute and grow is correlated to headcount. Every company is a little different, however for established companies the following axioms remain true:

People cost money
Companies run on budgets
Budgets take planning

Getting more people therefore, means planning ahead in the company’s budget cycle. Of course, you will have had to do your homework justifying the needs and benefits additional people will provide. These budget cycles are usually yearly.

Demands for people aren’t always conveniently aligned to yearly budgeting however. New projects and new market demands appear all the time. Let’s say you were budgeted for three hires this year and you just got a new unforeseen project that requires a fourth person. That headcount comes out of that budget of three regardless if you had other plans. Have no budget? Well you can wait until next year, or you can start using your powers of organizational persuasion to ask for someone else’s budgeted req. This can work, but you may have to negotiate to make that happen.

Another alternative is attrition. If someone leaves, you can usually backfill them. This gives you an option. If you choose to use that person elsewhere, you still have one fewer person in the team they left. Tough decisions.

In any of these scenarios, I advise getting to know well in advance who owns the budgets and who the gatekeepers are. Make friends with them. This isn’t a disingenuous activity. Get to know the people in your org, and the surrounding orgs. This will help you. This includes the executive support staff. They often do the processing work on behalf of execs.

A habit I’ve cultivated is asking selected peers and more senior executives for 1:1s. They don’t even have to be in your organization chain. They can be as often as you agree upon. It’s easy to do and over time you form a relationship. This only has upside. At worst, one will simply ignore your request or not have time to meet.

A final option for staffing is contractors and outsourcing. These both still require funding, but this can sometimes come from a different variable cost budget vs. a hiring budget. This still comes out of a budget however so be prepared to justify the spend and value you expect to gain just like a full-time employee (FTE) hire.

INTERLOCKING PIECES

Teams are made of people, and people are all different. You can’t simply swap one for another. Hire and aggregate the strengths you need, then invest even further in your team with time, training, cross-training, and mentoring to make them stronger. Your team and your results will continually improve.

Lack of investment to growth leads to stagnation and eventually attrition. Ambitious people aren’t happy to sit still for long. They want challenge and they want to see the fruit of their labor. Undesired attrition is hard to overcome because it’s irreversible and it’s not the lowest performers who quit. You can replace people, but you can’t transactionally backfill multiple years of specific domain knowledge about product, processes, people and more. Fortunately this can be discouraged by focusing on your team. If someone great does leave for a better role you made them ready for, then this is a bittersweet success.

If you’re a new product team leader your new job is management. You will still work closely with product, but first you have a team to take care of. They need you in this capacity and you need them as team members. Make the team stronger by thinking about the team along with the individual members. Draft the future state you need and work to get there daily.

ABOUT LUKE

by Luke