How would most beginner product managers handle frameworks as compared to experienced ones?

[HerbertWarnick]

IMO, a product manager with more experience might be more likely to build from an existing framework which includes documentation and a community that can provide answers. An inexperienced product manager might be at a disadvantage, as it is harder to find resources when starting out. In the app world, there are a lot of products and choices out there, so it’s hard to know what the best ones for a team are to start with. This is why expertise in your area is important. Product manager for an app or web-based product experience. The ability to build and launch an MVP (Minimum Viable Product) from scratch is a central and important skill for a product manager who works on apps or websites.

What do y’all think?

Thanks in advance.

[MaireHamilton]

Beginner product managers may struggle with using frameworks because they may not fully understand the purpose and value of the framework or how it should be applied. They may also lack the experience needed to adapt and customize the framework to fit their specific product and situation.

Experienced product managers, on the other hand, have a good understanding of various frameworks and have likely used them in the past. They are able to use the framework as a guide, but also have the experience and flexibility to adapt and customize it as needed. They also have a good sense of when a framework is the right tool for the job, and when it is not.

Instead of trying to force a framework to fit their product, beginner product managers should start by understanding the purpose and value of the framework. They should also seek out mentorship and guidance from more experienced product managers on how to apply the framework to their specific product and situation. Additionally, they should be open to trying different frameworks to find the one that works best for them and their team.

[MatthewShun]

Yes, that’s correct. An experienced product manager is more likely to have a good understanding of the various frameworks available and the benefits and drawbacks of each one. They are also more likely to have used a framework before and have a sense of what works and what doesn’t. They can leverage the existing documentation and community support to quickly ramp up and understand the framework. This allows them to focus on applying the framework to their specific product and situation.

In contrast, an inexperienced product manager may struggle with finding and understanding the right framework to use, as they may not have the same level of familiarity with the available options. They may also have difficulty finding the necessary resources and support to implement the framework effectively. This can add extra time and complexity to the product development process.

In summary, experienced product managers have an advantage in that they can use the existing framework and community resources to quickly ramp up and apply it to their product, while inexperienced product managers may struggle with finding and understanding the framework.

[BobbyDuncan]

Well, before comparing the frameworks being handled by newbie PMs and the experienced ones, let’s take a look at the different frameworks. There are several frameworks that product managers can use to attain best stakeholder satisfaction:

The Kano Model: This framework helps product managers to understand and prioritize customer needs by categorizing them into three categories: basic needs, performance needs, and delighters.

The Value Proposition Canvas: This framework helps product managers to understand the needs of their customers and how to create value for them by mapping out the customer segments, pain points, and gain creators.

The Stakeholder Map: This framework helps product managers to identify and prioritize different stakeholders and understand their needs, influence, and interest in the product.

The Jobs to be Done Framework: This framework helps product managers to understand customer’s underlying needs and motivation for using a product by focusing on the job or task they are trying to accomplish.

The RICE Framework: This framework helps product managers to prioritize and prioritize features by evaluating the potential impact, confidence, effort, and urgency of a feature.

These frameworks can help product managers to understand customer needs and prioritize the features that will best meet those needs, which in turn leads to stakeholder satisfaction. It’s important to note that the selection of the framework depends on the product, team, and the customer needs. Product Managers should evaluate the suitability of each framework for their specific situation and use it accordingly.

[EvaRichardson]

Some other types of Frameworks are:

Information Architecture: Organizing the Product for User Interaction. This framework can help product managers with information requirements and prioritization of features that will best satisfy customer needs. Strategic selection of these features will result in revenue generation and user satisfaction. Key components in this framework are personas, use cases, feature maps, wireframes/prototypes. and content discovery.

Wireframes/prototypes: Wireframes and prototypes are low-tech tools that can be used by product managers to present their ideas. They are a very fast, low-investment way to get feedback on an idea or concept, allowing team members to include design suggestions in the wireframe/prototype itself rather than requiring them to rely on a separate graphic designer. Wireframes give directions for how the interface should look before development, whereas prototypes are more of a rough draft for developers and designers to work from. In general, wire frames should leave lots of room for user input; designs will have to be refined and changed as the user involvement changes.

User test: A mockup is created that simulates how a user should interact with a site. Prototyping: This is the process of creating early-stage designs for an interface or product, typically through paper and images, which can then be used to determine whether there are any problems with a design concept before continuing development.

[Luisneilson]

You are right. Beginner product managers may be eager to make an impact and show their value, but this can lead to them not taking the time to understand the current situation and the reasons why things are the way they are. They may come in promoting a “new way” of doing things without fully understanding the existing systems, processes, and challenges. This can lead to resistance from the team and stakeholders, as they may not see the value in the proposed changes and may be skeptical of the new PM’s understanding of the situation.

Instead of immediately promoting a “new way,” beginner product managers should take the time to understand the current situation, the team and company goals, and the reasons why things are the way they are. They should establish rapport with the team and other stakeholders, and work to understand their perspectives and concerns. Only then, they can propose new ideas and changes that are aligned with the team and company goals, and that take into account the existing systems, processes, and challenges.

By taking the time to understand the current situation and building rapport with the team and stakeholders, beginner product managers can create a more solid foundation for their ideas and changes and increase the chances of success.

A seasoned PM would take the time to understand the current situation and the goals of the team and the company before diving into the product development process. They would also take the time to establish rapport and credibility with the team and other stakeholders, this is key to building trust and alignment throughout the process.

They would create a clear vision and strategy for the product and communicate it effectively to the team, this would help to create momentum and alignment. They would also be skilled in managing the team’s expectations and keeping them inspired and motivated as the product development process moves forward.

Additionally, A seasoned PM would also be able to anticipate potential roadblocks, and have contingency plans in place. They would also be able to manage and balance competing priorities, and make decisions that align with the company’s overall goals and objectives.

Overall, a seasoned PM would have a holistic approach to product development, taking into account not only the product itself but also the team, the company, and the market. They would be able to lead the team and stakeholders through the product development process with a clear vision, strategy, and effective communication and leadership skills.

[DianneStinger]

I let everyone know I want to set up a quick 1:1 when I join a new team. I offer open-ended questions to get to know them, such as how long they’ve worked for the organization or been on the team, etc. Inquire about their hobbies, childhood, or whatever else.

But in that first 1:1, I make sure to cover the following points specifically and explain that I always want the folks I work with to be aware of this information:

They possess knowledge, abilities, and expertise that I do not, and I will always be appreciative of their suggestions for making the final result as outstanding as it can be. (I tailor this based on the person’s function and the kind of input I’ll value from them; while speaking with engineers and designers, I frequently emphasize that I’m open to input/feedback/questions on things that are “out of their zone”).

Because I can only learn how my work is assisting or hindering them in their employment from them, I highly welcome comments. Additionally, the quicker and more direct the comments, the better, as I can quickly take it to heart and adjust.

Any background information on the team or the product that they believe I should be aware of as I acclimatize? (This one can reveal some true jewels and be quite helpful.)

In light of the current circumstances, how do they think I can best assist the team?

I will often, if not always, avoid using the word “requirements” when speaking to designers and engineers, explaining that it is my responsibility to conduct research and make final decisions on the product side. The only absolutely necessary things (tax, legal, compliance, etc.) are those, and the rest is up to us to decide what the greatest thing to build is.

Discussion objectives:

• Assure them that I’m a helpful person who isn’t a jerk.
• Ensure that they will feel secure working with me.
• Make sure that no issues or conflicts come up in our first 1:1 conversation so that we have some relational capital to draw on if they do.

To ensure that this process can continue on a regular basis, I usually set up a recurrent 1:1 with important teammates (such as the lead or main engineer).

[AnushkaGarg]

Right on @DianneStinger! You did a great job of summarizing this!

But a small piece of advice here. IMO, follow this path with caution. Even though it sounds great and lots of people are attempting it, if done incorrectly, you could come off as someone who is looking for someone to take advantage of. In these sessions, the PM usually drones on about their list of credentials or gives the other person the impression that they are in an interview.

[ElvinHenriques]

Not the commenter you replied to but sharing my 2 cents anyways: I usually attempt to work toward making team members appear good to their superiors when developing that initial rapport when placed on a new team, especially if it wasn’t necessarily yours or the team’s decision. (And as time passes, continue to do so for others who are helpful and/or kind to you.)

This means that compliments are offered both publicly and privately when appropriate, and that criticism and conflicts are addressed quietly wherever possible. Basically, demonstrating via one’s actions that one hopes to present a unified front with the other members of the team and lessen everyone’s daily stress than it would be if you weren’t there to assist them.

[TerryAnthony]

I love this advice @ElvinHenriques! Especially about making other team members look good. It costs you nothing but wins you an ally that you will be able to rely on.

[ElvinHenriques]

Thanks @TerryAnthony. Additionally, it makes for a pleasant workplace for everyone! When my older coworkers show signs of confusion about something with Jira, I personally enjoy spending a little additional time coaching them since it’s so rewarding to see the joy in their eyes when something that has been puzzling them suddenly makes sense.

And then those same coworkers will gently suggest to me via private conversation that perhaps I should reconsider my decision because [reasons] in order to not undermine or disgrace me when I’m being an idiot about anything (eventually happens to all of us!).

Working with established trust is considerably more pleasant than having everyone constantly watch out for one another.

[TerryAnthony]

@ElvinHenriques. Your interaction with your complimentary engineering manager(s) is crucial in my opinion. Make friends with them, learn about their problems and how you might help, and ask them what they (and the team) believe to be important. Often, their priorities will coincide with your own.

Keep track of your victories so you can celebrate/grow as a team and play them back to the team. Try to simplify everything for yourself and your peers. As others have stated, do so carefully.