I’m no stranger to Udemy, I’ve previously used the site to take a Google Analytics certification course, refine my copywriting skills and learn a bit of HTML and CSS coding. I was struggling with cabin fever during Toronto’s recurring lockdowns and decided to sharpen my product management skills. Over the last few months I’ve been taking the Become a Product Manager | Learn the Skills & Get the Job Udemy course.
Become a Product Manager Udemy Course Info:
Instructors: This course is taught by Evan Kimbrell (Founder of Sprintkick, Ex-VC, Ex-startup founder) and Cole Mercer (Sr. Product Manager @ SoundCloud, Ex-Bonobos, Gen. Assembly).
Pricing: The course price is $109.99 normally but often as little as $14.99 when on sale.
Includes: 13+ hours of content with a dedicated Slack channel and linked resources for extra reading. This course is divided into 17 different sections.
Rating: This course has earned 4.5/5 from > 32,000 ratings
Check out the course here!
I investigated several different courses and finally selected this one after reading the glowing reviews. A major benefit of this course is the included access to a Slack workspace where you can discuss the course content and network with aspiring PMs from around the world.
Disclaimer: Udemy offers major sales ALL the time, like seemingly every other week! I have bought classes worth hundreds of dollars for as little as $14.99. Also, this post is not sponsored in literally any shape or form.
Without further ado…
These buzzwords are bandied around a lot in startups, so it’s important to know the difference. This course does a fantastic job at breaking down these key concepts in layman’s terms from the outset.
Bonus! Agile vs. Waterfall: The waterfall development process is ideal for features with dependencies or mission-critical softwares (ex. braking engines for cars). It’s less collaborative than the agile software development process as everything is designed up front and passed in stages from team to team.
This course has an entire section dedicated to “Competitive and Market Analysis.” As a product manager it is important to understand your company’s primary competitors. You should have a sense of their:
Not all competitors are equal; there are different types to watch out for. Direct competitors offer the same solution for the same problem. Think UberEats and DoorDash. An indirect competitor offers a different solution for the same problem and may have a different target customer group. An indirect competitor of UberEats would be HelloFresh. A potential competitor would offer something to the same/similar target group but addresses a different problem (aka a peripheral competitor). Amazon could be considered a potential competitor to UberEats. A substitute competitor solves the same core problem in a totally different way. A substitute competitor for UberEats could be a private chef or more realistically, a roommate who dabbles in cooking.
As a product manager, it’s important to understand the competitor landscape of your product. The course facilitators list various digital tools to monitor your competitors such as Mention.com, Google Alerts, Crunchbase.com and more!
A feature table is a comparison chart used to compare your product vs. your competitors. The X-axis lists the competitors and the Y-axis tracks dimensions (features & factors). Try making a feature table comparing your product to its direct competitors (as discussed above) first. Choose to evaluate the features and factors that are important to your product group.
As a PM, you need to know what’s considered competitive or cutting edge in your product’s market. Competition is an ever-changing landscape, so you’ll need to consistently monitor your competitors. Your job is to make sure your solution is obviously (not subtly) better than your indirect, potential and substitute competitors for your target consumer base. Use the feature table framework to make sure your product is obviously better. Your product vision is how you win over the market.
When monitoring your competitors, keep tabs on the following:
The definition = The practice of establishing a continuous and iterative communication line with your customers. The framework of communication known as “Customer Development” is a major tool for PMs to evaluate if they’re building the right product. After all, you can’t come up with great products in a vacuum (Dyson vacuums are amazing products though - don’t get me started on their haircare line!)
Customer development is useful for risk mitigation and opportunity recognition. Customer Development can be broken down into the following stages: discovery, validation, creation & building. The key to Customer Development is the user interview.
There are 4 main types of interviews:
If you want to learn more about how to effectively run a user interview I suggest checking out “The Mom Test” by Rob Fitzpatrick. It’s an excellent and fast read that was recommended to me by my manager.
So you’re ready to interview, but where do you find people to interview? If you’re a PM of an existing product, you already have a pool of active users to reach out to. Try targeting customers who are active on social media, have contacted customer service or are highly engaged (whether that’s # of purchases, # of likes, etc.) with your product. That last group would be considered your power users.
If you’re launching a new product, you’re going to need to look for interviewees externally. Explore LinkedIn, Reddit, Quora, Twitter and even your competitors (go to their SM and see who is engaging there). When you contact potential interviewees there are a few best practices of cold-emailing you should abide by:
Keep in mind that cold emails have a 3:1 (or worse) ratio, in other words you’ll need to send at least 3 cold emails to garner one response. This part of the course reminded me a lot of Seth Godin’s blog post “Email Checklist.” I bet there are at least 5 ways everyone could improve how they draft emails, myself included.
An MVP or minimum viable product is “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort” (“The Lean Startup” by Eric Ries). An MVP is designed to test a hypothesis and can take many forms (from a landing page to a form to a video, etc).
The stages of a MVP experiment:
There are three possible outcomes of a MVP test:
As a PM, you’ll find that ~ 90% of your MVP experiments will end up as #3. To avoid conflating #2 and #3 it’s important to define a MCS or minimum criteria of success.
Different types of MVPs (minimum viable products) that you can use to gauge interest. In simplest terms, MVPs are a simulacrum of a real product, not a complete product themselves. MVPs come in various forms:
Keep in mind! Larger organizations have the resources to weather failed products. There is a different risk/reward calculus for start-ups. The biggest risk for startups is using all resources on a futile or failed endeavour. Meanwhile, risk to brand perception is often the biggest concern for established companies. The Wizard of Oz MVP is the most labour-intensive of all the above, but also the most protective of the brand (opposite true for Email MVP). As a product manager, you need to gauge your company’s tolerance for risk: do they care more about resources or more about the brand?
What is a metric? A metric is a # measurement of something, synonymous with a KPI (key performance indicator). In Agile development, feedback loops are driven through metrics. As a product manager, it’s important to understand that all metrics are interconnected. You’ll need to keep a close eye on a select few that you associate with product success.
What makes a good metric? A good metric should be understandable and relatively simple; should generally take the form of a rate or ratio. Avoid looking at two metrics that are correlated and assuming a false connection. Correlation DOES NOT = causation (this was hammered into my head during middle school science).
What gets measured, get managed.
— Peter Drucker
There are various categories of metrics, including:
The goal is to pick at least one metric for each of the above stages. It’s a funnel-like journey for the user and you want to optimize your metrics at every step.
*An activated user has signed up for the product and performed a desired action; just downloading the app isn’t sufficient.
Keep in mind the difference between exploratory vs. reporting metics. The latter are metrics that are consistently tracked over long periods of time to measure product health. An exploratory metric is exactly what is sounds like, a data point to hunt down clues about user behaviour.
Epic. A fun adjective and a key term for product management. An epic is the building block of product management; also known as a grouping of one or more features or functionalities that we want to build. Also also defined as a piece of work that takes longer than one sprint to build.
There are often 3-5 epics per quarter (depending on company size), an example epic could be translating an app into Spanish or implementing photo sharing in direct messaging. It’s important to note that not all epics are external, they can be internal tasks such as migrating to a new database (in comparison, features are generally always consumer-facing).
An epic is accompanied by an “epic spec sheet",” a form of documentation also known as a requirements documentation. The purpose is to allow anyone in the company to see what you’re building and also serves as a guideline for your product team. An epic spec sheet includes the following sections:
PMs are responsible for creating/maintaining these requirement sheets, specifically the first two sections.
Product Managers are responsible for the what and the why. Designers and engineers supply the how. PMs harness user stories to help clarify what needs to be achieved with a new feature. The format of a user story is the following: As an X, I want to do Y so that I can Z. For example, as a user, I want to send pictures in a direct message with my friends so I can share my memories with them. User stories are often stored in the project management tool used by your team for easy reference.
Acceptance criteria is a set of requirements a software must fit to be considered complete. The acceptance criteria should be double (triple!) checked before releasing a feature. The acceptance criteria for the user story above ^ could be: “Given I am a user who has successfully uploaded a photo from my computer, when I click ‘send’ the image is sent to my friend through the direct message and then appears in the chat.”
How can a PM determine how long it will take to build a feature? Software estimation is quite complex (let alone for those without engineering backgrounds), however, a PM can accurately estimate software using velocity. Velocity is the number of story points accomplished in a period of time. Confusing? Let’s take it back.
Story points are values meant to represent the amount of work required to complete a given task or feature. Different companies use different scales for story points. The PM should assign story points to every task in a sprint to generate a total score for the sprint. For example, consider a theoretical sprint where there were 5 items but only 3 were finished. Perhaps each task in said sprint was allotted 5 story points: 5 + 5 + 5 = 15. That sprint has a velocity of 15. PMs can use the velocity data of past sprints to calculate the average velocity and determine how much work can reasonably be accomplished in a single sprint. Still confused, no worries! Read more about velocity here.
There is no way I can squash everything included in this course into one article, but I’m going try my best. Some more key takeaways:
How to structure a hypothesis like a PM: We believe [subject] has a [problem] because [reason] . If we [action], this [metric] metric will improve. Note: All products (should) stem from problems.
PMs are responsible for feature triage and identifying what to build next. There are a lot of sources of feedback to filter through: internal feedback, user test data, online feedback, analytics/stats, news, market trends, watching competitors, customer interviews, WHEW! Make sure you understand the differences between qualitative vs. quantitative data. Note that customer interviews don’t directly scale (dozens of interviews don’t magically extrapolate to thousands of users.). Bottom line: decide which feedback is relevant and which is junk, then synthesize info. to make decisions.
A helpful framework for above ^ PMs are not tasked with coming up with the ideas, the ideas come from everywhere including (EMUC): E = employees, M = metrics, U = users, C = clients (applies primarily to B2B PMs). Note that a user is not always the same thing as a client.
User personas! These aggregates of observed user behaviour are often made by UX designers to build empathy for the user:
Hot Tip: Stay on top of industry news as a PM (a few minutes each day with a cup of coffee in the morning). GOOB (Get out of the building!)
Learn as much about technology as you can (particularly if you’re a SaaS PM) such as familiarity with programming languages and relational databases. The benefits of this extracurricular learning are HUGE:
MVP experiments generally accrue quantitative data (compare to qualitative data from customer interview). You must collect BOTH types of data. The quantitative data provides the what, the qualitative data adds the why.
Every company does roadmapping differently, but it’s important to note that they are inherently incompatible with an agile development process. After all, how can you be agile if you’re handcuffed to a roadmap? While they can still provide value, roadmaps are generally inaccurate. Why have them at all? Executives and investors like to see quarter-based maps of expected progress.
Failed products or features can still benefit departments of a company. For example, the Google Glass product probably lost lots of money but earned valuable press coverage and attention that positioned Google as a cutting-edge innovator.
When communicating with engineers be super super super detailed. If something goes wrong, it is your fault as the PM. When you’re pitching an idea, have a good idea of where the feature will go in the future. Watch out for tech debt which inevitably falls on the engineering team’s shoulders. Most importantly, do NOT treat like the engineers like an agency.
Remember this. Recite it every morning. Print it out and pin it to your desk. Get a damn tattoo. Find a solution for a problem rather than trying to fit a problem to a solution.
Course rating 5/5
That said, I advise waiting until the course is on sale to purchase. A lot of the information above can be found free online from disparate sources. In my opinion, the single, biggest benefit of the course is that all the teachings are condensed into one place.
Why 5/5? This course helped me understand the entire process of launching and iterating a product; the whole product lifecycle. It gave me a holistic view of being a PM and introduced me to countless new terms and resources. I would confidently recommend this course to anyone who is starting in a new product role or is curious about exploring the career. (Be sure to check out the bonus 17th section that includes interviews with working product managers.)
Side Note: One of my favourite aspects of this Udemy course was the articles linked to different lessons for extra reading. I bookmarked all the links for later reading.
**Note: Article originally posted on May 30th, 2021 on brandcereals.com, migrated to Mirror in Jan 2022