What has become painfully clear is that there are goals we pursue as PMs and dismal realities of the job. Hence, I’m curious in what you’ve learned from your experiences and how you handle these contradictions.
Product management isn’t a science. 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 the whole. We hardly ever consider the role that luck plays in anything.
Yeah, honestly, I hate to think about how many times I was right because of a gut feeling or just…vibes versus data driven decisions. Randomness is more prevalent in all facets of life than we want to acknowledge.
@MalcolmSequeira, I don’t think you should hate it, just accept it. If you are managing a strong growing product it’s going to be hard to screw it up. Don’t be too arrogant about it. If you’ve got a product that hasn’t found it’s way, don’t feel like it’s a personal failure when things don’t go to plan.
The more I look at products the more I think it’s a miracle it worked out because of how many things had to go right.
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 businesses 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 subpar.
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 have found my best tools are from the social sciences, psychology and sociology. It matters if we solve problems that users and customers believe they have, as much as it does to solve the workflow issues.
Exactly. It’s about the skill of the practitioner to be able to deploy and scale and adapt those frameworks and best practices. Getting it right isn’t binary, there is an understanding of how certain you need to be and making the decision based on that. What is the cost of being wrong? If it’s high, you take one path, lower, you take another.
The best practice is accepting our sobering realities. 90% of startups and a ton of products just aren’t great.
Leading teams and building great products is hard. Navigating it is having vision and working through the details.
Here’s a few of mine:
-
We often make decisions based on intuition or product sense. You can get better at using your instincts over time, but it usually involves making a lot of awful mistakes.
-
Frameworks are helpful to learn, but actually using them is borderline impossible the way most businesses are run. Knowing them will help with the product sense, not as helpful as experience.
-
“Playing the game” is more important than it should be. As in, getting certain people - stakeholders, senior leaders, etc. - to like you and be on your side is an important part of this job. Without it, influencing people enough to buy in to your roadmap is impossible and you’ll always be micromanaged.
-
You can’t do anything by yourself. In fact, you are usually the only person in the room who doesn’t have a tangible skill. I can’t just go on Upwork and start doing product work for someone. Building usable, functioning software without engineers or designers is incredibly difficult. We only succeed if they do. Our job is to make these talents of theirs come together in a way that helps everyone succeed.
Superb @KaneMorgan, last point about can’t do anything by ourselves resonated harddddd with me.
Sat in on a technical call with some of our engineers the other day… boy did I feel dumb. I like to think there are topics I’m way more proficient than them at, but idk…
1000% it’s a gut feel and I hate how some of my product leaders expect me to document every decision I make.
If you have to ask for guidance on expected functionality for more than 50% of the feature you’re trying to build, you probably shouldn’t be the product owner of that feature.
Most often when they say they use Scrum, they really don’t. Maybe they do Scrumfall. They just have a 2 week sprint and a daily stand up and call it Scrum.
To be fair, i would not recommend following scrum by the book. You should never follow a framework by the book, that goes against the core itself of Agile principle The teams should define themselves their process, and very often scrum is used as a common basis and from there teams derive I’m so glad I don’t do scrum but some kind of variants my team agreed on, that works for us
@MarcoSilva, Its generally a catch 22. Because Scrum is a framework but it’s also prescriptive. it inherently is NOT scrum to follow scrum. Its also an idealist framework and very few organizations can actually allow it to thrive. The teams can rarely be self-managed because they have different managers outside of the Scrum team that have influence on the work the Scrum team does and I’m not talking about them as stakeholders.
Here’s my take:
- Startups aren’t all outcome based. Some are just top down driven feature factories.
- You can’t change the product culture at the company bottom up. The company leadership needs to be on board.
- As much as everyone talks about idea validation, most companies want teams to start building right away and aren’t comfortable with PMs spending time validating before anything is built.
We’ve got graves marked by Confluence pages written by product managers who tried to figure things out because the enterprise didn’t really want product managers. Three generations dead and gone because the company didn’t really want to have anyone other than execs calling the shots at every level.
Scary on point. I just got fired as a pm because of these reasons (and me insisting on doing best practices)