15min daily standup (can be call or on slack). Purpose: highlight and remove issues and blockers. Everyone can be silent if there are no issues or blockers.
Grooming:
Sprint Planning:
Retrospective:
Post Mortem:

I also write Epics and break those down into stories, and engineers break those into tasks (often within Jira, but you can do this on many other project management programs as well).

Agile versus Waterfall

In the era of CD roms being how you install and use software, development teams would build in a waterfall method - spend years building a complete product and ship it AFTER each and every “needed” feature was complete. This way of building can lead to massive issues in that the development team already spent all that time and money upfront, and the adoption of this software isn’t at all guaranteed. And, the way the software was built is potentially in some cases not tested enough to ensure the usefulness and accuracy of the software.

Those issues with waterfall gave way to the Agile methodology. Some engineers got together and signed an Agile manifesto (https://agilemanifesto.org/) where they laid out a faster, more iterative methodology that could be used to build better software faster. And, the most excellent software teams on the planet tend to be Agile teams.

Scrum and Agile go together but are not the same tool. But, combining them leads to the best results from my experience, especially when you are dynamically applying the guidance of Scrum. You need to adapt the Scrum ceremonies to the team and situation you are in today to make it work. By the book is not the most successful way to run living and breathing teams. And, over time, even the same team may enter a new situation and the ceremonies may need to be adjusted again. So, word of the wise, no one wise will suggest implementing scrum by the book. If they do, send them this write up AND this link.

On the Product Role

As a Product Manager, it is my role to learn from customers (internal and external), product usage data, financial data, and the confluence of all the above mentioned data, as well as competitive research and insights to determine WHAT the company’s technical resources should be focused on to add the most value NEAR and eventually FAR term. I determine WHAT our goals should be and WHAT that means (in terms of dollars and metrics). And, then WHEN, or in other terms, outline PRIORITY - what sequence should things be built for. And crucial to communicating the WHAT we should focus on and the WHEN, I need to clearly communicate the compelling reasons WHY I decided the WHAT and WHEN and make a clear case that stands amidst complex counter-points that are also steeped in reality.

The other important part is HOW. I have opinions on this held very loosely, because I empower my design and engineering partners to inform that most of the time. But, from time to time, as the owner of the consequences of what we ship, I will need to make some specific recommendations by creating strong arguments in terms of HOW we build things - but this is done very rarely.

Framework I use for determining WHEN / PRIORITY:

BROKENNESS!

This is the emergency rating based on whether something being broken or poorly executed stops business or makes doing business SO DIFFICULT that it is basically stopping business. OR the brokenness, whether a bug or poor execution/design = we are having issues that lead to any of the below pillars to crumble.

Revenue

How does something increase or decrease / hurt revenue growth?
This tends to be the most exciting category for every product team I have been in - this is where most business leaders are most heavily persuaded to focus attention

Volume

Of customers or issues or errors or accounts, etc.
How many users / people, how many companies/ accounts, are affected by this error? Or, out of all of our errors, how many are attributed to this reason? Or when something bad happens, to how many people or accounts is this happening to? Or of all the times an action is attempted or taken, how often is a bad thing happening instead?
And, does any of this tie back up to revenue risk, loss, or gain?
Numbers AND rates often are most effective in tandem, as in 1000 users = 50% of customer population, and puts 1000ppl X their revenue at risk. That is $X of our $Y revenue at risk.

Pain

It is too cumbersome to take a necessary action for customers - just the action leaves a sour taste in our customers’ mouths. OR it is so painful, they would rather use other tools than ours if they could for this job. OR, maybe they have to use a different tool to do something, but they NEED data from our platform to do it, and exploring is painful, or we don’t export the correct, needed columns, or not in the correct order, which creates loads of manual work, etc.
This category is usually representative of poor execution or under-execution or lack of scope that is now leaving a gaping hole in a significant workflow for customers. These types of issues can link to volume and revenue to highlight opportunities to prioritize in order to retain customers or build for strong product adoption.

Sequencing Benefits

Once we know what we should build and in what priority, we then may need to re-arrange these items slightly merely due to the benefits of sequencing, or building one thing before the other, whether it be foundations for future features or products or de-risking an investment to ensure we’re building it right or fully understand the WHAT. This is often where technical requirements are most impactful - to do X we need to have Y in place to support X functions. So, in this category, we are often making technical trade offs to ensure we’re not building on shaky foundations, running way too far into risky territory, or simply building an important part of a feature but without the under-pinnings of the feature that make it valuable.

Resources on Project Management:

Asana guides: https://asana.com/resources/project-management
https://miro.com/blog/

Project Management tools:

Jira (by Atlassian) - used by most engineering teams but not at all the “best”: https://www.atlassian.com/software/jira
Asana: https://asana.com/
Notion: https://notion.com/
Miro:https://miro.com/
Clickup: https://clickup.com/
Trello: https://trello.com/tour
Monday.com: https://monday.com/
Hive: https://hive.com/

Resources to help you get in the mindset and build a strong Product Leadership career

Become a Product Manager

Books I loved directly about Product Management:

Books indirectly awesome for life and product mgmt:

Podcasts that may help cultivate product sense and business vocabulary:

Scrum + Agile Guidance from me + stuff you can read:

Agile versus Waterfall

On the Product Role

Framework I use for determining WHEN / PRIORITY:

Resources on Project Management:

Apollo.io Product Pivot Process