Business Meeting

Top 10 Ideas from the Business Analyst’s Mentor Book

This blog post is a review of the Business Analyst’s Mentor Book by Emrah Yayici.

Why Read Business Analyst’s Mentor Book?

Last month, I read The Passionate Programmer. One of the points this book made was that it’s not sufficient to be “just a programmer” aka code monkey aka cin >> coffee; cout << code;.

In order to stay relevant, you must learn the domain of the business you’re operating in.

For a company, it’s invaluable to have developers that can speak to clients in the language of their business domain. A lot of time and frustration can be saved by having a good understanding of the business side of things.

For this reason, I’ve decided to read the Business Analyst’s Mentor Book, a book chosen for the Business Analysts’ (BAs) reading circle at my company, Avaloq.

BA Mentor Book

Here are my top 10 ideas from this book.

1. Business Analysts in a Nutshell

BAs are mainly concerned with defining functional and non-functional requirements for a system.

They organise requirements gathering meetings with the client to understand what they need.

2. Project Management Triangle

This is also known as the Good, Fast or Cheap dilemma and is actually a pretty cool way to think about project management constraints.

In an IT project, you can only achieve two out of the three objectives of delivering something that is Good, Fast, or Cheap.

In other words, a good product can be built fast, but with expensive, high-quality resources. On the other hand, the product can be done cheaply, but with a lot of time invested.

I like this idea because you can apply it also to fitness. You can have a nutrition plan that is good, i.e. healthy, but it’ll probably take a bit longer to prepare if you’re aiming for lower prices, or you can get it already prepared, but for a higher cost.

3. Must-Have vs Nice-to-Have Features

When time to market is crucial, then the project should deliver must-have features as a priority.

This is especially relevant in the context of Minimum Viable Products (MVPs). You want to implement the must-have feature(s) ASAP to start getting customer feedback. Nice-to-have features should be implemented if enough resources are available.

4. Use Case-Driven Analysis

This technique is used for gathering requirements. It answers the questions:

  • Who are the actors?
  • What are their goals in using the system?
  • How will the actors interact with the system to achieve their goals?

Actors can be users or external systems that interact with the system for which we’re gathering requirements.

The author highlights the difference between use cases and functional requirements. The former represent the goals of an actor, while the latter represent actions needed to achieve the goals.

For example, “money transfer” can be an use case for an app and “input receiver’s account number” can be a functional requirement.

5. Stop Selling Once You’ve Made the Sale

The book also has a chapter on giving presentations. Besides the usual tips like “be natural” and use analogies to make messages more memorable, there was one tip I found particularly useful.

The idea is to stop selling once you’ve made the sale.

The author gives an example of a salesman that was presenting some printers to his company. At one point, the team was convinced to buy one of the products, and instead of stopping the presentation, the salesman continued pitching the rest of the products.

In the end, the team decided to postpone buying a printer due to the multiple available choices.

6. What’s a Product Owner?

The product owner represents the voice of the customer. The person in this role defines requirements as user stories and prioritises them in the product backlog.

The book says that in principle, the product owner doesn’t have IT knowledge as he/she is selected from the business unit.

Therefore, BAs have taken the role of product owner as they’re kind of at the intersection of the business and technical side of things. This allows them to prioritise requirements, change requests, and bug fixes.

7. Shelfware

Shelfware is software that sits on a company’s shelves as it’s not used.

The idea here is that a company shouldn’t invest in software such as requirements gathering software if they’re not going to use it.

Additionally, for some reason, shelfware sounds like a fancy term to throw around at a dinner party.

8. Agile vs Waterfall

The author says that agile is not suitable for every project.

He gives an example of a team working in an agile manner on components A and B without problems. Then, the team needs to work on component C and realises they need to go back to refactor components A and B. He argues that a waterfall approach would be more suitable in this case.

I disagree with this view as, in principle, following coding guidelines such as the ones advocated by Robert Martin (Uncle Bob) in Clean Code will help you take future likely changes into account. Uncle Bob specifically addresses “coding to unknown code” by using the adapter design pattern.

Lastly, change is inevitable in software. Modifying components A and B is a natural consequence of software evolution. With a good design, changes should be localised and relatively easy to manage.

9. Testing

The book explains the importance of testing including the ideas of test coverage and regression testing.

Testing should be done early. Additionally, risk-based testing should also be performed. This type of testing looks at exceptional and boundary cases.

Lastly, regulatory constraints prevent the use of production data for testing.

The author says that ideally, you’d have tools that generate test data by masking subsets of production data. This is also one of the issues I’ve encountered at my workplace at Avaloq. We’re currently looking into ways of generating synthetic data.

10. Baby Duck Syndrome

People like consistency in terms of UI design.

When shown a new design, users usually favour the old design instead of the new once. This is known as the baby duck syndrome.

The lesson here, at least in the view of the author, is that the UI design should only be changed when really needed.

I’d argue that with tools such as A/B testing, it makes sense to change the design if this improves conversions, for example.

What I Didn’t Like

There are quite a few bad things about this book.

First of all, there are no references to support the author’s statements. My impression was that I was reading someone’s personal opinion on the topic.

For example, the author addresses BAs that want to be project managers. Apparently, you should gather at least eight years of experience as an analyst before moving to a manager role. There was no further explanation on this eight year mark.

Secondly, there’s a lot of repeated information, so the content could be collapsed to a few chapters.

Thirdly, there’s a lot of obvious or superficial advice. Here are a couple of quotes:

Business analysts should not escalate every problem to upper management before trying hard to solve problems themselves.

Business analysts should be open-minded and solve hard problems in creative ways.

Oh, OK.


In conclusion, my three key points are:

  • BAs gather requirements for a system.
  • Use case analysis is a method of identifying system requirements.
  • Good, Fast, and Cheap are competing objectives.

There is some value in this book if you know very little about business analysis/software engineering. Otherwise, I’d look somewhere else.

I’m in the process of getting some better recommendations from my BA friends so consider subscribing to the newsletter to stay updated.

About the Author Dragos Stanciu

follow me on:


Like this article? Stay updated by subscribing to my weekly newsletter:

Leave a Comment: