Myth buster!
In general, the reason for any chaos could largely be attributed to lack of understanding, swallowing spurious information, falling prey to speculations. Is it possible to steer clear of myths?
« Rewind…!
I’d like you to hark back for a second.
Think about the period 1995-99.
Think of computer systems, software organizations, desktop applications, OS & platforms.
There was something of significance that the whole world back then had their eyes & ears opens to & their fingers crossed firstly in an aim to gain more information from the sources back then that were mostly print medium like magazines, digests, newspapers etc. in an anticipation of some kind of a positive result that could help avert the impending doom.
Even the ones with the faintest of memories do remember the phrase “Y2K”.
There was no clear understanding that people had over a bug that was to do with programs coded in a manner that considered only the last 2 digits of the YEAR in the DATE which led to erroneously rolling the date back to 1900 for all period / horizon-based calculations in such cases.
Today it is more of a mantlepiece / survivor’s banner that hangs on the walls of Tech people from the 90s and a favorite tea-time joke for some. But, back then 90s kids did feel the pinch of the statement…
“Turn off your computer before 12/31/99”.
A large contributor for all the chaos and people going helter-skelter over the hype & hoopla about the Y2K bug was the lack of understanding. And, once people got the understanding of the problem it was such a simple solution of a minor change in code and the recompilation of the executable over proper interpretation of dates if you are referring to the application level.
So, be it then or today.
The reason for uncontrolled chaos could largely be attributed to the lack of proper understanding or even worse is, swallowing spurious information and unscrupulously falling prey to speculation / myths that often get attached to and are known to surround problems.
» Fast Forward… & Play!
Fast forward to today and one would sense that not much has changed over speculation adding confusion contributing to whole lot of unwanted chaos and the culprits remain the same though - lack of proper knowledge and understanding.
NOTE: For the rest of the sections, PM = Product Management, PMs = Product Managers.
In a world that’s more relevant to product management there is so much confusion over what a Product Manager’s role in an organization is, what his responsibilities are all about and the parallel that’s drawn from roles that are namesakes as in Project Manager, Program Manager etc.
Let’s try and cover a few of the common myths here and see if we can build some clarity over segregating and quantifying what PM roles are all about and what they ought to entail.
Some common myths about product management, product-based roles:
1. Product manager is the CEO of the Product
Often touted as the CEO of the product, many PMs could get confused over the amount of control they have / have been allotted over strategy, decisions as opposed to the tactical part where they have to get down to actual work.
It is mythical to think that PMs are the CEOs and are responsible for everything that’s to do with any given product as a whole.
Truth: Yes, PMs are accountable for all strategic / tactical decisions / moves they make. But, that often starts and ends at the scope of the goal they have been assigned wrt a product / geography / customer segment / target market and even there they will have to work by seamlessly integrating their purposes and collaborating with all the other concerned teams and members.
2. PMs make all decisions by themselves
As for the major portion of the decision-making operating within the confines of the allotted scope, PMs are free to and also tend to make decisions over a variety of tasks over planning them and executing them as well.
But, it definitely isn’t true of the world that PMs work all by themselves in finding problems & coming up with ideas that could lead to solutioning products / features that could solve for them.
Truth: Yes, when you start off as a PM it may be true that you don’t have anybody reporting into you and it may hold good even hierarchically as well. But, that doesn’t really mean you are all alone and have to do the work all by yourself. Always, do remember that you have all your teams and your best bet is to influence everyone, collaborate with them seamlessly as and when required and involve them experts in their fields at all those crucial stages of the product right from Ideation to Growth.
3. PMs mostly work alone in IC roles
At many organizations it is advertised as a part of the JD that one has to be a self-starter and possess the ability to work with minimum direction. Extending this and appending it over the previous point, it could be perceived that PMs meant to work as Individual contributors. But the truth is far from that.
Truth: PMs role never demands them to work in an IC role anywhere. They are in fact tested over their ability to collaborate in a team. The only bit of truth about the individual contributor role is in how the PM uses all the data / information thus gathered from various sources over his respective interface(s) with each of them and builds on that to gain clarity over:
“why” is this important?
“who” is this for?
“what” is to be done?
“how” are we going to do this?
It is also about how this information obtained is deciphered and bundled as one, perhaps over a document in order to build a shared understanding that all teams could align over.
4. PMs shy away from product work as they step up in the ladder towards Leadership
Another common misrepresented / misunderstood bit is - as a PM rises through the ranks and gets to the leadership level, he will detach himself completely from work that is commonly identified with PM roles and concentrate only on people management roles and the people he manages will be other Sr. PMs, PMs, JPMs, APMs.
Truth: As PMs grow professionally and personally it is possible they may get more lucid with their responsibility and gain deeper experience and impeccable command over one specific area like for instance, Growth, Marketing, Sales et. al. So, apart from contributing regularly towards assisting the entire team gain more clarity over each step right from Ideation to Growth, they could choose to stick to working and heavily contributing towards that one specific area they have a dominant expertise over. But having said that, there is no escaping PM work really and if one were to take a consensus on this, many PMs wouldn’t want to get detached either.
5. PMs are supposed to know everything about the domain the product belongs / caters to
PMs are mostly domain experts and have in depth knowledge of the vertical the product is associated with. So, considering someone who has spent a decade in say, Retail Banking there is a high possibility that he has an expertise in almost all things related to the commercial banking domain alongside having an in-depth knowledge of the business side of things precisely over the work he did / the product(s) he built.
Truth: It is more specific & personal in reality. When some PMs like to hit up the SMEs within the organization in an effort to gain a deeper understanding of the why and what of the product they are building as they believe that it would put them in a zone of comfort, there could be many other PMs who get more deeper into the domain and follow topics online and partake more interest as a personal choice and it could have absolutely nothing at all to do with the success of a given product they built.
More than knowing information what could be more important for a PM building a product in a particular domain would be “having & working with the precisely right amount of information leading to factoring in all the required nuances”.
6. PMs are all MBAs from Tier-I universities
The role of a PM is of high agency & high visibility. So, when talking in the parlance of PM, it is only but natural for large sects of the market to think highly of the role and those notions don’t stop there. In the same vein, there is also a similar kind of a perception about the salaries they make and the Ivy-league degrees they hold.
Truth: Not all PMs are MBAs and this is proven beyond doubt based on the interactions I have had with the PMs across the hierarchy over product communities. What’s more, it is also popularly believed that any MBA degree (let alone a fancy one from a top tier university) would not really help in one becoming a good PM, which is also proven across many a survey and exchanges on Twitter.
MBA degree and a fancy one too from a TIER-I university may certainly help you get a foot in the door and help you land your first job. But, when most of the large organizations / MNCs still underpin on qualifications and it is hard to miss as it is highlighted in bold somewhere even as a part of the JD (TIER-I university MBA only), most of the start-ups & product-based organizations who hinge on PLG (product-led-growth) following all the best practices they should be in envisioning, building & scaling products and their teams, don’t really care too much for fancy degrees and qualifications and that is true for most part of the world as of today.
But, having said that one ought to embrace facts & reality as it could be a crazy race and totally heated-up, a boiling pot kind of a scenario when interviewing for these organizations as the talent pool & the competition would be top notch. FYI, over the past 4 yrs., the rising interest & trend in the no. of people taking to product management has prompted even the best universities across the world to curate special courses (6 months – 1 year) that are focused on Product Management alone.
7. PMs have to be hands-on with technology
When one talks of products today, the reference is either towards hardware / software related products and almost all of these are built using some kind of technology, some latest & disruptive too. When the Tech used may differ with each of these products, there is a myth that a PM has to be hands-on with Tech and only then can he fit in to the whole ecosystem and at some places PMs are expected to code as well.
Truth: When nobody asks for hands-on experience in technology for a PM, there are some people who transition from Tech & coding backgrounds who think they feel comfortable with the so-called Tech advantage they bring to the table, but eventually that turns out to be a curse than a boon. Reason is, the propensity to start thinking from the perspective of design, architecture, databases, process flow et. al. when there is a need to focus on problems, markets, users and all from a much higher level.
Also, the inclination to jump right into and narrow-in on solutioning could hamper the vetting process of the entire idea which may eventually go unevolved – which is a major antipattern.
Having said that, a position like TPM (Technical Product Manager) is one place that may use up skills previously gained from Tech.
8. PMs have nothing to do with the success / failure of the product
Problem solving and solutioning could be the major areas for anyone working within the confines of a product. It often happens that someone with a background in software architecture / solutioning who was working in a team contributing at stage(s) of product development just worries about building a product that solves one particular problem. So, the natural extension is to go by having absolutely zero onus over the business outcomes - the success & failure.
Truth: Product management has just so much more to it than just product development. One of the first things that PMs have to do / be good at doing is to identify and define the success criteria of the product they are building by measuring outcomes tangibly and putting a time & price over the growth of the product post release evaluating it over the effort, resources and operating within allotted budgets.
Desirability, Feasibility & Viability do make a lot of sense here right at the start and PMs in reality do own a lot more than just being accountable for the success / failure of the product.
9. Everybody in the team reports to the PM
Often the phrases “management” / “manager” in the job role tends to confuse people as they enter into product management. The perception that all teams & members report into the PM is a biggest myth of all time. Also, it may feel like an endless ocean without a sign of the shore anywhere as every team that is present in the organization works well in silos contributing to the overall cause & there is nothing that one is chiefly managing.
Truth: Starting out as a PM it is only but natural that one feels like the loneliness of a long-distance runner. This could be because one would have to get down to work all by oneself wrt building & gaining clarity over each aspect of the product right from a stage of absolute clutter / mess to a workable action plan via a strategy, roadmap, backlog et. al.
But, there is absolutely nothing to be alarmed about. You should have all your teams right from CS, Design, UX Research, Tech / Devs, Marketing, Sales et. al. at your disposal and the right approach would be to blend in well with all those teams, members and collaborate seamlessly. You won’t have anyone reporting to you and that’s why you’d have master to “influence without authority”.
10. PMs generate ideas all by themselves
PMs work many a times could mostly deal with generating tons of ideas and choosing / prioritizing one amongst all of them that fits in well with the goal / higher purpose aligned with the organizational goals. And, this factor alone could lead to a lot of new entrants feeling / getting eternally lost in a maze, psyched, roadblocked over a complete a lack of direction and not knowing how to approach it all.
Also, given the fact that it is one person’s idea could lead to some kind of a disconnect over building it as Design, Devs & UX teams may not connect well with the concept which is crucial for the success of the entire product.
Truth: Ideas can be generated alone, no doubt. But, that’s often not a requirement nor the central goal when it comes to a PMs job. When some PMs are able to generate great ideas all by their own, it is still better to put it out there and throw it open to the team(s) being completely open for brainstorming and discussing what everyone thinks the Pros & Cons are. There is no better way to factor in variables / parameters that you might have missed out on and also enable a platform for seamless exchange of thoughts from all the teams.
Also, there is no better way to help gain a shared understanding.
11. PM & product development aren’t connected at all
If it is not like there was enough confusion over what product management entails, what is in and out of scope, there is often lack of clarity over who owns the product development activity – the build phase of the product when it chiefly is to do with Engineering and come under the direct purview of the SEMs aka Product Development Managers in some places.
Truth: It is untrue to think that PMs don’t have anything at all and are completely disconnected from product development. In fact, what could product management even mean without involving development / building the product. But, that doesn’t mean PMs get involved actively in the product development activity from scratch. PMs do build a roadmap, backlog, features, user stories, definition of done and are involved in planning the entire build phase defining the “What to build” when they closely work with SEMs (Software Engineering Manager) and build a shared understanding of the requirements, who then work with the DEV teams building them in silos.
But, in some organizations PMs may actively get involved in product development sometimes even get down to architecture / writing code and they may be called TPM (Technical Product Managers) and it mostly happens at places where the product in question is a Platform meant for use by other Engineers.
A good PM learns quickly about the demarcation and the necessity to draw the line between understanding what his work entails and leaving the other Tech / build related decisions to the respective experts in the team entrusting them to do their jobs well.
12. PMs actively contribute in architecting the product
In defining the “what to build” some PMs especially could get much deeper into spelling out the backend design, APIs, process flows, information architecture, communication channels, protocols, front-end, UI design. There are actually blurry margins in some organizations over this as well contributing a lot more to the overall confusion.
Truth: Given today’s way of work, talking of fitting the best man for a given job, any Tech team normally would have a hierarchy comprising Designers, ENGG / Developers, QA, Architects, PO (Product Owner), SEM (Software Engineering Manager), Project Manager, Product Manager. In the true sense of the word, each of these have their purpose defined around their deliverables and none of these roles are interchangeable without overloading a particular resource. When PMs job remains to be more strategic and a bit of the tactical side defining the “what to build”, Software Architects are experts in detailing it out and defining everything related to high level design and coding standards, platforms to be used et. al. so that the Dev teams could incorporate that knowledge effectively to finish the build smoothly sans hiccups.
Bonus Points
13. Product management & Project management are one and the same
Though most of confusion is clear wrt a larger audience who are aspiring Product managers there is still a bit of it remaining in a few organizations as it is abundantly clear with the way some of the JDs are written. Also, in some places the use of acronyms adds fuel to the fire as they both turn out to be homophones - PM.
Truth: Product management takes complete ownership and directly governs a larger aspect of the whole product right from the Ideation, Planning, Strategy, Roadmap, Backlog to the Build, Release, Growth stages whereas Project management deals with governing the build cycle over management around minutes, internal team meetings, tasks, resources, timelines, deliveries et. al. more aligned with the People management side of things.
14. Product owner & PM are interchangeably used designations
Often the confusion between the PM & the PO comes down to defining the accountability bit and the ownership in specifying a scope around who owns what part(s). The fact that some JDs use these terms interchangeably don’t help much either.
Truth: Though in some organizations PMs are known to participate in daily stand ups from time to time, the majority of times it is the PO (Product Owner) who takes up this activity. Talking of Agile, the Product Owner’s role goes into picking Epics and elaborating them to build a certain degree of clarity for all Dev teams to operate with over writing User Stories and defining Acceptance Criteria / Definition of Done.
15. PM & BAs are almost the same as former is an extension of the latter
It is only but natural to think that someone playing the role of a business analyst right now would transition into product management next. There is a bit of an overlap between the 2 roles & it shows over the skills required to do either of these jobs.
Truth: When it may be true and also the way of the world that some people who played the role of a Business Analyst went on to take up Product Manager roles, there is a clear differentiation. The transition from BA to PM isn’t a given either. When the scope of a BA is more oriented / often times limited towards solutioning starting off with the gathering of requirements & gap analysis to get to understand user’s requirements properly and define a scope of work, the PM has a much bigger purpose that he’d have to worry about apart from requirements and the build activity.
And having said that some qualities / traits like Empathy in dealing with the user’s requirements and not taking them verbatim to build solutions, influencing stakeholders / members of internal & external teams, playing the role of a SPOC (single point of contact) does come in handy for a BA stepping up to a PM’s role.