3 Lessons Business Analysts can Learn from Product Managers


After doing business analysis in the tech industry for ten years, I’ve spent the last 2 years as a product manager. During this period, I’ve realized there’s more in common between the roles of IT business analyst and product manager than I had expected. On the other hand, there are also some aspects of the job that translate into valuable lessons for any BA interested in increasing the value they deliver to their organizations:

1. Clarifying intent and desired outcomes is critical when communicating software requirements.

Too often business analysts focus on describing the functional and non-functional requirements for a solution, with little or no time dedicated to making the intent behind those requirements explicit. Product managers, on the other hand, know that there are always more to build than there is time, and that in order to get buy-in for their ideas, they need to produce evidence that an opportunity is indeed promising. For this reason, product managers tend to spend considerable time making business outcomes explicit, and validating that their requirements will indeed support the achievement of those outcomes.

Business analysts can deliver more value to their organizations if they think more like a product manager, and spend time clarifying and communicating the intent behind each new proposed feature. Sadly, that’s not a common practice even in agile environments, where the “why” is supposed to be explicit in each user story.

Consider the story, as a customer, I want to be able to sign up to back-in-stock alerts so that I can be notified when an item I want is available again for purchase. The hidden expected business outcome here is to increase the profit of the webstore by reducing the number of lost sales caused by sold out items. By clarifying this expected outcome, a business analyst can investigate whether this requirement will indeed produce value for the company before resources are allocated to implement the feature. For instance, imagine that this particular webstore specializes in holiday gifts. With a bit of analysis, the BA could determine that practically all sales happen within a few weeks of any given holiday, and the likelihood of a sold out item to be placed back in stock in time for a lost sale to be recovered in this timeframe is negligible. The BA could now go back to the stakeholders who asked for a back-in-stock alert armed with evidence that it will not produce the desired outcome. The development resources that would have been assigned to building this feature could then be redirected to the implementation of another feature capable of delivering true business value for the organization.

2. The key to building valuable and useful software is to focus on jobs to be done rather than features.

Many IT business analysts see as their chief responsibility the creation of software requirements that are complete, unambiguous, testable, and feasible. They will spend the majority of their time creating and perfecting artifacts such as software specifications, user stories, process diagrams, wireframes, and seeking sign off for those deliverables. Product managers, on the other hand, know that until you have developed a real sense of empathy and understanding of the user needs, there’s little value in documenting software requirements.

One of the first things I learned as a product manager is that the Jobs-to-be-Done Framework is a powerful tool to help companies build the right software to satisfy business and user needs. The framework allows us to look at the motivations of customers in using a product, rather than on software requirements or feature lists. Users don’t adopt a product because it offers email notifications or 99.9% uptime; they adopt it to solve a problem. If, as a BA, you spend time understanding the “job” that your users are hiring your software application to do, and the things that challenge, frustrate, confuse, and delight these users, then you can help your organization solve the right problems and build more valuable and usable applications.

In one of my early consulting projects, I was asked to review and prioritize a list of 500+ change requests from users of an enterprise application, with the purpose of increasing adoption. The system didn’t solve the problems of the sales team well enough for them to decide to “hire” the software to do the job, so 80% of the sales team were still using local spreadsheets to execute the tasks that were meant to be performed using the application. The lack of user adoption caused problems for other teams who couldn’t easily access the information stored in the local spreadsheets.

By doing interviews and observing the users do their work, I was able to identify the root cause of the problem that had triggered the largest number of change requests. Turns out the users had to access information in the application while speaking to customers holding a traditional phone headset. They quickly got frustrated trying to hold the phone to their ear while typing search terms and navigating the screens. Instead of making costly changes in the user interface to enable users to perform their tasks in the system using one hand, a better solution was to equip each workstation with a hands-free headset. This simple change enabled users to have both hands free to interact with the application, eliminating the pain they were experiencing trying to hold the phone while using the system.

Good product managers know that adding new functions or workflows to an existing software application should be a rare occurrence. To achieve better results on their software projects, business analysts must develop the same discipline product managers use to validate that a requested change will truly make things better for users. Dedicate time to understand the problems users are trying to solve and the way they work today, and collect facts and observations about their pains and joys. Then use this information as a springboard for brainstorming solutions and validating that the solution that you or your stakeholders have in mind does solve real problems.

3. To get your ideas recognized and adopted, you need to sign up for sales.

I come from an engineering background, and it took me a long time in my career to finally recognize that becoming a master salesperson is the key to making significant improvements and solving problems others would think impossible.

As a product manager or business analyst, if you’re making an effort to clarify intent and desired outcomes for your projects, and developing in-depth knowledge of the jobs your users need done, you’re naturally going to develop your own ideas about what will truly solve the business problem or make things better for users. And it’s quite possible that at least some of those ideas will not match what other stakeholders had in mind for the product or initiative you’re working on.

Like business analysts, product managers typically have to rely on influence rather than authority to get their ideas heard. However, while many business analysts I know like to say they “hate politics”, effective product managers understand and accept that “politics is the art of getting things done”, and that championing your ideas means signing up for sales.

Business analysts often tell me they wish they had more influence with their business and technical stakeholders. They can’t get managers to show up for meetings to review project requirements, or enforce agreements with other departments, or align leaders behind a proposal. Many of those BAs stop trying to make change happen because they believe it is too difficult, if not impossible. As a product manager, I learned that there is a handful of high-leverage behaviors that can lead to rapid and profound change in thoughts and actions of your stakeholders. Here are some of things that can help you get better at influencing others:

  • Become a serious student of the art of sales. I’m now a faithful listener of The Advanced Selling Podcast, and a regular reader of books describing the principles and skills that successful influencers use.
  • Examine the times when you have succeeded convincing others, and try to identify the force or strategy that led to your success.
  • When preparing to present your ideas to decision-makers, don’t forget to address the emotional side. Presentations that focus exclusively on hard data only provide direction without motivation for people to change. One of my favorite examples of how to get things done combining rational and emotional arguments is in the book Switch: How to Change Things When Change is Hard [1].

Looking back at my time as a business analyst, I have no doubt that it would have been easier to get buy-in for my ideas if I was spending less time behind closed doors analyzing problems and documenting solutions, and more time building the case for my recommendations. As a BA, I was good at dedicating time to interviewing and observing end-users to identify the best solutions for their problems, and at gathering hard evidence to support my recommendations. I was not nearly as good at building relationships with decision-makers and nurturing allies for my proposals, or at coming up with stories for my presentations to make the hard data more meaningful for my audience. Incorporating these aspects to my work definitely helped me become a more effective agent of change.

What about you? Do any of these lessons from the product management world resonate with your experience as a business analyst?

Author: Adriana Beal, Product Manager & Business Analyst

Adriana Beal has developed a successful career in business analysis and product management, having lead the investigation of business problems, defined winning solutions, and written requirements documents for a large number complex software projects. She is also the coach of Crafting Better Requirements, a program that has helped hundreds of business analysts improve their requirements documentation and communication skills, and the author of the ebook Measuring the Performance of Business Analysts, which has been adopted by dozens of BA managers interested in improving the performance measurement systems in their organizations. Her next ebook, designed to help BAs struggling with getting the right information to analyze and use to specify their solutions, will be called Tested Stakeholder Interviewing Methods for Business Analysts.

Footnotes/ References:

  1. Jon Stegner believed the large manufacturer he worked for was wasting huge sums of money in poor purchasing habits. His analytical case was compelling, but he knew he had to break through to feeling to get people to act. If things were going to change, he couldn’t just rely on spreadsheets, the savings data, the cost-cutting protocols. With these things, he’d probably have gotten some supportive nods, and executive agreement that overhauling the purchasing system would be an important thing to do… next year. Instead, Stegner collected a specimen of each of the 424 different types of glove that the company was purchasing from different suppliers, and piled them up on the conference table. The reaction was visceral, and soon Stegner had the mandate for the change he had sought, saving a great deal of money for the company.

Article image source: Fotolia © christianchan

Like this article:
  18 members liked this article


Scott Sehlhorst posted on Friday, September 18, 2015 8:56 AM
OUTSTANDING article, Adriana!

100% agreement here :)
Adriana Beal posted on Monday, September 21, 2015 6:55 PM
Thank you for the compliment, Scott!

It's always a great honor to get a "stamp of approval" from you :-).
Reidmanchester posted on Monday, December 21, 2015 3:38 PM
Fantastic point. Absolutely correct. As I look back on my time as a BA I invested far too much time documenting needs and designing solutions when the real effort should have been ensuring the real problem is clear and then gaining buy-in for the solution. Next article I hope you'll tell us your tricks for overcoming 'NO' when your solution is correct but contradicts what the sponsor thinks they need.
Adriana Beal posted on Monday, December 21, 2015 5:16 PM
Thank you, @reidmanchester, for the positive feedback.

It's great that you recognize the risks of excessively focusing on the analytical / solution design aspects. This often comes at the expense of truly understanding the underlying business and user needs and gaining buy-in for what you've identified as the real problem to solve. Just by understanding this point you're already positioning yourself for greater and more meaningful BA work :-).

As for your request for tricks on getting buy-in when stakeholders have their mind set on an inferior solution, stay tuned! This is a great idea for a new article. I believe Modern Analyst already has another article from me on the pipeline (a continuation of this article's topic that you'll probably enjoy as well), but I'm going to make your suggestion the topic of my very next article. You guessed right that I have some tricks up my sleeve that worked over and over in my career, and I'll be happy to share with the community here.
Adriana Beal posted on Sunday, March 13, 2016 9:58 PM
Check out

There you'll find my answer to your request:

"Next article I hope you'll tell us your tricks for overcoming 'NO' when your solution is correct but contradicts what the sponsor thinks they need."
osjo73 posted on Wednesday, October 5, 2016 11:45 AM
I agree with this articles premise with only one issue. As a BA our main job is to understand the problem domain, solution domain and help communicate this understanding to stakeholders. This does take some time and effort. My assumption here is there is no "analysis paralysis"; The analyst is spending the appropriate time analyzing problems, solutions, and helping to communicate the possible solutions.

It strikes me as a little much to ask the BA to be a "salesperson" as well as do their job in the same amount of time. Granted, if you have that skillset, this is awesome!!!!!!!!! Go for it. But now you are saying to be effective at your chosen career means you need the detail oriented, organized, analytical type person to ALSO be adept at marketing/selling. A good salesman can get you to buy ice in a snowstorm! A good BA should be focused on the business value/needs. Yes, being a good salesman would help to influence stakeholders. I just wonder if this line of thinking is asking the BA to become the "All knowing" and "All being" to be successful at their job.

Maybe I am over thinking this or maybe I am just stubborn. I am a good BA. I am an analytical thinker, I've learned to be an active listener, and I have a technical background; I love details. What are my weaknesses? I couldn't sell you ice water in the middle of Las Vegas during a heatwave!!!!!! Am I doomed?
Adriana Beal posted on Wednesday, October 5, 2016 1:49 PM
@osjo73: You are not doomed :-).

Accepting that "we are all in sales now" is about recognizing the fact that we, business analysts, to be effective at our jobs, have to be good at influencing others. In our daily routine, we have to convince stakeholders to provide the information we need to understand and analyze their problem, get them to drop requests that don't contribute to the solution, and so forth.

Being a successful influencer requires getting comfortable with the identity of someone who sells (not products, but ideas). If you're not convinced yet, I recommend reading the book "To Sell is Human: The Surprising Truth About Moving Others" from Daniel Pink. The author explores this wider definition of sales (which has nothing to do with being able to sell ice in a snowstorm, by the way!). It's a great resource to help BAs improve their ability to influence others and get their ideas heard.

Thanks for leaving your comment!
SeasonedBSA posted on Tuesday, August 28, 2018 12:06 AM
Hi Adriana,
I am keen to do a course in 'Crafting Better Requirements', can you kindly let me know if there is a session starting and course fee details? The 'Get in Touch' link doesn't seem to be working.

Adriana Beal posted on Tuesday, August 28, 2018 8:11 AM
Hi, @SeasonedBSA

I'm glad you told me of the issue with the contact us link on the Crafting Better Requirements Page of bealprojects.com. It's back working now. The current batch of participants is finishing the 2-month program, and registration will reopen at the end of September. If you're interested, please write to info [at] bealprojects [dot] com to get in the waiting list, as seats are limited.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC