How can a business analyst prepare to be a product owner?
Business analysis provides a natural foundation for product ownership. Here's how you can build on that strong foundation to become an effective product owner.
Recently a connection on LinkedIn asked me an interesting question:
After working as a Business Analyst and Project Manager for several years, I've discovered that many of my previous tasks actually fit the Product Owner role perfectly.
So yesterday I applied for a Product Owner role. I'm hoping you can provide a pros/cons overview to help me determine which skills I still need going forward and how to obtain those specific talents...
This is a great question, and I thought for sure I would’ve answered it somewhere before. After all, filling product owner roles with project managers and/or business analysts is a common pattern.
Strangely, I have not written directly addressing that topic. The closest thing was an article titled What product owners need to know about business analysis.
So I decided to tweak that article, to answer my connection’s question.
First a caveat
One issue I’ve found with many articles for product people is that the author doesn’t clearly state the context the article assume. Product work in different situations has a lot of similarities, but there are also key differences.
When I originally wrote this article the implied context was organizations that build software for their own use. Partly because that’s my background and partly because that context is more likely to have business analysts and where product owners may make sense.
I’ve made some revisions to fully lean into that context in this retelling.
Business analysis: the foundation for product ownership
Once you start product ownership, you need to practice three habits to be an effective product owner:
Focus your team on outcome over output
Build a shared understanding
Make sure decisions gets made
The skills you bring from your previous experience are all helpful toward adopting those habits.
I’ve found that a good foundation of business analysis skills can be particularly helpful in becoming an effective product owner.
To see how that may be the case, consider this definition of business analysis from the Guide to the Business Analysis Body of Knowledge (BABOK):
Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.
So you’re going to need your business analysis skills and you’re going to need to know how best to apply those skills to product management responsibilities.
Here’s a look at how business analysis skills can help you with each of the three habits I mentioned above.
Focus your team on outcome over output
Outcome is the change you’re trying to introduce to the world. It’s why you’re creating or changing a product. Outputs are the things you produce in order to satisfy that need, or the solution.
In order to focus your team on a particular outcome, you need to know what that the outcome is, make sure everyone on the team has the same understanding about that outcome, and have a way to check whether you’ve satisfied that outcome.
A key aspect of business analysis is to clearly understand why you are doing the work you are doing – this is a way of identifying the outcome.
I’ve found techniques such as the problem statement and opportunity assessment to be helpful in not only identifying the outcome, but also a way to guide discussions that help everyone on the team understand that outcome and how their activities relate to it.
The best way to know whether you’ve satisfied an outcome is to measure progress and success based on that outcome.
One way you can measure based on outcome is to establish clear, measurable business objectives that you can use to gauge progress and success.
Build shared understanding
Shared understanding answers two questions:
Does your team understand the outcome you’re trying to deliver (discussed above)?
Do you all agree about the characteristics a solution should have?
The act of building a shared understanding in a collaborative fashion is just as important as the resulting shared understanding itself.
The conversations that occur during this process give your team a clearer understanding of the problems users and stakeholders face, and identify risks and assumptions that are relevant to an effective solution.
This is where business analysis skills are the most helpful. Most elicitation and analysis techniques get everyone on the same page about what the problem is and how you’re choosing to solve it.
The business analysis techniques that I’ve found most helpful as a product owner include:
A variety of models including process flows, wireframes, report mockups, and data models
The value of these techniques is not the resulting output, but as aids to a conversation.
You’ll find it’s easier to build a shared understanding when you involve your team, including stakeholders and users, in a conversation where you talk, draw, erase, question, and consider using the techniques.
A whiteboard (or electronic equivalent) is definitely your friend when using these techniques to build a shared understanding.
Make sure decisions get made
Once you have a shared understanding of what you’re trying to accomplish, the next thing to do is provide guardrails for the decisions that team members make.
While the leaders of your organization make key decisions, such as whether to create or update a product or not, you and your team make many decisions on a day-to-day basis that impact the product.
In order to make sure you and your team makes effective decisions, you need to keep those decisions in line with your shared understanding of the outcome your product delivers.
One technique that is extremely helpful for providing guardrails is decision filters. You also need the ability to work with stakeholders and your team to identify the information necessary for decisions and to reach those decisions in a timely manner. The facilitation skills included in business analysis can be extremely helpful in those situations.
How you can pick up these skills
If you come from a business analysis background, you’ve got a head start on those skills, but you may feel you can always get better.
I’d like to humbly suggest a couple of resources you can use.
One of those resources is a set of videos I put together. Analysis Techniques for Product Owners is a set of video training sessions that show you how to apply analysis techniques to product ownership.
Analysis Techniques for Product Owners is available on Safari – O’Reilly’s online learning platform. Sign up for a 10-day free trial to view the video lessons.
If reading is more your thing, check out How To Be An Agile Business Analyst. Don’t let the title fool you. It’s really a hand book for applying business analysis techniques in a product owner role.
I even used it as the basis of a book club for a group of product owners.
The path is more common than you think
There are a lot of paths into product ownership. I’ve always thought that coming from business analysis was a no brainer because that’s the path I took.
For the longest time, I didn’t see many people writing about it so I did some research to find out if the move was as common as I thought it could be. I summarized what I found in Business Analysts Can Be Product People. There are some good tips in there for people who made the move from business analyst to product owner to product manager.
I also saw some recent confirmation that moving from business analyst to product ownership was a good idea from Steve Johnson. He suggested that having business analysts fill product ownership roles may work better than asking product managers to do it. I’ll leave the argument over whether you should have both product managers and product owners working on the same product for another day.
What’s your experience?
Did you move into a product owner role from a business analysis job? I’d love to hear about your experiences, successes or challenges.
Thanks for reading
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.
Talk to you next time,
Kent J. McDonald
Founder | KBP.Media