There are a variety of Product Management Methodologies out there. Most commply used systems are the LEAN, SCRUM & KANBAN software delivery methodologies which form part of the AGILE Development Framework Methodology.
Essentially, there isn't one perfect methodology out there. Just like there is no definite course, or defined structure on how a Product Manager Role is to be executed, the same rationale is experienced here.
Both the Product Manager Role and the Methodology used may differ from team to team, product to product, and even company to company. What tasks as a Product Manager you may have executed at Company ABC may be the total opposite to what you would be required to do at Company XYZ. Potentially, this is one of the great aspects of being a Product Manager. You work in an autonomous manner, working around the team, the product and the company to achieve a set of goals, which are KPI or metric-based. How you go about doing this is up to you, just do it!
In its purest and most simple form, the Agile delivery framework is based around the following throughout the product development life cycle:
Stakeholder Engagement - Involving the right people from day 0
Communication - Clearly commnicate and provide clarity across all stakeholders
Prioritisation - Clearly define the Minimal Viable Product (out of 10 features, 2-5 may actually be MUSTs)
Iterative - Frequent delivery of products (Promoting prototyping)
User Involvement - Involve the end user early in the cycle
LEAN Product Development - This process is typically embraced and utilised by the very early start-ups who typically have little to no capital or investment opportunities. LEAN specifies to be intelligent, to focus on creating an MVP whilst not haemorrhaging any monetary resources. Simply put, building the first prototype yourself, or with a group of people who may have embarked on a journey with you, therefore building a product or company without the need of financial resources going towards other third parties.
This methodology is not typically used amongst more mature and larger organisations, although it may be used on something very innovative and futuristic to solely identify if the product is fit for further R&D.
SCRUM Product Development - SCRUM is the more disciplined approach from the 3. SCRUM is mainly made up of the following disciplines:
Daily Stand-ups - The Product Team hold a 10-15 min daily 'washup' meeting simply to empower and motivate communication, clarity and time to highlight at high-level any risks or concerns for the SCRUM (Product) Owner and SCRUM Master to tackle after the meeting
Sprint Planning - Every feature not definend in detail is in a Backlog. A backlog contains all the features, changes, bugs, etc pertaining to the Product. Typically, a backlog is never ending and constnatly being updated - which is known as a healthy backlog, depicting change is constant. Therefore, a Sprint Planning session is the process of choosing which features to work on, and placing them into the sprint backlog. All features placed in the sprint backlog would be planned for the next Sprint.
A Sprint - The term Sprint is a term used to define a start and end date of the product team being in development. Some comapnies/teams may also refer to this as a time-box, although Sprint is more used in the SCRUM methodology. Typically, a Sprint commonly lasts for around 2 weeks, although may be stretched to 3 and even 4 weeks. Inevitably, every feature going into the sprint would not exceed the 2, 3 or 4 weeks worth of effort (based on the amount of resources a team may have). Such disciplines provide control and visibility on when features would be marked as done.
Sprint Retrospecitive Meetings - Ideally, after every sprint, the product team get together for an hour or two to disucss the last sprint, pretty much like an After Action Review. Discussing what may have gone wrong, and why. What may be improved for the next sprint as well as what elements, decision may be done differently. Just like everything in life, experience is the toughest teacher of all, providing the test first and the lesson after. Lesson's learnt amongst software product teams (and projects in general) is generally a great source of information for whenever requring to make decisions on future products.
KANBAN - Really is a mix between SCRUM and LEAN. Kanban relaxes the highlighted disciplines in SCRUM, whereby it typically uses 'cards' which would contain one feature in its most granular form. Each card is placed in columns, Starting from a To Do, to In Progress, to finally Done. This methdology does not enforce daily meetings, planning or even some form of visualisation plan. Solely letting the product team take the time they need on the individual task and get it Done in time.
Potentially, I envisage such a methodolgy to be used amongst very small teams where the Product Manager can clearly handle the small amounts of features, slowly being provided to the product team, knowing in what state every feature is in.