The following are difficult archetypes within a product managementĀ organization:
- The People Pleaser
- The Scope Wiggler
- The Patent Author
- The Napkin Sketcher
- The Executive Assistant
- The Sales Liaison
- The Dictator
- The Scope Creeper
In a Software Development organization, the job of the Product Management team is to define the business requirements for the software. There are no set standards for how Product Managers do their job, but generally they will have access to project stakeholders such as executives, salespeople, and customers that provide the insight they need to document the business value the software should provide.
Product Managers can be a center of controversy on a project as they are the first step in the Software Development Life Cycle (SDLC). Any wrong decision they make – no matter how small – affects the entire project. Furthermore, if they attempt to correct any wrong decision, the resulting changes can have rippling consequences throughout the entire project including the project schedule, UI design documentation, technical design documentation, software implementation, and test plans.
As Product Managers tend to have business backgrounds, they often struggle to provide specifications with the level of accuracy required for the software developers to precisely develop the software. This often leads to a contentious relationship forming between the Product Management team and Software Developers on the project. The heart of most debates on which software development process to use (Waterfall, Agile, etc.) is the desire to cross the divide from the non-technical Product Managers to the highly-technical Software Developers.
Where are the BA’s? Where are Clients/Business representatives? š
I had a tough time picking the right level of granularity for the roles, but ultimately settled on 6 buckets that were focused enough to understand, but broad enough to lump several roles into. In the case of Product Managers, I lumped in BA roles as well as account managers; in the case of Designers, I lumped UX and Graphic Designers together; for Developers I lumped developers and architects together. Certainly not a perfect classification system, but I hope I cast a wide enough net to be useful.
Thanks for the answer! Fantastic idea and great job I must say. Unfortunately as a BA in a software house I cannot say that my role can be merged with account managers at all. It seems that you never experienced work with a BA :). Of course under umbrella of Product Managers we are closer to the point but.. in most of the cases Product Manager is on the client side while BA is on the contractor side (or both) however all of them have another “problematic characteristics”. I just wondering how many and what types of BA’s you can find.
No two companies will define a “BA” as having exactly the same scope of responsibility. For example, I’ve worked with BAs who only wrote agile stories; as in, they didn’t actually have any say over the product itself. I’ve also worked with BAs who were pure SMEs, and didn’t do anything related to documentation; they were just there to act as readily accessible experts should the developers need them. I’ve also worked with BAs who were marketing focused, in that the were focused on finding an characterizing competitive threats and opportunities more so that a specific product itself.
Ultimately, a “Business Analyst” is extremely broad term, much like a “Data Scientist”. There isn’t much industry consensus as to what exactly constitutes someone who analyses the business (which business? whose business? what type of analysis?), so companies are free to interpret the role to fit their needs. That said, I haven’t experienced a hard delineation between the responsibilities of a “Product Manager” and a “Business Analyst”, but have seen quite a bit of overlap in the definition of the roles company-to-company. As a result, I felt it was acceptable to conflate the roles as I did with other roles.
With regards to “what types of BA’s I can find” for every role I am getting that same feedback: people want me to dig deeper and get more granular. Perhaps over time the definitions will expand, but I believe I will need community feedback to go much further than I have with the 48 definitions. I wanted to document what I had encountered in the wild, and my rule for each was that I had to encounter that personality at least 3 times. That’s a fairly high bar, and at this point in my career 48 is the limit of what I have identified. I have been thinking of creating some type of community submission system, so that people can debate new submissions to figure out if something is an archetype of just a one-off quirk they encountered at a specific job. What do you think of that idea?
There are a few anti-patterns here and the traits you described are typical of a junior PM and should be ironed out by the time youāre a mid to senior PM.
A good example here is the lack of collaboration with the software team.
In my team, we practice what we call the ātriadā. Design, product, and engineering come together to discuss a feature together. Doing this process in isolation will lead to a loss of context for each part of the team.
The triad works in the following way:
The PM will craft a story that takes the team along the customer journey. They should be aligning this to the teamās mission statement and vision statement (agreed to together).
The engineering team can then provide inputs around technical capabilities and limitations and how they would implement the features.
The design team can then start putting together the visual treatments that accompany the story the PM is telling with the technical inputs from the engineers.
Now we have alignment on feature set.
The next anti-pattern here is how deep the PM is going with requirements.
The PMs goal is to set vision and inspire the team to deliver value. The development of a technical specification is best suited to either a BA or the engineering team.
When writing user stories, the PM should be articulating the value a piece of functionality brings, and then the acceptance criteria should cover the desired outcome of using the feature.
For example, letās say weāre creating a software for an ATM.
The vision is to create a user experience on the ATM that is just as good as going to a human teller.
Features for this include the ability to authenticate your account, view your balance, withdraw some money, deposit some money, and transfer money between accounts.
Letās look at the authenticate feature:
Story: As an account holder using the ATM, I want to authenticate my account prior to transacting, so that the bank knows it is me using the ATM
Acceptance criteria: a user inserts their card and is prompted for a 4 digit PIN. If they enter the correct pin then they are presented with the āchoose transactionā screen. If they enter the incorrect pin, they are shown an error message and asked to re-enter the pin.
Now there is enough detail that the technical team can develop their technical tasks around. They should be deciding things like the hashing algorithms, any protocols that need to be used.
I think the crux of the problem here is hiring the right PM for the team. If the SDLC and technical depth is extremely important to the team, then a PM with software experience should be part of the hiring criteria.