Beal Projects

A DON'T list for business analysts and product managers

As Robert Cialdini reminds us, despite the fact that we've been told time and again that positive information is always better than negative information, studies show that time dedicated to understanding our failures and leveraging the mistakes of others has more instructive implications than attempting to learn "best practices".

In this living document Adriana Beal will be sharing the mistakes, lapses in judgement, and blunders often seen among practitioners of business analysis and product management. To avoid these common pitfalls, remember to visit this page to reread the list whenever you're starting a new project.To contribute to the list, use this form (you are welcome to include a link to your LinkedIn profile or homepage to receive credit).

1) DON'T forget to use storytelling when presenting your findings and recommendations

How this problem typically manifests: You have to present controversial findings and convince stakeholders to change their plans based on facts and quantitative analysis. You then proceed to stuff every research point, potential benefit, and implementation detail into a boring presentation that overwhelms and confuses the audience.

Why this is a problem: No decisions are made, no projects approved, and no minds changed based on a complex and dry slide show full of facts and figures. Stories are what helps your audience retain and commit to the message you want to deliver.

How to avoid it: When preparing a presentation to share findings and recommendations with customers or business stakeholders, remember that your main goal is to persuade people, not merely convey data. When you are preparing your presentation, start to organize your ideas with the objective in sight. Decide which facts truly need to be included, and leave out irrelevant details. Make sure to block time to come up with stories that will help make your ideas memorable. Think back to interesting anecdotes, stories, observations that fit the idea you're trying to communicate, and weave them into your narrative. Books like Made to Stick can help you develop storytelling skills that are instrumental to getting buy-in for your proposals.

2) DON'T use jargon unless you have evidence that your audience is familiar with it

How this problem typically manifests: You are doing an interview with customers or facilitating a requirements workshop with subject matter experts and start using terminology that is not necessarily part of their vocabulary (e.g., "we're looking to improve the UX of the product", "we're going to add a CRUD matrix to the specification").

Why this is a problem: Technical jargon can alienate decision-makers and cause subject matter experts to stop contributing to the conversation if they aren't familiar with the terminology being used.

How to avoid it: Even though special terms can be a useful shorthand within a group and may be the clearest way to communicate inside the group, when you're addressing a larger audience, pay attention to avoid words you use routinely that may not be familiar to them. It's fine to use acronyms like CRM and BPM with your business stakeholders if these terms are already part of their vocabulary; it's a bad idea to assume that, say, a group of PhDs doing research in electromagnetism, will understand what you're saying if you start including these terms in the conversation without defining them first.

(Idea contributed by Adam Sharpe.

More advice on this topic here: Use this simple trick to become a better stakeholder interviewer.

3) DON'T waste time perfecting a draft document before you share it with your audience

How this problem typically manifests: Instead of producing a first (likely flawed) draft for a proposal, wireframe, or requirements specification, and use it to get feedback from others as early as possible, you work behind closed doors until you can present a "perfect" draft that satisfies your ego--but fails to create an opportunity for collaboration and validation of hidden assumptions early on.

Why this is a problem: The more time you have invested in your draft, the more likely you are to become a victim of confirmation bias: once we've made up our mind, we tend to seek information that confirms our opinion, and dismiss or discount information that invalidates it (i.e., we don't let new information in the door that could change our decisions). Also, people will be more reluctant to share their viewpoints if they see your work as a "final" proposal as opposed to something still under construction and open to suggestions. This may cause important opportunities to improve your proposal or specification based on input from peers and other stakeholders to be missed.

How to avoid it: There are many benefits to sharing a flawed first version of what you're working on. Accept the fact that it's OK for things to be ambiguous at the beginning of a project, and it's also OK to start building and sharing visual models that may be significantly flawed in their initial drafts. As illustrated in this article, as long as you are clear about the purpose of your visualizations (test assumptions, develop a common mental model of the problem, explore and evaluate options), there is little-to-no risk associated with making mistakes in your first diagrams. A "wrong" conceptual model may be the fastest way to get to the right solution, because it helps expose flawed assumptions that might otherwise remain hidden until it becomes much more costly to take corrective actions.

(Idea contributed by Adam Sharpe)

4) DON'T assume your customers (or end-users) know what they need

How this problem typically manifests: In the course of using your application, users get frustrated with the time required to complete a task, or the inability to perform an action they feel is important for their job. They submit a change request asking for a specific change in the user interface or system behavior. The request is prioritized (either because it's coming from an influential stakeholder, or several people are asking for the same change and it seems like the right thing to do), only to generate a new influx of requests for additional adjustments, or even protest from other users whose workflow was negatively affected by the new or modified feature.

Taking user requests at face value can lead to an endless cycle of building new features that don't solve the real problem.

How to avoid it: The problem is caused by the fact that, when experiencing a frustration, most users will focus on the problem manifestation as opposed to the real problem.

In order to deliver real value to users, the key is to fully understand the underlying problem before jumping into solution mode. When a user requests X, ask what will be different when X is available. What will the user be able to do then that he can't do now? You may find out that what he is trying to accomplish is already available through a different feature he isn't aware of, or that another solution he hasn't thought of would be much more effective to solve the problem.

Successful BAs and PMs do their homework to truly understand who their key stakeholders are (from the people writing the check to the ones who will have to use the application to perform their job), and learn in detail what jobs the software is being hired to do for these audiences. They also put significant effort into determining what initial hypotheses they need to validate during the analysis phase in order to avoid negative surprises when the solution is finally deployed. It all starts with asking the right questions to the right people.

Photo: Creative Commons - Nicolas Nova

Since to err is human, the list will keep growing. To receive infrequent updates from, make sure to subscribe or follow us.
To contribute to this list of mistakes, use this form (you are welcome to include a link to your LinkedIn profile or homepage for credit purposes).