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! 

Don’t run away from discomfort at work. Clarify, remove obstacles and find purpose.

There will be times in your career in which your work won’t push you into that magical state of flow. The work that you are doing will not hit that balance of challenging without stressing you. You may be working on a project that doesn’t challenge you enough. You may be comfortably project managing a simple initiative. You may be executing on a plan instead of brainstorming a grand idea. Alternatively, you may be stressed because your company asks you to do work that’s not exactly fitting to your strengths. Your contribution feels forced, uncomfortable, and stifling. Your instincts will want you to run away from such a situation. To switch roles, change companies, or ask for more work. Anything to get back to that feeling of productivity and contribution that you may have felt before. Yet, first take the time to step back and reflect on what is happening.

Do you need to do this work? If the work that you’re doing doesn’t necessarily fit your skills or experience level, it may be wise to postpone or delegate the effort. Don’t assume that because you were asked to do this you must do it now. Clarify the relative priority of the project or task. Explore options to defer or delegate the work and do other work instead.

Is this work necessary for your growth? Maybe you are new to the company. Or maybe you are moving to a more senior level of contribution. These two situations can feel similar. You may feel that you are not contributing as much as you are expected to. However, you first need to learn the ropes before you can contribute at a higher level. After that initial ramp up period your contribution will be drastically improved. Discuss the situation with your manager to ensure that her perspective is the same as yours. Also, be patient.

Is this a temporary situation? Consider whether this is a temporary situation due to an uncommon business situation or transition period. There may have been a slow growth quarter in the company or a change in priorities causing you to be ‘stuck’ with this work. While you wait for work that’s a better fit for your skills, consider working on an ‘extracurricular’. You can volunteer your underutilized skills to help on other projects. Often having another project that plays to your strengths can give you the boost that will get you through not-so-good phases in other projects.

The bottom line is to not confuse a temporary situation that doesn’t allow you to be at your peak with a situation that you must escape. You may be able to defer or delegate the work, push through the situation to develop new skills, or find temporary relief in other work that plays to your strengths.

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 for other posts like these.

Why would a professional join a startup?

I originally answered this question in Quora. Expanding upon it here.

I wrote about the case to quit consulting to join a startup, and my reasons haven’t changed. Key reasons to join a startup include:

  1. You want to build a startup. If you are thinking of building your own company in the future, there’s no better way to learn about the particular challenges that a startup faces than working on one.
  2. Growth opportunities. A startup will stretch you to think and execute quickly. You’ll solve difficult problems on a daily basis. You will often find yourself with responsibilities that a large company wouldn’t trust you with at your age and experience level. It will be hard work to make it successful, but if you succeed as a company, the rewards are large both in terms of skills development and experience.
  3. Career flexibility. You are more likely to have opportunities to do work across functions and thus discover new passions. Startups’ flexibility usually means that you can take your career in new directions. Thanks to this flexibility I was able to transition from a Consulting career into Product Management.

Why quit consulting to join a startup

I’m often asked about my decision 2 years ago to leave a great consulting career to join a startup. Here I explain my key considerations when making the decision, and why I think it was the right decision for me. The rationale follows many of the reasons Raj outlined in his post “Don’t Waste Your 20s at Google or McKinsey”.

When I graduated college in my early twenties, the key goal for me was to get some real world working experience and maximize learnings. I joined consulting with the following goals:

  • Learn “business” to complement my engineering background
  • Get real-world experience on what it takes to run a company
  • Reevaluate whether I needed to pursue an advanced degree to further my career

The general guideline was clear, make the most of my time by learning through real world experience, and be compensated in the process. I would only go back to school, I decided, if I couldn’t further my growth fast enough in my job or was being undervalued given my lack of an advanced degree.

I spent 3 years in consulting at Accenture, a period in which I learned about managing a multi-million dollar a month project effectively, financial considerations of a services public company, managing client relationships and, among others, delivering value despite any crises that emerge. I had the opportunity to make contributions to large projects, I had great mentors, and financial compensation was great. I realized that, however, the learnings I wanted to pursue were no longer in alignment with what consulting would offer, but I was afraid to make a change and give up great compensation and benefits. Somewhere along the way I started valuing compensation more highly and lost focus of my initial goals, maximize learnings in my 20s.

I just believe that the way that young people’s minds develop is fascinating. If you are doing something for a grade or salary or a reward, it doesn’t have as much meaning as creating something for yourself and your own life.
– Steve Wozniak

The key factor that was bothering me was my inability to gain experience that would be relevant in a startup environment. Entrepreneurship had always been in the back of my mind, yet I didn’t see a path to building the skills necessary to start a new company. The kind of problems I was helping tackle in large enterprises had little resemblance to those that would determine whether a startup succeeds. The companies I worked with had resources and challenges very different from a startup environment. The longer I stayed in consulting, the harder it would become to acquire the right skills in the right environment.

I decided  to re-focus my career to maximize learning, particularly the learning needed for me to run a new venture in the future. This time I wanted to be part of a team growing a company from relatively early stages. How small the company was would be a consideration, but there were other key considerations that would drive the kind of startup I would ultimately join.

First acknowledge the key risk. There was little I could have done to truly understand the chances of a startup succeeding. I could look at how much funding the company had raised and from who, but that wouldn’t tell me whether management would blunder or the market would tank, and the company would collapse shortly after I joined. Statistics for how many startups are successful were not reassuring. As such, I had to join an environment in which I would learn and grow quickly, even if the company failed.

Find a team that will appreciate your skills. A consulting background comes with a set of skills that most tech startups often don’t appreciate or understand. This is particularly true if a consultant doesn’t have a technical background, which in Silicon Valley translates to having studied computer engineering. I had to find a team and a role that wouldn’t hinder my ability to grow by under-appreciating my skills. Ideally, this would be evident by the company having leadership with similar consulting-like background, and a role that leveraged those skills effectively.

Find a team you admire. The company could cease to exist, but the people within that company wouldn’t dissipate overnight. It was critical to find a team I could learn from and with which I could work with in future opportunities were this company not to work out. In other words, I looked at the company and thought “if I work here for a year and the company fails, would I regret having spent that time working along these people?”  My goal was to answer this with “absolutely not.”

This search led me to join BloomReach in 2013. I admire the team, the company is tackling interesting problems, and the leadership has truly leveraged my consulting background. Joining a fast growing mid-sized startup gave me the ability to both meaningfully contribute to the company outcome, have real impact and ownership, but still have enough experienced mentors to help me as I learn and grow. These mentors truly care for my development, and have helped me pursue great opportunities as the company continues to grow and so do the career opportunities.

Giving up a high-paying consulting career to join a startup was not easy at first, but I’m confident that it was the right choice to acquire the experiences that will prepare me to lead teams in an entrepreneurial environment. I was lucky to make this decision while it is still relatively easy, earlier in my career, and encourage others in similar positions to consider maximizing their learnings and experiences in their 20s.