By Deane Barker on March 2, 2005
Admit it: whenever some group like 37 Signals or Six Apart comes out with a new software product, you secretly think, “I could of done that.” How many of us developers thing we could build something just as good if we only put in the time?
Josh and I spent a few days last month talking about content management, Big Medium, and pursuing that elusive goal of the creation and nurture of that app every one of us has tucked away in our heads.
Tell me about the history of Big Medium. Did you start it with the intent to create a saleable product? Or did it start as something else and was there a moment when you thought, “Holy cats, I could sell this…”
The short answer: Big Medium began as a custom-tailored project for a magazine website for runners. The “Holy cats” moment came midway through the project; when I wrapped it up in mid-2002, I went to work adapting that code into a more general product. I released Big Medium 1.0 two years ago, in January 2003.
Okay, I’ll bite. What’s the long answer?
The first rumblings came earlier, five years ago, during my own frustrating experience as a customer of web content management systems. At the time, I was heading up a news-and-analysis website called “The Next Big Thing” (alas, it was not). We had a bunch of smart, talented people on board, and like the whole world in 1999, we had Big Dreams. But we didn’t have a content management system to make our site tick.
So we went shopping. We found huge, expensive systems that required teams of consultants and animal sacrifices to make them work. At the other end, we found simple systems that managed sites with cookie-cutter designs offering few opportunities for customization. It’s amazing, but apart from blogging tools, this is still very much what the CMS market looks like now. While bloggers have a wonderful choice of free and inexpensive software to create and edit sophisticated personal journals, organizations with other types of sites are often forced to make a lousy choice between the two extremes of the cost/complexity spectrum.
Or they do what we did back in 1999 and hire a company to roll a custom CMS. It was a godawful experience. We spent a huge amount of money and time on a web-publishing system that rarely worked. There were a variety of reasons that “The Next Big Thing” failed, but that was a big one: Instead of helping us do our job, the technology kept getting in the way. It drained time, money, and enthusiasm, and in the end we didn’t have any of the three left. In retrospect, it would have been simpler just to hand-code all of those pages ourselves, and that’s just crazy.
I was convinced that lots of small businesses, non-profits and others were banging their head against this particular wall, and I became fixed on the idea that there had to be a better, cheaper way to do all of this. Why couldn’t “the rest of us” have an easy, flexible CMS that we could install ourselves in 20 minutes on pretty much any server without any particular technical knowledge? Easy to say, of course, before you actually start trying to do it.
So really, Big Medium was conceived less as a product than a personal passion, one that comes squarely from a user perspective. The idea is to take the headaches out of web publishing, to create a publishing environment that is affordable, flexible, comfortable and, above all, that doesn’t get in your way. I want to help other types of sites have the same publishing ease and panache that blogging software has given bloggers.
And hey, it actually seems to be working. I don’t have any illusions — there are still a million different ways that I want to make Big Medium better. But it’s incredibly rewarding and humbling to get so much mail from customers who tell me that Big Medium has gotten them excited about web publishing again. So yeah, it seems to be making some headway, both as a product and as a mission.
What’s the current organization of Global Moxie? Are you the only employee, or do you have a room full of 700 programmers somewhere? At what point in the life cycle of Big Medium did Global Moxie pop into existence?
Global Moxie is, literally, a mom and pop shop, just my wife and I. I handle most of the development and the support, and Ellen does the business end and does much of the testing, too.
Global Moxie predates Big Medium by about a year, and you might say that it got its start on September 11, 2001. Like most of us, I was profoundly affected by 9/11 and it pushed me into a reevaluation of my life, both personal and professional. Long story short: I left my job, left New York, moved to Paris, and decided to start my own outfit.
Originally, the plan was to do custom web design and development, but with Big Medium, the focus shifted entirely to a product-based business. There may be other products down the line, but at the moment Global Moxie is all about Big Medium. That seems to cause branding confusion for my customers, by the way. I don’t know if it’s these particular names or what, but it’s common to see people conflate them into a single name, referring to Big Medium as Big Moxie or sometimes Global Medium. I see it all the time. Go figure, I’ve yet to hear anyone refer to Six Apart’s Movable Type as Six Type or Movable Apart.
Whatever name you call it, I don’t think Global Moxie will become a giant operation in the near future. It just doesn’t interest me to do the “get big fast” thing. I guess there’s more Ben & Jerry’s in my DNA than Amazon.com.
There are certainly pros and cons about staying small, about wanting to stay close to the product. On balance, I see far more pros than cons, but it definitely takes discipline to avoid being pulled in too many directions and to stay on track, to continue to ship while still giving customers the support and service they deserve.
Out of necessity, this has changed the way that I work, encouraged me to develop strategies for protecting the time required by each of the aspects of running my own shop. Maybe even more so, it’s changed the way that I think about designing the code. You’ve got to build it in a way that allows easy feature expansion in the future, especially by outside developers. This last element is what’s occupying me most with the development of Big Medium 2.0, which features some major structural changes to help make new development much more nimble.
Do you differentiate between ARTICLE management and GENERAL CONTENT management? Big Medium is article- or news-centric. Is there a temptation to generalize, to design it to handle more than just that content type? Do you resist or embrace this temptation, and why?
Great question, and I think it gets at one of the difficulties of adapting project-specific code into a general-purpose product. Big Medium definitely shows its roots as an application that was originally designed for a specific use: managing articles and news for one particular site. From its first days, it was designed to manage and define content in a very specific and somewhat inflexible way. Not only does it define content as an article, but it defines content as my idea of an article. Your review of Big Medium in the early days (“Big Medium”) was right on the money about this (“Open and Closed Content Management”)
Happily, my definition of an article seems to match up pretty nicely with the way that most news, magazine and marketing websites define pages, too: headline, text, images, pullquotes, author information, etc. So for lots of sites, Big Medium gives them all that they need. But when someone wants a data field that Big Medium doesn’t offer, or if they want to offer a completely different kind of content — a catalog of products, an image gallery, an event calendar — they’re out of luck. They have to get creative and hack the code, or, more typically, they pair Big Medium with a third-party application, which often works quite well.
So at the moment, Big Medium’s definition of content is pretty well cooked into the code. Am I satisfied with that? Well, yes and no. For the last two years, my focus has been on refining this specific application of content management, to improve and polish an article editor that’s appropriate for news and marketing websites. I think that it does what it does very well, and until recently that was good enough for me.
I’ve gradually come to understand that in order for Big Medium to grow and for me to keep up with the steady flow of feature requests, Big Medium has to evolve beyond its original definition of content. More than that, it needs to evolve beyond its original conception as a single application.
What do you mean by evolving beyond a single application?
Well, that’s where Big Medium 2.0 comes in. This new version is still in alpha testing, but to give you a little preview, it’s built more as a platform than as a specific application. From a user’s perspective, it will do all the same stuff and more that Big Medium does now, but it will have support for multiple types of content along with a programming interface to allow other developers to create extensions for new content types and new functionality. Fundamentally, the idea is to make Big Medium into a friendlier environment to build upon, not only for me but for other developers, too.
This should create more flexibility, sure, but my hope is that it also starts to attract developers to the Big Medium platform. That would mean that Big Medium’s development would no longer be limited by my available time or by my imagination. Others could tailor Big Medium to do things I’ve never even thought of.
The challenge of course is to do all of this without complicating the user interface so that I can continue to make the experience of actually using Big Medium easier and more fun while making the underlying engine more sophisticated.
Tell me about how you plan releases. Do you have a set release schedule, or do you just push out incremental changes?
In general, I try to release a major “point” update (v1.1, v1.2, v1.3) with significant new features every six to nine months. In between, there are minor releases (v1.3.1, v1.3.2, v1.3.3) every two to three months. Those are typically driven by bug fixes but often include some minor feature enhancements.
When you’re selling software, you quickly realize that your business is driven by version releases and that it’s important to keep shipping code on a regular basis. First, in the most fundamental bread-and-butter way, a new release always means a spike in sales as well as a boost in general interest. A new release is noted in trade journals, blogs, software trackers, and so it’s a natural publicity event that gets you new exposure and new customers. But second, and equally important, it’s an opportunity to improve the software experience for your current customers by giving them the features they want and squashing the bugs they don’t. So there’s a real customer service aspect to having regular releases.
Unfortunately, there are some bad actors in the software industry who release so-called “major” updates that aren’t really so major in order to force upgrades and boost revenue from existing customers. That’s particularly true, I think, for mature software products that don’t really need any more bells and whistles and whose new features are therefore not really all that useful to anyone. When that happens, the software company takes upgrade dollars from their customers without giving them any real features in return. In that case, you see the first business aspect of version releases, new revenue, trumping the second aspect, customer service.
There are ways to avoid that cynical conflict so that you can still turn a buck without betraying your customers’ trust. I’ve tried hard to come up with a licensing and pricing system that gives my customers some confidence about upgrades and any future costs so that they’re not penalized by a steady stream of releases.
How do you make sure you stay on pace with your releases?
When I start working on a major new release, I have a very clear list of features that will be in that version and, usually, in the version or two after that. Those lists are crafted to fit into the six- to nine-month interval that I mentioned for major updates. Of course, for this to work, you need to be good at scheduling, and your estimates have to be realistic. I have to confess: I’m terrible at scheduling. My schedule spreadsheet is my bete noir. But I’m gradually improving, and slowly but surely my project estimates have become more accurate.
Unfortunately, developers often sweep project schedules under the rug. In general, I think we’d all prefer to say, “it’ll be done when it’s done.” And why not: it’s more fun and more engaging to dig into the code than it is to tinker with a project schedule. But as bad as I’ve been at it, making and maintaining a detailed schedule is absolutely worth the time and effort. A detailed schedule certainly helps me to manage my customers’ expectations, but perhaps even more important, it helps manage my own. I know when I’m going to ship, I can track the progress I’m making, and I don’t beat myself up if a feature is taking longer to implement than some gut estimate would have told me. It’s all planned out.
One thing that makes scheduling difficult for me, and probably for other independent developers, is the fact that I wear so many different hats. There’s my tech-support hat (flame-resistant for putting out fires), my marketing hat, my web-design hat, and of course my propeller-powered coding hat. It’s often hard to predict how much time these roles are going to demand from day to day. Of course, if you let yourself get too distracted from development work, it puts your release schedule into a spin. So when you run a small code shop you have to be realistic about the demands that those roles place on your time, but also disciplined about protecting solid blocks of uninterrupted coding time.
How do you decide what gets into a new release and what doesn’t?
It’s all about listening to customers, and it’s particularly important to include those crucial “I would have bought your software if only…” almost-buyers. Customers and potential customers are extremely generous with their feature suggestions. I’ve found that this feedback is typically not only quite good, but also very consistent. The same feature requests, usability complaints and “how do I?” questions keep coming back. So the priority of my customers’ needs has always emerged quite quickly, and their agenda defines the broad strokes of my feature list for major version updates.
That said, it’s also important to say no, to be sure that the features that I implement really do align with my own vision for Big Medium. I really don’t want Big Medium to turn into a Swiss-Army-Knife tool that handles every last aspect of every last kind of website, although I think that some of my customers would clearly like that to happen.
The trouble is, I want to say yes to my customers every time. I want them to love Big Medium and to make it do everything they ask. Hey, I just want to be loved, is that so wrong? Well, unfortunately, yeah it is. Feature creep isn’t good business, and it’s not good for Big Medium itself. The thing is, in order to be on guard against feature creep, I also have to be on guard against that eager-to-please part of me.
So how does an average day in your life go? What’s the split between coding and administration?
Making your way as an independent developer (or independent anything for that matter) requires some serious time-management kung fu.
My days are generally divided between three different activities: customer support, coding and research. I’d say that the three are pretty much equally important, but it’s a daily challenge to protect time for each. Also, the three activities draw on different parts of my brain and personality, and I find that it’s not easy to shift gears quickly from one to the other. For me at least, it’s important to separate these activities as much as possible, to set aside discrete blocks of time for each.
In theory, my goal is always to have two three-hour blocks of coding time every day, padded and book-ended by customer support and R&D activities. It doesn’t always work out that way, but that’s the target. At a minimum, I typically manage at least three or four hours of development work.
Wow, so that means that a lot of times administration and support takes up more than half of your day?
The first hour or two of my day goes to customer support, addressing the email inquiries and support-forum posts that have come in overnight. Because I’m in Europe and most of my customers are in the US, the time difference means that there’s always a fair amount waiting for me when I haul myself and my coffee over to the keyboard. (Most of the West Coast’s workday, for example, happens after mine is over).
I can’t emphasize enough how important good support is, and it constantly amazes me how many companies do it so badly. The response that customers get to their inquiries does nearly as much to define the customer experience of your product as actually using the product itself. It takes time and patience, but when you provide prompt and detailed responses, it just does so much to raise customers’ confidence in the company and comfort with the software. It pays for itself, both in retaining current customers and generating referrals to new ones. Happy customers in turn send you more customers.
Beyond the simple business logic of it, I find customer support to be satisfying in two other ways. First, detailed contact with customers gives me a really clear idea of what works well and what doesn’t with the software and the interface. Second and most personally, I want people to enjoy using Big Medium. I’m personally vested in this thing — sometimes too much, maybe — and anything that I can do to make the experience clearer and more fun for my customers has a high priority for me. Providing solid and reliable support is a big piece of that.
Of course, actually coding features and improving the interface is arguably an even bigger piece. The bottom line is that my work has to be about moving the code forward. So at mid-morning, after coffee and customer support, it’s time to put everything else away and move into the code.
You mentioned that it’s sometimes difficult to make the transition between these activities?
I make this shift every day, and it never gets any less painful. When it’s time to launch BBEdit and Affrus to get down to work, I find myself opening Firefox or NetNewsWire instead. Read news. Check e-mail again. Anything to avoid the text editor. Getting started is, without question, the hardest part of the day for me. Once I’m into the code, though, everything else fades into the background. I’m engaged and it’s easy to slip into a state of flow. But man, those first ten minutes are murder, each and every day.
So for me, it’s hyper-important to create an environment with no distractions, because if I get pulled out of the code, I have to face starting up all over again. Seriously: a 30-second distraction often costs me ten minutes to recover the flow again. So before I make that impossible leap of opening the text editor that first time ‘round, I always quit email, my instant messenger, my news reader. I put on my headphones and kick off a mix of music that I find code-friendly. And I don’t answer the phone. Protecting this time is the biggest reason that we don’t offer telephone support.
I’m a big believer in the three-hour rule described by Ole Eichorn in his essay “The Tyranny of Email”: “Programming cannot be done in less than three-hour windows.” On the other hand, I also find that my productivity drops off if I do much more than three hours without a break. Happily, if I time things correctly, my three hours of coding in the morning drops me off at lunch time. After a bite to eat and maybe a coffee at the corner cafe, I do an email check and maybe dip into my news reader to catch up on favorite sites. Then I’m ready to face the text editor all over again. After another agonizing ten minutes, I’m back in the flow.
You also said there was a third daily activity, research. What role does that play in your day and in your work?
This kind of research is basically about filling my sandbox with fresh sand to play in. It offers an opportunity to reevaluate the way that I do things in Big Medium and think through new opportunities. But even more, it stirs the creative juices simply to see how other people are approaching and solving problems. And here I’m not talking only about technology. Programming is a richly creative activity, and I find it inspiring to see what others are doing in other creative realms. I live a short walk away from the Pompidou Center, Paris’ modern art museum, and after a stroll through its galleries, I find myself energized and full of new ideas for Big Medium as well as other projects.
So I use the term “R & D” loosely to describe escaping my own head and getting some knowledge, perspective and inspiration from others. I think it’s incredibly important for independent developers to do. It’s something that’s often tempting to put on the back burner, since it rarely feels like work, but I find that it’s crucial for staying excited and stimulated about what I do.
How many sales do you have to do to keep things afloat?
We don’t have much overhead, so most of our sales go to the bottom line. We work from home, so there are no office expenses. Our costs are pretty much limited to our computer and internet costs, our web server, some light advertising, and our taxes. We live off of the rest, and we have financial responsibility only to ourselves. I’ve worked in companies with much larger expenses, where millions in revenues were required to make a product worthwhile. For us, a few hundred licenses per year earns a modest living, which is really all that we’re after.
Truth is, I could make much more money working for a design agency or tech consultancy, but I started Global Moxie with other, non-financial rewards in mind: the satisfactions of bringing my own creation to market, of helping others to handle creative projects they otherwise couldn’t, and of crafting a personal work environment tailored to my own work habits.
Of course I’d love to see Big Medium become even more popular, but I’m also realistic that it’s unlikely to make me rich. I’d caution anyone starting their own software shop to check their dreams of immense wealth at the door. It’s certainly possible to become wildly successful, but the odds aren’t with you. Starting a business and launching a product is hard work, and while it’s totally exhilarating, it also has its own moments of outright terror, especially in the early days. Will the software sell? Are we right that it fits a real need? And of course my personal favorite: Will we starve if it doesn’t catch on?
Fortunately, we’re not starving. We have a modest and growing user base that’s enthusiastic about Big Medium and — most flattering of all — grateful for our product. Besides simply paying the bills, there’s not much more I could ask from a company that we created on our own from scratch.
Where do customers come from, for you? Word of mouth?
We do some light advertising in the various scripts directories, as well as keyword listings with Google, Overture and LookSmart. That gives us a certain baseline of traffic, but I really think that the old public-relations saw is true: “The best advertising you can get is the kind you don’t pay for.” Word-of-mouth referrals, articles in the press, and links from bloggers have definitely done the most to send new customers our way.
By design, one of Big Medium’s most attractive features is its relatively low price and the fact that it has no per-seat fees. It’s cheap. But that also means that trying to market to individual customers is not particularly attractive. The cost in time and effort to land a new customer that way always outruns the revenue. So we try instead to scale the effort by focusing our PR efforts on organizations that communicate regularly with groups of potential customers. We contact associations that represent local and regional newspapers, churches, non-profits and small businesses.
As important as marketing is, it’s not something that I particularly enjoy, and so I’m also not particularly good at it. Even though I’m a big believer in my own product, I find being a pitchman for it uncomfortable. Part of the problem, too, is that while I’m enormously proud of Big Medium, I also see hundreds of different ways that it could be improved. My instinct — and I think that it’s a common one for developers — is that it’s not really finished until it’s perfect.
That’s foolish and it’s bad business, because Big Medium is already plenty useful as it is and it can only reach its full potential through the support of more customers. Having your own business means not only riding your strengths but also finding ways to compensate for your weaknesses, what Merlin Mann has called “patching your personal suck.” This is one of my personal sucks, and I’m still trying to find new, more comfortable ways to shoehorn more marketing time into my day.
What is the most important single piece of advice you would give someone who is considering writing, selling, and supporting a Web-based software product?
Push the interface. Drop your notions of the web’s limitations and push hard to create a richer, more dynamic experience than the medium’s status quo.
It’s such an exciting time to be working on web interfaces. After a few years of relative stagnation, web interfaces have suddenly enjoyed a real explosion of innovation. The Google gang is just phenomenonal with the stuff that they’re teasing out of the browser in apps like Gmail, Google Maps and Google Suggest. Through lightning-fast client-server interaction and novel uses of dynamic HTML, they’ve raised the bar of what we can and should expect web-based apps to do.
Google’s not the only shop pushing the limits, of course. Panic has recast the familiar shopping cart with a drag-n-drop interface. Ta-da Lists provide a subtle example of how on-the-fly communication with the server can make a single web page nearly as responsive as a desktop app. TypePad has an easy, drag-n-drop tool for building blog templates. These are all great interfaces — inspiring, really.
These innovations in mainstream web apps should send a real wake-up call to all web designers, and particularly to designers of web apps. Pages of static forms, text and images don’t cut it anymore. That certainly goes for me and Big Medium, too. That’s a big area of focus for me these days, and it should be for all web developers.
No kidding, an enhanced web interface is emerging as make-or-break stuff. This isn’t about making something cool and flashy (although, sure, I like cool and flashy as much as the next guy). It’s about creating experiences that are faster, easier and more intuitive for your customers. If you provide that, you’ll see more sales and a lower support load in return.
At the same time, though, it’s also more rewarding. Hardly a day passes when I’m not surprised and delighted by some new innovation in my field. I hope some of my stuff occasionally surprises and delights, too.