4 ms·

My 12 years exp. being manager: - You're the CEO of the product. You drive the vision. - You know your product from 0 to 100%. You know everything. - If anyo

My 12 years exp. being manager: - You're the CEO of the product. You drive the vision. - You know your product from 0 to 100%. You know everything. - If anyone wants something or know about one problem, you should be the first one to know this. Never go to team members. - You should be able to identify problems, the source, before declaring it as "a problem to solve" for your team. AKA "false positives", "that's not a bug, that's the behavior", etc. Be the shield for this shit. - People will use all kind of trickery to force you to do things for them. Learn how to say no. Learn how to prioritize. Remember you have your own interests to cover for your product. - Always tell what you want to achieve, what is needed, how much time it will take and what will be the deliverable. The more defined the answers, the best for both team and you will be. - You're the one taking the last decision. Everyone must acknowledge this. - You should listen people, and rely on their expertise. They will tell you how to do something, but don't let them to change your high level achievement. - Tell the people what you want to achieve. - Call on people when they did stuff out of the planning. AKA: "I've been doing this nice animation, now the product looks nice", etc. - Always talk individually, short meetings, instead big team meetings. Consensus always drive bad products. - Nothing goes production without your approval. - Enforce criteria acceptance: all features must be done according to the plan, not what the developers wanted to implement. - Kick out toxic people from your team. The earlier, the better. - Never let people insult you. - If you happen to make a mistake, be the first one acknowledging this. Never try to justify incompetence. Always try to solve that to avoid new cases in the future. - Try to help team members who aren't motivated. Talk to them. They're confused with their role in the project, usually.

frenchman99 7y ago
> - If anyone wants something or know about one problem, you should be the first one to know this. Never go to team members. > - Nothing goes production without your approval. > - Enforce criteria acceptance: all features must be done according to the plan, not what the developers wanted to implement. I wouldn't be able to work for you. Sounds you want to decide everything. But sometimes, the manager's plan doesn't work out as it was supposed to be. I've found that relying on the technical expertise of developers yields better results than forcing them to code line after line what the manager thinks is best. Then again, some people probably like your style. To each his own.
- meerita 7y ago
  I said "you should rely on the team expertise". Sadly, you're reading it wrong: if the criteria acceptance says feature X must output Y, then if we see that it outputs P just because someone didn't liked the initial agreement, then it is not teamwork, it is what you want to do. Sadly again, this kind of free will leads to poor products. The production thinng is imporant: you must be aware what you launch, do the internal communication, external, making sure things goes well. If you push to production features without approval you're basically creating a problem. I think you want to be in a place where you can rule, meaning, being the CEO of the product and the one who make it. Maybe I'm wrong asserting this, but the product manager has to be accountable.
meerita 7y ago
> If anyone wants something or know about one problem, you should be the first one to know this. Never go to team members. What I am trying to say is, it is better first to talk the manager if you think there's a problem or you want a feature than going to the team and bothering them with things. The manager has to be able to analyze your requests, check if there's a real problem, not a false positive, then mediate with the entire stakeholder things to allocate time to do your requests. The opposite would be you changing the scope of every person's agenda because you have the free will to move on to anyone.

frenchman99 7y ago

> - If anyone wants something or know about one problem, you should be the first one to know this. Never go to team members. > - Nothing goes production without your approval. > - Enforce criteria acceptance: all features must be done according to the plan, not what the developers wanted to implement. I wouldn't be able to work for you. Sounds you want to decide everything. But sometimes, the manager's plan doesn't work out as it was supposed to be. I've found that relying on the technical expertise of developers yields better results than forcing them to code line after line what the manager thinks is best. Then again, some people probably like your style. To each his own.

meerita 7y ago
I said "you should rely on the team expertise". Sadly, you're reading it wrong: if the criteria acceptance says feature X must output Y, then if we see that it outputs P just because someone didn't liked the initial agreement, then it is not teamwork, it is what you want to do. Sadly again, this kind of free will leads to poor products. The production thinng is imporant: you must be aware what you launch, do the internal communication, external, making sure things goes well. If you push to production features without approval you're basically creating a problem. I think you want to be in a place where you can rule, meaning, being the CEO of the product and the one who make it. Maybe I'm wrong asserting this, but the product manager has to be accountable.

meerita 7y ago

> If anyone wants something or know about one problem, you should be the first one to know this. Never go to team members. What I am trying to say is, it is better first to talk the manager if you think there's a problem or you want a feature than going to the team and bothering them with things. The manager has to be able to analyze your requests, check if there's a real problem, not a false positive, then mediate with the entire stakeholder things to allocate time to do your requests. The opposite would be you changing the scope of every person's agenda because you have the free will to move on to anyone.