August 1997 BeDC: Approaching the Market

August 1997 BeDC

Approaching the Market

SCOTT PATERSON: Since we have a pretty small crowd and I'm an informal presenter, as we go through this stuff, if there are questions we'll address them at that time instead of waiting until the end.

My name is Scott Paterson, I'm the other half of the evangelist team with Michael. I'm going to go through Approaching the Market. I did a white paper on this topic, it's available on our Web site, and most of the information from here is drawn from that paper that I wrote. In that paper there are actually more details than I'm giving here. In some of the areas I go into, you'll see there are actually figures and numbers that I go into further detail in the white paper.

But anyway, the point of this presentation is that after you go through and create some great piece of software, there are still at least another eight areas that you have to consider as you bring your software to market. Most of this is drawn from Be's own experiences in bringing operating system software to market. Some things, as we went through the process, we said, "Oh, I wish we had thought of this beforehand, it would have made it a little bit easier for us." So hopefully we'll convey some of that to you and you won't make the same mistakes we did.

The areas I'm going to cover include production of your software, things like producing physical media. As you know, the BeOS comes on CD, so we have some experience in that area.

Creating awareness for your product. Obviously if nobody is aware that you have software to sell, you're not going to get many customers. How you can do that effectively, some of the things you can leverage to help you. The decision to actually purchase software, tools that can eliminate barriers to purchase. The actual transaction, how to minimize cost to you in accomplishing a transaction, how to exchange money.

Installation. Kind of the second half goes together except for support, installation, registration and updates. Some interesting things regarding registration and easily targeted future customers.

And finally, technical support, which was, out of all these areasi, the most surprising to me. I worked with Ed Romson, who is our director of customer service, on producing some technical support numbers, and what it costs to do it yourself or to have a third party do it, and I was actually shocked at how expensive technical support really is. We'll go through that.

So as you're doing the production of your software, you finish coding, you need to consider if you're actually going to produce hard media. A little bit later on -- in fact most of the presentation will focus on electronic delivery of your software, since it's the most inexpensive. But you may have to produce disks and CD-ROMs. And some simple strategies that you can use to lower your costs here are to have larger production runs, to optimize your production runs, so that you distribute one-time costs for setup things, like CD setup, printed documentation, manual configuration setup. You can spread the costs of those one-time charges across more units and have a lower per unit cost.

Now, you have a problem, because as you optimize your production runs and have fewer software revisions, you also have a greater obsolescence risk. So there are good and bad things with doing that. Having regular software releases is good because they're regular; however, you can go too far and only have an update once every five years, as we've seen with some software companies. And if you try to throw everything in there, it becomes kind of a nightmare. You can go the other way as well where you go ahead and print however many thousands of CDs and a couple of weeks later you make a change to your software. That shouldn't really necessitate producing new CD-ROMs, but you can at least optimize how you go about doing software revisions.

As you get down into electronic delivery of your software, it's by far the least expensive way to do software delivery. As I go later on I'll talk to you about a few specific entities that exist to help you accomplish electronic software delivery, specifically over the Internet. But you can do neat things like design to your distribution channel. If you're going over electronically, you certainly don't have to have printed color manuals, even a printed color box.

One thing I'll point out here is, even if you do electronic software delivery, you might still want to have a retail box. It's a real box with printed documentation. As you've seen with Be, we actually have a couple of ways to get the BeOS. We're working on a Web-based download. What we do have for $49 is a retail box, which is a nice four-color box with printed documentation and a CD. And I don't think I was really surprised, but a lot of people at Be were surprised, at just how many of those we've actually sold already, even though we're telling people all these different ways to get it for free, or if you just want the CD it's $10 and we'll send you that. Other people like to sometimes -- they get great satisfaction out of opening a box and holding the manuals in their hands, taking it into the bathroom, that kind of stuff.

So I would encourage you to have some kind of package like that where you can charge a little bit of a premium. And I consider $49 for the Preview Release quite a premium, because we're not a mature operating system yet, so people are shelling out some money, and that's kind of cool.

So other things you can do when you design your channel, you can reduce the number of colors on your packaging and on your printed manuals. The other things that you can do, when you do stuff like printed manuals, make them not revision-specific. So if you do have to go and change your software and print new CDs, you can reuse some of the pieces of your kits, of your hard media kits. If you really need to put a revision number on there, use labels. When you go to a new version you can put labels on top of those labels and reuse your manuals, reuse your packaging.

So you want to create awareness for your software products, so people at least come and take a look at what you have available and give it a try. We found the power of the Web to be incredible. In fact, going way back into Be's history, right to the original Be business plan, we had something like this in mind. Jean-Louis said that "All Be customers will be connected through some kind of network." I think he planned on using a Novell network. And they'd get new news automatically; they'd even get software updates automatically. Thankfully we didn't have to do that, I think that would have been an overwhelming administrative nightmare for Be to set up. The Web came along and does that quite well.

So you should leverage existing Be-related Web sites, and I have listed a few on here. I think the top two are very important, BeForever and BeOS Central. I know every morning when I come into work I go to those Web sites first to find out what's new at Be before I talk to anybody at work. They're pretty good about reporting new stuff, and as developers release software they always send these Webmasters mail plus a little news about what's going on. They're also pretty active in researching stuff that appears in the press, and sometimes I find it there first before I find it anywhere.

The BeDepot is something I'll talk about further in detail later on in the presentation. But basically it has a catalog of Be software. It's a Be-specific Web site, not to be confused with the next on here which is the Be-specific Web site run by Adamation. Adamation has an FTP area with a lot of Be software. They also archive BeDevTalk Discussion List and make that available through a Web interface.

Then BeHive is currently run by Mac User. We'll have to see what happens with that, because, as you know, Mac User and Mac World are merging into one magazine. But I suspect that they will continue to have a Be-specific area somewhere.

The one that I'm obviously missing -- and I put this on a slide, but it didn't make it into this version of the presentation, I guess -- is BeWare on our own Be Web site. I think people that go and look for some Be software, the first place they would turn is the Be Web site. And actually I know from Ron, our Webmaster, Ron Theis, that the most popular area besides the Home Page is the BeWare area. So people come and see what new software has been uploaded. Right now we have a Preview Release area in the BeWare area to list what software is specifically for and available for the Preview Release.

Did you have a question back there?

FROM THE AUDIENCE: Yes, sort of a side topic on BeWare. Already it's getting kind of slow if you just go into the utilities area and you're waiting for that list to download.

SCOTT PATERSON: Right.

FROM THE AUDIENCE: Is there something you can do to break it up?

SCOTT PATERSON: The question is, when you go to some of these listings -- actually, it's kind of nice, because the problem is, the listing is getting so long that it's taking a long time to download -- so are we doing something about that? Yes. Right now we use a table-based listing, and it's building the table that takes such a long time. I think we're going to go to straight listing and alphabetical. Take a look at the Preview Release area and you'll see it; it has an A, a nice graphic A and then the A stuff. I think we're probably going to go to something like that.

But I'll bring that back to Ron, it's something I mentioned to him before. But it's not really related to your network connections, because even in the office it's slow for Netscape to figure out the table and put everything in the right place. So leverage your related Web sites.

Produce trial software if you can. That's, granted, a lot of work to somehow take a version of your software and either disable it, by having limited functionality, by putting in a time delay so that it works for 30 days, or you have to actually purchase. But there's nothing like being able to try the software before you purchase. People get very comfortable with a peice of software, they start to find ways in which they can't live without it, and then they need to purchase it. Whereas to purchase something without ever having been able to play with it takes a greater leap of faith and is basically a hurdle to purchase.

Be evangelism. As I mentioned, Michael and I are the evangelists, and we're here to help you do a number of things -- we'll do anything that will help you to be a successful developer. You can drop us an E-mail. And later in the presentation I'll have our E-mail addresses; that's probably the best way to get ahold of us. But we'll help you with beta review, feature lists. We'll help you, once you're ready, get in touch with the proper press people so you get some good attention for your software. We'll give advice, just because we have some experience in this area, not only our own but working with other developers.

We love to take software out on demo tours. I'm pretty much the main demo tour guy, and I spend a lot of time going throughout the country, and I like to have new software to show. It gets a little old when you're just demoing functionality of the BeOS itself. It's nice to bring up something like BePaint and BeWriter and show people how good what a mundane application like word processing gets by running on a multithreaded system and being multithreaded. So we like to show that stuff and take it out and be evangelists for your software as well.

Be User Groups are always looking for content to present, so if you have a local Be User Group or Be User Groups in your area -- I think we're getting more and more every day; I think we have three new ones this week that are listed up on our Web site -- go talk to them. They would love to dedicate a whole session to you. They're always looking for a new face to talk about.

Finally, create a great demo. There's nothing like a good demo to draw people in. And I definitely see this as far as drawing developers to the BeOS platform when I go out on the road. If I give a good BeOS demo, typically I'll get -- out of a 100, say, I'll get three people who will come up and they'll be really jazzed, and they want to start -- they're developing for Windows or for Macintosh, and they want to start developing for the BeOS. And these are the people who are the most motivated. And the same thing goes for end users. Those same types of people will be the most motivated to start by looking at your software, playing around with it, and eventually purchasing it.

I'm also going to write a newsletter article, not for the Tuesday after MacWorld but the Tuesday after that, in which I go through how to give a good demo. And it's not how to give a good BeOS demo, but it's tips on how to give a good demo of your own software. I don't pretend to be some great demo god or anything like that, but it's just simple little tips that help to produce a better demo.

Things like, if you're trying to demonstrate a piece of your application, it's better not to have it down here, it's better to have it up on top of the screen. And we saw an example of that yesterday when Tinic was showing DualPlayer. I was sitting in the back row, and he was dropping the sound files onto the player, and the panel which he used the most was down here at the bottom of the screen, and it was a little difficult to see. He eventually got it higher up on the screen. But just simple tips like that.

And I found a few resources on the Web. David Curzi has a very good Web page on how to give a good demo. It's more from a presenter's perspective rather than how do you actually show software, but it's good reference material. So look for that newsletter.

Okay, the decision process. More information is always better. You just want to supply a potential customer with everything they need to make an informed decision. So you might want to go ahead and do some marketing collateral, the dreaded marketing collateral; you don't actually have to have printed material. I think it's certainly sufficient if you have something up on a Web site that people can print out and take with them, that will probably suffice.

I was just kind of watching over in the developer lab, and we had a couple of vendors at their tables, and I noticed probably half a dozen times where people asked, "Do you have some printed materials, some printed collateral that I can take away with me to read and I'll bring it back tomorrow?" So if you're going to do something like that, in that case it might make sense to have printed documentation when you're at a show or a conference, something like that.

You want to have Web links, have your marketing collaterals up on the Web, or if you have a Web site, you want to have links all over the place, or least where it makes sense, that take the customer directly to ordering information. Or if you do electronic distribution of your software, take them right away to where they need to go to purchase the software and get it, so if they've made that decision, "Yeah, I want to get this software," it's as easy as possible to do that.

I was purchasing the Guide to Apache Web Server from O'Reilly Associates, and I was on the Web site, and I was reading the description of the book; it had the nice picture of the horse on it. I said, "Yeah, okay, I want to get this, because I want to learn more about this particular server." And it actually took me four pages, I had to go through four pages before I could actually get to a link where I could then add it to my shopping cart, which then I could total up and purchase over the Web. So you want to make that as easy as possible.

I'm not going to talk again about trial software, I mentioned it before, but that helps with the decision process.

Have good documentation. A lot of times that may be the first place that a user goes to start their experience with your software, and you can provide that in a couple of ways. There's StyledEdit in the BeOS, which is good enough to do documentation in. And there's also HTML, which is becoming an industry standard for documentation. Almost every piece of new software that I have today has HTML documentation with it, and it's user- friendly. Well, it's user familiar is what I kind of call it. Users, they're happy to use HTML and look at documentation in a browser. So you don't have any problems there.

Frequently asked questions are very important, especially as we get a little bit later on into technical support. You want to kind of head people off at the pass, help them help themselves. A typical analogy I use is gas stations. Most of us like to pump our own gas rather than be bothered to go to full serve and have somebody pump it for us, not considering that that's usually like a dollar more per gallon.

Access via electronic mail. Kind of as I get down the list here, these last two things are probably somewhat less important. Electronic mail is still important. However, you as a developer, you obviously have a focus on a software and you want to spend your time doing coding rather than dealing with a large mailbox full of E-mail sort of questions. At the very least have a mailbox, and if you're not going to be able to respond to incoming mail in a timely fashion, have some kind of auto responders, just so a customer knows, "Yeah, we received your mail, it hasn't been lost, and we will get back to you in some kind of time fashion."

Finally, there's the dreaded phone. You may or may not want to provide this. At the very least provide a phone number for your business. It doesn't have to be a 1-800 number, but if somebody really wants to call you, they should be able to get ahold of you. It's just a decent business practice in general.

Okay. Transactions. I'll tell you a story first. Ron Theis, our Webmaster, has a little clipping outside of his cubicle, and it details the cost of implementing a transactional Web site, one where you can purchase software, and it says that the average cost to set up a fully functional Web site like that is $3 million. And I don't know where they get the numbers from.

But anyway, basically we have a transactional Web site at Be, you can order software through our Web site. And his question at lunch one day was, "Okay, there's a little bit of discrepancy between my salary and $3 million, and the cost that we did incur to set up the Web site, and I was just wondering if I would see any of that difference." And Jean-Louis told him, "Oh, sure, just don't start spending it right away."

So here are some example transaction costs of doing it yourself. And this is based partly on experience that we had setting up our Web site, as well as StarCode folks gave us a little help with some of the costs that they incurred to set up their transactional Web site. So if you're going to do it yourself, the hardware, the software, some of these are one-time costs and some of them are ongoing.

Net access and administration of your site the first year at the very least is going to be $53,000. If you compare this, if you look at how that compares to the cost of selling your software and doing it through a third party, that has a 15 percent fee, transaction fee. Based on 7,000 copies of your software, $50 each, that will cost -- that will give you $350,000 of revenue times 15 percent is $52 1/2 thousand. So that's kind of a break-even point.

If you're going to sell more copies than that, then you might actually start saving some money by doing it yourself versus doing it through a third party. However, again, you have to go back again to, what is your focus, and do you have time to be setting up something like this, administering it? Will that allow you to continue to produce revisions to your software and further your software technologywise?

Now, the third-party side of things, I've got a few examples up here. BeDepot run by StarCode is a transactional site that is specific to Be software. They're already distributing a few pieces of software up there. I believe that BeWare is going to distribute electronically all their software through StarCode. Ro Design, I was reading their software through BeDepot. And the exact numbers are in my white paper up on the Web site, but I think the transaction cost that BeDepot charges is about 12 percent, which is pretty low when you consider some of the other alternatives.

I'll explain that Kaji was born out of shareware; it was really a site that helped shareware authors to get paid in whatever currency, whatever country they're in. BeDepot does that as well. It's starting to do a little bit of commercial software. I wanted to try it out so I'd have a sense of how productive it was, so I looked around for a piece of software that I thought was interesting. Of course it was Be.

And I went ahead and purchased through Kaji, and it took -- from when I submitted my credit card information, it took six days before I got any code that unlocked program. And for an electronic distribution of software, that was a little bit long for my taste. And they charged 15 percent of the transaction cost, off of the transaction cost, the rest goes to the author.

Software.net is probably the closest comparison to the retail channel in electronic format. They charge not only transaction costs, but they also charge you $250 just to list a product with them. This is very similar to in the retail channel where you have to buy shelf space or buy an ad in a magazine just to get your software distributed, then I think they go ahead and take a 20 percent cut. Actually, they ask you to list your product with them at 40 percent off of what you would normally do at retail, and then they take a 20 percent cut of that. So it's a pretty expensive electronic alternative.

All right. Installation. Again, there are third-party ways of doing it and there are do-it-yourself ways, and they vary. The ones I have listed up here, PackageBuilder and Software Valet, again by StarCode, helped to provide customized installation.

The really nice thing about this is the second point, there's less chance of improper installation, because you as a developer can control exactly where all the files are placed, and basically an end user just goes ahead and clicks on Install. They can review where you're putting things, see what things are being changed. But then when you hit Install, it goes in and places all the files in their proper folders. So you have less chance of improper installation, which equates to having less work costs, as compared to do it yourself, which I'll explain in a second.

PackageBuilder and Software Valet are also integrated with BeDepot, so they understand about going out and grabbing software from BeDepot, installing it, telling BeDepot it's had a successful installation and registering -- I'm getting a little ahead -- and registering customer information. So it's a nice integrated solution.

Do it yourself, there are certainly a couple of tools included with the BeOS that help you to do some of this yourself. The typical tools, Zip, Tar, GZip, you want to create an archive of your installation. You can also curse directories and keep that information in there so that when a user unarchives the file everything gets placed in its proper directories. However, that typically requires command line usage, and that's more for a technical user. It was great when we were doing our developer releases of software, everybody was more of a technical user, because it was really only developers use the OS, but now as we go into an end user release that's not so much the case.

You can get add-ons. There's ExpandMe, which allows the user to click a file, use the context-sensitive menu, select ExpandMe, and it does it from a graphical standpoint. But still you have some chance for an improper installation which immediately requires technical support. I think when you see the technical support costs you'll understand why you would want to eliminate that.

So I kind of combined registration and updates together. Registration is very important, because if you can get the information about customers you've already sold the product to, these are the easiest customers to target in the future. It's also the least expensive customer to target in the future. They've also invested in you, so they have an interest in your future technology and your future products and updates to your software.

There are a couple of ways to go about getting that information, and I think I have listed them here in order of effectiveness. Mail-in cards are by far the least effective way to get registration. I used to work for a large networking company in the messaging division, and I was just always amazed, because we had a messaging engine as our product, yet we didn't use the engine to do registration, we only supplied a mail-in card. And I wasn't surprised when we got 8 percent return, you know, 8 percent registration. That's just terrible. We didn't know who our customers were.

Fax, again, is not very good. The end user, there's a hurdle there, because they feel like they have to pay to actually register their software by faxing you their information. It's also inconvenient. You can set up an 800 number, but it's still inconvenient. Electronic mail is getting a little bit better, you can automate how you handle the incoming mail. Web based is even better than that, because if you use something like a Web-based form, you can collect a little bit of additional information. You can find out a system configuration.

Maybe you've been trying to get your software to run in an 8 megabyte configuration and you realize all of your registrations that are coming in, nobody has less than 32 megabytes of ram. Well, maybe that's not such a high priority, running 8 megabytes anymore. If most of your customers have color printers, that becomes a higher priority, so you have to have support in your application.

Finally, software automated. One of the later products that I worked on at that company was an Internet client, and we built them the ability to use the Internet to do your registration, and we saw 80 percent registrations. So you can see how drastically that improves.

Updates. Before I forget, sorry. You have to decide, there's not that much information here, but I guess it's really up to you and your perspective, you have to decide what updates are free and what they cost and how they're delivered. Typically, and this is very general, but I guess the philosophy at Be would be, things that are just bug fixes typically are free updates. It's when we do something to improve the performance of the system or add major new features, then that calls into consideration for a cost upgrade. And you know that BeOS is done on a subscription model, so if we add new functionality or performance, maybe that would count as one of the subscriptions.

Finally, delivery. If you've done something like use BeDepot, they can automate the delivery of updates, and even the installation of updates to the customer. It's probably your least expensive channel to do that.

All right, technical support. Ed Romson helped me out with this, and I have his E-mail address at the end as well. He said he'd be happy to work with anybody in figuring out the technical support and how they really want to do that. But he gave me these numbers as kind of industry standard numbers, and I think they're mostly Silicon Valley numbers, so they may not apply across the country. Certainly salaries differ from where you are. I'm sure Gateway has different salary structures than some Bay area companies since they're located in the Midwest.

Anyway, two peoples' salary and benefits, $200,000. They can do 30 contacts per day per person. People in general have an 80 percent efficiency. So that's 260 workdays, they handle 12,480 calls, and that comes out to, when you divide it by the cost of these people, $16, a little bit over $16 per technical support call. That totally shocked me. I went through and did the math a couple of times, and it works out that way. So if you have a product that you sell for $50 and you get one technical support call, that's a pretty big chunk out of your revenue. So that's one thing to consider.

There's also third-party technical support. And your mileage may vary. You may find some ways to reduce your own technical support costs by utilizing some of the methods I mentioned using Web-based technical support and stuff like that. I'll talk about that in a second.

Be does first-line technical support through a third party. And the numbers here, we actually bid out to three or four different companies, and this is kind of the average that we got from all of the companies. Depending on the number of contacts per day, you have different rates. And this is pretty self-explanatory. And it's in the white paper on the Web site if you want to refer to it a little bit later on, but obviously the more contacts you have, the less the cost. You can see, even at 50 contacts per day, it's already under that $16 number. So that's one avenue that you can take as well.

And there's the do-it-yourself stuff that I mentioned before, technical support. FAQs, FAQs, FAQs. I can't underemphasize the importance of having frequently asked question documents. You come to the Be Web site, and there's a lot of stuff that you can use as templates, the marketing collateral and our FAQs. You'll see that we have extensive, extensive FAQs. And it's probably actually hard, we make it just a little bit difficult, to find that technical support phone number. We want people to dig around just a little bit. And we'll see how this goes, we may change it eventually. We want people to see if their technical support question has already been asked, and if it's been answered, they can find it themselves.

We have a Web-based form, which is the second thing here. So if they've gone through and helped themselves with the FAQs, filled out the form, given us some information -- and again, here you can customize the form so that you get good information in, well-thought-out information, what kind of system you're running on, what's the configuration, and what's the specific problem you're having -- it forces someone to think about it and type it out. We'll give people who go through that process a little bit of a priority in getting technical support.

There's E-mail, which can turn into a nightmare if you have one E-mail box for technical support. If you have somebody answering that on a broad basis, that's pretty good; that's kind of expensive. But again, you should have at least some kind of auto responder to let people know that their mail is not falling into the bit bucket.

Finally, there's dreaded phone support, which I've gone through in the previous two slides, which can be expensive.

A few resources. I mentioned the white paper that's on the Web. It's in the developer area about three quarters of the which down the page. There's myself and Michael Hopwood. My E-mail address is Scott@be.com. And feel free to contact me about anything. And then there's Hopwood@be.com; that's Michael Hopwood's address. You can work with either of us. We're starting to I think split up where we focus in terms of applications. Michael is focusing more on graphics, 3D, that kind of stuff. I'm focusing more on productivity, games and Internet. But those aren't hard definitions, we certainly work on just about everything as well.

Then Ed Romson is Romson@be.com, and he's our director of customer support. He's happy to help you with technical support issues, help you contact third parties if you want to go that route. He's also happy to help with production. So if you want to do CDs and stuff like that, we've gone through the process of finding inexpensive production houses that provide quality work, and he's happy to supply that information as well.

Okay, that's pretty much the presentation. You didn't have any questions throughout, but are there any questions now? Yes.

FROM THE AUDIENCE: With DR9 we have the new directory structure installed on our disks by default, and we've got a routine named Find Directory that lets us pull out any of a couple of dozen interesting directories. Some of them are kind of obvious, but not all of them, and I was wondering if you could point out where to find what's an appropriate thing to put in various of these directories.

SCOTT PATERSON: Well, I guess so. Let's see. I mean, you're talking like there's a Datatypes folder or there's a Home Config folder, Add-Ons folder?

FROM THE AUDIENCE: Right. Under Config there's Add-Ons.

SCOTT PATERSON: Yes. Basically, there's a BeOS folder, and stuff inside of the BeOS folder is read-only. And then if you want to go in and modify the system, you do it through Home Config in that directory structure. It's a pretty broad answer. I mean, there are a number of directories there, but that's basically where you would go and add your own stuff.

FROM THE AUDIENCE: I was wondering, for example, is there anything, off the top of your head, that belongs just in Home Config as opposed to in one of the subdirectories that's off of Home Config?

SCOTT PATERSON: No, not that I can think of right here off the top of my head.