At the end of January, I’ll start a new job as a L7 (principal product manager), therefore I’ve been honing my abilities lately. With so many frameworks, reading this sub has been both great and strange. Although I’ve found plenty that look intriguing, I’ve only really used four frameworks in my career to date.
Although I don’t want to admit it, there are times when I feel like half the users on this site are more knowledgeable about frameworks than I am.
Am I missing something? Or do the majority of people settle on three to four frameworks and stick with them? I would also appreciate any tips on how to be the best L7 possible.
This serves as a filter for inquiries, suggestions, etc. Although roadmaps may have a future focus, we try not to begin development on anything that is not regarded to be absolutely important in the upcoming six months. Product to product will differ in what that actually implies, but the process is what matters. Don’t design items based on what you think potential customers will require in the future. Build them based on their current requirements. Some people assume that you are perpetually behind, although that’s usually not the case.
Since of this attitude, you are frequently forced to release MVP features and iterate because you have customers who, in theory, have a true need (or there is some other compelling reason),
A model is a framework. While all models are imperfect, some are however helpful. There is no one ideal framework for product management because it deals with such a broad range of circumstances, including technology, markets, lifecycle stages, and governance models. I always begin by comparing a variety of frameworks, choose the one that comes the closest, and then add or delete components as needed. Please make an effort to refrain from dictating a specific framework for your reports.
I believe frameworks are best used during interviews. That crap is never used in real life. Decisions are made in a far more random and arbitrary manner.
I disagree. It’s true that when developing a new feature and providing a “final recommendation on what to construct,” you generally won’t mention GAME, for example, directly.
However, frameworks like user story mapping, continuous discovery, and product principles are all widely utilised today.
Additionally, frameworks don’t have to be formal. When performing a straightforward value/effort analysis, you always employ a very basic but efficient paradigm for ranking.
@DhirajMehta, In terms of how I actually experienced it, I believe you said it best. The three frameworks you listed are among the basic ones I use, and they are all ingrained in my routine procedure.
The sheer number of frameworks that seem to be variations of the main ones I use simply surprises me more, I suppose. They all strike me as being a little too planned and formal for my tastes, but perhaps this is the norm these days because of the way lower-level interviews are performed.
In terms of how I actually experienced it, I believe you said it best. The three frameworks you listed are among the basic ones I use, and they are all ingrained in my routine procedure.
The sheer number of frameworks that seem to be variations of the main ones I use simply surprises me more, I suppose. They all strike me as being a little too planned and formal for my tastes, but perhaps this is the norm these days because of the way lower level interviews are performed.
I agree that decisions are frequently made hastily and arbitrarily, but I would equally add that decisions are frequently made incorrectly. Although there may not be a framework that is ideal in every situation and there is sometimes not enough time to consider frameworks, in my experience, settings without frameworks are rarely successful at scale.
I disagree strongly; although I don’t use frameworks for every single decision, they are crucial for major ones. Not so much for strictly adhering to it, but more for inciting the appropriate discussions about what the primary user need might be and other ways to address it (JTBD), or for comprehending the dangers involved in doing nothing at all (cost of delay). Although it is not required to quantify these frameworks to the nth degree, they do assist in catching assumptions and bringing to light information that could otherwise remain concealed.
Excellent question! I’ve often thought the same thing and understand the sense of inadequacy that comes over me whenever someone brings up a framework I’ve never heard of.
Even though I don’t consider myself to be a very skilled PM just yet, here are my two cents:
Frameworks are helpful because they frequently alter your perspective and prompt you to do tasks that you may otherwise forget or skip.
Let’s take the scenario where you were developing a new product concept and were primarily concerned with getting user feedback and developing a convincing value proposition while assuming that the proposed solution was financially feasible. A short glance at the well-known “Desirability, Viability, Feasibility” venn diagram from the Lean Startup framework may serve as a helpful reminder to take the time to research Viability before spending excessive time on a product that will never be profitable.
It rarely makes sense, in my opinion, to follow any one framework religiously, and doing so can occasionally restrict progress and agility. However, it’s beneficial to be familiar with a few frameworks and to regularly apply them to your product to determine whether you’re on the correct trajectory. Depending on what feels appropriate for a certain circumstance, I like to borrow elements from several frameworks.
Be familiar with as many as you can. Only apply as or if appropriate. They are useful guidelines. There’s an old expression that goes something like, “Most models are wrong. But some are useful.” Those who ignore them completely - my opinion - disrespect the role as a craft and depend more on being lucky than being smart. Which isn’t to say they’re not smart. They probably are; maybe very much so. They’ve maybe been fairly successful with native intelligence and intuition so maybe they choose to ignore the more formal structures. I still believe you end up limited by limiting your toolsets and therefore likely circumscribing your viewpoint(s). Frameworks are just different lenses with which to view the world. And when you use different lenses, you tend to see different things.
My favorite metaphor is that among my too many hobbies is woodworking. I build fine furniture. I’ve got probably 10 different ways to cut wood and 6 different drills. Technically, I could probably do most cuts with my jigsaw alone. But really, the table saw is best for precision rip, (long), cuts, the miter for cross, angles and bevels, etc. etc. Same for drills, etc. etc. Sometimes I’m missing a tool and have to get creative. Or there’s no good tool for the task and you just have to sort something out.
Sure, you need skills to use the tools and with practice that comes. But even choosing which tool is part where the art meets the science. That is, intuition and judgement still applies to select the thing with which you’ll go deeper with more rigor. Over the past handful of years I’ve been working mostly in healthtech related areas. So I try to have some rigor in approaches; regardless of which approach we’re using. Because screwing up is not going to be just about some ad slots not firing or some lost sales. People can get hurt. So the category you’re dealing with maybe makes a difference in your approach as well. MVP for a new content site? Maybe fast and loose is fine. But even a basic product in a highly regulated industry like finance or healthcare maybe requires something more formal. All your choice. And consequences.
Really, you’re question is about what you see as a certain level of professionalism with your craft. It’s your choice. The Body of Knowledge for Product, (as with everything else), just keeps growing. So it’s unlikely any of us would master them all. Nor do I believe we have to. So I end where I began… Be familiar with as many as you can. This way, when you’re faced with a challenge, you can say, “You know, THIS tool might work here.” Then you can dig in a bit deeper. But you don’t necessarily have to be an expert on every single one of them all the time.
I think there are a lot of persistent themes in frameworks, adjusted slightly to prioritize different outcomes in your solution. They are most helpful as patterns you can apply to problems then prescriptions. No one has applied them exactly as they are written on the blog post, even the company who wrote the blog post. (Looking at you Spotify model).
Kanban is focused on continuous flow, scrum is focused on creating time-boxed feedback cycles. Both are looking to increase the speed you can arrive at a solution. Same story for the scaling frameworks, all looking to have a pattern for keeping multiple teams focused on larger outcomes and moving everyone in the direction that is important for the business. Some are more interested in managing dependencies than others and some are more or less centralized.
The important thing is to understand the framework and your business context well enough that you know when to apply which framework and when to apply it as written vs modifying it to fit local conditions. I would expect a principal pm to be able to do that effectively and explain why they are deviating from a framework that is in place and be able to start combining frameworks to get the parts that are most helpful.
I do think frameworks are helpful as a form of recommended practice and as patterns you can use as shorthand without having to explain everything from scratch. It’s much easier to say “we do Kanban with this modification” than explain what Kanban and your modification are from the ground up in every conversation.
Frameworks are excellent for giving structure to your ideas and communication style, but if you rely on them excessively, you risk losing trust because inexperienced talent tends to overuse frameworks.