Product Discovery 101

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?

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

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!