Last week, Drift's David Cancel controversially claimed 'there's no co-relation between level of experience and success' in Product Management. Hunger and mindset, he maintained, count for much more so there's no point hiring PMs with experience.
In Summary: This week, all hell broke loose in response. Leading the charge was Rich Mironov, Product OG, who tore into David's post from multiple angles. Technical knowledge is definitely important for PMs, domain expertise is useful, but no guarantee of greatness. Experience, on the other hand, is essential.
Close behind was Mind the Product's Martin Eriksson who also took issue with David's disregard for PM experience.
Recognising patterns, knowing how to tackle them, and how to deliver the best product possible in the most efficient way: all this comes from experience. Only experience will help you when facts don’t fit the theory. Mindset and attitude are only part of the equation. Now that Product Management is a craft, experience matters. A lot.
Look within, says Square's Gokul Rajaram.
In Summary: When founders decide to hire a full-time Product Manager in order to focus on being a CEO, they all make the same mistake. Everyone wants to hire someone new.
Gokul's advice? Always convert an existing employee into that first PM. All Product Managers need trust and respect from their team to be effective, but for the first Product Manager it is absolutely critical. As both founder and engineering team are used to operating without the role, it's far easier if the new PM is someone they already know (and admire).
Finding the right person internally means identifying whoever is most passionate about the product and your customers. This is how it happened at Google, Facebook and Square. And what worked for Mark, Larry and Jack probably works for the rest of us.
If not, forget it and move on, says Shardul Mehta (aka the Streetsmart Product Manager).
In Summary: If you're going to pursue an idea for a product, make sure it solves a problem worth solving.
Drawing on Stull and Myers' book, Tuned in, Shardul lists the 3 questions that must be answered before you invest money or resources into development.
The problem you are solving must be urgent and pervasive and your target customers must be willing to pay for it to be solved. If the answer to any of these questions is 'no', then you need to pivot.
Too many products fail because they solve problems that are not a big enough deal to be worth paying for. You may hate having to take out the trash, but would you pay someone to do it twice a week?
Same, same but (very) different says Lola Travel's Ellen Chisa.
In Summary: Ellen has held product roles at Microsoft, Kickstarter and now Lola. Having reached the level of Product VP, she's well positioned to compare and contrast the role with that of a hands-on Product Manager.
Product Managers will spend time interviewing future candidates, but a VP Product decides when the Product Team needs new additions and defines what you need from the process.
If you want to be an effective leader at executive level, you must empower the Product Team you’ve built to do their jobs. A Product Manager's job is to be down in the details, so a VP Product must learn to trust the team to handle those details. That’s why the hiring process is so essential.
But the process of taking and applying feedback remains the same no matter which role you have. The Product Manager and VP of Product are both measured by their ability to receive, internalise and strategically act on feedback.
Focus on the problem, says MTP's Martin Eriksson.
In Summary: Martin believes lengthy requirements documents are the worst way to bridge the gap between customer needs and your Product Team.
From the amount of time they take to create, the way they lead to 'feature bloat', to how they need to be constantly updated, this method of specifying your product's 'requirements' is as obsolete as it is broken.
Instead, products should evolve via market research, close communication within the Product Team, rapid prototyping and iterative user testing. This approach is faster, more enjoyable and more efficient for all involved.
More than you think, says John Cutler.
In Summary: When estimating product development, how many of us account for training and support, system maintenance and the opportunity cost of not working on other priorities?
By listing the 17 hidden costs of shipping new features, John highlights how engineering is just a small part of the overall cost. This puts greater emphasis on Product Managers to ensure their teams only build features that add value to their customers and the company's bottom line.