How Can a Stakeholder Know What They Don't Know?

Requirements Mind Reader.png

Welcome to an exciting Dreamforce 2070! 

Salesforce partner Clairvoyance just announced the beta test of My Business Analyst (MBA), powered by Einstein Mind Reader. Clairvoyance claims that MBA expedites discovery of business needs by reading stakeholders’ minds. MBA takes stakeholder thoughts about business needs and turns them into a requirements database. 

Your company has a client in the MBA beta test program. The client wants to see how MBA compares with your talent as a respected business analyst / architect. The pilot focuses on the customer journey from a lead to a sustained customer relationship. MBA fascinates the marketing vice president. She’s the first to try it, eagerly thinking of ways to capture, qualify and assign leads. The sales VP comes next, thinking about converting leads into prospects, and prospects to customers. Then, the customer relations VP thinks about tracking customer cases and measuring their satisfaction.

MBA distills this massive collection of thoughts into hundreds of requirements records. The VPs review their requirements, edit them for accuracy, and make sure the requirements cover every need they thought of. They hand the requirements off to you for evaluation.

First, you examine the marketing requirements. The marketing requirements cover the happy path quite well. Marketing runs a campaign, collects leads, and assigns qualified leads to sales. In a meeting with the marketing VP, you ask what happens to the leads that don’t go to sales. She admitted some uncertainty about it, apparently enough to keep MBA from creating requirements. She wants “warmer” leads to go to inside sales for follow up, and the rest go into a drip campaign. What are the criteria for a lead going to inside sales? The marketing VP discusses that with the inside sales director.

Next, you evaluate the sales requirements from MBA. The lead assignment process does not align with marketing requirements. The sales requirements track conversion of a lead to a prospect, creating a proposal and a contract. The requirements do not include a process for tracking lost sales. The marketing requirements expect a win / loss analysis to gather information about competitors and their products.

Finally, you turn to the customer relations requirements. They assume that every customer will register on the customer relations website. They don’t specify what should happen if a registering customer does not have a matching contact record in the system. When you ask the customer relations VP about it, he admits forgetting about that exception. He works with you to develop a process where a customer service administrator will find unmatched customers. You also recall marketing has a need for each new customer to get a welcome email from customer relations. That exposes another gap, as the customer relations requirements do not include the welcome email.

You meet with the three VPs to analyze the requirements gaps. They collaborate to fill the gaps between departments. The marketing VP asks how MBA missed key requirements. Having thought about it, you speculate that MBA could only create requirements from business needs that the VPs knew well. If they had incomplete knowledge of a need, MBA didn’t have enough data to create a requirement. 

The sales VP who would rather close deals than attend meetings, appreciates the value of this meeting. The others agree. They report to their beta team that MBA did a good job capturing well known business needs. However, it missed requirements shared across departments. It also missed exception cases that the VPs did not have at the top of their minds. They conclude that MBA will not eliminate the need for a business analyst motivating them to collaborate and clarify the needs they know about. They look forward to discovering new advances at Dreamforce 2071.

Collaborate with stakeholders to clarify vague business needs, transforming them into well known needs. 

This is the sixth in a series of posts about unknowns in the discovery process.

This is the sixth in a series of posts about unknowns in the discovery process.

Previous
Previous

Build What We Need, Not What We Asked For

Next
Next

Exceptional Discovery