Can we really trust Amazon, Google, or our Competitors?

Let’s take a look at a hypothetical, but very typical, conversation that happens while eliciting new functional requirements.

Business Analyst: How would you like the search feature to work?

Stakeholder: Like Google.

Or, another example.

Business Analyst: What should happen when the user selects “Add to cart”?

Stakeholder: I have no idea; why don’t we just do what Amazon does. They are the expert in online shopping.

And just one more.

Business Analyst: What profile information should we collect from new users when they register?

Stakeholder: Not sure. Let’s copy {insert name of closest competitor here}.

On the surface, these answers are clear and logical. Google and Amazon are profitable businesses and have well-thought-out website features. Your competitor might also be extremely successful. There could be very good reasons to copy what they do.

Or copying what they do could lead you into deep trouble. Although we can copy the feature, we often can’t see the underlying logic that makes the feature work, often know little about the organization’s business model, and definitely do not know the business need they were hoping to address when they implemented the feature.

In fact, having worked inside many organizations, I can tell you that often what’s on the outside isn’t even the result of the organization’s best thinking. More often it’s what they were able to implement of their functional requirements specification about a year or two earlier when the project got rushed out the door.

Let’s take a simple feature like reviews. Many organizations emulate Amazon’s review feature only to find it doesn’t provide the benefits they expect. Reviews require users to leave reviews. Putting a review box up on a product page will not necessarily help your products sell better. When you pay attention, you’ll realize that Amazon cultivates reviews in many ways and yet there are still a fairly limited number of reviews.

Case in point: My book, How to Start a Business Analyst Careerhas sold thousands of copies on Amazon and yet, as of this writing, has only 23 reviews. (If you’ve read the book in any format, it would be wonderful if you could add a quick and honest review. Buyers do read them and you’ll be helping a future business analyst decide if this is the right book for them.)

Adding reviews is a simple feature. Getting buyers to leave meaningful reviews is much more complex. And without the content, the reviews feature can actually have a negative impact on sales.

So what’s a business analyst to do when a stakeholder says, “Just copy ____”?

In my early days as a business analyst, before I learned to have a little finesse, I responded in one of two ways – both of them wrong.

  1. “Oh, yes, that makes sense, let’s do that!” {And off I go to write up a requirements spec after reverse engineering the website in question.}
  2. “Oh, really, so you think you are building the next Google, eh? Where’s my stock?” OK. I never, ever said this to a stakeholder, except possibly as a sarcastic joke when I had a really good foundational relationship already in place. But it ran through my head on more than one occasion. What came out was more likely something like, “Oh, what a great idea. But we need to be a bit more specific,” accompanied by a thin smile and tough-to-disguise eye roll.

Neither of these responses is particularly helpful in moving the business analysis process forward. So what do you do instead?

A better approach starts with realizing that your stakeholder has offered you valuable information – not all of the information you need or great information, but valuable information. They’ve given you a model to start from. Yet you need to help them clarify what they mean and you need to analyze the requirements in more depth.

Here are some approaches to turning their valuable offering into real information you can use to analyze the requirements. For the sake of simplicity, we’ll assume our stakeholder has asked you to replicate Google.

(Crazy, I know.  Do they even have a clue how many people work there? And that they get 4 hours a week for personal projects?  And that Larry Page has a magic computer coding wand? But I digress.)

Approach #1 – Yes You Are Wonderful, But I Have More Questions

“Google, yes Google is great. I use it all the time. Let’s take a look at Google and see exactly how this would work.”

Then follow up with: “I can see we’d like a basic keyword search. Are there any other fields you’d like to be searching on?”

And, “Google seems to display a page title and snippet of text for each search result. What would we want to display in these spots?”

And so on …

(If “and so on” turns your insides out with worry, our Requirements Discovery Checklist Pack has you covered. Inside is a complete set of questions to consider when building a search feature, as well as tackling other types of requirements.)

Approach #2 – Yes You Are Wonderful, Please Tell Me More

But maybe your search feature should be nothing like Google. Maybe the idea of a keyword search doesn’t even make sense for your content. Maybe your stakeholder is asking for a feature that Google doesn’t even have, like, I don’t know, processing an insurance claim.

“Google, yes Google is great. I use it all the time. Let’s take a look at Google. {Bring up Google} “Were you thinking of the keyword search box? How do you see that working in our application?”

Most likely, either your stakeholder will realize emulating Google doesn’t make sense or they will enlighten you as to what they meant by “do it like Google” which was nothing like what you were assuming.

Either way, you win.

Approach #3 – Yes You Are Wonderful, Let Me Figure That Out, Then Let’s Talk

This approach works well when you don’t have a way to look at Google right now, your stakeholder has identified a competitor website you’d feel stupid not understanding, or you forget this advice completely in real-time and promise to get to work copying Google.

It goes like this. You analyze the specified feature of the website. You make an educated guess as to how it relates to your project. Don’t worry about this too much. You can be completely wrong and still get valuable information. In fact, the more wrong you are the better information you might receive.

You create a wireframe which shows how your application could implement a similar feature. You present the wireframe as a starting point for a discussion. You also come up with a bunch of questions using the approaches outlined above.

What you are hoping for here is not that your wireframe is magically right. What you are hoping for is that your stakeholder begins sharing what they really meant when they said “let’s copy Google.”

You save face by presenting a prototype that shows you were listening and able to start figuring things out while also getting the information you really need. Everyone ends up happy.

Alas, we are at the end of this article. It’s been great chatting with you about one of my favorite topics – that dicey combination of elicitation and requirements. Oh, the joys of being a business analyst! For those of you who are new here, that was not sarcasm. Yes, I do love this stuff. Yes, I am weird like that. But maybe, since you are still reading this rather long article, so are you.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.