Product Frameworks
After graduating with my newly minted degree in computer engineering, I was ready to use everything I had learned in undergrad to solve problems, build amazing software, and write thousands of lines of code. The only problem was that while one of my favorite classes was algorithms, I didn’t really have the experience to see similarities in software problems and common approaches that a particular problem dictated. This is where a book that was quite popular at the time, Design Patterns by the famed ‘gang of four’ came to my rescue. The book had been out for about 10 years by the time I graduated from college. It was filled with amazing nuggets of knowledge aimed at breaking down common problems found in software development. An added bonus was that the book also allowed developers to communicate with each other more efficiently as they could now describe a problem according to what design pattern it matched.
After I had a few years of software development under my belt, I started to see software patterns, problems, and approaches more clearly. However, I also started to feel a bit constrained as I wanted to use each pattern as it was proposed but sometimes I had to adjust the pattern slightly or mix it a bit with other methods. I wanted to be more creative with my software development skills and feel less constrained by the design patterns. The problem I was running into was that I sometimes found problems that didn’t fit nicely into a specific design pattern. This meant that I would try to see if I could force it into one of the patterns which led to more complexity (the opposite of the intent of a design pattern). Ultimately, I realized that design patterns are a fantastic starting point in any software development endeavor and they also help train software engineers in algorithm construction. However, it is important to realize that the design patterns should not restrict thinking and it is okay to veer away from a design pattern in favor of a solution that fits the needs of the problem. Upon this realization, I implemented this approach for many years as a developer before I transitioned to the world of Product Management.
As I started out in Product Management, I came upon a familiar scenario. Frameworks. Product Frameworks are to Product as Design Patterns are to Software Development. As such, I found Product Frameworks to be a great starting point as I grew in my product experience and skill. If I needed to prioritize features, there was a framework for it. Roadmap presentation and development? No worries, there was a framework for that too. What about product discovery or user surveys? Frameworks existed for those too. Frameworks helped me to think differently about Product and learn from those before me in how to think and act like a Product Manager.
Over the years, as I grew in confidence and experience as a Product Manager I started to feel the same way about Product Frameworks as I had about Software Design Patterns. This is where I find myself today, I believe in Product Frameworks in the same way I believe in Software Design Patterns. However, I feel as though they should be viewed as a base from which product managers can approach their particular problem or need. Product Frameworks can help kickstart your product learning whether it is prioritization or roadmap development or putting together a journey map. Product Frameworks also serve as a method to quickly communicate an approach with fellow product managers and stakeholders. Further, you may find that a particular product framework holds the exact solution to the problem you’re facing as a product manager and helps provide a fast track to resolution. But, one thing to keep in mind and be okay with, is that sometimes these frameworks might not exactly match the product problem you’re facing. If this happens, you’ll need to be a bit flexible with your framework utilization and perhaps mix and match a few frameworks or throw in your own creative solution to help get to the finish line.
As you dive into all the amazing Product Frameworks that are available, try to think about why that framework was designed. Who would benefit from it? What types of problems does it solve? Then, building from these observations, try to see if there are times when a bit of creativity is warranted. Be sure to study the frameworks and understand why each one exists. Then, as you gain experience, use this knowledge to grow and perhaps tailor frameworks to your needs. It is important to respect product frameworks for what they are and what they provide, but you shouldn’t feel constrained by them - rather, keep an open mind with each new product problem you face and remain flexible as you grow in your product career.