I am an accomplished Product Management expert and instructor. After working 15 years in small and FAANG companies, I moved on to helping others excel in their product career. My online courses were attended by over 20,000 people, and hundreds of them got a new job thanks to my help. I am also a co-author of a best-selling book, "Next-Gen Product Manager," and a successful live event speaker.

I'm currently focusing on growing my Newsletter, tending to live cohort training I lead with Aakash Gupta, a fellow product creator, and growing as a speaker and in-house trainer for companies that seek my help.

If you need my help, make sure to contact me today on LinkedIn or email me at contact@drbartpm.com.

Do you also panic when you see your new product's backlog for the first time? Here are 8 steps to make it your own and shiny:

1) Really, don't panic
It can look scary and overwhelming initially. Don't worry, it will get better in time; it just needs time. Rome wasn't built in a day, nor was it refurbished in a similar time span. It will be nice and shiny in a little time!

2) Let it go for a sprint or two
While you adapt it to your vision, just start with using whatever's on top. You need time, and the work on top of the backlog will usually be the most polished. 

3) Start clearing poor quality from high-quality epics
Look for stuff that is months, if not years old. You should be able to quickly identify obvious trash, i.e., feature requests from people who already left the company.

4) Shorten the backlog to a manageable number
I believe that I read in the Scrum Guide that 50 is the maximum you should aim for. Anything beyond that is simply a lie. Keep the 50 with a FIFO mentality.

5) Establish a draft epic format
Now that you have the numbers in order, let's start working on quality. Establish your ideal epic/PRD/task (whatever it's called in your backlog) format. Be sure to include impact hypothesis and tracking requirements among many others!

6) Confront the format with the team
Ask them if they are comfortable with the format. Maybe it will be better to have tracking requests as a separate subtask rather than in the main body. You both work on those, it would be best if you all feel comfortable with it!

7) Make your own due diligence on the remaining epics
Perhaps your predecessor had already some impact hypothesis, metric estimations, etc. DON’T ASSUME (S)HE DID A FINE JOB AND YOU CAN JUST USE IT AS IS. It’s yours now, and if you are going to make decisions based on them, you'd better make sure you can also take full responsibility. In fact, I have just the tool to help you out:

Thumba.ai, my newest patron, we enable you to generate a comprehensive set of user stories and acceptance criteria (and testing plans), which otherwise would have taken so much time. Especially when trying to evaluate and improve existing backlog items. 
Now you can integrate with Jira or Azure board in order to quickly generate great user stories easily.

Check them out here: www.thumba.ai

8) Start adding your own initiatives
Now that the backlog is clean and yours, it’s time to wow your stakeholders with initiatives that have no legacy history behind them. Good luck!

So, does your backlog look like a huge piece of doo-doo? How did it happen?

Let me know in the comments!

Would you like to become a better product manager every day? Sign up for my free newsletter: https://lnkd.in/ddD_FU5q

Looking to land your next product management job? Aakash Gupta and I can help:
http://www.landpmjob.com/

#productmanagers #productmanagment #backlog

Dr Bart Jaworski

Become a great Product Manager with me: Product expert, content creator, author, mentor, and instructor

This is what a Senior AI PM at Google's GitHub looks like. It's wild. Is it what PMs are turning into? 
Let's examine:

Take a look: https://lnkd.in/dGFZUCVN

Shubham Saboo made 484 contributions in the last year (>1/day). Before I give you more details, here is something to help you build your own GitHub like this:

Master building AI products from scratch and become an AI PM, then Product Faculty's #1 AI PM Certification:

• Master the full AI product lifecycle — Discover → Design → Develop → Deploy
• Learn RAG, fine-tuning, evals, and agentic AI
• Build scalable, production-ready AI products
• 3,000+ AI PMs graduated
• 660+ reviews - highest on Maven.

For $500 off, go here: https://lnkd.in/diQHbFth

Why would you care?

Well, new-age AI PMs don't just write PRDs. They ship:

• Prototypes
• Frameworks
• Perspectives on AI
• Open source contributions
  
The bar for technical fluency for AI PMs continues to rise as PMs like Shubham Saboo raise the standard. 

AI PMs don't just have a theoretical understanding of concepts, but a practical knowledge of AI engineering.

Take a look at Shubham's top repos for inspiration:

• Collection of LLM Apps: https://lnkd.in/dR-uiiaz
• MCP Playbook for AI agents: https://lnkd.in/dhD-Nwzm

These are practical resources that he's collected himself. They aren't necessarily at-scale production apps. They're PM-friendly projects. 

He's also built a more technical open source Python toolkit for building AI agents: https://lnkd.in/eCsAzPtR

When you put these types of work products together, jobs come to you. This is how you break into AI PM. 

If you look at his LinkedIn, most of his career was in dev rel. But a Github speaks louder than titles.

This is what all aspiring AI PMs should do:

• Start with Prototyping: https://lnkd.in/dx4s8WMR
• Then pick up Cursor: https://lnkd.in/dBjGUB29
• Build with Claude Code: https://lnkd.in/d73wHmiX
• Ship to Github: https://lnkd.in/dSqicgSV
• Create a Portfolio: https://lnkd.in/d_EH5BxU
• Build a Job Search System: https://lnkd.in/dUjZFNJr

Then you too can become an AI PM at Google like Shubham. He's created the roadmap. Now follow.

Thank you Aakash Gupta for pointing all that out initially.

#productmanagement #productmanager #aimpm

I will help you become the best Product Manager possible as a content creator, author, mentor, instructor and acting Senior Product Manager

Do you know it is counterproductive for a Product Manager to take part in technical solution discussions? Here are 8 reasons why:

• PM might have a technical background, but it's no longer his/her focus! It's better to concentrate on research for the next great update.
  
• The development team should be able to reach a conclusion on their own.
  
• If they aren't, they need to learn to do it!
  
• You can't be relied on to be a moderator and a leader of technical 
  solution meetings. If anything, it's for the Scrum Master to sort out!
  
• The more you are involved in those discussions, the less time you have to do Product stuff.
  
• It's a waste of time to explain to a PM different brainstormed technical solutions. He/she needs only the bottom line!
  
• PM, knowing too many technical details, might reject ideas because they appear too difficult from a technical standpoint. Product thinking should rarely be tainted by such limits!
  
• This can make the team believe that the PM doesn't trust them. You should trust them!

Did you ever overplay your technical hand?

Let me know in the comments.

Would you like to become a better product manager every day? Sign up for my free newsletter: https://lnkd.in/ddD_FU5q

Looking to land your next product management job? Aakash Gupta and I can help:

http://www.landpmjob.com/

#productmanager #productmanagement #developmentteam

Are you swamped by work and still struggle to say "No" to more requests? Here are 8 ways to help you make this all more manageable: 

1) Treat every request as a point of inspiration
As a Product Manager, you are supposed to be on the lookout for the best opportunities to add value to your product at a minimum cost and risk. That means you need to be certain that an idea meets those criteria, and you need time to look into it. Thus:

2) Give yourself time to research the request. 
Only when you are sure you want to do it, put it in the backlog.

3) Be diplomatic and transparent in your communication
Every request should go through a verification process. You will need to dedicate time to explain that you need your numbers and time to give a final assessment. At the same time:

4) Keep common sense
there are potentially great ideas and things that either are plain stupid or will never happen. You don't need to deceive your stakeholders, so giving a straight answer when you already know it is a good way to go. At the same time:

5) Take your time explaining why you said "No."
While presenting the reasons a request is rejected, take your time. Explain your thinking, and show the data that proves that initiatives that have your attention at the time are well chosen and are set to solve serious challenges. Let the stakeholder follow your way of thinking, and you need to:

6) Be data-driven
Whether you are saying "No" outright or after research, show all the figures that are associated with your answer. This will take time and effort, for sure, but it will be less of a fuss than being pushed to work on something that does a disservice to your product! At the same time:

7) Encourage stakeholders to come up with future ideas and requests
I know about Product Managers who were asked nothing, as they have grown a reputation that they will reject anything their way. However, never saying "Yes" will also be a mistake! You need to cherish creativity and initiative around you, and surround yourself with a team of "unofficial junior PMs" who can one day come to you and bring that Eureka moment! Thus:

8) There are no stupid ideas
While something might seem stupid right now, it can turn out brilliant in the future. It won't hurt to note down all the incoming ideas outside the backlog and look at them from time to time. Who knows? Maybe at least one of them was requested ahead of its time?

Did you ever struggle to say a "no" to a stakeholder request?

Let me know in the comments.

Would you like to become a better product manager every day? Sign up for my free newsletter: https://lnkd.in/ddD_FU5q

Looking to land your next product management job? Aakash Gupta and I can help:

http://www.landpmjob.com/

#productionmanagement #productexperience #communication

I hope you do realize that your dream Product job can become a curse of ongoing stress if you let it. Here are the 6 biggest stress factors and how to manage them:

1) Too many expectations, too few tools and resources to achieve them

Why it happens: PMs are often seen as the "do-it-all" person. They are expected to deliver impactful results with limited time, team, or budget. 

Solution: Be vocal about needing support or lowering expectations until you get what you need. 

2) Too many things to add/change/fix in the product

Why it happens: Everyone has a "small request", and somehow your backlog balloons into an endless wish list with no clear expectations of what each ticket needs.

Solution: You can say "no" to stakeholders more, but you can also use the help of my newest patron, Thumba.ai. It can generate a comprehensive set of user stories and acceptance criteria (and testing plans), which otherwise would have taken so much time. This way, you can come to a backlog session with polished tickets and quickly tell an opportunity from nonsense and get to work!

Now you can integrate Thumba with Jira or Azure board in order to quickly generate great user stories easily.

Check them out here: www.thumba.ai

3) Too many meetings to do actual work

Why it happens: PMs are the glue between multiple teams, which makes you a meeting magnet. But too many meetings mean no time for actual strategy, problem-solving, or execution.

Solution: Prioritize the 3 most important goals each week and avoid meetings that do not contribute to those goals.

4) The Dev team is making it harder for you

Why it happens: This can happen when developers resist taking ownership of challenges. It’s frustrating and often stems from a lack of confidence or clarity in their roles.

Solution: Force them to be more senior, take responsibility for removing roadblocks, and provide end-to-end solutions. They will resist, but will thank you later 

5) Unrealistic goals

Why it happens: Unrealistic goals often come from leadership underestimating the complexity of the work or setting targets based on aspirations rather than realities.

Solution: Only one really: Be vocal when the goals are being announced/revealed. Your silence will be taken as acceptance, and that will come with an expectation of hitting the unrealistic goal.

6) Being in a constant firefighting mode

Why it happens: When bugs, outages, and emergencies dominate your time, strategic work takes a backseat. Features get delayed, stakeholders get frustrated, and the cycle continues.

Solution: If bugs and issues delay your features, it's time to act. Stop everything, put everyone into debug mode to find common cause(s) of the fires and prevent them as much as possible. 

So, are you stressed way too much in your Product job? 

Let me know in the comments.

Looking to land your next product management job? Aakash Gupta and I can help:
http://www.landpmjob.com/

#productmanagement #productmanager #mentalhealth

Aren’t you just sick and tired to be called a “𝘱𝘳𝘰𝘫𝘦𝘤𝘵 𝘮𝘢𝘯𝘢𝘨𝘦𝘳”, when you are a 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗿? Let’s settle the difference once and for all:

The 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗿 should focus on the following:

• leading teams without real authority,
• shaping Product vision, strategy, and goals,
• carrying for the financial health of the product.
• conducting research that justifies his/her choices,
• be on a constant look for new market opportunities,
• listening to users and clients and reacting to feedback,
• deciding on what problems to solve and in which order,
• setting and measuring the success criteria of developed items,

At the same time, the 𝘱𝘳𝘰𝘫𝘦𝘤𝘵 𝘮𝘢𝘯𝘢𝘨𝘦𝘳 should be:

• Figuring out the effort required to complete a project
• Breaking big pieces of work into manageable chunks
• Monitoring project progress and setting deadlines
• Directing the team to achieve a common goal.
• Solving issues that arise and get things going

In short, the 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗿 decides what problems to solve and in which order, and the 𝘱𝘳𝘰𝘫𝘦𝘤𝘵 𝘮𝘢𝘯𝘢𝘨𝘦𝘳 creates a plan to make it happen within a specific window of time and oversees the execution of this plan.

𝗩𝗲𝗿𝘆 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁:
Many companies will see their 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗿𝘀 as both 𝗣𝗠s and 𝘱𝘳𝘰𝘫𝘦𝘤𝘵 𝘮𝘢𝘯𝘢𝘨𝘦𝘳𝘴. That is a clear anti-pattern that leaves the 𝗣𝗠 with very little time to prepare the product’s long-term horizon. Instead, he/she only focuses on the current and next sprint, and is often too stressed and overworked, losing the ever-so-needed creativity and free thought!

In an ideal Agile Scrum scenario, the 𝘱𝘳𝘰𝘫𝘦𝘤𝘵 𝘮𝘢𝘯𝘢𝘨𝘦𝘳 is not a role. Her/His duties become part of the development team's responsibilities, which they need to carry out, often with the help of the Scrum Master.

How is your 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗿 role shaping up, given this post? How often did you do 𝘱𝘳𝘰𝘫𝘦𝘤𝘵 𝘮𝘢𝘯𝘢𝘨𝘦𝘮𝘦𝘯𝘵 rather than 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗺𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁? Did you manage to regain your product focus?

I am looking forward to your stories in the comments.

Let me know in the comments.

Would you like to become a better product manager every day? Sign up for my free newsletter: https://lnkd.in/ddD_FU5q

Looking to land your next product management job? Aakash Gupta and I can help:

http://www.landpmjob.com/

#productmanager #productmanagement #agilescrum

Is Agile development as good as advertised? Let me play devil's advocate and look at the ugly sides of Agile development:

You probably heard the leading narration: 

Agile - Good ✅
Waterfall - Bad ❌

Don't even get me started on the abomination that is SAFE...

Back to the topic: is it really that black and white?

Haven't we all been there? In theory, Agile Scrum seems perfectly reasonable and allows you to focus on your goal rather than a predefined outcome. Thus:

• You perform detailed research to establish a vision, strategy, and roadmap.
• Based on that workshop, prioritize projects in the backlog.
• The team agrees on the details and the road forward.
• You create a Minimum Viable Product (MVP) to test.
• You test and analyze to understand the results.
• You start again based on the learnings.

And you know what? This will work, but...

...only when developers create something barely commercial within a group of enthusiasts, say, early Facebook.

However, what happens when a drug called "actual business" kicks in?

• The constant pressure to deliver results.
• The focus is broken by company-level meetings.
• Rather than focus on one thing, you work on several that overlap.
• You are expected to deliver the same results despite cutting resources
• The number of people in the process introduces "The telephone game."
• Ongoing expectation for things to happen faster, cheaper, and with better quality.

And so on, so on, I could probably type until morning.

But what is the main reason that Agile Scrum appears not to be compatible with serious business?

Predictability. 

Serious business makes predictions ahead of time, and its success depends on whether those predictions are right or wrong.

Do you see where this is going?

Thus, when an Agile Scrum PM says, "I know my goals, I will do my best to achieve them, but I don't know how yet".

The business responds:

"Unacceptable. Come to me with a plan by next week".

And since business > product framework, we, the PMs, are basically forced to work in a waterfall without some of the details in the delivery plan.

Delivery date, outcome, and predicted output are still required, though.

Thus, the agility comes down to adapting to the design that comes later, dropping scope when the deadline approaches, and fixing technical setbacks as they are discovered.

In this case, Waterfall should, in theory, be a better match for business work, as its outcome and output are locked once the plan is finalized, and no one needs to spend years of their lives in meetings to plan out the work 2 weeks at a time.

That obviously comes with its own set of painful issues that still push Agile as the leading framework.

Amen.

How about you? Are you a true believer in Agile Scrum?

Let me know in the comments.

Looking to land your next product management job? Aakash Gupta and I can help:

http://www.landpmjob.com

The third cohort is starting soon. Secure your seat today.

#productmanagement #productmanager #agile

Do you fear the refinement (a.k.a. grooming) session with your development team? I used to dread those meetings, but these 6 simple actions helped:

1) Don't let it get to you
You are probably asking something that will be difficult and challenging for them. We have all been there, and sometimes we rebel against a large challenge. But once the initial shock goes away and you start thinking about how to deal with it, it is no longer as scary. Perhaps it is a matter of giving your team the time to process the details. Hopefully, that will all be fine in time. But speaking of time:

2) Involve the team earlier next time
Usually, the initial skepticism comes if you don't make the proper initial introduction. If you share your early plans and research, the devs will be more informed and ready for things to come. They could chip in early and help you avoid potential hurdles in the ideation stage already.

3) Demand data, not opinions
If the negativity continues after the initial proposal, make sure that your team can prove to you that the idea is super difficult and/or is doomed to fail. However, without the data and evidence, those are just meaningless opinions. Hopefully, you already have the data to show your credibility.

4) Ask "why" like a maniac
Even if those opinions resist your evidence, it's a good idea to understand where the perceived difficulty comes from. Very often, speaking about those challenges out loud spawns ideas on overcoming them. However, if the difficulties are real, it's good to:

5) Show them the wider context and research
Your idea might be challenging, but if it solves a real Product problem, it fits your Product's mission, strategy, and values, and has leadership support, it makes a great case to progress. Any wider context that will support your idea will be helpful. However, there is also the nuclear option:

6) If needed, play the nuclear "I'm the PM" card
At the end of the day, it's your call to decide on what the team needs to develop. The development team not being happy with your choice should not stop you, especially if, after investing the time to convince them. Your firm position will push the team to, perhaps reluctantly, find solutions. Let me stress, however, that this is your final Hail Mary, as it can also damage the relationship with the team. Perhaps you do this, try a more gentle approach to find a low-effort MVP that will prove you are right? 

Did you ever have to push a project against a skeptical team?

Let me know in the comments.

Would you like to become a better product manager every day? Sign up for my free newsletter: https://lnkd.in/ddD_FU5q

Looking to land your next product management job? Aakash Gupta and I can help:

http://www.landpmjob.com/

#productionmanager #teamcollaboration #refinement

It's so true that Product Management theory and best practices are only used during job interviews. Here are 8 reasons why:

Before the promised 8 reasons, let me note that there is nothing wrong with this discourse. Knowing about it shouldn't prevent you from pursuing further Product education. Though it won't always be 100% applicable, I assure you it will help you get out of more than 1 jam and will allow you to really impress your peers! 

Having said that, here's why theory is so different than reality:

1) Lack of focus
Theory always describes building a product/increment as if you are working on a single piece of it. That would make a relaxing and slow job! Instead, you are actually working on 5, 10, 15, maybe more different development initiatives at the same time. That is bound to force you into some shortcuts! 

2) Lack of resources 
Whether that is time, number of developers, designers, or your very own brain power, it is not possible to attend to everything that all the stakeholders need. You may know how to deal with that in theory, but that never takes into account the stress, emotions, and pressure put on you. 

3) Dealing with real people
No theory will prepare you for dealing with your seniors and peers. Sometimes, you will do something out of the box; sometimes, you will have to "bend the knee" to successfully perform: 

4) Maneuvering the politics
No Product Theory prepares how to deal with the stupidest things you will have to do to fit the politics and please the shareholders. I've been on the receiving end of this stick more often than I would have ever expected. 

5) Everything is stretched out in time
It's easy to follow specific steps when it's a tight diagram on paper. When you need to take real meetings with people who have their calendars blocked for weeks on end, everything starts getting much more difficult, and you need to get creative to get things done!

6) There will always be too many high priorities
Just like that, I never met a stakeholder who would be happy with PM's scope of priorities. Sometimes it's not about preventing the fires but choosing what will burn :(

7) Unexpected things will happen (a lot)
How can you have a tidy, by-the-book process if things get broken and new emergencies pop up daily? I know I get lost when all hell breaks loose!

8) You are just a person
It's one thing to know what to do. It's another to have the mental strength and resilience to see it through... 

Did you ever fail a product management interview by being too honest and pragmatic?

Let me know in the comments.

Would you like to become a better product manager every day? Sign up for my free newsletter: https://lnkd.in/ddD_FU5q

Looking to land your next product management job? Aakash Gupta and I can help:

http://www.landpmjob.com/

#productmanagement #productmanager #jobsearch

It can really hurt when the MVP of your dream project becomes its own parody. Here is how to deal with it:

There is something common between all the members of the development team, including designers, developers, you, and the product manager: the desire to create something special, something that looks great, feels great, and works just awesome. 

However, the reality is brutal. 

There's this famous triangle of quality, speed, and cost that limits you to choosing only two out of the three edges of the set triangle. 

Realistically, you will always be pressured to release and test as much as possible, as fast as possible.

(If you are not, please let me know. I want to work in your company.)

Thus, quality is the only remaining slider that you can realistically operate with. 

Which, of course, isn't ideal. It would be so great if you could just get more developers or more time and deliver your dream project

But coming back to the ground level:

MVP (Minimum Viable Product) that you, as an Agile Product Manager, are supposed to deliver, doesn't have to necessarily be bad and dysfunctional. 

In fact, it's a true craftsmanship and a show of PM skills to create one that's appealing enough and not too complex, and yet can prove that the whole concept and the full picture you had in mind for your project is the way to go. 

So what are the features of a great MVP that won't stop you in your development tracks, and you can be proud of it? 

1) Make your whole project roadmap, where MVP is a milestone, not the destination.
If stakeholders only ever see the MVP, it easily becomes the final product. Give them the full picture upfront, and when the first step succeeds, they'll be hungry for what comes next rather than satisfied with the minimum.
 
2) If you can't give it the right quality, let it go.
Some ideas require too many sprints to get right, and the stress simply isn't worth it. Great concepts fail because of the people or constraints around them, and that's okay. Knowing when to walk away is a core PM skill, not a defeat.
 
3) Be patient.
Not every idea is viable today. Shelve it, keep your data estimates handy, and wait. New tools, technologies, or a change in stakeholders can give your concept the runway it needs later.
 
4) Protect one thing that makes it feel real.
In the rush to cut scope, every "nice to have" gets axed, and sometimes so does the soul of the product. Identify the single feature or design detail that makes your vision tangible, and fight to keep it. An MVP without it might be functional, but it won't make anyone believe in what comes next.
 
Have you ever released an MVP that lost too much of its original value to be successful?

Let me know in the comments.

Looking to land your next product management job? Aakash Gupta and I can help:

http://www.landpmjob.com/

Would you like to become a better product manager every day? Sign up for my free newsletter: https://lnkd.in/ddD_FU5q

#productmanagement #productmanager #mvp

How often did you feel like quitting your job when forced to add a feature that made no sense? Is there any solution to this madness? There is:

Let's face it: Hardly any Product Manager is truly independent and works with actual stakeholder requests, not "requests (or else)". 

Should you be upset?

Probably...

The better strategy would be to deal with it and work around it.

How?

Here are 6 ways that will help you deal with unreasonable "requests" while maintaining your professionalism and keeping an open mind:

1) Assess the impact, cost, and potential loss if ignored for the request
If you know how much work is needed to add the new feature to the product and what value will it bring, you are able to prioritize it against other entries in the backlog. Bonus points if you can assess what will happen if you don't add the requested feature. Sometimes, we need to add silly things to the product, just because competition made users expect them. Example? Most of the recent Apple iPhone updates have been chasing AI Android features.

2) Present the cost of delaying other roadmap items
With point 1, you know exactly what will be left behind if you prioritize the new request. Maybe it is critical, but what you already have on the roadmap is "critical-er"? If your backlog has more than 1 such stakeholder "request", get them to duke it out and decide the winner between themselves.

3) Find the quickest possible MVP
Just because you don't like an idea doesn't mean it is stupid or bad. Let data speak for itself. Thus, it's worth considering how to create a minimum viable version of the stakeholder's request to check with data whether the expected impact is there. With this approach, you might save months of pointless development.

4) Discuss the request vs goals
If the request is compatible with your current product goals, then at least it contributes to your success. Otherwise, it is a waste of time, and either the goals need to be changed or the request forfeited. There is no other solution,

5) Request additional team members
Things can be only 2 out of 3: quick, high quality, cheap. So if everything that is already on the roadmap needs to happen AND you have to add the new request, then you need to either sacrifice quality or get more people to work with. 

6) Have everything in writing
At the end of the day, make sure to record all that we discussed over emails or signed meeting notes. If all goes to shit due to stakeholder pressure, you need to have your ass protected when the witchhunt drops.

There you have it! I hope these 6 pieces of advice will help you in such difficult moments. 

Have you ever had to deflect a stupid AI project?

Let me know in the comments.

Would you like to become a better product manager every day? Sign up for my free newsletter: https://lnkd.in/ddD_FU5q

Looking to land your next product management job? Aakash Gupta and I can help:

http://www.landpmjob.com/

#productmanager #productmanagement #mvp

taplio

Bart Jaworski's Linkedin Analytics

Bart Jaworski

Performance ScoreBart Jaworski's LinkedIn Performance

What is Bart talking about?

Who is engaging with Bart

Bart Jaworski's Best Posts (last 30 days)

Ready to grow your LinkedIn presence?