10 things I believe to be true for any product manager
A collection of thoughts from the day-to-day struggle of building product
Find the original here and more at albuquerque.io
1) Product managers’ most important skill is common sense
Voltaire said “Common sense is not so common”: praise the heavens it to be common around Product Managers. PMs are responsible for everything and responsible for no one. This means everyone will push for what they individually want, their own motivations (a new tech, a new tools, that new trend). Most times a good dose of common sense is what separates delivering, from failing, and aligning everyone at the table towards what is right is what makes the difference between a good product leader and a bad one (props to Julio on the quote).
2) Product management is chaos and will always be chaos
I once again challenge a product manager to state “in my startup, the process of building product is quite smooth. We plan ahead, we have all stories written, we test our designs, our developers know what to build on kick-offs, our grooming is prioritised, our backlog is rich, our checkpoints don’t require sprint changes, we don’t need to make up work to compensate delayed deliverables”. Product management is plain and “simple” chaos. Either estimations went wrong and suddenly we won’t deliver on time; or there’s a “fire” and we need to solve it now; or there are countless re-opens and the sprint, which was looking so good, just went down the drain; or QA missed an edge case and a buggy feature is live and we need to roll back; or we don’t have designs ready and we can’t get them to engineers; or we didn’t have the time to build the user stories ahead of sprint estimations, etc times-a-million. Or every single one of these things is happening at the same time. Two times a day. While you’re “hangover” from the all-nighter you pulled last week because someone ran a command and killed the production database and you had to restore everything overnight. Product Management is chaos, will always be chaos, and that is why it’s amazing.
3) Product is more about what you won’t build than what you’ll build
Product managers are protectors of users, time, scopes and teams: there is little else that needs to be properly done in this world. Of course doing it is ridiculously hard, as they are often substitutes, not complimentary. And to add on top of it, everyone wants to prioritise their own “thing”: beautiful design, that new code language, refactor a legacy process, etc. This is unlikely to be what users value the most. End of the day, successful product management comes from prioritising what will deliver more impact considering a balance of cost (resources) and time to market. This leads to a lot of “No’s” in protection of the right “Yes”. When everything is important, nothing is important.
4) There is always another way
There is no single way of solving something. “Creativity is the mother of invention”, and it’s the product manager’s responsibility to kickstart this way of thinking and push every functional leader to think outside the box. Hustle because there is always another way. Make it your motto. Let everyone know: there is always another way.
5) Holistic strategies don’t build user stories
Avoid getting trapped on the high-level / strategy discussions for too long. Ground your team to a level that can actually get something to be built. Holistic strategies are important, but only if they can be translated into epics, user stories, tangible actions. There are few things that are more frustrating than just speaking “down the line”, “our vision”, “in an ideal world”. There is no down the line, vision or ideal world if we don’t build that next sprint, homie!
6) There is no 9-to-5 in product
Work-life balance is a big topic everywhere. It’s probably even bigger around startups (and investment banking) given the average age of people, high ambition and the difficulty to succeed. Even though we should all fight for a healthier lifestyle, product management can rarely afford it. There are just too many things needed to bring good products to users’ hands. And even if we don’t have direct execution responsibilities, PM’s are the foundation to keep everyone and everything together. This requires surveillance, self-awareness and an insane care for detail, as it’s easy to miss out on stuff that separates success from failure. As Gary Vaynerchuk puts it “are you working hard enough?”.
7) Everything takes longer than you think
I challenge one product person to tell me the following sentance: “Estimations were correct, what we built actually matched how long we thought it would”. Notice I don’t even say “faster than expected”, I say “matched”. Human beings are quite bad at predicting time as we’re naturally optimistic, even after plenty of (wrongly predicted) attempts. Daniel Kahneman calls it the “Planning Fallacy” and goes in depth about this in “Thinking, fast and slow”. Even if you could accurately predict development time, there is a number of exogenous variables that impact feature releases (weather it’s deploys that were blocked, QA environments/processes that bottlenecked, release processes that required extra overhead, etc). It sucks but just remind yourself and everyone around: everything takes longer than expected, 100% of the time.
8) Getting requirements is more about what’s between the lines
Collecting requirements from stakeholders, both internally and externally, is like a game of darts: rookies think that winning the game means aiming at the bullseye, while in reality there are rules and the centre is not always the highest scoring target. Users explain their problems using solutions, or how they see their problems being solved. This is a natural compensation mechanism. The issue is that the side of the brain that processes a problem is different from the side of the brain that thinks of a solution. PM’s should be experts on problems, not solutions, so it’s key to look for the problems between the lines to get to root causes. Try using “the 5 why’s” to force your users into their problems and away from their solutions.
9) Silver Bullets don’t exist. Period
If you build product in a startup, it’s normal to be close to founders. Founders are idealistic and optimistic. So optimistic that they believe it’s that “one little thing” that will make the business explode. This is what people call “a silver bullet”. Don’t be fooled: silver bullets don’t exist. It doesn’t matter how much media tries to mask them with overnight successes, it wasn’t “silver bullets” that made top startups successful. At best, something that looks like a “silver bullet” could bring a better experience but don’t expect double or triple digit growth. Growth comes from consistency over time: delivering endless iterations and features which are user-fit, solve problems, and incrementally improve retention and/or conversion.
10) Don’t ship features and forget about them. Don’t be a factory
One of the most impactful articles I’ve read in a long time was “12 signs you’re working in a feature factory”. This really resonated with how we we used to build product at Uniplaces, plain and simple. And the worst part is that a significant number of product teams around the world work this way. When I interview for product positions I generally ask a question: «Do you think the world needs more products?»: my answer is “Yes because the world needs better products and the way to get there is through competition, and the more good products are built the more great products are built”. The thing is the standard of product quality determines the speed of innovation (or how fast products get great) and shipping bad features, bad experiences, poor problem understanding, does a disservice to this cycle. Build and ship what people want, and if you end up building something people don’t want, you need to be emotionally unattached to kill it, as easy as when you brought it to life.
