A few points if you are seriously looking at this as a business start-up:
- I like the idea and have contemplated this on many occasions while trying to track time, though I personally have since moved to flat-rate, tier structured pricing models.
- If you are looking for concrete answers and guidance on your potential demand, as well as information on price sensitivity, perform STRUCTURED MARKET RESEARCH. That is, do not ask open-ended questions on a single thread. Determine your industry, market, then segment, and create a survey (or surveys) to administer to a REPRESENTATIVE sample of your population. Make sure you have a large enough response rate, given your sample size. The results you will get will actually represent what your target market's desires, opinions, etc. are. That being said, open discussions with potential users in a community like M&A on Newschoolers is a fantastic way to gain general beginning insight, (and in some cases a pretty solid idea of a starting point). Just be mindful that the responses you are getting are simply anecdotal, not statistical.
- I hope the majority of that was information you have already thought about, and if so, I mean in no way to offend, just trying to give a little guidance on your initial moves so you're not kicking yourself for making an ill-supported business decision.
Now, my *anecdotal* response to your initial post and general product idea:
- Not sure the scope you are looking at, but it seems to be a rather niche segment. First question would be is there enough demand?
- Given there is enough demand, what are your costs and time for development? Is this going to be a large undertaking, or simply you doing some coding for a few weeks on your own? Additionally, if the barriers to entry are in fact very low, what is to stop someone else from creating the same plugin, but better? Why/how are you going to make yours different (i.e. how will you differentiate your product from other current or potential competitors).
- If you're looking to make this a plugin type product, what platforms are you looking into? Would there be a way to develop one version that integrates well across various platforms - think about FCS3, FCPX, CS6. Now Mac platform vs. PC. Also, what about the older versions. Will a smaller filmmaker with CS5, for example, be able to use the plugin as well? Think about the possibility of alienating potential customers - not everyone is currently operating on the newest software. Also then consider the cost of development, if that means more efforts to make the plugin compatible with the older software suites - do the revenues from those potential customers justify the extra development costs?
- Additionally, what about other media professionals. Will the plugin work in, say, Adobe Illustrator? That could be an entirely different market - graphic designers. Then there are Photographers with Photoshop and Lightroom. Even further, would it be possible to extend the plugin across to other arenas within these media industries? Possibly colorists, or sound designers? What about music producers, with the surge of electronic music and so much production occurring on computers today - maybe apply the plugin to programs like Logic and Ableton. Going back to Creative Suite, some additional targets could include web designers, book designers, platform designers, animators. Specifically within the Creative Suite collection, there is pretty much a profession aligned with almost every program offered. (sorry for that abundance of possibilities, more and more came to mind as I was writing).
As for pricing, I see a few options on the business end: Premium/differentiated image, Price competition, Freemium model, or an Acquisition play.
- Premium: This seems to be the model you are currently thinking about - basically figuring the willingness to pay from your market and trying to best match that, while covering your costs. This would, realistically, be selling a relatively few number of plugins (subscriptions, perhaps?) for a relatively high price. Generally a safer bet because each unit sold brings you significantly closer to your break-even point and then the subsequent units sold yield higher returns (with the price roughly equaling profit per additional unit sold after break-even).
- Price: On the flip-side, you could offer a low price with the intent to sell on a larger scale. Your margins would be significantly lower on a per-unit sale basis, so you would have to sell more of them in order to become profitable. However, with the lower price, you would (in theory) be able to capture a much larger portion of the market, which could far exceed the profits of the aforementioned "Premium" model. This is what happened with the massive initial success of iPhone Apps when they were originally released at the $.99 mark. From the app developers' perspective, they invested tens of thousands of dollars to create the app. They then needed to make that investment back in order to be successful, so selling the app at a dollar per unit was a terrifying idea. However, from the consumer's perspective, it was much easier to justify downloading a useless game for just a dollar, rather than putting serious thought into the price vs. reward they would get from the app. As a result, that notion of "it's only a dollar" shared by millions of users led to millions of apps downloaded, which translates to millions of dollars in profits.
- Freemium: This is somewhat of a hybrid of the first two and is where most mobile apps have gravitated in the past year or so and continue to move towards. This pricing structure would include multiple tiers of the plugin. The plugin would be made available for free download (or whichever implementation method you chose) as a basic, or 'lite' version. This also could help protect against piracy, since you would be giving away the basic version for anyone who wants to try it out (a great example can be found with Black Magic Design's DaVinci Resolve line). The money lies, then, with the more performance-oriented users who want more out of the plugin. These users could then upgrade to the full version for, say, $9.99 to gain all of the features. This would take some careful thought as to the different features offered in the full vs. the lite version. Generally in image-focused plugins (MB Looks, etc.), the free version might have a MASSIVE watermark across the screen, forcing the user to buy the premium if they want to use it for results, posting, etc. I personally am against this route, as it can actually anger the free users and detract them from the brand/product as a whole. What you would want to focus on is getting the free users to use the plugin enough for it to become a staple in their workflow and then when they need to use it to get to the next level, they cannot move forward in their work without it. Taking Black Magic Design's model with DaVinci Resolve Lite - they offer the entire program in full functionality for free, but limit the number of nodes you can use in a given color grade, a feature only needed by high-performance users. This could be applied to your plugin in the following way: The lite version could offer full tracking of time editing, but only for 1 or two projects per month, but unlimited use with the paid version. As a result, the full use of the lite plugin motivates users to effectively track time to accurately bill clients, which (in theory) ultimately leads to higher volumes of work. The plugin has now been implemented into the editor's workflow successfully, which has led to additional work, which the editor now needs to continue using the plugin for. As a result, the editor now needs to upgrade to the paid version. With this model, the strategy is all about initiating use of the plugin and then establishing a dependency on it.
- Acquisition: This would be a potentially higher risk, higher reward play. The ultimate goal is to create a plugin, development team, infrastructure, and/or anything else unique to your plugin, or the way it is created, and license or sell it outright to the companies themselves. Acquisition as a plan/exit strategy would be the cleanest way to monetize the plugin, but the most risky. You essentially would create, develop, build, test, etc. the plugin within the entire Creative Suite (let's pick Adobe as the example), and then propose to Adobe that they buy the rights to the plugin (more likely), or buy full exclusivity to the plugin, its concept, etc. (less likely) to implement it directly in the software as an included Adobe plugin. At this point you would negotiate a contract and walk away with a lump sum, rather than hinging your returns on units sold/subscribed. Getting acquired would not be nearly as easy to accomplish as it sounds, or as any of the other monetizing/pricing strategies. A major risk involved is that if you invest all of the time and costs to create the plugin and they turn you down, you have no recourse of action. There will remain little opportunity for you to bring the plugin to market on your own, as you would need Adobe's cooperation, which is a bridge you have then more-or-less burned.
- You could, however, enter the market under one of the first three pricing strategies in hopes of gaining enough exposure, following, and use to get onto the radar of the companies themselves, in which case acquisition could come onto the table from them approaching you (even less likely, but a possibility). This would be best implemented under a low-price or even free structure to get the plugin used by enough people who, in turn, would create a "pull" on the companies to implement it directly into their software (rather than a "push," which would be you telling the company that they need it for their software).
Some thoughts on this from a business perspective. If you were already aware of the majority of my points, I'm sorry. I also apologize to everyone for the extensive length of this post. You seemed to want some serious thought and ideas about your concept, so I figured I would share.
Best of luck in all of your endeavors, and let me know if you have any questions or would like clarification on any of my points.
- Chase
