Showing Customer Concepts

Understanding Customer Requirements

Relating the Customer Terms

Once a purposeful architect has compiled a glossary of customer terms in discovery, how can s/he show his or her understanding of the terms? Reviewing the glossary term by term will turn a discovery meeting into an executive snoozefest, losing the attention of most stakeholders. Besides, there’s more to customer terms than their definitions.

Each customer term (noun) expresses a concept. For example, the Salesforce Sales Cloud includes these six concepts:

Account
Contact
Contract
Opportunity
Order
Quote

Each concept has a relationship with one or more of the other concepts. For example, an Account employs a Contact, enters into a Contract, presents an Opportunity and places an Order. A Contact informs an Opportunity, negotiates a Contract and receives a Quote. Account and Contact have seven relationships with the other concepts, which relate to each other.

Showing Concepts and Their Relationships

Once a purposeful architect understands customer concepts and their relationships, how does s/he show that understanding to the other stakeholders? S/he creates a diagram representing concepts as shapes connected by lines showing their relationships with each other. This diagram is called a concept map.

Here is a minimal concept map showing the relationships between all of the concepts listed above, except Contact:

The map shows each concept in a box. An arrow between two concept boxes shows their relationship. The direction of an arrow shows how to read the relationship between the concepts it connects. For example, an Account presents an Opportunity. A simple concept map like this works well as an introduction to showing concepts and their relationships. Showing a few concepts and relationships at a time makes it easier for stakeholders to comprehend the concept relationships.

Adding Contacts to the concept map introduces four relationships with the Contact concept:

Showing the Way to Deeper Discovery

Let’s say a customer stakeholder asks what a contact does regarding opportunities or contracts. They want to know which contact makes a purchase decision, who influences the decision and who negotiates the contract, among other things. Some contacts play the same role on all opportunities. Some contacts have multiple roles. Contract negotiation can involve several contacts in various roles.

The purposeful architect shows the Roles relating Contact to Account, Contract and Opportunity:

Click map for a full page view

Agility Starts Here

Creating a concept map incrementally takes the same approach as agile software development. It starts by showing stakeholders a minimal design and collecting feedback. The model development continues in cycles showing incremental changes. The stakeholders focus on digestible changes rather than deciphering a complex map revealed a long time after the last discovery meeting.

Concept Map Considerations

A concept map works hand in hand with a glossary which defines each concept in the map. The glossary serves a reference for understanding. The concept map illustrates understanding. For example, a new stakeholder reviews the concept map and asks what a concept means. S/he finds the definition of the concept in the glossary.

Someone familiar with the Sales Cloud data model may notice a resemblance between it and the concept map. Those very familiar with the data model will notice differences between the two. A concept map may resemble a data model, but it is not. It can inform the design of a data model later in the development cycle. A concept map does not require the details nor is subject to the constraints of a data model.

To some, a concept map may resemble a process map with its boxes and labeled arrows. It does not show process flow, only relationships between people, places and things shown as concepts on the map. Process mapping happens later in the development cycle.

A purposeful architect presents a concept map only to reflect his/her understanding of customer concepts and their relationships. Customer stakeholders have an opportunity to clarify, correct or complete that understanding when reviewing the map. A common understanding of concepts and relationships among all stakeholders clarifies their communications. It can prevent misunderstandings that result in a solution not meeting customer expectations.

Diagramming customer concepts brings all stakeholders to a common understanding of the people, places and things a customer manages in the scope of a solution.

Additional Information

I created the concept maps using Elements.cloud. It is intended for drawing process maps, but works well for creating concept maps.

For more information about creating concept maps, see Business Knowledge Blueprints by Ronald G. Ross.