 |  |  |
| Main | |
I See Markup, Part 4 - Productization
This is the story of my C++ XML parser product CMarkup.
In summary so far, I wrote a small XML parser for our project (Part 1), it turned out to be useful and at the same time the XML industry was a big stinking mess (Part 2), and this provided an opportunity to start selling it (Part 3).
If you buy coffee at coffee shops regularly, you become sensitive to how well-run a particular shop is. I admit that when I go to get my coffee I am like a New Yorker; I really don't want anyone wasting my time. But once I get my coffee it is a different story, it is a time to relax, to sit and reflect. I sometimes spend that time reflecting on how well-run the coffee shop is.
My goal with CMarkup is to be that well-run coffee shop. Nothing fancy, just get the important things done.
One of the coffee shops I go to always has coffee ready, while at other places I am sometimes asked to wait a few minutes while they brew a fresh batch. It is as if they have over-extended themselves in their eagerness to provide a suite of products that they neglect their core product. This also made me aware that there are actually two separate but important aspects to the product that I am looking for when I go to get coffee: one is good coffee and the other is for it to be ready!
Funny thing is, as a programmer I am often scouting around the Internet for software tools or articles, and I have the same mentality. I am looking for something that solves my problem, but I also want it to do it with a minimum of hassle. My instinct is that that the longer it takes me to find out if a tool will serve my requirements, the longer it will take me to integrate that tool, so I am likely to move on when it starts taking too long. It is all a measure of the productization and how well it is geared to me as a customer. He are some reasons I get turned off:
- Creates a mess of files and deep subfolders. Some products are like the guy at the club who takes up more than his share of the dance floor. When you install the product it starts running to the far corners of your computer sticking stuff everywhere, or else it has a deep subfolder tree, the justification for which is buried deep in a programmer's mind somewhere.
- No quick "How To". A bad product wants you to understand everything about it before you start using it.
- Poor website layout, poor aesthetics. The ISV that has no awareness of how bad its website looks and works is likely not to be aware of other things that matter either.
- No screen captures. Everyone knows you need screen captures up front.
- Large download. People only put up with large downloads when they already expected it and they really really want it.
- External dependencies. "oh, by the way, you need to download 3rd party open source software XYZ." It also seems very detrimental to me when you have to buy into a (huge) platform download like the Java SDK or .NET.
- Bad documentation size to value ratio. This is when it is little more than fluffed up API syntax and unhelpful descriptions. The worst is when you could have written the description yourself based on the identifier, for example: function GetManifest() is explained as "function to get the manifest from the object," oh thanks a lot, that's very helpful (notice sarcasm here)
- Reading what it will do in the next version. This stuff should be hidden away in a section called "Future Ideas" or "Pipe Dreams."
- No user comments or discussion or signs of recent activity. People want a sense that there is someone on the other end of the wire (like today, hello).
So, coming out the starting gate I wanted to avoid the pitfalls I saw everywhere else.
Why is CMarkup the best XML tool out there? One word: "productization," the process of tailoring a product for customers out of raw software.
There is a lot of brilliant software in the world that never develops a clientele, never finds its niche, because no one bothered to productize it well. At the same time, there is a lot of bad software with wide distribution because it is productized well. CMarkup is not productized as well as I would like even though much more time has been spent on productization than on coding the software itself. But what works with CMarkup works because of aspects of it that reach into the customer's world well, primarily the original API concept, the support, and the work that goes into finishing releases.
Productization involves web presence, branding, how the targeted problem is defined, niche awareness, advertising, discussion groups and community building, software design and scope, defining and focusing on a target problem set, solution elegance, ease of integration into customer projects, dependencies and requirements, trying it before buying it, documentation. It is an endlessly fascinating topic that I will continue to touch on whenever I write about the software industry.
The key here is that the customer only wants what is valuable to him right now, including software that works and the answers to his questions, he cares very little about anything else. When you are serving someone in a cafeteria, and there is a whole line of customers, you are trying to shovel stuff onto peoples' plates as fast as they ask for it in the way that they want it. They don't want to know that your back hurts or that you had to go to a second bakery to get the right kind of bread. They simply see what they want and are more than willing to pay if you give it to them quick.
Since I wasn't going the route of "this will solve all your problems plus wax your car," my strategy was to capitalize on the "I can do that!" factor to get people into that crucial try-out phase.
My primary CMarkup article has a zip file with a project you can use to see how it works. But more simply, what I tell people to do is add the CMarkup class (just a .cpp and .h file) to their own project and try out three lines of code: include the header, instantiate the class, and load an existing file. Although I have worked hard on many aspects of productization, I've always felt this was the real clincher for C++ engineers. If I can impress upon them that CMarkup is one single source code class with no dependencies outside the default compiler platforms, they will hopefully say "I can do that" and give it a shot.
I chose a price that is not too cheap, but not expensive either. The price was $159 for the first few sales starting in March 2001, and then raised to $249 after the original productization work got done in July that same year. It has stayed the same since then. I got a lot of advice on pricing around that time, and the general concensus was that $249 was low for a source code product in a small specific niche like this. It seems low when compared to billable hours in U.S. contracting, but of course it is a lot of money to small developers in some other countries. CMarkup has been sold to people in 20 countries or so.
Many XML classes and tools on the web have more "stuff" than CMarkup and are even "free" but that does not mean they speak directly to customer problem sets or do not cost more in the long run.
A product may promise a lot, but it is a real disservice when it takes a lot of work for the customer to realize that potential. It ends up being up to the customer to see if he/she can get a return on the time invested in trying to use the product.
Productization includes all the work that goes into increasing the likelihood and reducing the time between a customer's awareness of a problem and the point at which the customer is productively using your product to solve that problem. Many ISVs, especially those run by computer scientists, don't pay enough attention to this aspect of software production, but that presents us with the opportunity to put out a better product.
As far as I can tell, this is why CMarkup has been consistently selling for 4.7 years. It is really fulfilling to give customers something that works and makes life simpler. The next installment in this series looks further into a key product strategy: not chasing standards. Thinking of the coffee shop I mentioned, this strategy that I will be talking about helps me to focus on "simply having the coffee ready."
| Main | |
