Cracking the PM Career: The Skills, Frameworks, and Practices To Become a Great Product Manager (Cracking the Interview & Career)

A huge part of your early credibility will come from your direct knowledge of the customer.

Development is where you turn the ideas into working code.

Notifications. The best kind of notifications let people know that something they were waiting for is available. Perhaps they were waiting for a coworker to complete a task or for their food to be delivered to their door. In these cases, people would be frustrated if you didn't notify them. People might also opt-in to reminders to use your product

Every Friday afternoon, the product management team and other interested folks from the design, research and analytics teams sit together for an hour and "tear down" an interesting mobile or web app. By "tear down," we don't mean "criticize", but rather investigate and reverse engineer the thinking and experience under

Always start with the goals: Taking a few minutes at the beginning of each piece of work to get everyone on the same page about why you're doing it and what you're hoping to accomplish can make a huge difference in your success. Frequently revisiting the goals not only keeps people on track, it helps morale as well!

One thing you should not do is cut out polish.

Here are some common areas for assumptions that are worth validating: Why users choose your product over an alternative Which features are must-haves vs. nice-to-haves How much time and attention users put into learning the product The impact of "minor" usability issues The discoverability of a feature The extent of the inertia to begin u

Common tasks during the develop phase include: Writing stories or tickets for engineering Determining which metrics to instrument and track Triaging bugs Checking in with teammates regularly to unblock them Trying out each feature as it's being built and giving feedback Keeping stakeholders and approvers up-to-date

Here are some different approaches for splitting a product into multiple releases: By risk tolerance and friendliness: Start by releasing to users who can tolerate the most bugs, missing functionality, and UI hurdles so you can start getting feedback before all the polish is added.

By customer type or use case: List which requirements you need for each, then look for a list that's short and mostly a subset of things you need for your higher priority use case.