Announcing: The Case Study Series

Do you struggle to understand the business justification for your projects? Find it difficult, of not impossible, to convince stakeholders to dedicate time to exploring the problem before jumping into “solution mode”? Have a hard time demonstrating  critical thinking, initiative-taking, and influencing without authority skills in job interviews or performance reviews?

This new series will feature six case studies tackling the top challenges identified by Adriana Beal while coaching business analysts over the past two years. Lessons are based on concrete, real-world examples designed to help you understand, remember, and apply knowledge to succeed in your business analysis career. All case studies conclude with notes that help you review and memorize what you’ve learned and extrapolate the lesson to other real-life scenarios.

To download a sample and learn more, visit The Case Study Series page.

Are you using the right unit of analysis in your software projects?

One of the mistakes I see repeated over and over by product managers, product owners, and business analysts, is using features as their “unit of analysis”.

It doesn’t help that books and online resources reinforce this notion all the time:

If the focus of your work is to define and prioritize features, chances are you’re missing huge opportunities to address important and underserved needs for your internal or external customers.

To increase the value you deliver to direct or indirect users of a software application, change your “unit of analysis” from feature to problem statement.

Here’s an example from a content management tool used by marketers to store and publish content to blogs and social media.

The product team is looking for opportunities to improve the quality of the product with the goal of increasing user adoption. It plots an “importance and satisfaction” graph and identifies an opportunity to improve the widget used to upload images and videos to the content management tool that will save users some clicks and make the upload process faster and more delightful.

  • Analysis at feature level: A usability test is performed for the new upload widget. All goes well, and the feature is prioritized for the next release.
  • Analysis at problem statement level: By performing “problem interviews”, the product manager identifies an obstacle that is preventing more users from adopting the tool: marketers can’t see the number of times a piece of content has been published, and prefer to use their own spreadsheet to keep track of when/where content was published so they can avoid content fatigue. Until this barrier to product adoption is overcome, there’s little point in continuing to improve the service dimension, as a faster and more delightful method to upload images is not going to convince non-users to adopt the content management tool.

When you shift from feature to problem statement as your unit of analysis, you develop a more holistic view of value and increase the odds of delivering a product that people want to use. One useful way to arrive at a valid problem statement is to use the following framework:

Service: The work the application does or help users do.

Barriers to success: The circumstances or obstacles that prevent the service from being successfully delivered or the application from being adopted by its intended audience.

Desired outcomes: The measures of performance that customers use to judge its value and are inherent to the execution of the service.

Here’s the framework applied to our case study:

Application:  Content Management tool

Who is it for: Marketers publishing content to blogs and social media

  • Service:  Store text, images and video, and publish content to blogs and social media.
  • Barrier to success:  Lack of visibility into how many times a piece of content was already been used and when causes marketers to prefer the use of a spreadsheet to keep track of their content in order to avoid the risk of content fatigue.
  • Desired outcome: Minimize effort to publish content to blogs and social media while preventing content fatigue.

Problem statement (in the format of a key question): How can we remove the barriers keeping marketers from using our content management tool in order to increase user adoption?

Given that the new file upload widget would merely help improve the service dimension without supporting the achievement of the desired outcome, it would not be prioritized until the barrier to success was removed. A capability that may not have been requested by users yet–a counter of how many times a piece of content had already been used, and in which channel–, would be given a higher priority because of its higher potential to produce the desired outcomes for the customer and the business.

This kind of analysis can be applied to all sorts of software initiatives, from small enhancements to entirely new products. By shifting your attention away from prioritizing individual features and concentrating instead on solving a problem end-to-end for a group of users with the customers’ and business’ desired outcomes in mind,  product teams can pave the way for the evolution of their product toward much higher levels of customer satisfaction and value delivery.


You may also like:

Stop prioritizing features


Three product management myths affecting customer satisfaction and user adoption

Recently I’ve had the opportunity to study the situation of a few software products from the perspectives of customer satisfaction and user adoption.

Here are the top three myths I’ve found in common in these disparate products from different companies. Together they help explain why these products were not performing as well as expected in their target market.

Myth #1:  If we listen closely enough, customers will offer all the answers on how to create value through our software products.

The reality:  Customers are great at telling us about their habits, problems, and aspirations, but not about how best to address their needs with technology.

Example (fictitious, adapted from a real scenario)

Product: Content management platform used by enterprises to store pieces of content (images, videos, text) used in blog posts and marketing campaigns across social media channels.

Popular request from users: Ability to manually tag content pieces so that it’s easier to tell in the future when and where each piece of content had been used in the past.

What happened once this request was further investigated? A combination of problem interviews and observation of users in action led to a better solution: automated tagging.  Rather than building a capability that would have to rely on users being diligent about tagging pieces of content themselves, a set of automated rules makes the process of flagging and filtering content by various dimensions much more reliable and valuable for the customers.

For example, when a piece of content is published from the platform, the system automatically flags it as published, logging the date/time and publishing channel. Subsequent publishing of the same content increments a counter and adds a new log of date/time and channel. This way, content publishers composing a new blog or social media post can tell whether a piece of content has been already used recently, and content creators  can use the same information to inform their future creative process. Creators and publishers  can trust that the publishing status of each piece is up-to-date, something that would be impossible to guarantee if the system had to rely on users to manually tag published content, as originally requested by customers.

Key takeaway: It’s foolish to expect customers to know the best solution for their problem. Listen to their solution ideas , but don’t take their opinions for granted. Use techniques like problem interviews and observation to study the problem space and come up with alternative solutions that address the essence of the problem to be solved before deciding upon the most appropriate choice.

Myth #2: Being “data driven” greatly increases the chances of product success.

The reality: Quantitative data often fails to provide all the information we need to design the best product or feature.

Example (fictitious, adapted from a real scenario)

Product: Mobile app used to manage and listen to podcasts using a smartphone.

Popular feature: Auto-delete after the user has finished listening to a podcast.

Unintended consequence of the auto-delete feature:  Many podcasts have a portion at the end in which the host asks listeners to write a review or reads a sponsor ad. Many users prefer to skip this last portion of each episode. When these users are listening to podcasts in bed while preparing to go to sleep, they may wake up in the morning with a result that is opposite of what was intended:

  • Podcasts the user listened to entirely are still in their downloaded list because the final portion of the recording was skipped.
  • Podcasts the user didn’t listen to until the end (or didn’t even start listening) have been deleted because the user went to sleep while the app continued to play each episode to the end.

Unless the product manager belongs to this particular user segment, it’s very unlikely that he or she will be able to detect the issue without some serious customer research. Quantitative data may tell us when the app starts losing users (which may be moving to a competitor doing a better job predicting which podcasts should be deleted or preserved) but won’t tell us why.

Key takeaway: Tools like problem interviews and observation are again valuable sources of relevant data about the value delivered by product features to different user segments. Interviews with non-customers and former customers can also be a powerful tool to help uncover issues that are hard to detect without an in-depth understanding of the criteria users use to judge product value.

Myth #3: Once we’ve solved a problem for our users, we can move on to the next problem to solve.

The reality: As systems thinking tells us, our equations hold only until something changes in the system’s structure.

Example (fictitious, adapted from a real scenario)

Product:  Another content management system (this time an internal product used by a large organization to publish knowledge articles to their website)

Enhancement: A capability  added to allow content creators to label content items.

What happened?  Initially, users loved the new capability. Content creators started using labels to flag content for management or legal review, to indicate it was work in progress or ready to use, to associate the content with a marketing campaign, etc. But because no conventions were being used to create new labels, soon the application was cluttered with duplicate labels (“Valentine’s” and “Valentine’s Day”, “legal”, “legal_review”). Finding a label to apply or use to filter content from a dropdown with hundreds of labels became a nightmare, and within a few months, feature usage dropped dramatically.

Key takeaway:  We can’t always predict how a new product or feature will affect the future system state. The way out of the trap is to treat the changes in user behavior happening over time as useful feedback, and to take corrective action when performance starts to degrade. (In the labeling example, the solutions included creating a separate workflow for things like management and legal review, and folders for saving content related to a specific event or marketing campaign. With less use cases requiring labels being applied to content, the capability became valued again, and user adoption increased substantially.)


Going back to basics

A message posted by in the discussion forum of the Business Analysis Leadership group got me thinking. We were talking about requirements reviews as a good practice to improve the quality of the requirements delivered by a business analyst, and a manager wrote,

I have seen some companies where the manager tried to implement a requirements review done with the other BAs. Because the other BAs don’t know much about the project, and nothing about the business needs, processes and requirements, this kind of review was soon abandoned because it was not productive at all.

It’s curious how people will find all sorts of excuses to give up on an approach that has been proven to produce a positive impact. The book Software Requirements by Karl Wiegers, among others, provides good advice on how to set the stage for effective requirements reviews. Among his tips:

Give reviewers context for the document and perhaps for the project if they are not all working on the same project. Seek out reviewers who can provide a useful perspective based on their knowledge. For example, you might know a coworker who has a good eye for finding major requirements gaps even without being intimately familiar with the project.

In my experience, it’s not hard to find people within the organization capable of highlighting issues with a set of requirements (or user story acceptance criteria). Members of the BA, QA, development, and support teams are typically good choices. Even when they’re not very familiar with the specific project or business process, by reading a project overview and reviewing the process flow they should have enough context to make a positive contribution during the requirements review process.

But this is only one of many examples I see in the BA community of people finding excuses not to apply proven techniques to their business analysis work. Here are others:

“Oh, but it’s easy for you to do that [ take a step back to focus on the problem space before jumping into “solution mode”] because you shifted to product management from business analysis. It’s much easier for you to impose resistance when stakeholders are impatient to get their project started before the problem is fully understood”

(Hmm… No, I’ve used the same approach while working as a senior business analyst at a large tech company, and it succeeded even when I had been explicitly told by IT management not to talk directly to our business stakeholders. )

“This book doesn’t provide any solid material for reuse – its full of theoretical approaches which will never work on the job practical approach. The methods and the approaches are good for schools or colleges which teach BA for first timers.” 

(Really? Before I made the recommendation in reply to a request for a good reference book on BA activities, I had  worked on two successful large projects that used the exact same techniques it describes.  Clearly this person was looking for a “silver bullet” that doesn’t exist, while refusing to try techniques that do work, but only if you put significant effort to prepare, educate executives and teams, etc.)

To avoid falling into the same pitfall, here are a few things to ask yourself:

  • Am I looking for excuses for not doing the hard work? For example, not defining quantitative success criteria for my project because there’s no time or people to provide context?
  • Did the approach I use fail because it’s not applicable to my situation, or because I’ve not applied it the right way? Scott Sehlhorst has written great article that illustrates this situation. His post is about product roadmaps, but it could be applied to useful BA practice: “Drawing a stupid relationship diagram is bad, therefore, don’t draw a relationship diagram!”
  • Did I use the premortem technique  to avert failure? When you’re attempting a new approach, it pays off to pretend a success or failure already occurred so you can identify the conditions required to win, instead of waiting until the end of a project to find out what went wrong.


Image by Mario Klingemann

When Visual Models are Better than Textual Requirements (Part III: User Flow Diagrams)

Let’s face it, textual requirements are not great at clarifying the sequence of interactions a user has to go through as they try to accomplish a task or achieve desired outcome. Use cases can be a little better, describing the steps that demonstrate all interactions the user has with the system. Take for example Scott Sehlhorst’s example of an online purchase, in which the normal flow goes like this:

1. The user will indicate that she wants to order the items that have already been selected.
2. The system will present the billing and shipping information that the user previously stored.
3. The user will confirm that the existing billing and shipping information should be used for this order.
4. The user will confirm that the order information is accurate.

5. […]

Still, when you’re trying to convey to business and technical stakeholders the journey the user will have to go through to accomplish a goal like making an online purchase, a visual representation describing the specific sequence of action leading the customer to the desired outcome is going to be much better. As explained in this article from Signal v. Noise, 

Flows written down into stories or paragraphs are hard to reference and they don’t easily decompose into checklists for design and review.

The article shows how to create one of my favorite visual representations: the user flow diagram. Below is my adapted version of the main component of this type of diagram:

Shorthand to represent steps in an interaction between user and system.

Sometimes, users may choose different actions as their next step, in which case we can use a modified version, like this:

Alternative notation for more complex flows

Let’s take a look at the online purchase use case described using this notation (in the scenario depicted, a registered customer has logged in, added products to a shopping cart, and is ready to start checkout):

Don’t you find it much easier to visualize the different scenarios that need to be accounted for using this type of diagram compared to textual requirements or even a use case?

For example, when the customer is looking at the “updated shopping cart”, in this diagram it’s easier to identify all the potential steps he/she would want to take from there:

  • Change their mind about a product or quantity, and update the shopping cart.
  • Proceed to checkout.
  • Decide to continue shopping.

Now you can account for all these actions that users may want (or need) to take in your textual requirements, use cases, user stories, wireframes, or other artifacts that may be used to produce a shared understanding of what needs to be built. Through conversations with business stakeholders (and ideally end-users as well), you may identify additional paths that should be available to improve the overall user experience:

From “Form with fields to enter new billing and/or shipping information”:

  • Optionally save the new information in the customer’s permanent records (if this is meant to be the new default for the customer as opposed to a temporary choice).

From “Order details”

  • Quickly edit products or quantities in the cart, or billing or shipping information, without having to go back multiple steps.

Note that these additional requirements could be considered “nice to have”, and simply added to the backlog for future consideration. Still, as with the relationship map described in the last article, this kind of  visual representation increases the opportunities to identify f potential improvements to the workflow.

The main difference between the user flow diagram described here and a relationship map or swimlane diagram is that the user flow places more emphasis on the user journey, highlighting all the steps required by a user to accomplish a task or a achieve a desired outcome. For that reason, they are particularly useful when you’re trying to identify and communicate requirements for customer-facing applications, since in this case providing an optimized user experience through a more pleasant sequence of interactions with the system can become key to ensuring better business results through improved customer satisfaction, loyalty, and retention.

This is Part III of a series. Read also Parts I – State Diagrams and II – Relationship Maps.

When Visual Models are Better than Textual Requirements (Part II: Relationship Maps)

In this series that starts with Part I (State Diagrams), and ends with Part III (User flow diagrams), I show how different visual models can help you create better requirements. If you don’t want to miss the next installments, make sure to follow me on LinkedIn or subscribe to our infrequent updates entering your email to the right.

# # #

As a business analyst working on software projects, you’re probably asked to draw a lot of diagrams. Sometimes it may be hard to understand why, when textual requirements is what’s traditionally required to get “sign off” from stakeholders for what needs to be built. But as we started to see in Part I: State Diagrams, visual representations can help you understand what questions to ask to uncover potentially hidden requirements, reconcile differing viewpoints about what the system is meant to do, and communicate the big picture of a solution being built incrementally, among other benefits.

In this article of the series, we’re going to take a look at relationship maps. While state diagrams focus on a single business object and how it transitions states in response to conditions and events, and process maps depicts the sequence of steps that transform inputs into outputs, a relationship map highlights the inputs received from external parties (customers, providers, partners) and the outputs provided to them, as well as the functional areas involved in handling those inputs and outputs and the handoffs (inputs and outputs) within the organization.

Imagine that you’re starting to work on a system to automate invoice processing for a hardware repair company. A relationship map for the project could look like this:

Because the diagram focuses on the affected business functions and their inputs and outputs, it’s easy to determine the cross-functional relationships between these functions (engineering, account management, finance) and the external actors (customers and providers). After building this map, a BA could identify a potential process improvement opportunity in the handoff of invoices to the customers (highlighted in orange above).

The analyst could ask relevant questions to stakeholders, such as, “Given that the finance department is responsible for generating the repair invoice the customer gets and receiving the payment, does it still make sense to have the handoff of the repair invoice from finance to account management before it reaches the customer?”  The proposed change would be captured in a relationship diagram like this:

But now, comparing it with the previous version, it’s easy for the BA to see that the account management is left “out of the loop” regarding the completion of a repair order, previously signaled to them via the customer invoice forwarded by the finance team. We can then modify the diagram again, to make sure the notification still happens (see added green arrow):

Note how in this version the customer still has to submit a repair request to the account management team, responsible for validating the terms, such as the service level agreement the request has to adhere to. But account management no longer needs to be involved in the customer invoicing process: the finance team can invoice the customer directly. However, since in the “as-is” process the invoice received from finance served as the notification to the account management team that the service had been provided, we now need to extend the “repair complete” notification issued by the engineering team to the finance department (for invoicing purposes) so it also reaches the account management (new green arrow).

Showing the first and last diagrams (as-is and to-be ) above to business stakeholders makes it much easier for them to understand the recommendation for the process change compared to writing a textual description of the proposed changes and directly asking for sign off for the final requirements. Once the process change has been well-understood and approved, a textual requirement can be created to communicate to the development team what needs to be built and tested:

When the engineering team marks a repair service as complete, a “repair complete” notification will be forwarded to:

a) the finance system (existing behavior, which already triggers the invoicing process); and

b) the account management system (new functionality that will update the order status in the account management system so that account managers can have the information readily available when interacting with customers over the phone).

# # #

Visual representations of business functions involved in a business process, like the one provided by relationship maps, can be extremely useful for identifying areas of improvement and communicating proposed changes in existing processes. Relationship maps offer an excellent view of the key business entities and the inputs and outputs that flow between them. They can also serve as input for the creation of other useful diagrams such as a process map, with the functional areas becoming lanes in the diagram. By not focusing exclusively in one type of visual representation of the business model, BAs can dramatically reduce the risk of overlooked requirements or missed opportunities to improve business processes.

# # #

Looking to take your textual requirements and visual models to the next level? Join the waiting list for the coaching program Crafting Better Requirements.


When Visual Models are Better than Textual Requirements (Part I: State Diagrams)

In this series, I show how different visual models can help you create better requirements. If you don’t want to miss the next installments, make sure to follow me on LinkedIn or subscribe to our infrequent updates entering your email to the right.

# # #

The ability to write high-quality textual requirements is a skill highly valued by many organizations, in particular the ones that have suffered the negative consequences of poorly defined requirements: project delays, cost overruns, expensive rework, dissatisfied users.

But visual models are also key to preventing misunderstandings and missing requirements as a business analyst specifies system behavior for an agile or traditional software project. A process map showing the sequence of steps, inputs, and outputs needed to handle a business process across multiple functions, a relationship map showing what information and products are exchanged among internal and external actors, a state diagram describing the behavior of an object over time — all these models can be extremely useful to facilitate the knowledge transfer about how a software application will support a business process, and uncover requirements that must be a part of the solution.

Let’s look first at state diagrams. A state diagram is a model suitable to when you’re trying to answer questions about the lifecycle of a business object: what states are allowed for it, what events trigger a change in the current state.

Example of state diagram depicting the states for the object “Contact” in an email automation application

The object (or data entity) can be anything that the business (and the information system that automates it) must keep track. For instance, a blog post in a content management system that can transition from “draft” to “published” and “deleted”, or a contact in an email automation system that can have the states of “subscribed”, “unsubscribed” and “deleted” (as in the example above), or a product in an ecommerce platform that can be in the states “in-stock”, “out-of-stock”, or “discontinued”.

Why draw a state diagram?

It’s possible to surmise the behavior of a business object over time analyzing requirements and use case descriptions. For example, one could gain an understanding of the contact object in a marketing automation system by noting how it’s handled in the requirements for User Subscribes to Mail List, User Unsubscribes from Mail List, User is Deleted by System When Email Address No Longer Exists. But if the state of the object is critical for the system (e.g., the business could get in trouble if contacts who unsubscribed from the company’s mail list are kept in the Active state by mistake), it’s helpful to be able to get the full picture of the object as it passes through the system.

Let’s say you’re writing requirements for a content management system. By drawing the desired states for blog posts (“draft”, “published”,  “deleted”), you could more easily identify all desired transitions (for example, not just from “draft” to “published”, but also from “published” back to “draft” to allow an accidentally published post to go back to draft where it can continue to be worked on). If your requirements didn’t account for this scenario, content managers would have to go through multiple steps to fix this mistake, copying the content to a text editing tool, deleting the published post, and creating a new draft.  The diagram would quickly highlight the missing transition to be incorporated into your requirements (“A content manager can revert a post from published back to the draft state to allow for more work to be done in a post prematurely published by accident.”).

What next?

Just reading articles or books about a business analysis tool or technique won’t get you far. To truly master the use of the technique, you must practice it in a context in which you receive expert feedback. Otherwise, you can end up like a senior BA who when asked to produce a state diagram to represent the states and transitions for gift certificates while participating of Crafting Better Requirements, created this:

Clearly the BA misused the term “state diagram” here.  “Purchase Gift Certificate” and “Redeem Gift Certificates” are not states of the object “gift certificate”. These are user goals that can be represented by use cases and business process diagrams. A valid state diagram for gift certificates would describe the states a gift certificate can be in (e.g., “created”, “delivered”, “partially used”, “depleted”) and what events would cause a gift certificate to transition from one state to another.

Luckily this senior BA made this mistake in a safe environment of a coaching program as opposed to in front of his manager and stakeholders at work. To avoid damaging your reputation due to flawed models like this at your job, see if you can enlist the help of a knowledgeable colleague to provide honest feedback for the diagrams you draw before you share them with a larger audience. Or take it a step further and do like the hundreds of BAs who decided to take their requirements writing and modeling to the next level by joining the Crafting Better Requirements program.

# # #

Read also Part II: Relationship maps and Part III: User flow diagrams

Goal setting: good or bad?

The advice “stop focusing on goals” was popularized in books like How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life by Scott Adams and Four Seconds: All the Time You Need to Replace Counter-Productive Habits with Ones That Really Work by Peter Bregman.

The authors’ premise is that establishing areas of focus and putting our energy into “systems” or habits can lead to better results than setting reach-it-and-be-done kinds of goals. Having goals can lead to myopia and the feeling of discouragement and stress, they say, while instituting areas of focus and routines broadens our perspective and makes the process of improving our situation more pleasant and rewarding.

Numerous other authors take the opposite stance, saying that goals are crucial to accomplishing great things in life. Who is right here? In my opinion, neither group has the answer.

Beal Projects’ two-pronged approach to achieving desired outcomes

In the framework I, Adriana Beal, developed for personal use and to help the participants of my coaching program to reorient their career in a more compelling direction, there are two complementary tactics:

Tactic #1: Finite, “from A to B” goals

Tactic #1 is about defining a specific outcome we are trying to achieve. The idea is to transition something (us, a business, a process, etc.) from point A to point B. A reach-it-and-be-done goal is extremely useful to help us focus our efforts. Instead of just relying on habits and routines (e.g., “I will read a book a month to keep building my competencies”) that may lead to unfocused efforts, a finite goal lets you concentrate on a specific outcome (e.g., “I will master machine learning by the end of the year”) that leverages our positive habits and routines to take your performance to the next level.

An effective “A to B” goal may look like one of these statements:

“Boost revenue by 20% this year”
“Drive down purchasing costs by $1 billion over the next five years”
“Find a repeatable and scalable business model”
“Halve the time it takes to respond to customer complaints”
“Get a job at a Fortune 500 corporation”
“Become more knowledgeable in predictive analytics”
“Lose 10 pounds”

Once a finite goal is achieved, it may need to be replaced with another goal that makes sense after “point B” is achieved. For instance, after achieving the goal of finding a repeatable and scalable business model, a startup would shift its focus to scaling the business, which becomes the next goal.

Sometimes, after a goal is achieved, it must replaced with permanent habits and routines (tactic #2 described below) in order to produce lasting results. For example, after achieving the goal of losing 10 pounds, a person could shift its focus to maintenance, changing the strategy from temporarily food restriction to long-term exercising habits and routines to prevent the weight from creeping back on. Or, after meeting a cost reduction target, a company may shift its focus to making the cutbacks sustainable, rather than risking decreasing quality or service by trying to further extend their cost reduction efforts.

Tactic #2: Permanent habits and routines to keep us on the path to success

In addition finite, “from A to B” goals, we need to identify the habits and routines that can keep us on the path to success, however we define it.

Imagine a person who defines success as living a life free from health and financial worries. They know that in order to achieve this desired outcome, they need to overcome some self-defeating behaviors, such as being sedentary, eating junk food, and failing to pursue skill development opportunities that can be translated into valuable career opportunities. Developing good habits such as packing healthy snacks to bring to work and regularly scheduling blocks of time to learn new skills free from Internet distractions may be key to staying on track with this long-term goal.

The verdict

Rather than picking a side on this fight (“goals are counterproductive” vs. “goals are the key to success”), a better option is to use integrative thinking to incorporate both ideas: well-designed goals that mobilize our efforts toward the removal of obstacles in the way of a desired outcome, and recurring patterns of behavior that are critical for getting us closer to our long-term aspirations.

If you think about it, the chances of success are increased by a combination of positive habits and behaviors that with time-bound goals dedicated to overcoming an obstacle in the way of achieving a desired outcome. The problem with goal setting is not the approach itself, but that it’s often used incorrectly. To quote from goal-averse author Scott Adams,

“A hammer can be used to build a porch or it can used to crush your neighbor’s skull. Don’t hate the tool.”

But how to identify the right goals and routines to adopt?

There is no shortcut to selecting the right goals or the right habits to cultivate: you need to do your homework, starting from your own definition of success and looking for proven ways to get you there. For example, research shows that chess students who study with coaches have higher national ratings compared to those who don’t. If you wanted to become a chess master, it would make sense to first set a goal to do some research to find a good coach, and then  replace it with a routine of deliberate practice under the coach’s supervision.

If you study the trajectory of highly successful business analysts, you’ll notice that while there may be large differences in their career paths, they all share three critical attributes: the ability to generate valuable creative ideas to solve business problems, communicate these ideas in effective ways, and get buy-in for those ideas from decision makers. To elevate your role, get access to the most interesting projects, and build a compelling career, you need to develop laser-like focus on developing the skills that count the most.

Need inspiration for defining your next goal? Download the guide Beyond SMART Goals: Effective Goal Setting for Business Analysts.

Wondering which new habits to adopt to work your way up in the skill ladder? Check out our list of recommended superpowers all business analysts should be developing to remain relevant in a world of constant technology advances. 

Photo: Jonas Hosler (CC BY 2.0) 

Is it possible for a BA to concentrate on both Business Analysis and Business Analytics side by side?

A reader asks:

Is it possible for a BA to concentrate on both Business Analysis and Business Analytics side by side?

In order to have a productive conversation about a topic without getting derailed by misconceptions, first we need to eliminate any confusion about how the terms are being used. So here’s how I’m using the following terms throughout this article:

Analytics: The science of applying a structured method to solve a business problem using data and analysis to drive impact. [1]

Business analytics: The use of simpler analytics methodologies on past data. [1]

Advanced analytics: Everything else, including predictive analytics. [1]

Business analysis: The activities associated with defining and understanding business problems and determining the right solution. Such activities include problem identification, requirements discovery, analysis, specification, validation, approval, as well as knowledge transfer about desired outcomes, requirements, assumptions, and risks to the delivery team.

Just based on these definitions, it’s pretty clear that business analytics (as well as advanced analytics) can have a huge impact in the quality of business analysis. Analytics can help you understand the specifics of the problem you’re trying to solve, and add precision to decisions about priorities, requirements and design.

Here are some examples of how business analysts can use analytics to improve the quality of their solutions:

  • A BA working on the prioritization of change requests submitted by users of an internal application can use analytics to determine how many people would benefit from each of the proposed improvements and make prioritizing recommendations accordingly. (E.g., “500 users need to reply to a message in our platform each month, and in average each of these users replies to 10 messages a month. 30% of the time users have to change the “From:” field before replying so the message is sent from a shared account. The “reply-from” enhancement meant to facilitate changing the “From:” field will affect 500 x 30% = 150 users and 500 x 30% x 10 = 1,500 replies per month. We recommend bumping this improvement to the top so it’s implemented before this other planned enhancement that will only affect 12 users performing an average of 3 actions per month.”).
  • A BA working for a credit card issuer and responsible for a system that manages the credit card approval process examines historical data and notices that the company is showing signs of increased losses and incorrect actions for customers. She uses descriptive analytics to divide customers into multiple segments and recommends the company moves from the existing single model for predicting risk for all customers to distinct risk models that handle only a subset of all customers. The change improves the accuracy in risk modeling and creates millions in loss savings.
  • A BA working for a retail business and responsible for specifying a solution to enable the company to implement a survey to collect the preferences of its “high value customers” uses historical data to expand the reach of the customer survey.

As you can see from these examples, analytics helps BA find better solutions to the problems they’re trying to solve. Business analytics and advanced analytics are extremely useful problem-solving tools. Used well, they can make for better software products, happier customers, higher profitability, more productive employees, improved accuracy in risk modeling, quicker work turnaround, and all sorts of positive outcomes.

So to answer the reader’s question, not only it’s possible for a business analyst to focus on both business analysis and business analytics in the work they do, it can hep you dramatically expand the value you deliver to your organization.

How to get there?

You can’t be great at business analytics without getting out in the real world and start spending time with business data. If you don’t have an opportunity within your workplace, find a nonprofit to help, and get to work analyzing their survey results or Google Analytics data. You don’t need a PhD in statistics, but being familiar with basic statistics will greatly enhance your career as a business analyst with analytics expertise, so find some online resources to help you get a solid grounding on this topic. Statistics training will help you enhance your analytical thinking and look at business problems differently.

For tips on getting started with predictive analytics, check out the resources listed at the end of the article It’s time for business analysts to add machine learning to their “bag of tricks”

[1] Behind every Good Decision: How Anyone Can Use Business Analytics to Turn Data into Profitable Insight


Photo: Neerav Bhatt (CC)

A reader asks: Should the BA be responsible for providing design inputs for developers?

I’m new to the business analyst role (8.5 mos to be exact), and I came across your webinar “6 Mistakes That Lead to Missing Requirements” from Bridging the Gap. During the Q&A portion, a question came up about listing “solutions”, and another about some projects requiring the BAs to provide the developers high fidelity mockups. I’m in this exact situation right now. The team I am part of requires the BA to be the one documenting the design specifications. We’re not so much into understanding the requirements – the developers want to know right away what design specs to implement.

So my question is – is it really the BA who provides the design inputs for developers? Is it the BA who writes the design document? I’m really confused. If I simply give them the requirements (the conditions that must be fufilled), they wouldn’t know what to do. We are in an agile environment, so I know that the line delineating each role tends to get blurred, but I’m getting more and more pulled into the solution space as opposed to staying in the problem/requirements space.
I hope you could shed some light. Thank you!

Before I offer my answer to this question, let’s look at some facts:

1. Most software requirements can be satisfied by more than one software design.

It’s very rare that a functional requirement can only be satisfied by one particular design. For instance, a requirement for a webstore that says “the system will allow customers to write product reviews” could be fulfilled by many different designs, including a button “Write review” that when clicked opens a pop-up window, a link saying “Leave a review” that when clicked shows a sliding panel with the fields to be filled out before submitting the review, and a “reply to this message to leave a review” feature that automatically processes a customer review submitted via email reply.

And note that we’re not talking just about user interface design here. There are other aspects of software design, such as where to allocate capabilities across modules and components, which technical methods will be used to implement a feature, etc., for which there will be multiple designs capable of satisfying a given set of requirements.

2. Shortcomings in user interface design can dramatically limit the value delivered by a solution, even if it implements the right capabilities.

If you implement a requirement with a design that makes it difficult / confusing / time-consuming for users to perform a task, the negative consequences in terms of user adoption, productivity, etc., can be significant, to a point where the solution may deliver negative value to the business.

3. As with requirements, great design results from iteration.

The same way that producing quality requirements requires iterating on the problem domain to make sure the requirements address the right problem or opportunity, producing high quality designs requires multiple passes to explore and refine concepts in pursuit of the best solution.

Bottom line: design needs to be taken care of by *someone*, and the best teams wil have designers who collaborate with the rest of the team to design the optimal solution based on the agreed upon requirements.

As you can see from the three facts above, design is an important element that needs to exist separate from requirements and coding. Embedding UI design in the requirements is bad because you’re prematurely limiting how the requirements will be addressed (is a pop-up window truly better than a sliding panel to provide the ability to submit a review?), before different ideas can be explored. And leaping from requirements to coding is bad because it means the design will happen implicitly during coding, without considered thought. It’s like deciding to build a house based on the requirements “must have 3 bedrooms, 2 bathrooms, and 1 kitchen” without thinking through how to best allocate the rooms. You could end up with the requirements met but the residents unhappy that they have to pass through the kitchen every time they want to go from their bedroom to a bathroom, or dissatisfied with the high cost of temperature control because room placement didn’t take advantage of the position of the sun.

An additional benefit of separating design from requirements is requirement stability. If you’re embedding design into your requirements, and the user interaction has to change (say, from clicking a button to using a dropdown) because of a technical constraint or to maintain consistency with how other user actions have been implemented, your requirement (the capability or condition the solution must meet) doesn’t have to change. This can save significant time, ensuring your requirements documentation (e.g., user stories and acceptance criteria) doesn’t have to change, only the design, and user acceptance tests if you’re designing those based on the user interaction.


The main reason we have so many BAs confused about their role and which documents they’re supposed to create is that in many organizations managers aren’t aware of the importance of separating requirements from design and design from coding. Typically in these organizations there are no designers on the team, and developers are rewarded by the number of lines of code written, or user stories implemented, or tasks marked as completed, rather than by truly solving the business problem. This means developers don’t want to “waste time” exploring different ideas on how to implement a specific capability. The BAs in these organizations are left with the task of producing the final design, often with insufficient time to dedicate to understanding the problem and articulating and validating the requirements before jumping into “solution mode”.

Now, should the UI (or, for that matter, the technical) design  be done by the same person doing the requirements work? I don’t see a problem with that, as long as the person has the skills and time to perform both jobs well. The reality, though, is that the skills required to produce great UI design are different than the skills required to create excellent requirements, and it’s rare to find the two sets of skills in the same person.

This means that having the same individual in charge of requirements and design may result in a design with great look and feel but that doesn’t solve the right problem (if the person has design skills but not business analysis skills), or a solution with usability issues (if the person has good analytical skills but not the knowledge or or talent to produce a good design).

Here’s an example that illustrates the latter, extracted from a previous project. The requirement stated that users would be allowed to upload up to 3 files concurrently. The BA created a wireframe that looked like this:

When the developer saw how cluttered the design made the page look, he suggested a different design:

(This is a low-fidelity representation created just to illustrate the point; the actual design looked much better.)

In this new version, in the (rare) occasions the user needed to upload more than one file he or she could click “Add more” and the system would add a second line for input. Users agreed that the design change made the page much more readable and efficient for the majority of users navigating from field to field using the tab key to fill out the form with just one file to upload.  If the developer just followed the specification provided by the BA, an inferior solution would have been deployed.

But note that regardless of the design choice here, having requirement statements documenting the expected behavior (“users must be allowed to upload up to 3 files concurrently”) is important to reduce the risk of a design choice failing to meet the actual requirement. People could get so involved in the discussion of the best user interface that they forgot what the original requirement was. With a design linked to an actual requirement statement, it’s much easier to remember to address details like the need to prevent users from uploading more than 3 files. Based on the stated requirement, a separate annotated wireframe could be created to show the state of the screen with input fields for 3 files and the “Add more” button disabled.

The most effective teams I worked with had one or more user interface designers available to work on software projects, taking the functional requirements produced by a business analyst and translating them into low- or high-fidelity wireframes in collaboration with the developers and the BA. The business analyst would remain involved throughout the design process, contributing with suggestions and validating that the UI design accommodates all the functional requirements and exception cases and doesn’t incorporate unnecessary capabilities that increases software complexity without adding value.

(The best teams I’ve worked with also had software architects in charge of developing and maintaining a solid architecture of modules and components that made enhancing the system easier over time and ensured performance, security, scalability and other quality requirements would be met.)

But what if I work for an organization that doesn’t hire UI designers and expects the BA to deliver design artifacts to the dev team?

In some organizations without designers, you may be able to find talented developers who have a passion for good user interaction willing to sit down with you to discuss alternatives to implement a given capability (as in the “file upload” example above). In other workplaces, programmers will be unwilling to engage in this effort, and the task will fall on your plate.

The best advice I can give to people who are in a situation like the one described by the letter writer is to try to educate your boss on the importance of separating requirements work from design work. Even if you can’t get help for doing both jobs, at least try to ensure that in each project you have time to dedicate to understanding the problem to be solved and writing requirements that are free from premature design constraints that you validate with your stakeholders before moving to the design phase. Even if your developers don’t care about the actual requirements, *you* should care and make sure that the wireframes you deliver accommodate all the functional requirements and address exception conditions that can arise. And if you don’t have a background in user interface design, you should also try to read about this topic as much as possible in order to avoid making egregious mistakes when creating wireframes for the development team.

And, when you’re looking for a new job, ask about the company’s practices as to what pertain to requirements, design, coding, and testing. If given a choice, go work for a company that already sees requirements as an essential step on the path from business needs to satisfied customers and for managers who insist on creating designs on a foundation of high-quality requirements, as this will dramatically increase your ability to deliver successful solutions.