Frameworks are no checklists but mental crutches
By over-relying on single frameworks we loose our ability to critically think.
As product managers, we love frameworks and checklists. However, it is important to understand that frameworks are not checklists. It is important to understand the difference between those two and the real purpose of a framework. Checklists are complete and prescriptive. Take the example of a pre-flight checklist. It should include all vitally important functions of the plane and give explicitly or implicitly clear instructions on how to test it. Another example would be the assembly instructions from a piece of furniture, which should tell you exactly what to do and, eventually, should lead to a fully assembled piece of furniture.
Checklists can be a tremendously powerful tool, especially regarding quality and consistency. However, checklists fail in complex environments. There, a step on the checklist might work only every other time.
The more fuzzy an environment or problem, the less likely it is that you will find a suitable checklist.
Frameworks, on the other hand, exist to frame an otherwise fuzzy problem, turning naturally ill-structured problems into structured ones. This is tremendously valuable for any management profession that needs to tackle complex issues. However, we need to keep a few things in mind:
Frameworks are always incomplete. A framework is always a simplified version of reality. As a consequence, no framework can claim to be always right. So, we should consider if the assumptions of certain frameworks are being met.
Frameworks frame (duh ?). That means we need to be careful when considering which framework we use as they might favor specific solutions, neglect or oversimplify certain factors, or they might be suitable for specific decision altitudes. For example, the business model canvas is great when it comes to developing a product from scratch with a new business model but becomes quickly useless when the business model is fixed, and the product needs to be optimized through marginal improvements. Another example would be the breakdown of cost and profit into its different types and drivers, as often used in consulting job interviews. This framework might be great for identifying optimization potential but falls short regarding innovation, especially disruptive ones.
Knowing the principles and theory behind frameworks lets you know when to adapt or ignore them. This seems to be tough to swallow regarding agile development methodologies, which are essentially frameworks. But understanding the intent and reason for, for example, Scrum meetings makes it sometimes obvious to identify when to disregard them or even Scrum altogether. Or, lo and behold, combine frameworks if you feel it helps you develop better solutions. Personally, I once introduced a heavy mix of Scrum and Basecamps Shape Up. On a product level, we prioritize on a theme level representing either one epic or a bundle of thematically related epics. This theme is being prioritized and fixed for 6-week cycles, and we were very strict about not altering the foundational priorities of topics that are already in development. The breakdown of themes into stories is then done in a Scrum manner. Stories are collected and prioritized in a backlog and pulled into our biweekly sprints, and we are honestly very quick to alter sprints whenever necessary. Most of these changes originate from inside the team or from new "insights" like having severe bugs in production, but are never triggered by a stakeholder's new feature request.
I find this differentiation worth mentioning because frameworks are treated like fanatic religious beliefs way too often. Many SCRUM practitioners and SAFe opponents are prone to overvalue their framework and become too rigid in their application. The same goes for debates around the superiority of growth loops vs. funnels. Sometimes, using different frameworks on the same problem can open up new perspectives on a challenge, mitigate each other's blind spots, and generate a more complete view of the problem. But we should always see them for what they truly are: Intellectual crutches. We use them to get a hold of intellectual ground we otherwise are overwhelmed and unable to stand on. However, over-relying on crutches deteriorates our capability to think critically and entices us to apply them more often than they are fit.