Your MVP is not your Data Model
Your data model is the lens through which you evaluate your product and user behavior. Its should be led by your vision and not your MVP
What is the difference between a Jigsaw puzzle and a Lego set? A Jigsaw puzzle has one right configuration, and tough luck if you don’t like it. But with a Lego set, when you don’t like something you tear it down and build something entirely different.
As entrepreneurs we accept pivots are a fact of life. We understand it takes many iterations to achieve product-market fit. We want these iterations to happen quickly and cheaply. We want, ideally, to work with Lego bricks — but often we end up working with pieces of an oddly designed puzzle.
When building our MVP, it was difficult for us to see Trackmemo as anything else but the whole. When pitching, the focus was on the big picture. When designing, it was always if the entirety made sense to the user. As each individual piece got built, all that mattered was that it fit in. And we were still surprised when the result was a fairly complicated jigsaw puzzle.
And yet, we were not building Trackmemo because the big picture was new. We realized that when people communicate at work, it is always in context of some content — a document, a task, an account — and in current tools the content gets pushed away from the conversations reducing productivity and hindering collaboration. Our idea was to shift from a user — conversation view to a user — content — conversation view. It was about capturing and utilizing relationships that exist today but in our opinion are underutilized. But while building the MVP we worried too little about the details of how these relationships manifested in the product.
The mad scramble after our MVP release taught us a few lessons.
- Your data model is not your DB schema. A good DB schema is an efficient implementation of the data model. Your API might be a better representation of your data model.
- A data model with lesser constraints is not better. A good one imposes the right constraints on the product.
- A good data model is a language to describe your product vision. It communicates your product vision, and its scope beyond the MVP.
- A well thought out data model makes older data reusable. Time spent in building this gets repaid many times over even if you pivot once.
- Changing your data model often implies changing some fundamental assumptions about the product and/or business. Its better to proceed in these cases with some caution.
In retrospect, if we go back and build Trackmemo again we will spend significant amount of time early on building our own Lego bricks aka nailing the data model.
