The Entity Relationship Blueprint (ERB) is the foundation of your product. During this process, you’ll be defining and organizing the data your product will use. Essentially, it’s about identifying the core entities (things like “users,” “accounts,” “subscriptions,” etc.) that your system will interact with and mapping out the relationships between them. 

I get it—data modeling isn’t everyone’s idea of a fun afternoon. But before we can get to the exciting parts like flowcharting, UX design, or even writing code, we have to lay the groundwork. Everything else—your Information Architecture (IA), user flowcharts, and the actual development—relies on this first step.

It’s important to note that your ERB is not the same as a developer’s Entity Relationship Diagram (ERD). In technical terms, what developers do in their ERDs is part of a process called Domain-Driven Development (DDD). DDD is about structuring software to reflect real-world complexities, which means developers take the ERB and extend it with the granular details needed for building the database and technical architecture. While your ERB is a more high-level, simplified version of the ERD, by first developing this blueprint, you’re laying essential groundwork, doing much of the legwork that will make the DDD process smoother for your development team. 

Creating an ERB ensures that you and your team are speaking the same language. You don’t want to get halfway through development only to realize that when you said “customer,” the developers had a completely different idea of what that meant. Are we talking about your customers, or your customers’ customers? Miscommunication like this happens more often than you’d think. The ERB helps prevent these issues by making sure everyone is clear on the nomenclature for the entities and how they relate to each other.

You may be thinking: can I skip this step? In most cases, I’d say no. Without a solid ERB, you’ll spend a lot more time later realigning on basic application direction and the nomenclature in the app. When I first started building software, I used to dive straight into creating flowcharts, skipping over the data modeling part. That approach seemed faster, but it ended up costing me more time in the long run. As my understanding of the product’s data model evolved—and as stakeholders would “surprise” me with new parts of the application we hadn’t talked about before—I found myself having to constantly go back and update the flowchart and IA to ensure they remained the source of truth.

Eventually, I realized that if I took the time to create the ERB first, it saved me from making those time-consuming revisions later on. The ERB helps achieve alignment at the highest level before moving forward, clarifying key relationships and making sure everyone is on the same page from the start. That being said, if you’ve previously documented your data model and have a high level of confidence in the existing data model of your product, you may be able to skip to the IA or flowchart. If you’ve never sat down and mapped it out, now would be a great time to do so. 

In this chapter, we’ll break down the process for creating an ERB, step by step. By the end of this exercise, you will have achieved two things. First, you’ll have a logical foundation for your product’s data architecture. Second, your product’s idea and technical requirements will be aligned.

Getting Ready

Before I walk you through the steps of the process, there are a few housekeeping tasks that need to be taken care of. 

Assemble Your Team

Creating an accurate ERB is essential for setting up your project for success, so it’s crucial to bring the right people on board from the beginning. Typically, this includes business leaders (like the founder or CEO) and any subject matter experts (SMEs) who have a deep understanding of the business and how it currently operates. 

SMEs are especially valuable if your product aims to enable digital transformation, as they can provide insights into existing processes—the “hard way”—that your product is meant to streamline into a digital solution. Often, when building an MVP, the founder is the primary SME because they’re solving a problem they’ve personally experienced. Their firsthand knowledge is critical to ensure that the entities you define align directly with the real-world needs your product will address.

Choose Your Tools

There are plenty of tools out there to help you create an ERB. Personally, I prefer FigJam because it’s part of the Figma ecosystem, but you can also use Whimsical, Miro, or even AI-powered tools like Supabase’s AI-powered tool for data modeling. If you’re not very technical yourself, don’t be afraid to leverage ChatGPT or other AI tools to help better understand the business nouns and determine the cardinality between entities.

Leave Perfection at the Door

Don’t worry about getting everything perfect from the start. You’ll likely make adjustments to the ERB as you go. What’s most important is that you remain flexible and focus on getting the broad strokes right—you can always refine things as you move through future steps. 

The Process

So, how do we go about creating an ERB? Before we get into the specifics, let me give you a quick overview of the steps: 

Step 1: Identify the Key Business Concepts (Entities)

We first need to identify the important elements in your product, the “things” your platform will track and manage. Examples of entities could be users, subscriptions, and invoices. 

Step 2: Define Each Entity

Next, we’ll define what each of these entities represents within the context of your business. This may seem tedious at times, but it’s important that everyone knows what the difference is between entities such as “customer”, “client”, and “user”. 

Step 3: Identify the Relationships Between Entities

Finally, we’ll map out how these entities are connected to one another. Does one entity belong to another? Can there be multiple associations between them? This is where we figure out how everything interacts in your system.

Now, let’s break each of these steps down in detail.

Step 1: Identify the Key Business Concepts

The first step in creating your ERB is identifying the key business concepts, also known as entities. These are the building blocks of your product. Think of entities as the most important “nouns” that your product will be working with. They’re the things your system will track, manage, or interact with, and they could be anything from people to objects to abstract ideas, depending on your product.

Here’s how to go about identifying your entities:

1. Start with the Basics

Start making a list of the core components or nouns of your business. What are the main things you’re tracking or managing? Common examples of entities include:

  • Customer
  • Subscription
  • User
  • Account
  • Item

Tip: If you’re unsure about which entities are most important, look at your business model. How does your business operate, and what are the key things it needs to function? This can help you identify the most important nouns or concepts. If you’re building an e-commerce platform, for instance, your key entities will likely include “Customer,” “Product,” and “Order.” 

Don’t worry about missing a few entities right now. Just try to think of as many as you can. 

2. Think About People, Objects, and Ideas

Entities can usually be grouped into three categories: people, objects, and ideas. Here’s a breakdown to help guide your thinking:

People: Who are the main people or groups interacting with your product? Customers, users, admins, team members from the same company?

Objects: What tangible things does your system manage? Orders, files, reports, etc.?

Ideas: What abstract concepts are important to your business? These might be things like “proposals,” “projects,” or “subscriptions.”

3. Keep It High-Level

At this stage, you don’t need to worry about the smaller details or specific properties of each entity. We’re focused on defining the big picture. For instance, instead of thinking about the specific attributes of a user (like name or email address), just focus on “user” as a general concept. We will get into the details later.

To help get you started, here are a few examples of entities for popular software: 

  • For a project management tool: Project, Task, Team, Client.
  • For a SaaS platform: User, Subscription, Plan, Payment.
  • For a CRM software: Contact, Lead, Account, Activity. 
  • For a learning management system: Student, Instructor, Course, Module. 
  • For an HR management platform: Employee, Position, Payroll, Benefits. 
  • For a social media platform: User, Post, Comment, Follower. 
  • For an inventory management system: Product, Supplier, Warehouse, Shipment. 
  • For a healthcare management software: Patient, Doctor, Prescription, Appointment. 
  • For a task management software: User, Task, Due Date, Project. 

You get the idea. By the end of this step, you should have a list of core entities that make up your product. 

Step 2: Define Each Entity

Now that you’ve identified the key entities for your product, it’s time to define what each entity actually represents. Defining entities is a critical step because it ensures that everyone on your team—from developers to designers—shares the same understanding of what each entity means in the context of your product. The clearer these definitions are, the easier it will be to avoid confusion later on.

Here’s how you can effectively define your entities:

1. Describe the Purpose of Each Entity

For each entity, ask yourself: what role does this entity play in the system? Think of this as defining each entity’s purpose or job. What is it responsible for, and how does it interact with other entities? This description should be clear, simple, and specific enough that everyone on your team can understand it.

Here are a few examples of definitions for entities associated with an e-commerce platform: 

  • Customer: A person who purchases products from our online store. Customers have accounts, can place orders, and leave reviews.
  • Order: A transaction between a customer and our business. An order includes a list of products, payment information, and shipping details.
  • Product: An item that is available for purchase in our store. Each product has a name, price, description, and inventory level.

Tip: Whenever possible, use real-world examples from your product or business to clarify what each entity represents. For instance, if you’re defining a “project” entity in a project management tool, you might use a current or past project to help explain what data is associated with it, how it’s structured, and its role in the system. 

Project: A specific work initiative assigned to a team. Projects have start and end dates, deliverables, and a list of assigned tasks. For example, in our “Website Redesign” project, a sitemap is a deliverable and a task is a design review. 

2. Consider the Business Context

The same word can mean different things depending on your industry or product, so it’s important to define each entity within the context of your business. For example, the entity “user” might mean a customer using your service in one system, but it could mean an internal employee in another. So, as you define each entity, make sure the definition aligns with how your business actually operates.

3. Avoid Ambiguity

If your definition can be interpreted in more than one way, it’s too vague. Be as specific as possible, and don’t assume that everyone on the team has the same mental picture of the entity. If you’re worried any of your definitions are too ambiguous, ask individuals who weren’t involved in the initial process to interpret your definitions. If different people interpret a definition differently, then it needs to be cleaned up.

Here are two different definitions for “client”. Which one do you think is more clear? 

  1. A person who uses our product.
  2. A person or organization that purchases our consulting services. A client can have multiple projects and access to reports.

Obviously, b is the better definition. Make your definitions more like b. 

4. Differentiate Similar Entities

Some entities might seem similar, but they serve distinct purposes in the system. It’s important to clearly distinguish between them. In a project management platform, for example, there could be a “proposal” and a “project” entity. Both denote stages of an engagement with a client, but they play different roles. A proposal serves as a preliminary outline of the work to be done, with estimates, timelines, and deliverables that are subject to approval. Once approved, it becomes a project, marking the start of active efforts to complete the agreed-upon tasks, with tracked milestones and deadlines to ensure progress.

Clearly defining and distinguishing entities that feel very similar to each other—such as “order” and “invoice”, “request” and “ticket”, or “quote” and “contract”—streamlines communication between stakeholders, designers, and developers and helps prevent confusion. 

5. Capture the Key Attributes

At this stage, you don’t need to get into the detailed properties (attributes) of each entity, but it may be helpful to note the most critical attributes for each one as part of the definition. This will give everyone a better understanding of what kind of data each entity holds. Later, these attributes will be built out in your IA and user flowchart. 

Here is an example of some attributes for a “customer” entity: 

  • Name
  • Email address
  • Phone number
  • Shipping address

When I do this, I usually list attributes beside the entity in the ERB: 

After you’ve defined all of your entities, make sure these definitions have been clearly documented and are easily accessible by your team. Anytime someone has a question about an entity, they should be able to refer back to these definitions.

Step 3: Map the Relationships Between Entities

Now that you’ve defined your entities, the next step is to create your ERB by identifying how these entities are connected. This involves determining how they interact with each other, how information flows between them, and ultimately, how these relationships shape the overall functionality of your product.

Let’s break down how to identify and map these relationships. 

1. Define the Relationships 

Unfortunately, “it’s complicated” won’t be sufficient. There are three primary types of relationships you’ll be looking for between entities: one-to-one, one-to-many, and many-to-many. These relationships define how tightly or loosely connected different entities are within your product.

One-to-One: In this relationship, one entity is linked to only one instance of another entity. An example of a one-to-one relationship could be between an employee and a user account in an HR system. Each employee has one user account, and each user account belongs to a single employee. I label this relationship as “1:1” when I create an ERB. 

One-to-Many: Here, one entity can be linked to multiple instances of another entity. For example, on an e-commerce platform, a customer can place multiple orders, but each order is only tied to one customer. This is one of the most common relationships you’ll see between entities. I use “1:Many” to label this relationship. 

Many-to-Many: In this relationship, multiple instances of one entity can be linked to multiple instances of another entity. In a learning management system, for instance, many students can enroll in many courses, and each course can have many students. I label this relationship as “Many:Many”.  

2. Ask Questions

The easiest way to map relationships between entities is by asking questions about how they interact. Some questions to guide you include:

  • Does one entity belong to another?
  • Can multiple instances of this entity exist for another entity?
  • Does this entity have a relationship with multiple other entities?

Here’s an example of how to ask questions for your entities. 

Q: Does a customer have multiple orders?

A: Yes. A customer can place multiple orders (one-to-many).

Q: Can an order have multiple products?

A: Yes. An order can include multiple products (one-to-many).

Q: But, can a product be part of multiple orders? 

A: Yes. A product can be included in multiple orders, so the relationship is actually many-to-many.

By systematically asking these questions for each entity, you’ll be able to identify the relationships and better understand how your entities interact. 

3. Consider Hierarchical vs. Peer Relationships

Just like how an organization may have multiple departments within it, some relationships are hierarchical, meaning one entity “contains” or “owns” another. However, other relationships are more like “peers,” in which entities interact with each other on equal footing. 

For example, in an LMS, “student” and “course” have a peer-to-peer relationship. There is no hierarchy between students and courses; they are simply interacting with each other as peers. A “module” can belong to a “course” though. They have a hierarchical relationship. 

Understanding whether your entities have a hierarchical or peer-to-peer relationship will help guide how you lay out your ERB. 

4. Test the Relationships with Scenarios

Once you’ve mapped the relationships in your ERB, you need to test their validity with real-world scenarios. This helps ensure that the relationships make sense in the context of how your product will actually be used.

First, brainstorm a few hypothetical scenarios a person could encounter when using your product. Here’s an example:

Scenario: A customer places one order for three products and a second order with four products. 

In this scenario, a customer is able to place multiple orders, and each order includes multiple products. Does your relationship model support this outcome? If yes, then congratulations, you’ve mapped this entity relationship correctly. 

Let’s try another scenario. 

Scenario: A student enrolls in three courses, and one course has 30 students.

If your system supports a many-to-many relationship between students and courses, you’re on the right track. 

You and your team should create a handful of these scenarios to test against any entity relationships you aren’t sure you’ve correctly defined and mapped. This ensures that your relationships hold up in practical, everyday use cases.

5. Document the Relationships

As you finalize the relationships between your entities, make sure you’re clearly documenting them in your ERB. This diagram will serve as a reference for your team and ensure that everyone understands how the entities interact.


By the end of this chapter, you should have accomplished three things: 

  • Identified the core entities of your product
  • Defined your entities
  • Mapped the relationships between your entities. 

Completing the ERB exercise helps lay the foundation for your product’s data architecture and ensures that everyone on your team has a shared understanding of the system’s structure. With your ERB in place, you’ve set the stage for the next step in Blueprint Agile: building the Information Architecture Blueprint (IAB). This is where we’ll organize your product’s data into a navigable structure, determining which pages and actions need to exist for users to interact with your product effectively. You’ll learn all about that in Chapter 3.