From Business Analysis to Product Management

The transition from business analysis to product management happens often and naturally. I started as a Developer, then became a Business Analyst, and finally got promoted to Product Owner. During this journey, I faced many challenges I wish I had known before so that the transition would have been more natural. That’s why I want to share my learnings from this experience with you.

My story comes from a Product Owner's perspective, but titles don't really matter. Sometimes you may be called Product Owner or Product Manager, but the point is the job you do. The job is all about maximizing value.

Now, let me walk you through my learnings.

Why does this transition make?sense?

The role of a Business Analyst is broad, which means that companies may use this name for different activities. However, the primary definition has some similarities with the role of a Product Owner; that’s why the transition can happen smoothly.

A business analyst’s primary objective is helping businesses cost-effectively implement technology solutions by precisely determining the requirements of a project or a program, and communicating them clearly to the key stakeholders.

— Mayank Pratap, Roles and Responsibilities of a Business Analyst

What about the Product Owner role? Bob Galen’s way of describing the Product Owner role with four quadrants is my favorite:

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Some responsibilities between a Product Owner and a Business Analyst overlap. However, we need to pay close attention to more details in a transition. Still, the shift makes sense and can happen smoothly.

You will face some challenges, which I want to warn you about before you move. Allow me to share them with you.

#1 - Focus on Communication over Documentation

When I was a Business Analyst, I used to work within the traditional software development approach. The process was time-consuming and extensive:

• Business Analyst writes the requirement document
• Sponsor approves the requirement
• Development Team follows the instructions
• The QA Analyst tests the development
• The Release Manager releases the software

In the beginning, I was skeptical if it would work because the process was so lightweight. It was complicated for me to move from a traditional approach to the Scrum Framework. However, the vital part was understanding that communication is a crucial point for a successful team.

As a Business Analyst, I would spend 20% of my time with developers because the focus was on following the process. With Scrum as a Product Owner, I spend a minimum of 30% of my time with the Scrum team. Surprisingly, the team’s productivity skyrocketed because collaboration fosters engagement and motivation.

Individuals and interactions over processes and?tools— Agile Manifesto

#2 - Be Part of the?Team

In my scenario as a Business Analyst, I was part of a business team. In this case, I was separated from the developers, which created silos. Business Analysts focused on the strategy, requirements, and so on, while developers focused on building software. We didn’t interact much; our central communication was to discuss requirements details and ensure the same understanding.

As Product Owners, we are part of the same team. It is vital to understand that we are on the same level as the other members. Some Product Owners believe this role is at the top of the team; this is a vast misunderstanding. As a team, we are all responsible for the outcome. Therefore, the Business Analyst in the transition to the Product Owner needs to learn how to be part of the Scrum Team.

#3 - Avoid thinking about everything upfront.

When I was a Business Analyst, I was used to writing extensive and in-depth documentation to ensure all the edge cases and business rules were covered. Also, I needed to get formal approval from the sponsor. Then developers would be able to work on it.

The document would have all details, including wire-frames, business rules, and so on. Sometimes the documents would even have technical information like the entity model relationship. Developers followed the instructions; there was no room for discussion.

Skipping extensive documentation was something I needed to change drastically; I couldn’t understand how a team could work without that amount of information. I also didn’t understand how the business would accept something without formal approval. It was crucial to understanding the Agile Manifesto; it was a massive change of mindset, which took the whole team to a higher level.

Working software over comprehensive documentation— Agile Manifesto

In Scrum, there’s no requirement document; instead, there is the Product Backlog, which has the Product Backlog Items. They represent the work developers will do to achieve the Product Goal. An excellent Product Backlog Item is no more than an invitation to start a conversation.

A great Product Backlog Item starts a conversation. The goal of this conversation is to establish a common understanding. It is impossible to perfectly describe what you want to build. The best you can do is try to get everyone on the same page and reach consensus in their mind.

— Maarten Dalmijn, Great Product Owners write awful backlog items

#4 - Decisions

Business Analysts generally don’t make the final decision over a requirement, which was my case. I could neither approve a requirement nor define which was a priority; only the sponsor or someone else defined by them could make such decisions.

In the role of a Product Owner, the scenario is different since Product Owners make many decisions daily. The Product Owner is responsible for the product direction, thus being accountable for the Product Backlog and defining what has to be done and what will not be done. The Product Owner also decides when it makes sense to work on each Product Backlog Item.

In this scenario, during a transition, the previous Business Analyst will need to exercise how to make decisions and be accountable for those.

#5 - Learning Speed

While I worked as a Business Analyst, we tended to assume we knew everything upfront. Therefore we never talked about learning as the development of the product evolved. As I mentioned earlier, the process was heavy, which means releases took a long to happen. On the other hand, a Product Owner must accept that there are many details we don’t know. That’s why we need to release new increments as often as possible to receive feedback and adapt the direction.

Responding to change over following a?plan

— Agile Manifesto

Scrum is an empirical process, which means we accept that we don’t have all the answers upfront. We admit we build knowledge as we gain more experience. Therefore, making short cycles increase the chance of learning faster.

Learning fast was a significant change for me; it took a while to get used to it. However, now I cannot imagine working as before; there are endless benefits with smaller cycles. The most significant benefit for me is avoiding waste since we focus on smaller increments, then we receive feedback and adapt the direction quickly.

Final Thoughts

The transition from Business Analyst to Product Owner can be pretty smooth if we understand what we need to avoid and what we need to learn. Be sure that as a Product Owner:

• Communication is the most critical part; forget about extensive documentation.
• Be part of the team. Spend at least 30% of your time with them.
• Use the empiricism in your favor. Accept that you don’t know everything upfront.
• Learn constantly with the team through collaboration.
• Be ready to make decisions as well as be accountable for them.