OpenMinded

Polyamory is a topic that may be taboo for some, but it was naturally intertwined with the sugar dating realm. Building a bridge between alternative love views and community awareness was our challenge.

om-group-dashboard-001-drib.png

Objective 1: Feature, or not to Feature?

OpenMinded was well-planned (for the most part) in terms of its desktop and mobile presence. The biggest issue from a marketing perspective was seeking ways to monetize the website. 

Monthly membership is the same for all members as users could list any gender/sexual preference/relationship type they wished down to the most minute detail. 

I argued that raising prices was unjustified as the product was only 90-days into launch. Raising prices is often a crutch for lack of foresight, so I formed a plan for feature development.

My thought constraints were as follows:

1. Male/Female/Non-conforming members were charged the same, regardless of preferences.

2. AFF was our major competitor. The CEO had no interest in crossing into pornographic markets for advertising, so we were limited to consumer products and risked cannibalization by cross-promoting to the sister dating websites—a dwindling stream of revenue.

3. The desired emphasis was networking first, and dating second. Interestingly, our developers created the product with the emphasis in reverse. I then had to think backward to create the community aesthetic and downplay the dating features we had so heavily relied on in the past.

om-group-create-001-drib-1.png

Objective 2: Monetizing Groups

 Referencing relevant competitors AFF and MeetUp, I felt that group-based features were the best way to move forward with monetizing the OpenMinded website.  

I suggested a hierarchy for groups. There would be several major "welcome" forums that every new member would automatically be added to. If members desired a private group, I suggested that we charge an initial fee.

Beyond the initial fee, I proposed either a) monthly or, b) quarterly fees set by the group moderators at the time of formation.

om-group-dashboard-001-drib.png

Objective 3: Implementation

I found that it's easy to suggest a feature from an existing competitor, but it's another process altogether to improve it. 

Feature development proved to be time-consuming because our proprietary database tracked the site data for partners sharing an account as a single individual. This was an issue stemming from the initial site plan.

I proposed a solution: that our development team consider a "toggle mode" for profiles so that we knew, for all intensive purposes, if player #1 was in control or player #2. We could then use this focused data to fine-tune group matches in the future for shared accounts.