Polynomial!

Attracting customers: I see a pattern here, and it's dead-obvious.

Michelle Tampoya asks: How do we get people to buy?

Her advice is certainly good and probably useful, depending on how much you have dealt with the topic yourself before. To imply, however, as she does at the start of her article, that almost nobody else has a clue as to answers to that question, particularly in prolific forums such as the Business of Software or even at dedicated Micro-ISV blogs, is a little drastic to say the least. Such advice, and pretty much along the same lines, is pretty easy to get; it is what is preached on blogs and those forums whenever the question comes up, backed by those who have been there and done that quite successfully. (Most questions there are a variation of that question anyway; that's what business is about: how do I actually sell what I am offering, and once I got that sorted, how do I sell more? What is always interesting are the contextual particulars, the market, the competitors, the customers, the individual strengths and weaknesses with the consequent opportunities and threats. [1]

It is clear that with zero budget you have pretty much no other chance than to find other ways to spread the word. The best marketing is a fantastic product: even with a marketing budget, you'll need that. One of the most important lessons of marketing is that you simply cannot turn poo into chocolate, no matter how stretched your budget.

Still, I absolutely agree that it is worth pointing out that "no budget" does not mean "no chance", which is what many people still believe. Then again, I think this is more of a general state of mind that cannot be "fixed" easily by counterexamples or counterarguments. You may have the drive to find ways to "make it happen" no matter what resources are at your disposal or not. I'm not saying this is determined by nature or fate or nurture, rather that it depends on the context, but given an individual isolated situation, you will probably find that you belong to the one camp or the other, likely revealing our "real" preferences no matter what we wish they were. Just a vague suspicion on my part here.

Michelle writes:

As a community and web marketer, the question that first comes to me is not the how, but the why. "Why aren’t they buying?"

Leaving aside that, from what I have observed, this is the question most forum posters ask to begin with, suggesting that they have figured this mental leap for themselves already, I will point out that this is the only logical next question you can arrive at, were you to ask how to "get" people to buy your stuff.

How can other people be compelled to do something we want them to do? All possible answers boil down to two fundamental answers: attempting to force them (whether through fraud or at gunpoint), or to convince them by argument. In marketing, this is called "persuasion", but the idea is to:

• either design your offering so that it is obviously and plainly visibly in the best interests of that segment of the people you have identified as your target customers to buy your solution (in which case, they will do it, and the purpose of marketing simply is to reassure them, by providing the "arguments" that are applicable in the given context, which may include in a context of, say, consumer beveridges, seemingly "silly" arguments such as refreshment or lifestyle imagery)
• or, if your product is not that self-explanatory, to do the rest of the explaining because your customers cannot immediately deduce how their best self-interest is served from the evidence they have of your product or offering (maybe it is a new way of doing something, or a completely new kind of refreshment drink in jazzy colours)—in which case, the purpose of marketing is more of an argumentative challenge, but essentially the same.

I'm digressing a little but the point is that, ruling out the option of force, the only next question that you can logically arrive at after asking, "how can I get people to voluntary exchange their hard-earned cash for my product or service?" (i.e. arrive at a valuation of your product / service that ranks higher than their valuation of the sum of money you are asking for in exchange), is asking one of two "why" questions, where each will in turn lead you to the other: either "why are they not buying?", as Michelle suggested, or "why are they buying elsewhere?" / "when people do buy stuff, why do they do it?". In other words, why don't they realize (whether correctly or incorrectly aside) that my product serves their best self-interest? [2]

This isn't meant as much as a criticism of the article, as it just got me thinking and blogging after I finished reading it. Her five bullet points pretty much cover the basic prerequisites of marketing in practice, "community marketing" as it is called to contrast it with what is believed to be more "traditional", slap-in-the-face marketing.

Talking about proper marketing, I have to point out Spark This, a marketing resource that I just discovered today and that seems low on quantity (last update was in April), but for my tastes very high on quality.

---

[1] Yes, the highly-touted SWOT methodology appears rather obvious to me, I probably missed its essence. In fact, reading about it I could actually feel that I very seriously missed any essence there. As I so often do, I digress. But seriously: strengths/weaknesses are two names for the same thing: assessing yourself and your situation contextually. Opportunities/threats are again two monikers for the same thing: evaluating your findings of that assessment and interpreting consequences. But it is logically impossible, given that you have taken the initiative to assess, that you will not arrive at some conclusion, which was the point of the exercise, so the whole SWOT superstructure to me seems a little redundant and even pointless. Why state the obvious? People do that kind of analysis, arguably to varying degree and depth depending on an unknown number of local variables, all the time, it is a vital part of human action in general.)

[2] I realize that is nothing new since Adam Smith; for all the classical economists' errors, the Invisible Hand or Say's Law remain as timeless (they were valid before they were proclaimed) and true as ever.  ;)

The GUI-Usability-Fallacy

In my previous post I linked to that "Framework Studio" which I read about in the German dot.net magazin a while ago.

I just revisited their site and, browsing a screenshots section, encountered a typical example of what I'd like to call the GUI fallacy. Click the screenshot on the right for an example of what I mean. Somebody has obviously taken great care to give their application a "modern, fresh user interface". Maybe some manager demanded it as a "must-have" in "our competitive market", who knows. One can well imagine how a former version of the product may have looked typically gray and cluttered with information overload. Especially in the business market, you often have manager selling to managers, depending on those managers sometimes with decisions that annoy and demotivate the producers (developers) or the end users (some secretary?) or worse, both.

So now we have a "fresh, modern interface", that box is ticked, maybe they looked to iTunes or something for inspiration, done. But will it be any more pleasant to use? From the looks of it, I doubt it. (I will grant that judging a book from its covers is a risky business, but let me stress this: the customers, or rather, those who will have to use the system, do care; it highly influences their evaluation of a product as Ian Landsman so aptly pointed out.)

So merely judging from the screenshot, it seems to me that the graphics are all shiny, but the the program must be a pain to use. User interface without usability, that's what I call the GUI fallacy. "Just modernize the looks a bit, and we're done."

Who designs such interfaces? Who wants to work with that? People will work with that, no doubt: they have to, once they bought the product. But it is just a matter of time for a more attractive opportunity to materialize just right when they are ready to switch. That kind of GUI really makes it easy for its users to switch (ignoring the general hesitation of most to switch, especially when the financial stakes are high, which is probably the reason why badly designed applications are still so widespread).

But don't count on it.

Ah, the joys of reuse... but beware of productization

After I have decided to go for the localization tool (I find it difficult to blog about it without having a proper name for it first—usually, apart from my dubious company name, naming is not one of my weaknesses), I moved a great deal of the codebase of my other product development into a separate DLL for reuse. That class library, dubbed AuthorBase, now provides a pretty complete framework to easily and quickly create the scaffolding for an application that has some or all of the following requirements:

• A windowing system that allows for tabbed windows, separated into tool windows and document windows (similar to IDEs such as Visual Studio, Eclipse, or SharpDevelop, although my system does not support draggable or floatable windows—they are merely tabbed intelligently and can be re-arranged within their tabbing container)
• A 'project file'-based work flow, with all kinds of editors for all kinds of file types already built into the framework and easily extensible
• The application can extend the framework in specialized manners only, such as: extending the option dialog by additional tabs / sub tabs / option groups / options, extending the types of projects or items that are supported by the application, etc.
• There are standard commands (such as file, editing and formatting commands) and commands can be sent between tabbed windows
• Properties can be marked up to be persisted to and restored from user settings, this is done automatically on start-up and shut-down of the application
• There are pre-existing, but customizable standard windows such as splash screen, Start, Options, Create New Project wizard, Integrated Web Browser, Project Explorer, Properties and many more to come.

Since these are base features required by both my two forthcoming products, I have just halved the time taken for these base features per application simply by adding another application...  ;)

Both products belong to that strange hybrid application category that is authoring as well as productivity as well as developer tool (but in both cases, also offered to and usable by non-developers alike), so that shared code was the sensible thing to do. It also means that any further innovations (to user interface, usability, or even code-related stuff such as performance or the support of additional standard editors, say) are introduced to all applications utilizing AuthorBase.

A framework is not necessarily a product.

I'll admit it, AuthorBase was once a product idea of mine. Maybe it re-evolves into one, but I didn't go for it because although I saw a need for myself, I found the idea of pitching such a framework to development teams quite scary. That's a different matter with the two products I'm now developing: they, too, address issues that developers or development teams have, but they don't impose a certain architecture on their codebase, they merely offer outside-the-IDE process support to certain "orthogonal" concerns (such as localization) of their jobs.

Trying to sell generalized frameworks such as AuthorBase must be tough, because you are effectively selling a certain approach to application design. For prospective customers, that could be a real gain in time-savings, but there is simply a substantial risk involved: what if the off-the-shelf application design they purchased turns out to be crap? As programmers, how would they know before the market tells them, which would be too late?

In my opinion this is a very real risk that should be taken to heart and addressed by anyone attempting to sell products that essentially revolve around the idea of saving customers time by providing them with a fill-in-the-blanks application design. [1] My framework works for me because I have written it and although in theory generalized enough so as to be reused in third-party applications, my advantage is that as soon as I need an extension, I'll write it; as soon as I encounter a bug, I'll fix it. I know how developers tick: I wouldn't even try to convince them of my architecture by means of mere marketing. Notice the subtlety: they may well be fascinated enough by my upcoming products (or maybe not, who knows?) to enquire what kind of "component library" I have used, and if that occurs I might well wrap AuthorBase up and start selling licenses. But they would have to convince themselves by virtue of seeing and using a live application or two. I would have a hard time pitching something like AuthorBase out of the blue. The products, and for this kind of framework they would have to be very real products (not some kind of Notepad clone), need to be out there first (if only for quality assurance purposes, let alone the fact that these represent very real, time-consuming projects that hopefully will deliver a lot of value to as many individuals and teams as possible)—no amount of marketing lingo will sell developers or program managers a prefabricated application design scaffolding; however, a couple of successful live showcases might well do the trick.

Takeaway: no productization plans for AuthorBase at all, no time investment into it other than what is required by my current product development; but I'm aware that such an opportunity might well present itself, and I will probably not let it pass if that happens.

[1] As an indication that this risk perception exists quite in the way I describe, consider the fact that while generalized application frameworks, which suggest their own, unknown and unproven design philosophy to developers (such as Framework Studio) have a hard time gaining mainstream acceptance, there are other packages that prove extremely successful and serve the same purpose—to save time reusing attractive off-the-shelf design decisions (though mainly only as far as the GUI is concerned). The difference is that those are proven, widely distributed and thus standardized and consistent: witness the ubiquitous Microsoft look-and-feel clones. The risk element I talked about is simply taken care of here. If you want to sell your ready-made application design approach to developers,  it is that fear that you'll need to address and overcome.

A Micro-ISV diversion

While I continue developing my other major software product I have after a few hours of pondering decided to start developing another one concurrently. This one will be purely open-book development: I will blog about the whole process, gather feedback and ideas from others all the time, and hope to attract a small number of people interested in the tool and test-driving it for their own needs.

I want to develop the ultimate localization tool for .NET software developers and the translators they work with.

That's right. Am I serious? you wonder. I am. There are a few buts I'm ready to address right now, however I'm soo looking forward to hearing more: yours (before it's too late)!

But there are already existing mature packages on the market!

Yes, and they serve everyone and their dog, supporting .NET among 20 other technologies. Consequently, these products are priced between $ 500 and $ 5000 per seat, whether you need the full-blown suite including Delphi and Java and MFC support—or not.

But the .NET Framework and all IDEs already support us with basic localization tools!

While the .NET Framework comes with the basic technological foundation for localizing an application easily (namely the RESX file formats and editors readily integrated in the major .NET IDEs), there are a few points that I think are worth addressing:

• Ever localized forms or controls using the Visual Studio .NET designers? It is a messy process, particularly when you change sizes or other properties for controls in another language, intending to apply your change across all cultures, later realization you were accidentally working within a certain culture. Change your forms or controls substantially, delete or add controls, after already having localized parts of it and everything becomes a nightmare. It happened to me repeatedly that the designer fails to display the control and/or form again, or lost track of some binary property values (such as images) that just got lost in the ether. Attach a couple of cultures to a form or control and the designer gets slower, too. There has to be a better way.
• Ever localized forms or controls using the WinRes tool? (This is what you give translators who do not have Visual Studio and/or who you don't want to entrust with your entire projects with all other files etc.) The point is that this is only a very basic resource editor but it does not support the process as a whole. A translator might simply forget to check whether there are sub-menus in sub-menus of an item on a ToolStrip. Or think of localizable properties of items that are not directly clickable on a designer surface, such as ListViewItems.

I think that, just as documentation, localization should be somewhat separated from development, whether the person doing the stuff is the same as the developer or not. The whole "integrated" part of integrated development environments is a bit overdone, I think. It results in hacky tools that are fine for three-line demo applications but fail to provide streamlined support for the actual process and its many requirements. I don't want localization to interfere with my development, whether by having to switch between coding mode and translation mode or by having the inadequate, "resource"-centred rather than really localization-centred integrated tools destroy my forms/controls etc.

But the developer market is unthankful and you will have to face the not-invented-here syndrome!

One is typically advised against the market for developer tools along these lines, but I do not really buy into it. Sure, selling to developers may be tough, but selling to any particular market or segment has its own intricacies, I believe. Selling to consumers must be tough! Developers are used to, and keen on, trying new tools and interested in improving their processes using software. You do not have to first sell them on the idea that software can improve and streamline their work, something that many other industries still have to do. There is no, or much less of a chasm to cross.

Any more Buts?

So these are the three most obvious issues I have considered, apart from keeping at bay the burning vision of a fantastic product that I have in mind. It may soon take over, but first I'd like to hear your take on this.

Micro-ISV "opportunities": pick one for life

I have waited for this one: The new Google AdWords Editor desktop application (via Dennis Gurock). I used to dislike the web user interface so much that I'd rather not go in there to check stats or optimize ads at all! Such a "mission-critical" tool (for Google just as crucial as for their advertisers) certainly should provide an enjoyable experience (in software, if a tool performs according to expectations and behaves responsively, that already counts as an enjoyable experience). The web interface, while doing its core job satisfactorily, in my opinion didn't really deliver that.

Dennis Gurock writes:

It would be nice if MSN had a similar tool. It would be even better if you could synchronize ads and keywords between MSN and Google. Or if you had a single desktop application to manage all the different systems – complete with reports and statistics. Is this a Micro-ISV opportunity?

Sounds like a good one. I believe there are a few distinctive common patterns that lead to a Micro-ISV opportunity. If I have missed some, let me know:

• Pet project productization. A software developer identifies a software idea and thinking, "This could be fun!", starts a personal pet project around the idea. Later on s/he realizes that by "just putting in a day or two more", this could become a viable, marketable product. Still later, the one day or more turn out to be one month or more additional (mostly non-programming) work: polishing and furnishing, additional features to attract customers (that weren't required by the creator of the project initially), website creation, setting up payment processing, creating separate limited trial versions, including some kind of licence protection mechanism, you name it. This was the approach taken for my (mildly) "successful" first product, SuDoku Pro, and for my (rather) "failed" second product, Quotator.
• Consulting project productization. Producing custom software tailored to suit the requirements of consulting clients can lead to the realization of a product opportunity, once certain commonalities and overlapping feature needs are identified. Most products targeted at businesses, organizations and enterprises have probably evolved this way, as well as some authoring and developer tools, I assume, although the "personal pet factor" could well be higher here.  For the sake of simplicity, wether the work started out as a consulting project for a client or as an in-house project for an employer does not matter here; I think the commonalities are sufficient to afford a single category.
  
• Fix and improve. Working with some product or service, a slowly evolving and often repeating feeling along the lines of "how annoying, I could do this better, especially part X I would do completely differently" may yield a new Micro-ISV taking a new competing product or service to market. This can range from extreme cases (duplicating the entire product or service and including a few fixes) to extending (original product or service was too narrow) or narrowing (original product or service was too niche). Hint: try to avoid producing that feeling in your customers and you may avoid some future competition. ;)
• Deliberately seeking out a product idea. Some people are so fascinated by the Micro-ISV "career path" that they decide to pursue it first, then go looking for product ideas, sometimes even in an industry they have yet to learn about.

If you are serious about starting a Micro-ISV, what I would like to pass along as advice is a question I want you to ask yourself: would you mind spending the next one or two decades, or even the rest of your life, working on your solution / product / service?

Hell, no way!, I hear you answer and rightly so: who wants to spend the majority of the rest of their lives with just one activity, any activity? After all, part of what makes life exciting are new opportunities, changing interests, evolving opportunities and having fun along the way. Change is a fact of life, one that feels sometimes inconvenient, but nonetheless one that is a major reason for most of the actions and choices we make.

Now, what matters is not whether you would actually enjoy doing what you set out to do for the rest of your life, but your comfortability with the imaginative prospect. It can be helpful assessing whether, how well and how patiently (and consequently: how successfully) you will:

• go the extra mile that will be required before any milestone, no matter how small
• deal with challenges such as unsatisfied customers or customers failing to materialize, competitors, copy-cats, pirates and freeloaders
• continue to nurture and evolve your product, gearing it ever closer towards the needs of your customers
• and more or less enjoy the process

So here is my advice, maybe somewhat radical in Micro-ISV terms: when assessing potential areas of business to pursue, pick the one you would do for life. I'm not suggesting you should then go ahead and do it for fourty years to come, even ignoring the fact that such an opportunity seems unlikely. I'm merely saying that this will affect the outcome. Pick the one where you want to become a leading player. I'm not saying this is going to happen, or this should be your only goal and yardstick with which to measure whether you "succeeded" or "failed". I'm merely suggesting that this a good indicator for how enthusiastic you really are about the opportunity, deep down, and that this, again, will affect the outcome of your pursuit.

Case in point: SuDoku Pro. I never had any intention of entering the casual games software industry. While there were few competitors when I launched, this quickly changed within two to three months, given the many players in that market. Once launched, I was always quite hesitant to keep working on that product. I have done so for quite a while, up to a fairly mature point when I "freezed" the product. I'm now merely taking orders, issuing license keys and answering the odd support request. No marketing, no new versions (apart from the odd hotfix). Business has declined as a consequence that was predictable and that I have put up with, being the cost of developing my forthcoming product. It has more than paid for the up-front time investment, which is good. But had I asked the above questions beforehand, I wouldn't have done it, or rather I would not do something where the answer is "no" again. My main objective was to build, not a piece of software but a product, market it and sell it, and by that measure my experiment was successful indeed. (So maybe one "non-ultimate" project to get started with is OK for Micro-ISVs after all. ;)

However, you can quickly get lost in such projects and waste your energy and resources that would be better spent (better meaning more enjoyably and more lucratively) on "ultimate" projects: such where the answer to the above questions would be "yes".

My upcoming product is a lot more closer on the "ultimacy" scale, and it will have to be, for I have decided to go Micro-ISV for real.

Time flies like an arrow!

Would you believe it's August 13 already?

(Waiting period while you head off to less discouraging web content elsewhere.)

I have started working on my upcoming product in May and my schedule now is for a first public beta in mid-September. I will launch probably around the end of September. There will inevitably be unforeseen delays, and version 1.0 will be far less feature-complete than the "real, final product" vision I have mind—I hope it won't take me 10 years to get there—however, there is a neat deadline-of-sorts looming: the Larkware Daily Grind issue #1000 in late October, which I would love to sponsor by giving away a couple of licenses to my product.

I'm eager to tell, you're eager to hear...

but, alas, I cannot quite go into the details of this product at this stage. I'd love to!, seriously, I can't wait for the day when I can launch the public beta test and start blogging extensively about the project and associated topics. There is a cue as to the target market in this posting, but I can't afford to talk about it more. There are in fact a few existing competitors out there, and some of my ideas will address the shortcomings I see with their products as they exist to date, as well as the way they serve their market.

If my assessment is correct, I might well attract some of their potential customers (hopefully!), and naturally they will be quick enough to adapt their products where they see fit to address demand they have so far chosen not to service. By then it will be back to "equilibrium competition" (kind of) but I obviously don't want to give away that early and predictably short advantage, especially given that it will only balance the fact that I'm coming to market less feature-complete and probably initially a little buggier than those established players.

Don't get me wrong, I don't worry about competitors so much as I do about potential customers, but why grant them such a chance? I would love to do the whole web transparency thing, blogging about every aspect of the product and its development early on, getting early feedback and so on. But I will have to wait until the beta.

Fruit flies like a banana, but you knew that already.