Business Analyst to Product Manager
The traditional role of a Business Analysts in product development typically comes with responsibilities of liaising and communicating with product teams, engineering teams, end users and business stakeholders. The business analysts have domain knowledge in their respective field (insurance, banking, retail, healthcare etc.) needed to translate the requirement of end users/business stakeholders to the engineering teams. The role of business analysts exists in cases where the client owns the product (or product owner is from client organization). In such cases, the business analysts play a role of proxy-product owner.
Let us see what gaps business analysts need to bridge to take on a role of a product manager.
Skills of Business Analysts
The business analysts play an important role in any project as he/she converts all discussions, workshops, brainstorming sessions from end users and business stakeholders to requirements for the engineering team. The business analysts also analyse the existing and new requirements for positive or negative impact to project schedule, timeline. A great business analyst has an extensive analytical skill to analyse the data, workflow, documentation from users and create outputs (requirement doc/user stories) for engineering teams to consume. The business analyst is also a great communicator who can help directing the team, solving problems and forecasting. The business analyst uses data modelling practices to analyse findings and make recommendations for strategic and operational improvements.
Business Analysts have expertise in creating use cases, functional specs, business process modelling, rules, requirements documentation, and end user training documentation. In today’s world where there are many starts ups then ever before and the roles of business analysts are non-existent almost. In such organizations, product managers create the vision and product strategy. There is also a confusion about distribution of roles and responsibilities between business analysts and product owner. There are some roles which business analyst can also play instead of a product manager like story boarding, backlog refinement, acceptance testing, story writing, cost benefit analyst and tactical focus. If you need to move from a business analyst to product manager role, then creating business strategy, competition analysis, market analysis, defining product/feature priorities, strong focus on customer is some of the key skills that you need to develop. Identifying and bridging the gaps (mostly skills) can help you take on the product manager career path.
Product manager is a custodian or CEO of product in an organization. He/she identifies the customer needs and defines the larger goals that the product will fulfil and effectively articulate how the product will fulfil the goals. Product managers manages the product across multiple disciples like user experience, engineering, and business. It is the responsibility of the product managers to manage or make trade-off between the three disciplines for creating a successful product. Product managers set goals, envision success and motivate the team by defining outcomes. In a smaller organization, product manager role would be hands on like defining vision, set objectives when compared to larger organization where the product manger work with team of specialists, research analysts, marketing analysts to help in charting goals and objectives.
Indeed.com lists 2200+ jobs as product managers across the world. If you are playing a role of business analysts, have solid understanding and representing user needs, develop competitive, market analysis, help in prioritize product features and capabilities, then it becomes easy for you to transition yourself to a product manager in any domain. Even if you are a business analyst, develop the skills of knowing the product landscape, prioritization techniques, influencing without authority, facilitation techniques. These skills will come a long way in propelling yourself to a product manager role in your current or future organization.
Organizations across the globe are embracing agility using different methodologies and frameworks to meet customer demands and improve time to market. Scrum is one of the most popular frameworks within which people can solve complex adaptive problems, while productively and creatively delivering products of highest possible value. Scrum was developed to work best within a team size of 5 to 10 members and has to be cross functional to be effective and efficient. It becomes easy for the Scrum team to achieve synergy and resonate with each other if the team is collocated further. The Product Owner, Scrum Master and Development team work in tandem with fewer problems to deal with however and can release most valuable features quickly. The challenges and impediments increases with the addition of every Scrum team. There is also a general myth that Scrum may not be suitable for large scale projects or programs and people recommend or prefer other methodologies like LeSS or SAFe.
Challenges with Scrum in Large Program/Product Development
Can Scrum be used for large programs (involving more than 5-6+ scrum teams) and still address top priorities like fulfilling customer needs, improving time to market and reducing cycle time?
The answer is "YES"
Nevertheless, some of the questions that comes to our mind quickly when we think of scaling delivery using Scrum are below,
Let’s look at how the roles and artifacts are scaled when it comes to large scale product or program development using Scrum
Scrum Master and Development Team
Scrum guide mandates a small and cross functional team of 6-9 members for effective delivery. When the program demands more features to be developed in shorter time frame, one of the easiest way to achieve this to scale the team members to multiple scrum teams. This allows the scrum teams to pick up independent features from the product backlog for quick turnaround. Similarly, the scrum master could also be scaled to take care of the individual teams. However, it is up to the organizational maturity in agile adoption and execution as how many scrum masters are needed for a particular program setup and sets of teams. The scaling of the development team and the scrum masters will certainly help in development of features to meet the vision of the product.
In paper, Product Owner is just one person who is responsible for the product vision and maximizing the ROI. But in real world with complex product development, it’s often a shared effort and ownership. There needs to be an understanding on how to develop the product without hassles and inconsistencies through shared ownership between the Product Owners.
In general, when the product is new (in early stage) and hasn’t reached product-market fit—or is close to achieving it—one product owner will be the best person in charge of the product. This is due to the level of experimentation it requires during this stage and effective decision making is of paramount importance. Having multiple product owners during this stage would dilute and elongate the decision making process leading to ineffectiveness. At this stage, the single PO could help in making decisions quickly without wasting time in the process. When the product growth starts after entering the market stage, more features will be needed and it would become difficult to manage the product with single product owner. In that case, it would be good to have couple of product owners to manage the product. During this maturity stage, changes would be needed less frequently allowing the product owners to prioritize the changes and share the responsibilities easily.
Product Backlog is prioritized list of items or requirements needed to fulfill the product vision. Product Owner owns the product backlog and ensures that the Product Backlog Items are stacked in the order of priority to maximize the return on investment. In the Fig 1.1 shown below, during the initial stages of the product development (entering market fit stage), it is imperative that only one product backlog exists for the teams to work on. The product discovery stage is a separate journey altogether which involves user interviews, impact mapping, what and how to develop and prioritization techniques. When the product evolves over period of time (as mentioned above) or enters maturity, the product backlog can be owned by multiple product owners for managing and prioritizing features effectively.
Sprint Backlog will have prioritized list of features needed for development for that sprint towards achieving the product vision. The prioritized list of items will be picked up by the individual teams for development of the product features during the sprint planning meeting. Individual teams can have sprint planning meeting separately (to save time) along with Product Owner & Scrum Master to prioritize what is needed for the sprint.
One Product Increment is always recommended during the initial stages of the development of the product to ensure the minimum viable features are integrated well. This helps the product owner to quickly validate the assumptions about the product. Having single product increment hashes out all the issues with dependencies and integrations and enables users to validate the functionality end to end.
The Scrum ceremonies like planning, refinement, retrospectives, reviews can be done separately by the individual team along with PO and other stakeholders. You might wonder how the dependencies across the teams will be resolved as there is no common meeting to discuss those? Well, Scrum of Scrum can help the development teams to sort of internal dependencies where the Scrum Masters from individual team’s members represent to discuss about the dependencies and work towards resolving them.
There is also no doubt that Scrum would definitely be an ideal fit when it comes to large scale product development with some considerations listed above. The Scrum Framework is very light weight and has lots of process built within for a great product development. Although other scaling methods exists like SAFe, Less, [email protected] etc. the organization need to carefully consider the options to better suit their culture and the nature of the product being developed.