What are the best methods in product management compared to the harsh realities?

What has become blatantly clear is that there are goals we pursue as PMs and dismal realities of the job. Therefore, I’m curious to know what you’ve learned from your experiences and how you handle these conflicts.


Here’s my opinion:

  • Not all startups are outcome-based. Some are merely feature factories that are driven top down.

  • The company’s product culture cannot be altered from the bottom up. The corporate management must support the initiative.

  • Even though idea validation is a hot topic, most companies prefer teams to start building right away and don’t like the thought of PMs spending time validating before anything is done.


Confluence pages created by product managers who attempted to work things out because the company didn’t actually want product managers have been used to mark graves. Three generations are dead and gone because the company didn’t really want anyone other than executives making all the decisions.


Oh my God. This reminds me of a three-tiered, nested Confluence page that was used by only deactivated users for “product strategy.”


This should be the preface to every book on product management.


It’s not a science to manage products. Success is not assured by any of the frameworks, testing, or best practices. Since there are so many potential issues, it is impossible to always do everything right. In the end, the product is only one little piece of a larger puzzle. We hardly ever consider the role that luck plays in anything.


@NathanEndicott, I strongly dislike thinking about how many times I made decisions based on gut instinct or just my feelings rather than data. In many parts of life, randomness occurs more frequently than we wish to admit.


You shouldn’t dislike it, just accept it, in my opinion. It will be difficult to make a mistake when managing a product that is powerful and growing. Avoid being too haughty about it. If you have a product that hasn’t taken off, don’t take it personally if things don’t work out as you had hoped.

The more I examine products, the more I believe it was a miracle that everything turned out as it did given how many things had to be in order.


You make hundreds of decisions every day.

Try to make sure the average is “good”, you get the occasional “great”, and never make a “terrible” one.

The rest will come out in the wash.


This is why I can rage for hours about companies that only conduct A/B tests and never decide what to do with their products. No matter how well each component tests, if you don’t know what your product is supposed to be, the overall result will be terrible.


There are a ton of variables on your team that can impact your perceived PM performance. I’ve been much more successful lately with a quality designer and engineers who finish most of their assigned tasks within the sprint.


Agreed. I’ve discovered that the social sciences, such as psychology and sociology, are my best resources. As important as it is to address process concerns, it also matters whether we address issues that users and customers believe to exist.


Exactly. The ability to implement, scale, and adapt these frameworks and best practises depends on the practitioner’s talent. In order to get it correctly, you must first recognise how certain you must be and base your choice on that understanding. What does being incorrect cost? If the tide is high, you go one way; if it is low, you go another.


Here are some of mine:

  • Much of what we do is based on instinct or product sense. You can get better at using your instincts over time, but it usually involves making a lot of awful mistakes.

  • Although frameworks are useful to study, it is nearly hard to use them in practise given how most organisations are managed. Although not as helpful as experience, knowing them will aid with the product sense.

  • “Playing the game” takes precedence over what it ought to. As in, gaining the favour and support of certain individuals, such as stakeholders, senior leaders, etc., is a crucial component of this work. Without it, it will be impossible to persuade people to agree with your roadmap, and you will constantly be subject to micromanagement.

  • You are powerless to act alone. In fact, you are frequently the sole person present who lacks a specific talent. I can’t just sign up for Upwork and start working on someone’s product. Without engineers or designers, creating useful, functional software is exceedingly challenging. Only if they do will we succeed. It is our responsibility to bring these skills together in a way that benefits everyone’s success.


Last point about can’t do anything by ourselves resonated harddddd with me.

100% of the time, it’s a gut instinct, and I detest how some of my product leaders want me to record every choice I make.

You probably shouldn’t be the product owner of that feature if you need advice on expected functionality for more than 50% of the feature you’re trying to build.


Most of the time, those that claim to use Scrum in reality don’t. They might use Scrumfall. The only thing they call Scrum is a two-week sprint with a daily stand-up.


@LuisNeilson, Fair enough, I wouldn’t advise adhering to the scrum guidelines exactly. Never adhere to a framework blindly because it goes against the fundamental principles of Agile. The teams should determine their own process, and scrum is frequently utilized as a common framework from which teams draw. I’m very delighted that my team and I have settled on some scrum-free alternatives that work for us.


Usually, it’s a catch 22. Scrum is both a framework and a prescriptive methodology. Following scrum is intrinsically NOT scrum. Additionally, it is an idealist structure, and only a small number of companies can truly support it. Because of the numerous managers outside of the Scrum team who have an impact on the job the Scrum team completes—I’m not talking about them as stakeholders—the teams are rarely able to manage themselves.


Hot opinion:

  • Product management is no longer a real thing.

  • The executives are now PMs who prioritize the roadmap (epic/feature), and we are all POs who prioritize the backlog.

  • Problem identification and validation are no longer necessary because the executives instructed you on how to complete the project.


A three-year plan, a charter, a vision statement, dashboards, living project documents, dependency reports, marketing and BI projections, and maturity audits are all best practises. Deliverables for the yearly industry tradeshow are also powerful and clear.

The sad truth is that everything is unpredictable!

  • There isn’t time for a comprehensive charter.

  • There is a plan for two quarters, at most.

  • Onboarding is more ad hoc and lacks success standards.

  • Dashboard indicators vary from team to team and from quarter to quarter.

  • Every piece of documentation is static and challenging to relevance-check

  • Teams struggle to coordinate and collaborate, thus dependency isn’t codified.

  • PMs must nag and bribe BI and marketing to coordinate research, but without a clear mandate, everything is just vague and tangentially related to the product.

  • Audits of maturity take too long since everyone is rushing around like crazy.

  • When the sales team notices the mess, they will yell at everyone to straighten up while giving the customers a separate account.

Everyone is going over their budget limits and still asking for additional money to budget for initiatives without distinct business objectives.

While everyone is shouting, nothing is being done to put out the fire.