How To Think About Business Intelligence Data (part 2)

Welcome back to NoteLoft Newsletter - the shortcut for founders who want to go from MVP to scale. Every Saturday, I share what actually works when building software, so you can spend more time on deals, growth, and going to Pilates.

If you need help taking your product from MVP to scale, get in touch! We’ve grown our tech team, and we can’t wait to help you.

Let’s get into it!

The Mistake Founders Make With Messy Data

Last we spoke, I was telling you about that client who wanted my team to clean a big data set she’d given us. I disagreed; in my opinion, the priority should be to model the data, not clean it. I want you, as a founder, to understand the difference. Because the faster/cheaper/more efficient thing to do is to model the data early. 

Cleaning the data means going through every row and fixing what’s messy. Doing things like standardizing dates (for example: April 14th and 4/14 are the same thing technically, but not cleanly), removing duplicates, fixing typos. Those are things we can do after we model the data. 

Modeling the data means figuring out what shape the data should be in. What entities exist, how they fit together, and what the data is supposed to actually represent versus what we currently thought needed to be captured. It also informs real boundaries between what types of entities exist, and how they work together.

I recently started going to Hot Yoga Sculpt classes (I have never slept better; highly recommend), so let's use that as an example. 

Entities for Hot Yoga Sculpt Class

In software, an entity is the “thing” your product needs to understand. For a hot yoga sculpt studio, the important entities are pretty obvious: client, instructor, class, session, booking, and membership.

Now that we’ve defined the entities, we need to turn them into models. To do so, we’ll need to give each entity its attributes and relationships.

Turning Entities Into Models

Each entity has its own attributes:

Client — name, contact info, membership tier, join date

Instructor — name, certifications, specialties

Class — name, type, duration, max capacity

Session — date, time, location/studio room, instructor, class type

Booking — client, session, status — confirmed, waitlisted, cancelled — timestamp

Membership — client, plan type, billing cycle, sessions remaining

Then we define how they relate to each other:

A Class is taught by an Instructor during a Session.

A Session has many Bookings.

A Client makes many Bookings.

A Client holds a Membership that determines how many Sessions they can book.

And now we’ve modeled the data.

The model is not just a list of things in the business. It is the structured version of how the business actually works. It tells the software what to store, what to connect, and what rules to follow.

Now that we understand how the data is modeled, we can start designing the database, the front end. We can start thinking about the algorithms we need to implement to get a full app working. We can pick the correct order things need to be built in, create tickets, and assign work.

Anyway, after I explained the difference between the two, the founder got excited. She’s the kind of person who loves learning new things, even when it means we have to reject her ideas.

She’s the ideal NoteLoft client.

Speaking of which, if you’d like to become a NoteLoft client, book an intro call with me here.

Best,

LaToya