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

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

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

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

Start with company priorities

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

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

Build a framework to evaluate requests

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

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

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

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

Communicate and show your work

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

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

Whatever you do, keep it transparent

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

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

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

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

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

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

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

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

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

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

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

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

Follow omareduardo.com for other posts like these.

Wishlist: Product Manager bootcamp manual chapters

A product manager does just about anything under the sun to make her product successful. This makes it difficult for new product managers to know what to focus on first. I often wished there was a bootcamp manual on how to be a great PM. In particular, I’d love to read chapters on the following:

  • Prioritizing what to learn among the many responsibility areas.
  • Making a decision with insufficient data (and tips on sleeping soundly after that.)
  • Communicating to others that you’ve considered their feedback, despite many of those requests not making it to the product roadmap.
  • Balancing responsiveness to customer demands and other product differentiation.
  • Enabling true engineering creativity and innovation despite market and customer time pressures.

Developing skills to be a great Product Manager

Finding a consistent definition for what a Product Manager (PM) role entails is no easy feat, as I have quickly figured out while starting to dip my toes into the product management world.  This is true even when try to narrow my scope to thinking about product management within tech companies in the San Francisco Bay Area. There seems to be as many definitions for ‘product management’ as there are roles out there, and a great deal of opinions around what makes someone a good product manager.  At first I found the many ways in which people thought about product management a bit puzzling and disconcerting, how am I supposed to find out what actually works well?  But after some thought, I realized that there is a common thread around most people’s perspective of what a PM is, and the variety of opinions about what the role actually is gives me the flexibility to explore where I would fit best based on how I would like to define my career.

One way in which the PM role has been described to me, which seemed to capture the essence of how PMs approach their work at BloomReach, is to see themselves as the mini-CEO of their particular product or features.  Putting it this way, it becomes clear that at the end of the day although as a PM you are not actually doing the product’s development, you are ultimately responsible for making the product successful.  This may mean that you should be well-versed in many different areas across the product development cycle in order to do your role well.  However, depending on the company size, product phase, and team size your responsibilities and areas of focus may be very different.  Here are a few things that have come up over and over as good skills to have.

Getting technical and knowing how to code

There seems to be a lot of discussion around the need to know how to code to be a successful PM, particularly given the success of non-technical/non-programmers as PMs in various companies.  That being said, something that Amazon GM Ian McAllister very succinctly pointed out is that not being technical is never an advantage for a PM.  That is, you may do well in the role, but knowing more about the technical side of how products are built is always advantageous.  I talked to various PMs so far and this sounds true to many.  They encourage non-programmers by pointing out that the engineering team will do the coding and thus you don’t necessarily have to be a great programmer, which would take many years of hard work, but I have always seen their heads nodding while discussing the benefits of knowing how to code when being a PM, even if knowing the basics and building from there.  Given this, I am embarking on a journey to learn how to code using a few highly recommended resources: Code Academy’s Python Course, General Assembly’s Dash course, and using the JavaScript & jQuery: The Missing Manual book.

A few other things I have been told to learn from a technical standpoint include scripting for data analysis (to get insights), learning how to scale products, what levers can be used to make products faster, determining the right database structure/schema, among others.

Learning about User Interface (UI) and User Experience (UX) design

Steve Jobs is well-known for his brilliance in having focused as much on product design as he did on functionality.  He pushed the boundaries of how a product should be thought about to include an end-to-end view that would not only be technically impressive, but also ‘really cool.’  This allowed the products to enchant users through its ease of use.  It meant that graphics and design were smartly and intently applied to create a pleasant experience and remove any layers of frustration with the product.  Great UI and UX can very strongly influence the user’s reaction to the product, regardless of its complexity or how impressive is features actually are.

I would like to continue developing my eye to catch what is it that makes a product fun and exciting to use, and look for ways in which to bring this into the development of the products that I may have the privilege to work on.  For now, I am simply going through and reviewing the products that I love, and determine to what extent it may be a function of smart design instead of just technically impressive features.  Are there any great resources I should look into for this?  Let me know.

Understanding user needs

Ruthless prioritization seems to be one of the most critical aspects of successful product development execution.  Where PMs are most impactful is in determining which of the many great product ideas they should implement first, which ones to defer, and which ones not to implement at all.  There are many complexities introduced by each ‘minor’ feature developed given the need to make it work well holistically with the rest of the product.  As such, a great product manager needs to determine which features will make the most impact towards achieving the product’s vision and value proposition, and resist the urge to try to implement the rest of the features that may delay these from getting out to the users.

Going back to Steve Jobs as a great example, I have included below the transcript of one of his conversations explaining the big difference between having great ideas vs. actually executing on the right things.  That is where the rubber meets the road, as people say.

Steve Jobs on the importance of great executino

Focusing on Product Management – how I am planning to develop my product management skills

I have always found intrigue in the idea of writing posts for this blog, but the reality is that my focus has jumped around from topic to topic, making the site frustrating to follow.  The main reason this has been the case is a lack of a topic of which I would like to extensively write about and continue to learn and share things.

I decided to bring some focus to the blog around the topic of Product Management.  I think it is a intriguing and interesting topic and I recently started more strongly focusing my career on Product Management, at least for the next few years, and there is a ton for me to learn as someone who does not have a computer science background.  I am sure it will be an intriguing ride and I will use this blog to write about my learnings as well as to engage other interested folks in conversation.

To start, I am doing a few things to learn more about product management (in addition of learning from the Product Management team at BloomReach.)

I am looking to learn about topics that I am not familiar with given my lack of a Computer Science background.  I know that by not having studied Computer Science in college I am at a big disadvantage in knowing about the technologies powering current products and what is possible, but I am confident that doing my due diligence, continuously learning and immersing myself into relevant topics I can work my way through.  
If you have any recommendations, I am all ears.  I know there are many talented Product Managers out there and I would love to make the most from your learnings.