Category Archives: Product Management

The Fundamentals of Roadmapping

Posted on by

We are in an era of Objectives & Key Results (OKRs) and Key Performance Indicators (KPIs); tools companies use to track and measure their progress and ensure they are on track to reach strategic goals. In scaling startups, CEOs and co-founders have mixed feelings about delegating tasks they once owned to new layers of management. Some tasks, like perhaps managing the books to a new head of finance, they are eager to let go of, and some, like product decisions, can cause a lot of angst. In these times of transition, it’s not uncommon to implement OKRs/KPIs as a way to get comfortable with handing off these responsibilities. As management layers are added, there is a natural fear of no longer being close to the detail, of wondering whether a team can execute as well without a founder/top leader engaged in the day-to-day. I often hear CEOs/Founders of scaling companies ask how they will know if things are working if they are no longer in the weeds. These leaders want to trust their team and worry about micromanaging, but they also want accountability and the ability to track progress. 

Measuring performance and holding leaders accountable is indeed important, but what’s often missing is the holistic view of where the company is going and an organization-wide understanding of how it will reach its goals. Before setting those metrics, leaders must be clear about the True North for the business – the compass of your company’s identity and growth direction – and set a near-term vision with a roadmap to get there.

The 30K Foot View

Anyone that asks what your company’s 3-5 year roadmap looks like is clueless about how businesses – at any stage – really work. With constant innovation, new market entrants and potential black swans like a global pandemic, the best a leader can do is set a 12-18 month strategic plan that is directionally aligned with the company’s true north. That plan should be broken down by quarter with the assumption that the degree of confidence in achieving goals within each quarter will decline over time. You cannot predict the future, but you can build within a set of assumptions. Assumptions should be articulated for each goal as a means to establish confidence levels.  

Here’s a framework for thinking about the high level view of your company’s roadmap:

roadmapframework

High-level Roadmap Framework (c) Julia Austin 2020

The true north (or mission) statement should be at the highest level, a guiding principle of the impact your company is committed to making for the long term. When I was CTO at DigitalOcean, we coined the true north statement “To Empower Developers To Build Great Software”. This gave us focus on our target persona (developers) and latitude to evolve as needed to achieve that mission. While we were (and they still are) a cloud company, this statement said no matter how we evolved, markets change, etc. we would remain focused on what’s needed for developers to build great software. Google’s statement is “to organize the world’s information and make it universally accessible and useful.” Again, the focus is on the impact – the world’s information being accessible – not how the company delivers on that mission.

The 12-18 month vision statement should be a clear focus on near-term impacts. This may be to achieve a certain level of market adoption or to have a core set of offerings viewed as table stakes for the target audience. It could be the launch of a new product or service or a major financial metric like reaching Free Cash Flow.

Quarterly OKRs/KPIs should be brief (no more than 2-3 major goals), achievable, but with some amount of stretch. In other words, if you were using the traffic light rating system (red, yellow, green) not all of them will be “green” per quarter. More info here. Beware of over-adjusting OKRs every quarter – while they will definitely evolve, especially if the process is new to an organization, there can be a temptation to focus on changing the objectives vs. adjusting KPIs or accepting that the goals simply can’t be met for other reasons (poor leadership, systemic issues, market changes) which should be addressed outside of the rating process.

Expect each team across the organization to cascade their operational roadmaps from these strategic foci. Operational roadmaps should identify key initiatives and milestones. Some milestones may be a sum of parts (as in the Engineering roadmap below) and some may be more linear and timeline driven as the Operations and GTM roadmaps show below. Of course, each initiative can be broken down even further per team (see next section); that’s up to each team to decide how to manage from there. However this high level format is the right level of detail for broader communication across the organization and perhaps with your board or even your customers.

strategic_roadmap

Strategic Roadmap Example (c) Julia Austin 2020

The Process

I encourage a six-quarter rolling approach whereby each quarter the leadership team:

  • rates and reflects on last quarter’s results;
  • reviews upcoming quarterly goals;
  • adjusts assumptions and factors in any new information (market shifts, product/revenue changes, etc.) for the next 6th quarter;
  • communicates the updated company plan across the organization; and 
  • has each team create a tactical roadmap that lines up with the quarterly goals.

Below are representations of tactical roadmaps I’ve seen used in two very different organizations. In the first example, the product team and key stakeholders (sales, support and finance leads) review current priorities and drag and drop efforts according to their complexity and priority relative to company goals. They use a product like Mural to collaborate electronically (both when in-person and remotely). In the second example, a simple spreadsheet is used, projects are t-shirt sized using standard scrum methods, and there are links to each project’s details (in apps like Jira or Trello) for more information about relevant epics and user stories. PMs meet with engineering leaders each month to review and adjust as needed. In all cases, the details of each major initiative includes tie-backs to OKRs/KPIs. If they can’t be tied back, and measured, they should not be on the roadmap!

matrix_roadmap

Example One

 

spreadsheet_roadmap

Example Two

Considerations For Very Early Stage Companies – Pre-Product Market Fit

  • If your company is very early stage, expect to pivot the vision and the roadmap a lot as you learn and grow. Create guiding principles for when and how you would adjust a True North and/or Vision Statement. What factors must be true? What assumptions are you making about the market and/or target persona that may prove wrong or different than what was expected? Will you lean into these new findings and shift the direction of the business or keep testing those assumptions in different ways to learn more? Even the earliest staged companies should have a true north as they get started.
  • Avoid peanut buttering! One of my favorite terms, this suggests spreading many things across a broad surface vs. being focused on a few key initiatives. It is scary – especially for early stage companies – to commit to only 1-2 things when it’s so unclear whether either/both will be a success and there are so many other things to try. However, by spreading limited resources across too many things, it’s more likely nothing of substance will get done, or things will move too slowly OR each thing will be done with poor quality while possibly burning out your team. Pick those 1-2 focus areas and set time-boxed milestones that will drive next steps or a change in direction. For example, “we must reach 20-30% conversion rate with the current MVP over the next two quarters or shift to the other product idea.” Commit to these milestones and agree how close you’d need to be to reaching that goal to keep moving forward vs. cutting bait and moving on.

Considerations For Companies With Product Market Fit

  • Appoint a roadmap owner who can oversee the process across the organization. This is typically a senior product manager/head of product or Chief of Staff who is empowered to drive decisions and prioritize based on the 12-18 month vision. This role may be supported by a program/project manager who maintains the details in whichever tool or platform you use (e.g., updates the spreadsheet, inputs changes into Trello, etc.)
  • Be mindful of how much time your team is spending on roadmapping and the measurement process. If it’s taking more than a few hours per quarter to discuss, update and communicate the roadmap and OKRs, it’s costing your company far too much time and money. This process supports productivity, it doesn’t become the work itself! If it’s taking up too much time, it’s likely the goals and measures are far too detailed and/or there are too many people involved in the process.
  • Establish Rules of Engagement (ROE) for times when an opportunity or challenge may disrupt the roadmap. For example, what size/nature of a new customer opportunity would disrupt the roadmap? Can it only be for initiatives that were already on the roadmap, but further out? Will the sales team have points they can “spend” per quarter to reprioritize something? What about a major bug/performance issue? How bad would they have to be to disrupt the current plan? Once the ROE are set, these too should be managed by the roadmap owner. If the ROE are not adhered to, they’re useless, so only have a few and keep them simple. E.g., unless a new customer could grow revenue by x% and what they need is already on the roadmap, we won’t do it. OR if a bug is creating more than x% churn or denying service to a critical mass of customers, it’ll be fixed in accordance with the roadmap.
  • Prioritize the backlog and tech debt as part of the process. These are just as important as new features and the longer they are put off, the harder they will be to schedule and get done. Set aside anywhere from 3-10% of resource allocation dedicated to these efforts. It largely depends on how severe issues are, whether upcoming roadmap initiatives have dependencies on these issues and/or how long they have been festering. It can be useful to “age up” backlog/debt items to raise their priority.
  • A few finer points on this topic:
    • If a new request or critical issue bumps something else, always communicate the tradeoff(s) made and the positive or negative impact they will have on OKRs/KPIs.
    • Developers hate roadmap thrash! So try not to disrupt it too often.
    • Remember, for projects already underway, a reprioritization is not a 1:1 swap – there will be a J-curve in productivity each time a team has to stop something, start something new, and return to the old project later. 

Conclusion

There is no one best way to do the roadmapping process. How you lead, the type of product you build, organizational structure and culture all come into play to determine what will work best for your company. Having a roadmap process will improve the prioritization process and create alignment among teams, will provide transparency across the organization and should give leaders (including your board) the right level of visibility to ensure the work is getting done. Don’t create a process just for the sake of process or implement OKRs just because someone told you that’s what you’re supposed to do. Be thoughtful and implement whatever process works best for your company.

Do you have other suggestions on how to run a great roadmapping process? Please share in the comments!

Product Discovery 101

Posted on by

As an entrepreneur, how confident are you that you fully understand your customer’s pain points and/or job to be done? When I first meet an entrepreneur, they tend to start selling me on their solution before explaining the problem they are trying to solve. I typically see or hear little evidence that they’ve done true discovery work to validate the problem or their target customers. While gut feel or personal experience with the problem can be a strong signal there’s a problem to solve, without proper product discovery work, you won’t truly know if you have a winning solution.

For those that profess they have done proper discovery work and have validated the problem, but don’t yet have a product, my follow-on question is “How do you know people or companies will use your product?”. More often than not, I get examples of interest tests such as hits on social media posts or answers to surveys that are so biased it’s hard to trust the results. Further, they may have a good hunch there’s a job to be done that needs improving/replacing, but they cannot describe where in the customer journey they can truly make an impact.

I’m a big fan of confident founders who are passionate about their idea, but a little humility and a lot of discovery work can determine whether there’s a winning solution and save a lot of time and money wasted on building the wrong thing. If fundraising is also a consideration, being able to have real data vs. gut feelings and biased test results can be the difference between a modest angel round and a strongly led seed- or A-round.

To that end, a few tips…

Interest vs. Problem Testing

“We had 1000 clicks on our Facebook ad in the first 48 hours”,
“Our conversion rate from click to sign-up was 50%”, OR
“We interviewed a bunch of people and they said they’d use our product if we built it”

When I hear these types of quotes early on in a product’s lifecycle, I do a mental facepalm. These quotes suggest they may have found an audience interested enough to click on an ad and to give their email addresses, but they still have not proven anything about the actual usefulness of their product or that it solves a real pain point for their target customer that they are willing to pay for to fix. These tests are OK to do, but should not be the only way you validate problems to solve. If you plan to do interest tests, consider these approaches:

  • Social Media: Great for finding your audience, should be done on multiple platforms and carefully crafted so as to answer only 1–2 hypotheses. These hypotheses are commonly “Is this where our audience is if we want to market to them at some point?” and “Are they interested enough to click and learn more”. These tests can be expensive so be thoughtful about where and when to do them (e.g., if you’re building a product for teens, test on Instagram or Snapchat where they are (vs. Facebook)
  • Landing Pages: The best way to capture interest, email and demographic data. If they found you through social media tests or googling,
    a) you’ve proven they were interested enough to learn more,
    b) that your SEO works and they found you; and/or
    c) that they trust you or care enough about the problem you wish to solve that they will give you insight into who they are.
    These future customers are great targets for problem testing and could be your early adopters. Be careful though, early adopters are great for testing, but don’t always guarantee a chasm-crossing to the mainstream. This too must be validated.
  • Surveys: Surveys are very hard to do right and often capture a lot of random and very subjective information instead of getting real data to inform your product. We have this tendency to think “while we have them, let’s ask them everything!”. Great surveys are:
    • Ten questions or less,
    • reflective in nature (Ex: how many times did you buy “X” in the last month?) and very data-centric (Ex: how often do you order takeout for dinner?). Reflective questions should have ranges to choose from that do not sway the prospect or suggest there’s a right answer; and
    • capture basic demographic information only relevant to the questions at hand (e.g., don’t ask age or gender or income unless that’s specifically something you need to know about your audience); as long as you have contact information, you can always follow up for more demographic data if needed.

More important than interest tests early on, are tests that validate there is a problem worth solving and where exactly a product can be most successful in solving that problem. Validating hypotheses about the problem through a variety of methods is going to lead to a far better outcome than clicks on a Facebook ad. The more ways you can learn about your target customer and discover where the problems are, the more likely you’ll get on the right path to solution building. This process takes multiple iterations and approaches to get to a minimum viable product (MVP) that begins to address the issue.

Consider trying these different types of problem validation tests in your discovery process:

  • Interviews: Similar to surveys, interviews are as much an art as they are science. It is incredibly easy to lead a witness, bias answers and hear what we want to hear in an interview. The best guide for conducting a proper discovery interview is Rob Fitzpatrick’s book “The Mom Test”, which I encourage every entrepreneur and product manager I work with to read. A few key takeaways:
    • PRIORITY: Talk with strangers! Any interview subject who is a friend, family member or member of an affinity group (e.g., student/alumni at your school), you bias the conversation. They are more likely to tell you what you want to hear and validate your idea vs. truly objective answers. If you’re not comfortable talking with strangers, don’t interview or hire an independent consultant/friend to do it for you.
    • Write a script and be clear about what hypotheses you are trying to validate before the interview. Sticking to a script ensures a clean comparison of results after interviews.
    • Start by setting the stage. You are learning from them vs. selling them on your idea, no answer is a wrong one and set a time expectation — 30–45 minutes are ideal. Always end by thanking them, asking if you can follow up AND if there’s anyone else they suggest you speak with about the topic.
    • Always ask open ended questions — Ex, tell me the last time you…
    • Always have someone serve as observer & notetaker not just to capture what’s being said, but to look for body language, expressions and any other “tells” about the problem you are trying to learn about.
    • Do more listening than talking — you’re there to learn from them, not sell to them.
    • Unsure what they were explaining or want to reframe their response into hard data? Echo it back and see where that leads them. Ex: “So what you said is, you usually eat out twice a week?”.
    • Always record the session — most interviewees will not mind being audio or video recorded (the latter is better), especially if you assure them it won’t be shared outside of your team.
  • Ethnography: Observing prospects performing the job you hope to improve/replace can be extremely insightful. You may see hacks they would never tell you about in an interview or discover there’s a whole new set of problems in their process that you had no idea existed.
  • Emotional journaling or mapping: Having a prospect journal or map out their process and highlight how they feel along the way can pin-point exactly where they are most frustrated in their process. This is also a great technique if you cannot observe the prospect in the setting where the problem exists. Ask them to journal or map and send you something within a set period of time.
  • Journey mapping: Bringing together all your discovery work to identify where you found patterns of highs and lows. These may surprise you; often where we hypothesized there was the most pain in a process may be somewhere completely different.
  • (Don’t do) Focus Groups: I am generally not a fan of this form of discovery. It lends itself to group think and can lead to false results. Focus groups can be useful later in the product cycle when you want to get reactions to branding or observe groups of people using your product if it’s a tangible item.

Prototype Testing
The best way to validate a problem exists is to actually insert yourself into the process and learn by doing. These tests lean towards solution building, but the idea is you’re doing tests without building anything or building very little to get clarity on the problem and the customer. The most common forms of these tests are:

  • Lo-Fidelity Concierge Testing: Jump right in and assume part of the role that your product might fill in the future. If you were coming up with a new restaurant reservation system, this may involve a phone conversation with the party needing a reservation and having you do the actual booking for them and perhaps texting them to confirm their reservation. By being the intermediary, you are fully embedded in the process to understand all sides of the problem. The key to success of these early tests is to resist the temptation to correct your customer or other players and just go with whatever they do to experience the process. You can tweak things as you learn more about what works and what doesn’t work along the way.
  • Wizard of Oz (WoZ) Testing: Unlike a concierge test which is transparent and prospective customers are aware you are part of the solution, a WoZ test allows you to intervene without a customer knowing you’re doing work behind the scenes. This is usually created by having a prototype of some sort that the user interfaces with, but involves manual labor that users don’t see. For example, In the early days of Uber, a dispatch team was used to direct drivers to pick up customers and text customers about arrival times before they had complex algorithms and a driver app.
  • Physical Prototypes or Competitive analogs: If you are building something non-digital that could be expensive to manufacture before you test, there are several creative ways to do discovery early on.
  • Prototypes: Small runs of your future product or handcrafted using freelancers to do 3D printing, sewing or even a pop-up restaurant are ways to get your idea concept tested and feedback on its use before spending too much money. One of my favorite examples of these is a former student’s idea for a smoothie making machine for offices. Before he even made the machine, he started making smoothies in offices just to see what employees liked, how visual aids helped (having fresh fruit nearby inferring a fresh product) or offering add-ins like chia seeds or protein powder to see if they made his smoothies more appealing. Not only did he learn what flavors were most popular to focus his MVP, but he also got a lot of insight into the operations of small to medium sized businesses, how much of a footprint he’d need for machines, maintenance requirements, etc. It was an invaluable experience for this entrepreneur.

Smoodi team testing mix-ins with their early prototypes

  • Competitive analogs: Having target customers use other, similar, products can be as telling as using the product you hope to create. Using a tool like UserTesting to have a prospect walk through their use of a current competitive product can be very insightful. Having target customers use a competitive product for a week or two can also be insightful. Just be careful not to start creating your product based on what these other products have/don’t have. The goal is to understand how these prospects interact with those products today — it’s not to get feature parity.
  • Expert Testing: Sometimes, you are working in an area where you may not be an expert, but you have a hunch it’s a white space ripe for disruption. If you don’t have access to the experts or their customers, find or create a space for them to connect and observe through their experiences. This could be as simple as finding them on Quora or Reddit and looking at threads of questions that are related to what you’re exploring. You could create a forum for them to chat if none exists (e.g., an affinity group Slack workspace or Meetup) or even create an event to gather the right people. Another one of my former students got her start with ElektraLabs by creating an event which not only informed much of the early product, but also connected her with experts who went on to both advise her company and evangelize her product.

A Few More Best Practices
All of the above tests should be explored whenever you are in the process of validating problems and target customers. Try many and do them often. Testing never stops! Here are a few more things to consider when designing your tests:

  • Eliminate Bias: I can’t emphasize enough how important it is to have as objective a test as possible. This means not asking your friends, co-workers or parents to participate. Find total strangers who can give you honest and authentic feedback.
  • The Rule of 5: If you keep your criteria very tight — who you are asking and very specific things you are testing — you need not do more than five tests before you know where you are trending. But limit your variables per test (see next bullet).
  • Limiting Variables: The Rule of 5 only works if every test you do is limited to a couple of key questions you want answered. The more variables in a test, the harder it will be to discern what influenced an outcome. For example, if you are trying to test whether women ages 18–20 vs. women 30–35 have a problem finding a great yoga class, design a test that is the same in every way, just test it with five of each of these two different audiences. Similarly, limit variables in prototype tests such as in the smoothie test noted above, where when the founder tested add-ins at one particular site, that was the only variable he changed; all other aspects of the test remained the same including the site itself.
  • Breadth of Demographics: You may be designing a product that you believe everyone in the world will need OR that you believe only one target audience needs. Gender, income level, geography, etc. may or may not have an impact on adoption but you won’t know that until you parse things out early on and test a few. How a 13 year-old uses a product may be completely different than a 45 year-old (Facebook is a great example of this). Also, if you don’t test different demographics, you may miss an audience that could be in most need of your product.
  • Measured Outcomes: Start with a hypothesis of what will happen per test, ideally in measurable outcomes such as % of people who accept a restaurant recommendation or number of smoothie customers who want an add-in vs. those who do not. Decide what you think success looks like for these tests. If your outcomes vary, then consider whether your test was valid and/or whether the learning lends itself to further testing or abandonment of an idea. In the case of the smoothie, the founder hypothesized that his target customer would want 5–6 flavor combinations, but found only 2–3 flavor combinations were most popular, thus he limited the flavor options in his MVP.
  • Leverage Existing Technology: Finally, in today’s highly tech enabled world there are a number of ways to engage your target customers using what’s already out there to your advantage before building anything yourself:
    • Typeforms, google forms, etc. can capture form data
    • Online payments can be simulated using Venmo
    • Texting can simulate alerts and notifications
    • High fidelity web prototypes from Figma, Sketch, Invision, etc.
    • 3D printed mockups & scrappy hand crafted prototypes made from supplies you can buy online

Another former student of mine with a software engineering background resisted the temptation to code a solution and instead created a WoZ test by cobbling together Soundcloud, Dropbox, texting and a high-fidelity mock front-end. Once she had experienced dozens of people using this method and understood what they needed, she officially built and launched the product.

Test Early, Test Often!
With all the options available, there is no excuse for weak validation of problems and target customers early on in your product development process. One test or even a few tests does not qualify a product as marketable or fundable. The more objective tests you do up front, and iterate on those tests often, the higher likelihood you’ll land on a great solution that people want to use and buy.

This blog post is largely inspired by my course, PM101 at Harvard Business School. We focus the most of the semester on best practices for discovery. I have open-sourced the syllabus for this course here.

Are You Being Strategic About Hiring?

Posted on by

If I had a nickel for every time I get an email or text asking if I know any full stack developers for hire, I could cover the cost of my next trip to SF. I’m also struck by the number of founders who say they’re raising more money simply because they need more engineers to code, yet they do not have a good hiring strategy.

For decades, there have been books and articles about building engineering teams. The infamous book The Mythical Man Month, by Fred Brooks should be on every software engineer and tech startup leader’s reading list (It should also be re-titled either “The Mythical Person Month” OR “Nine women can’t make a baby in one month”…just sayin’). There are also many blog posts explaining why full stack engineers are unicorns. Yet, when I did my latest poll on twitter on top hiring priorities this is the response:

screen-shot-2019-06-02-at-1.20.42-pm.png

Sure, it’s fine to look for a generalist [or augmenting your team with an outsourced dev shop] to get basic stuff done, but being more strategic about your hiring process, is what could be the difference between a great product in the market vs. something basic that is slow to ship. Below are some tips on how to be more strategic about hiring:

  • Product prioritization leads to hiring prioritization: If you’re doing proper product prioritization via discovery – talking with customers and understanding what you need to get to product market fit or grow adoption – then these priorities set the hiring agenda. For example, if you’re realizing that your on-boarding process is too complicated, then hiring a User Experience (UX) person may serve you far better than someone who can code a fresh UI. If performance issues are causing churn, then hire a performance engineer; someone who knows how to diagnose and fix performance issues. Just like you are building a product to solve for the job to be done, hire the engineer for the development job to be done. 
  • Understand the roles: Do you understand the difference between a front end developer vs. designer vs. UX expert? (if you don’t, read this) Are you fluent enough in your architecture to know what type of engineer should be building which elements of your product? Many early stage companies are started by engineers who know exactly what they’re doing, but many are biased in the areas of which they are most familiar, even if that is the suboptimal choice for their current products. I’ve seen products built with .NET simply because the seasoned engineer-founder knows that platform best, without considering whether it is the best platform for their product and/or whether they’ll be able to hire engineers who are skilled in .NET (or want to learn it) to build it at scale. I’ve also seen many startups default to the language of choice for the full stack engineer they found to build their first prototype and then let that language dictate future work as their product gets market fit and scales. This rarely works out, unless that first engineer is a ringer, and most of the time the reality of having to refactor your entire codebase or port to a new language hangs over the product team…forever. 
  • Long term need vs. short term fix: Another common mistake is hiring a full time expert in an area that only needs occasional work. E.g., Performance engineering. Certainly, if you’re building a complex, distributed, application that has heavy computation or many API calls, then a performance engineer is a critical full time hire. However, it may behoove you to find a good contract engineer who specializes in performance tuning as needed; at least until you’re operating at scale. Same thing for a designer – unless you’re at scale and adding new features/products at a steady clip, then a contract designer may be prudent while you iterate on your MVP. You may pay a little more per hour for these contractors, but that far outweighs over hiring and paying a full time salary early on. 
  • Time Delay + J-curve: Just because you have cash in hand to hire, doesn’t mean you will find and hire the right people right away AND each time you add a new person to the team, there will likely be a j-curve impact on productivity.
    Screen Shot 2019-06-03 at 1.47.59 PM.png
    Therefore, when you prioritize hiring, factor in how long* some roles will take to fill (e.g., we don’t need a designer for a few months, but it could take three months just to find the right person) and be thoughtful about the cadence of adding new people to any team. Adding a bunch of new engineers at once is not going to accelerate development over night. Each time a new person comes on board, it’s disruptive to team’s flow – and this is not just about training them. It disrupts the whole     dynamic of the team. If you’re doing a lot of hiring over a discrete period of time, set the right expectations (with yourself, your company and your investors) that a ramp in hiring will likely slow things down until new teams settle into new norms. If the ramp is constant, by the way, your teams will never settle into a groove leading to employee dissatisfaction, high turnover, product delays, etc.

    *This delay should also be considered in the budget exercise for these roles. Don’t front-load salary expenses for open jobs that may take weeks or months to fill. 
  • Humans are not robots: Hiring is hard, and even when you get really good at it, at the end of the day these hires are human beings that have their own unique needs, past-job baggage and career aspirations. Their added productivity, how they diversify and/or add to your culture is only part of the consideration. Having a strategy to prioritize manager, team time and money for their human needs (benefits, HR support, a strong on-boarding experience, ongoing training and mentorship, etc.) is just as important as having a strategy to prioritize these hires! 
  • Apply the 80-20 rule: A great product leader will tell you that if you invest 80% of effort to understand the problem, it should result in 20% effort to build the right solution. The same applies to hiring. If you take 80% of your effort to develop a great hiring strategy and program, it should lead to 20% of the effort to bring great people on board and retain them for the long term. 

There’s a severe opportunity cost that comes with bringing on the wrong people and/or at the wrong time and not having the right people programs in place. Even if you are a tiny early stage company, having to let someone go, or having them quit, and finding a replacement not only stresses out the manager and team, but there is a productivity hit to all while you go through the process. Even though it may feel like you’re moving slowly through the process of building a team, a strategic approach will pay off.

You can read more about my thoughts on hiring for startups here. Please share other ideas on this topic in the comments!

So You Want to Be A Product Manager

Posted on by

Because I teach a course on Product Management at Harvard Business School, I am routinely asked “what is the role of a Product Manager?”. The role of a Product Manager (PM) is often referred to as the “CEO of the Product”. I disagree because, as Martin Eriksson points out, “Product managers simply don’t have any direct authority over most of the things needed to make their products successful – from user and data research through design and development to marketing, sales, and support”. PMs are not the CEO of product and their roles vary widely depending on a number of factors. So what should you consider if you’re thinking of pursuing a PM role?

As an aspiring PM, there are three primary considerations when evaluating the role: Core Competencies, Emotional Intelligence (EQ) and Company Fit. The best PMs I have worked with have mastered the core competencies, have a high EQ and work for the right company for them. Beyond shipping new features on a regular cadence and keeping the peace between engineering and the des

ign team, the best PMs create products with strong user adoption that have exponential revenue growth and perhaps even disrupt an industry.

Screen Shot 2017-10-31 at 1.44.18 PM

Do you have what it takes to be the best PM?

Core Competencies
There are core competencies that every PM must have – many of which can start in the classroom – but most are developed with experience and good role models/mentoring. Some examples of these competencies include:

  • Conducting customer interviews and user testing
  • Running design sprints
  • Feature prioritization and roadmap planning
  • The art of resource allocation (it is not a science!)
  • Performing market assessments
  • Translating business-to-technical requirements, and vice versa
  • Pricing and revenue modeling
  • Defining and tracking success metrics

These core competencies are the baseline for any PM and the best PMs hone these skills over years of defining, shipping and iterating on products. These PMs excel at reflecting on where each of these competencies contributed to the success or failure of their products and continuously adjust their approach based on customer feedback.

Emotional Intelligence (EQ)
A good PM may know the Do’s and Don’ts of a customer interview, but the best PM has the ability to empathize with customers in that interview, are tuned into their body language and emotions and can astutely suss out the true pain-points that their product/feature will address. A PM with a high EQ has strong relationships within their organization and they have a keen sense of how to navigate both internal and external hurdles to ship a great product. Here’s a deeper look at how the four EQ key traits, as defined by Daniel Goleman, relate to the PM role:

  • Relationship Management: Probably one of the most important characteristics of a great PM is their relationship management skills. By forming authentic and trustworthy connections with both internal and external stakeholders, the best PMs inspire people and help them reach their full potential. Relationship management is also vital in successful negotiation, resolving conflicts and working with others toward a shared goal which is especially challenging when a PM is tasked with balancing the needs of customers, resource constrained engineering teams and the company’s revenue goals.

    Authentic and trusting relationships within an organization can lead to more support if additional funding is needed for a product or to sway an engineer to include a quick bug fix in the next sprint. Outside an organization, these skills could encourage existing customers to beta test a new feature for early feedback or convince a target customer to try the MVP of a product still in stealth mode. These relationship skills can also be what makes the difference between having irate customers because of a bug introduced into the product and those who say “no worries, we know you’ll fix this!”. 
  • Self-awareness: PMs must be self-aware to remain objective and avoid projecting their own preferences onto users of their products. If a PM is in love with a feature because it addresses their own pain points (PMs are often super users of the products for which they are responsible), they may cause a user to say they love it too just to please the PM (“False positive feature validation”). If not self aware, a PM may push to prioritize a feature they conceived even when all the customer interviews and evidence is stacked against it. This lack of self awareness could derail more important priorities and/or damage the PM’s relationship with engineers who may lose confidence in their PM when the feature isn’t readily adopted by users. 
  • Self-management: Being a PM can be incredibly stressful! The CEO wants one thing, the engineering team another, and customers have their own opinions about feature priorities. Managing tight deadlines, revenue targets, market demands, prioritization conflicts and resource constraints all at once is not for the faint of heart. If a PM cannot maintain their emotions and keep it cool under pressure, they can quickly lose the confidence of all their constituents. The best PMs know how to push hard on the right priorities, with urgency, but without conveying a sense of panic or stress. These PMs also know when to take a breath and step away if needed, regroup, and go back into the game to get sh*t done (GSD). 
  • Social Awareness: According to Goleman, the competencies associated with being socially aware are Empathy, Organizational Awareness, and Service. PMs must understand customers emotions and concerns about their product as much as they understand the concerns of the sales team on how to sell that product (or support team to support it, or engineering to build it). PMs have to have a deep understanding of how the organization operates and build social capital to influence the success of their product – from obtaining budget and staffing to securing a top engineer to work on their product. Finally, social awareness ensures the best PMs service their customers with a product that addresses their jobs to be done which is ultimately what drives product market fit.

Read more about what Paul Jackson has to say about EQ and PMs here – including a sub-link of an interview with Sam Lessin, former VP of Product Management at Facebook, who says he has ‘never successfully trained empathy.’ (or as Lady Gaga would say “you were born this way”…or not!)

Company Fit
So if the best PMs have well developed core competencies and a high EQ, does that mean that they are then destined for success no matter where they work? Going deeper, it is taking these skills and personality traits and applying them to the right company – amid a broad array of opportunities – that will ultimately guarantee success.

I have yet to see a standard job description for a Product Manager because each role is ultimately defined by the size, type of product, stage, industry and even culture of the company. Assuming the core competencies and high EQ as the minimum requirements, the next step is to unpack who’s hiring and what they are truly looking for:

  • Technical Skill – The type of product, who uses it and/or the type of company (e.g. Google who requires PMs pass a technical skills test regardless of what product they’ll work on) will determine how technical a PM needs to be. If the company is building a SaaS CRM, there may be more requirements for experience with go-to-market and customer lifecycles than how the product itself is built. If it’s a data science product with machine learning algorithms and APIs, the role may require a lot more technical depth to not only understand how to build the product but also how to talk, credibly, with the customers who will use it. That said, having a basic technical understanding of what is “under the hood” and mastery of the tools that PMs use is definitely important for the role, anywhere. Colin Lernell has more to say about these necessary skills here.

    If you are an aspiring PM concerned you lack the basic tech skills for the role, you might consider taking online courses such as the renowned Introduction to Computer Science (CS50) course offered by Harvard University or one of the many intro and advanced technology courses offered by The Flatiron School. 
  • Company philosophy about PM – Every company has a different philosophy about the product development process and where PMs fit into that process. Below are the three most common types with pros and cons:

    • PM Drives Engineering: A “throw it over the wall” approach where PMs gather requirements, write the quintessential PRD (Product Requirements Document) and hand it off to Engineering to spec out the technical requirements. Contemporary organizations may do this process in a more agile and collaborative way, but the expectation is that PMs know best about what customers need and engineering is there to serve.
      • Pro: Engineering can focus on coding without a lot of distraction; tends to work well for Waterfall development shops with long lifecycles.
      • Con: Engineers lose sight of the big picture and do not develop empathy for customers which can lead to a poor user experience; often there are unhealthy tensions when tech-debt and “plumbing” work needs to be prioritized against customer requirements. 
    • Engineering Drives Product: More technically oriented product companies (e.g., cloud, big data, networking…) tend to be engineering driven where engineers are advancing the science in their domain and PMs validate solutions or create front end access points (UIs, APIs) to tap into this new technology. There can be a collaborative relationship and feedback loop between customers, PM and engineering, but typically, PMs are serving engineering in these companies.
      • Pro: Breakthrough technology can offer customers things they didn’t even know they needed (VMotion at VMware was a great example of this. An engineer thought it would be cool to do, a PM figured out how to monetize it and it became THE billion dollar game changer for the company).
      • Cons: Engineers chase the shiny new thing, over-architect the solution or iterate forever (seeking perfection) before getting customer feedback; PM input on priorities are ignored, which is sometimes the most basic needs of customers to encourage adoption and increase stickiness of the product.

        Screen Shot 2017-10-31 at 10.52.40 AM
    • The PM<>Engineering Partnership: There is a strong yin-yang between PM and Engineering where there is joint discovery, decision-making and shared accountability. Engineers join PMs in customer interviews and PMs are insprint meetings to help unblock tasks or bring clarity to  requirements, but the two roles respect the line where one starts and the other stops. PMs understand what’s being coded, but don’t tell engineers how to code and engineers have empathy for customers’ needs, but leave the prioritization to the PMs.
      • Pros: Streamlined prioritization process that values tech-debt/plumbing projects; better design processes leading to a more positive user experience; higher performing teams with improved product velocity, quality and typically, happier customers.
      • Con: Breakthrough innovation may not get light/investment; time-to-market may seem to lag (but I’d argue what’s released is far better aligned with customer needs with a far more scalable product).

I’m clearly biased (as is Fred Wilson) on the third type of philosophy about PM as I’ve experienced all three and found the yin-yang to be most effective, but it’s not to say the others are notably bad and, again, it really depends on what type of product, stage, etc,. Regardless, when considering a PM role, the philosophy of PM at the company could be the deciding factor on fit for the role.

  • Stage of company – The role of the PM at a startup is far likely to be responsible for “all the things” vs. a mature company where their role will be more distinctly defined. Eriksson, Banfield and Walkingshaw’s book Product Leadership has a section that has a lot more detail on this topic).

    • Startup: Beyond discovery, definition and shipping, they may also be responsible for pricing, marketing, support and potentially even sales of the product. These PMs thrive in a scrappy environment and are comfortable with ambiguity and frequent changes to direction as the company works towards product market fit and learns to operate at scale.
      • Pros: Likely to be more involved with company strategy, exposure to senior leadership/board, able to take more risks/make a bigger impact; more influence/authority over company resources.
      • Cons: Little-to-no mentorship or role models or best practice within the company (may have to seek externally); may not have requisite experience for some of the “things” (comfortable winging it); tight budgets. 
    • Mature Company: The PM may have a more narrow scope (deep vs. broad), have co-workers who handle pricing, go to market strategies, etc.. and likely part of a larger team of Product Managers.
      • Pros: More likely to have mentoring/role models and development standards/best practice; close association with an engineering team can develop strong relationships over time (great for long term impact/career growth); if product has market fit, there is an established customer base and performance baseline to work from vs. guessing until you get it right.
      • Cons: Less exposure to company strategy; just one of many voices of the customer; can get “lost” in the system; more politics; tight budgets. 
  • Founder/CTO/CEO relationship with PM – Especially in earlier stage companies, it’s important to know how involved the Founder/CEO/CTO is in the product process. If they are deeply involved, the PM role may play more of a support role to flesh out their ideas or validate concepts with customers vs. conceiving and driving ideas of their own. This can be great fun for some PMs who enjoy partnering with founders/c-levels and collaborate on the product evolution, but for some PMs it can be very frustrating if they prefer to take more ownership of product direction. It can also be challenging if the more technical founders/c-levels prefer working directly with engineers. This can leave PMs out of the loop or undermined (even if unintentional) causing not just personal frustrations but delays if they have to play catch up and/or continuously recalibrate. When considering a PM role that may work closely with the founding leadership team, be sure to find out their expectations of the PM function and decide whether this is the right fit with your interests.

There are of course many other factors to consider for any role such as the type of product you are building (B2B, B2C, industry, etc.), the humans with whom you’ll work and the overall company culture (diverse, inclusive, flexible work hours, remote culture, etc.), and of course compensation and benefits. There are also a million articles on hiring product managers to get perspective on what the hiring managers are looking for – I especially recommend my friend Ken Norton’s piece How to Hire a Product Manager. However, if you are striving to be the best Product Manager, consider all of the above before signing on to your next gig. Developing core competencies will be an ongoing activity throughout your career and leveraging a high EQ will ensure a more positive experience, but where you work, how they work and who you work with/for will ultimately determine your long term success.

Have additional pointers on succeeding in the PM role? Please share in the comments!