Pricing / entry cost for this tool

Dennis Brown see3d at writeme.com
Sat Nov 26 20:40:29 EST 2005


Dan,

I know you qualified that as *development* tool, but I am just  
thinking *tool*.  I don't look at Dream Card differently than  
Elements, or a low end CAD tool, or an outliner...  All are  
"consumer" tools to me.  I look at the utility of each to me to solve  
one type of problem.  Being a hobbyist, I use a lot of different  
tools, but not at the same time.  In fact, the reason I buy a tool is  
because I have just one project that I need the tool for.  I might  
use Rev like crazy for a few months, then not use it at all for a  
year, then back at it again.  I also have a lot of woodworking  
tools.  I buy the lowest cost tool that will do a reasonable job,  
then If I wear it out, or find it is the most used tool, I will  
replace it with a professional grade one.  If I were to go for the  
professional grade software, or wood working tool in everything I  
have, I would have to spend $100K in tools and if it were all  
software tools, $30K/year in upgrades  --that isn't going to happen!   
However, If I really got into Rev and was going to generate income  
with it, I would upgrade to a Professional version --just as I would  
with any other tool that warranted it.

I see examples of the multi price point tool products from successful  
companies everywhere.

When I buy a table saw, darned if they don't all have a similar user  
interface.  Expectations also change with the size of the  
investment.  If my cheap $100 saw (which lacks some features of the  
expensive one and comes with a short warranty) breaks, I try to fix  
it, or junk it.  Whereas, if my expensive saw breaks, the manufacture  
better damn sure get their asses in gear and get this tool fixed now  
--and they do!

In the case of RR, I think they are taking the right approach.  They  
primarily listen to and support the professional customers --exactly  
right, that gives them focus.  They maintain one interface and code  
base across their products --essential for limiting the incremental  
work involved in the lower priced products, since the company is too  
small to support multiple efforts.  Since Rev is complex to fully  
learn all the features, Hobby programmers that grow into  
professionals, do not have to start over in the learning curve.  I  
just can't think of a better planned way of doing this with the size  
that RR is now.

Being the type of customer that (if I weren't retired) could  
potentially turn Pro, I can speak from how I view these products.  I  
view the RR product line in a favorable light, but Transcript is rich  
and complex.  The biggest roadblock I see is making the documentation  
into something that captures the wisdom of this list that can be  
searched with only a concept of the problem to be solved instead of  
what the solution is called by someone else.  It is too big a project  
for RR to tackle.  It can only be done by this list.  But that is  
another thread on another list.

BTW, in the early 70's I was a freelance consultant for early Intel  
8008 based product developers.  I wrote an 8008 emulator for a  
minicomputer that I designed, and ran Intel's development tools on  
it.  I could turn around compiles 10 times faster than my customers  
using Intel's native development tools.  I provided hardware or  
software consulting.  The thrust of my consulting was to provide  
initial solutions, then provide the training to the customer's  
engineers to take over the project as soon as possible (I had my own  
products to develop, but needed to generate additional cash from  
consulting).  So my perspective does span a broader range than just  
the inventive hobbyist.

Dennis

On Nov 26, 2005, at 3:24 PM, Dan Shafer wrote:

> Dennis....
>
> A well-thought-out and appreciated post.
>
> But, as with others who have offered this viewpoint, I am compelled  
> to ask you to provide even one example of a development tool  
> company following the strategy you describe below that you say is  
> "being used by the most successful companies today."
> And I'll expand on that a bit. Not only can I not think of a single  
> *development tool* company following the strategy of trying to  
> serve two markets with a single product, I can't even come up with  
> a single successful software company doing that. When I think of  
> successful software companies in the desktop universe, I think of:
>
> Microsoft
> Adobe
> Macromedia (about to be swallowed by Adobe if that hasn't been  
> finalized yet)
> Apple (partly)
> Real
> Maybe Oracle (which is a dev tools vendor in large part, but not  
> much on the desktop)
>
> Adobe doesn't have a low-cost entry version of Acrobat or inDesign.  
> A trial version, yes, but when it expires you pay through the nose  
> to keep using it. Same with Macromedia. Apple supports low- and  
> high-end users in a couple of its strategic markets, but with two  
> separate products, not a low-cost version of the high-priced one.  
> Real has a free player but if you want to start creating Real media  
> streams you're gonna pay a bundle.
>
> So where are these software companies that are following this two- 
> market strategy successfully? To the contrary, I think the secret  
> to a successful company -- in any sphere -- is focus. Do what you  
> do well and let others do the stuff you don't do well. If RunRev  
> had a couple hundred people, *maybe* they could figure out how to  
> serve both markets with great success. Short of that, I am  
> unconvinced.
>
> On Nov 26, 2005, at 8:52 AM, Dennis Brown wrote:
>
>> I think that they are more likely to stay in business with the  
>> current model --it is the model being used by the most successful  
>> companies today.  They are growing (I assume) slowly as the  
>> product matures.  At some point I expect this model is going to  
>> propel them forward into a larger company that can offer better  
>> general support and product bug fixes (I think bugs cost more to  
>> fix than adding minor new features), while continuing to support  
>> the professionals needs.




More information about the use-livecode mailing list