Packaging a Product

I’m thinking about how to package up our wonderful new vehicles. Here are my thoughts so that I won’t lose them. I’m happy to share them with you and hope they’ll give you good ideas. If you have ideas better than mine, please comment.

Dizzi and I have been working on a number of vehicles and scripts to run them. In our home lands in Lexicolo, there are several interesting rides. There are narrated tours of the area by boat, cart, and balloon, there is a train running, and a monorail.

You can rez the tour vehicles from posts by my waterwheel, and the train runs right by there. The monorail can be found over by the train station in Dizzi’s Back Yard, on the west side of the region, about halfway north. The train goes there, of course, so that’s a good way to find it.

Our plan is to sell some of these vehicles as products, for people who would like to have a nice ride at their location. Naturally, we have more ideas than we have time to complete them, and though we have tons of running vehicles, we seem always to want one more little thing before we’re ready to put the first package out for sale.

Dizzi talks in terms of a “freeze” on the vehicles and scripts, and while I do understand what she’s saying, I like to think of it a bit differently.

Imagine a shipping area, with ready-packed boxes containing standard configurations all ready to go. These packages can be put out in stores ready to be purchased.

Behind the shipping area there is a warehouse of parts that are ready to go. Tracks, vehicles, signals, all the pieces we offer, each with its scripts in it, ready to be packed up.  When we define a new configuration to ship, or when we do an upgrade, these ready-to-go parts are picked from the shelves and put into a new ready-packed box and put in the shipping area. If the new box is an upgrade of an existing package (New! Larger Windows!!) we replace the old one. If it’s a new product we just add it to the available items.

Behind the warehouse is the assembly area. Here we find tracks and vehicles, fully constructed out of prims but empty of scripts. And we find shelves containing the latest scripts. In the assembly area, we make ready-to-go parts by putting the scripts into the pieces, and then we move them to the warehouse. 

Now this may seem to be a bit elaborate, but it’s just a way of thinking about what has to be done in any case. We have to make packages to put in stores. To make up the packages, we have to have scripted ready-to-go parts. To make the parts, we have to stuff the appropriate scripts into the empty parts. All those steps are needed … and every one is subject to errors. 

Suppose a piece of track has the wrong or a broken script in it. Then when that track is placed into some package, that package will rez a train that won’t work right, because when the train reaches the bad track it will stop or flip over or something else bad So an error all the way back in assembly won’t be discovered until we test-rez the actual package and run it.

Then we’ll have to go back and fix the script if it was actually broken, then build a new track with the good script in it, then reassemble all the packages containing that track. 

Now call me pessimist but I know that’s going to happen. People are, well, human, and they make mistakes. So while we will need those stable points, the shipping area, the warehouse, the assembly area, they won’t be frozen until the day when we finally get the package good enough and start putting it out for sale.

So my model of thinking has these staging areas in it, and as we start getting ready to ship these items, I’ll be setting up folders, or maybe even physical prims, containing the current known best pieces and parts, and we’ll put things together until we get them right. Then we’ll consider that product ready to go. Will it be “frozen” even then? I consider that to be a sort of marketing decision. 

Suppose that the first basic version of a tram has speed fixed at 4. And suppose we hear from customers that some of them want their trams to go slower or faster, or to speed up in some areas and slow down in others. We can make a marketing decision whether to upgrade the basic version from then on to have speed control, or whether to have a separate package adding speed control, or a separate version of the whole tram with speed control. 

If we decide to upgrade the basic to have speed control from now on, we can snap a copy of the current version, call the speed control tram version 2, and treat the first package as frozen. And we’ll probably do it that way. But we could just make the new parts, take the old ones out of the package and put the new ones in, with no explicit indication that this is version 2. 

Now I think, with Dizzi, that once we make a package available for sale, changes to it will always change its version number, if only because we’ll want to know what version people have when they call with congratulations and praise. :) But up until we decide a package is ready to go, we’ll be repeatedly changing scripts, filling prims, and making trial packages. 

That’s where I prefer my little shipping / warehouse / assembly model of things, because it helps me see what needs to change, and what has to move forward from that change to the final packages.