Thomas Edison once said, "Every failure is a lesson learned about your strategy."
Today, we bask in the warmth of the realization that failure leads to change, change leads to growth, and growth leads to improvement. For the last several years, we've built a web content management system (CMS) that is capable of things we have yet to imagine. The concept of others using our creation to create sites in ways we haven't considered is truly exciting. One feature, however, has been a thorn in our side since the beginning - the ability to derive multiple pages from a single entity.
[CAUTION: TECHNICAL MUMBO JUMBO]
In Marketpath CMS, a page is essentially a URL on your site, like mysite.com/contact-us. And an entity is a pre-defined object type, like an article, author, blog post or a calendar entry. A page is always a child of an entity and can't exist without some parent entity. An entity can have as many child pages as desired.
Here's an example of an entity with multiple pages. Let's say I'm a keto coach, and I wrote a white paper about the benefits of a ketogenic diet, and I want to promote it via paid ads. My goals are to establish my expertise for individuals in the 35-55 age group, convince individuals to read the material, and ultimately win some new clients. I am targeting both males and females in that age range.
With the way Marketpath CMS currently works (as of 10/5/2018), I can create two pages from the white paper article entity, one for males and one for females. It's the same white paper, but two different landing pages (and two different URL's). One page has images and CTA's that drive female engagement and the other drives male engagement. Two different audiences, but one single white paper.
[END: TECHNICAL MUMBO JUMBO]
This is a brief, over-simplified example. So if you're confused even a little, then you're in good company. Our biggest challenge with Marketpath CMS has been explaining the difference between an entity and a page. Technical-minded people mostly get it. The average Joe, however, can't make that connection and it simply baffles most people no matter how much we try to explain it.
Our failure is not keeping CMS relationships simple in the first place, and then not acting on the fact that we couldn't communicate them effectively. We have tried and tried to simplify the concepts and revise our explanations, but we can never get everyone on board.
So, our current development effort is to completely eliminate the one-to-many relationship between entities and pages. Every entity will only ever have a single page. The end user really won't have to think about the relationship at all. This change will dramatically simplify our users' understanding of the system and improve the overall user experience.
We concluded the advantage of the multi-page feature far outweighed the difficulty most users have understanding it. And when users can't understand your product, no matter how amazing it is... well, that's just bad product design. We're learning from our failure, and we're owning it.
The goal of any software development team is to build a product that solves a need. We identified the need to reach multiple audiences with similar or reusable content (as in our example above) and felt there were many more opportunities than what we imagined. And we still believe that. But it's a fringe usage of our system, and we somewhat disregarded the feedback we received. We assumed we could figure out how to get people to understand. We failed. We gave it a go but now we humbly swallow our pride and move on to bigger and better things.
Bye-bye multi-pages per entity. We loved you, but we probably won't miss you all that much.
