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:
- 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