This post makes some wild assumptions, like the fact that B2B PMs only interview customers, and not end users. Also, that they mostly build what people are saying they want to have.
Ironically, avoiding assumptions is the basis of product management.
At the end of the day, someone has to do the product role on the team. If the founder can scale that, great, and if the engineers can do it, even better! Unfortunately both options are extremely rare to find.
There are a lot of shitty PMs out there, just as there are a lot of shitty engineers or any other job function.. We would do better, I think, to discuss and promote better patterns, than trying to discredit a whole profession by clumsily reverse engineering a handful of gross assumptions and, probably, bad personal experiences.
This is not my article, I just found it when searching for any data on the subject. I'm aware of the article author's bias on the subject.
We run a B2B SaaS and 20% is the drop we've seen (comparing to monthly numbers of the last 5 years). This still needs to be analyzed better but it's taking time due to our messy system of multiple carts using different payment service providers.
Personally as an EU citizen I'm very in favor in these changes. I think the UX will become even more of a differentiator for banks and related products which is great. Banks FINALLY being forced to open APIs is also great for the fintech industry, so I'm not bitter at all. Just curious to see what other SaaS businesses have seen in their Euro traffic.
A lot of resources on product management are mixing what some commentators are pointing here: roadmap can mean:
1. Communication tool to tell others in the organization (or even outside) what you're planning to build.
2. A framework for your product and/or engineering team that helps you prioritize the work.
This article obviously focuses on the latter. One of the most common mistakes however is that PMs try to use a single deliverable for both.
Yes, there are interesting tools trying to address this but my advice is to study different frameworks to help you think about what your main challenges are - then stand up the process in a spreadsheet as you'll need a lot of flexibility to get to something that works in your specific case. Only then look for dedicated products and choose the one that works best for the process you ended up with.
Ironically, avoiding assumptions is the basis of product management.
At the end of the day, someone has to do the product role on the team. If the founder can scale that, great, and if the engineers can do it, even better! Unfortunately both options are extremely rare to find.
There are a lot of shitty PMs out there, just as there are a lot of shitty engineers or any other job function.. We would do better, I think, to discuss and promote better patterns, than trying to discredit a whole profession by clumsily reverse engineering a handful of gross assumptions and, probably, bad personal experiences.