What I Learned from a Udemy Product Management Course: 13+ Hours in 13 Minutes
January 17th, 2022

I have a hard time sitting still, so I decided to supplement my quarantine time with lots of modern fiction novels and a Udemy product management course. Here’s what I learned from 13+ hours of content condensed into a ~ 13 minute post. Basically, my class notes.

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…

1. Lean vs. Agile Vs. Scrum vs. Kanban - What’s the Difference?

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.

  • Lean = A cost-effective development approach, involves prioritizing initiatives and avoiding spending BIG money on projects unless you absolutely have to. See “The Learn Startup” for more info. Think of it as DIYing a home improvement project rather than outsourcing to an expert unless required.
  • Agile = Generally refers to software/digital products specifically (compared to “Lean” which is not software-exclusive). “Agile” means to apply a lean approach to software, it’s an iterative method of grouping tasks into small batches and prioritizing top features.
  • Scrum = A four-step process of development that seeks to maximize efficiency:
    • Step #1: A sprint planning meeting that reviews the product backlog, prioritize features to move into the sprint backlog. Time to discuss scope of work.
    • Step #2: Start developing said product, most common time-box for sprints is two weeks.
    • Step #3: Daily stand-up meetings (idea is that standing will expedite meetings) of approx. 10-15 minutes to align the team and identify pain points.
    • Step #4: Retrospective meetings (opposite of sprint planning) to perform a product post-mortem: what went well, what didn’t? These are generally led by the PM.
  • Kanban = A framework for implementing agile software development; does not use sprints or timeboxes. Once a task is completed, start work on the next ticket from the product backlog. This system does not use sprints and is ideal for customer service teams.

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.

2. Five Key Criteria for Understanding Competitors

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:

  • Product Core: Who is their product team? Who makes the product: physical engineers or developers? How good is their product team? 1 great engineer is better than hundreds of ‘good’ engineers.
  • Size of User Base: Companies with a larger user base have certain advantages - when they launch into new markets they have the potential to dominate, an easier time getting press coverage, and they can strike deals with other companies more easily. For example, Apple easily entered the music streaming market to compete with Spotify and SoundCloud.
  • Design: Products that are aesthetically pleasing tend to be better received. For example, Apple is a threat to any market they enter because of their emphasis on design. Imagine the streamlined design of an Apple toaster…
  • Brand: Positive brand perception brings many benefits such as high prices, more press & funding, and the benefit of the doubt from consumers.
  • Speed: How quickly can your competitor build and ship new products? This is most relevant in situations where the competitor is significantly larger (more bureaucracy = slower, less agile).

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!

3. Feature Tables & How to Make Them

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:

  1. Funding. Watch out for venture capital in the startup space. More $$ = more people, more ads, more resources. Crunchbase will be your new best friend.
  2. Acquisitions: A company could be buying another company to acquire their product team, integrate their user bases, etc.
  3. New features/product launches: These are major maneuvers. Here, Mention will become your second best friend.

4. A Crash Course in Customer Development & Interviews

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:

  1. Exploratory Interview: Most free-form interview; the intention is to discover pain points, assess the urgency of a problem and evaluate potential customer segments.
  2. Validation Interview: These interviews are meant to test a specific hypothesis and are hyper-sensitive to bias. Avoid introducing your product idea until the very end (if at all), do not elevator pitch or hype your idea. Only honest feedback is helpful, junk data helps no one.
  3. Satisfaction-Oriented Interview: Designed to gauge the customer’s feelings about the product, ex. “What’s one thing I could do to make this better for you?” These interviews can reveal the priorities of your users.
  4. Efficiency Interview: Meant to discover how an existing product fits into a customer’s life, aka contextual learning. Often product features are used in unexpected ways. Watch how customers interact with your product and ask them to walk you through how they perform different actions.

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.

5. Hot Tips: Finding Interviewees & How to Cold-Email The Right Way

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:

  1. Be brief. Time is a precious resource and everyone is busy. Stick to 4-7 sentences. Seriously.
  2. Be personal. Avoid sounding like an auto-generated email. Easy tip: add context for how you found them (ex. via Twitter or customer support).
  3. Appeal to their self-interest. Cater to their sense of altruism (or incentivize monetarily). Give people a reason to help you.
  4. Schedule a specific time. Ex. 3:30 pm EST next Wednesday. Avoid the back and forth of scheduling friction. Level up with a calendar integration that allows people to pick available times.
  5. Frontload your email with a personal introduction to capture the reader’s attention before they send your message straight to spam. Bonus: clarify that you’re not from Sales (people may let their guard down) - assuming you’re not of course.

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.

6. All About MCSs & MVPs

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:

  1. What is the problem/solution? What is it addressing? (Hint: what is the experiment testing?)
  2. Identify the assumptions (find the riskiest)
  3. Build a testable hypothesis around your assumptions
  4. Establish a MCS (minimum criteria for success) - otherwise how do we know if the experiment has succeeded or failed?
  5. Pick an MVP strategy type (discussed in next section)
  6. Execute MVP experiment
  7. Evaluating and learning from the experiment

There are three possible outcomes of a MVP test:

  • #1 the hypothesis is proven false and future work in this direction is futile
  • #2 your hypothesis is true by a wide margin
  • #3 is somewhere in the middle

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.

7. Be the VIP of MVPs

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:

  1. Email MVP: Simplest of MVPs, it can take the form of an email that pitches a new product. This is especially easy to implement for established companies that already have a list of users. Unfortunately, this MVP can be perceived as sloppy and dent brand reputation. Email MVPs are best suited for smaller organizations without brand anxiety. Try pairing this with a landing page or concierge service (discussed below) for a better customer experience.
  2. Shadow Button MVP: Requires more resources than an Email MVP but is still relatively easy to pull off. Put a button in an existing (digital) product that links to the “new feature” and track the click rate to measure interest. A Shadow Button MVP is useful for mid-size startups to triage nice-to-have features. The downside? It creates a universally negative response and can confuse consumers. Avoid seeming like a bug by acknowledging/thanking users for clicking and strive to limit the # of users exposed.
  3. 404/Coming Soon MVP: The 404 and Coming Soon pages are slight variations of the same concept; both are webpages with a message (whether it’s the 404 error or a friendly “Coming Soon!”). Amazon uses this technique every day and tracks interest against their MCS (minimum criteria of success). Oculus Rift started this way with a pre-order page when all they had was a rough prototype of the product. Companies with tons of webpages can better get away with 404 pages (eCommerce). The best practice is to design the page that matches company branding; avoid generic templates and proofread, proofread, proofread. Like the Shadow Button, strive to shorten the horizons of this experiment to avoid users running into these pages repeatedly.
  4. Explainer MVP: A video-format MVP that either pitches a product (think Kickstarter videos) or explains a product tutorial-style. Dropbox started this way as the founder wanted to test if there was sufficient demand for cloud storage. Video generally converts users better than all-text pages and can go in-depth on features. These videos can be a lot of work to make unless you have the existing team/infrastructure to produce video content. However, if you’re a scrappy startup who hasn’t set a quality bar you can get away with a lower-quality video.
  5. Concierge MVP: Involves 1:1 support as you walk a customer through a task. Rent the Runway started this way. Major pro: there is no buildout required for this (compare to Wizard of Oz MVP.) The key is to be upfront that the feature is not yet built - you can frame the MVP as a beta program being offered to a small subset of users. This MVP form is commonly used by large companies as it can be run discreetly, involves no fake buttons (which can potentially reflect poorly on the brand) and serves as a hybrid between Customer Development and MVP testing. Note that this form is management-intensive + time-absorbing; you burn a lot of resources per customer so it’s expensive to get large data sets.
  6. Piecemeal MVP: Uses various out-of-the-box softwares to match the functionality you need to test the basic version of what you want to build; aka a Frankenstein prototype. Groupon used this method when they created their original WordPress site and harnessed Apple Mail to manage order & generate coupons. This MVP format is not ideal for implementing multiple functionalities; it can be challenging to get off-the-shelf software to cooperate with each other. Pro tip: use automations (like Zapier or Integromat) to chain softwares together. Look for softwares that allow white labeling so you can add in company branding for improved believability.
  7. Wizard of Oz MVP: This form has the illusion of being a completely made product but the tasks are actually carried out manually by an individual. This method avoids the engineering resource-heavy task of building out server-side logic. Zappos actually started this way; anytime an order was placed employees would buy the shoes from a brick-and-mortar store and mail them personally to the customer.

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?

8. 100% Important Info About Metrics

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:

  • Growth & Activation: Measure how a product is growing, can be used to assess the effectiveness of marketing funnels and SEO. For example: total new users (by week, month, etc), new users by source, activated users.*
  • Engagement: Very specific to each company, for example, YouTube considers 30 seconds of watching content = 1 view whereas Facebook counts just 3 seconds.
  • Retention: Who’s coming back? This is closely tied to Growth & Activation metrics. For example, retained users & resurrected users.
  • User Happiness: Examples includes MDS Scores, # of customers who have submitted complaints, App Store rating, NPS (net promotor score), etc.
  • Revenue: Potential metrics such as LTV = lifetime value (how much revenue does a customer generate over a selected time period, ex. 1 year), CCA = cost of customer acquisition. B2Bs often track MRR = monthly recurring revenue and ARRR = annual reporting revenue (crucial for subscription services such as Dropbox or Netflix).

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.

9. Building an (Epic) Product

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:

  1. An Introduction: A summary of what the features are, what metrics you are trying to improve, links to supporting documentation, legal requirements, marketing plans, a place for early wireframes - anything that supports your case, written by the PM.
  2. Product Requirements: This section includes details about functionality, also written by the PM.
  3. Design Requirements: To be filled out by the PM and the (UX) Designers, may include early wireframes/sketches/prototypes.
  4. Engineering Requirements: Mostly completed by engineers after discussing the above sections, this is the place for database/technology requirements, ex. a certain API endpoints.

PMs are responsible for creating/maintaining these requirement sheets, specifically the first two sections.

10. A Few More Key Concepts (and 10 is a nice #)

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.

Other Useful Nuggets of Wisdom

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:

    1. Interview a large # of users
    2. Identify a user behaviour
    3. Write a description
    4. Give the user background info. (add a photo or sketch!)
  • 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:

    • You’ll know what can be realistically built (learn to estimate difficulty and timelines for building features on your own)
    • It builds strong relationships with engineers (and boosts your credibility)
    • You will better understand the impact of your decisions and the long-term technical implications (*shivers* tech debt)
  • 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.

Final Verdict

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

Subscribe to Brand Cereals
Receive the latest updates directly to your inbox.
Verification
This entry has been permanently stored onchain and signed by its creator.
More from Brand Cereals

Skeleton

Skeleton

Skeleton