products for good

Menu

Business

For a non-investor, I end up hearing a lot of pitches. I even make pitches of my own (not for companies, but for product ideas — same basic idea). Around Mozilla, we tend to say that things are “like the web” or “very Mozilla”. Those are equally fuzzy analogies, which assume a shared conceptual map — a dangerous assumption. What if your audience thinks of the web as a scary, confusing, complicated place? or have a Mozilla concept that is anchored by a dinosaur?

In the startup world, a quick glance at Angel List shows how prevalent that phrase is among budding entrepreneurs. It’s clearly both trendy and attractive to rely on other successes to explain your concept. I’m here to warn you about what may be an attractive nuisance, but suggest a simple way to do it better.

Whenever you say something like “It’s like YouTube for _____”, or “like Pinterest but for ____,” you hope you’re concisely communicating a key part of your business or product idea but you could easily miss the mark, and not know it. Analogies work to the extent that the analog is a concise description of a key concept, which you’re applying to a different market. The problem is that products, and especially successful products, are not that simple. If I say “like YouTube”, my interlocutor will have a very different set of words pop into their minds depending on whether they’re an Italian judge, my kid, a devops, or a music industry executive. The people you pitch to likely think differently than you do (after all, that’s likely why you want their attention, time, money, patches, whatever). It’s therefore much too easy to confuse rather than elucidate.

My advice is to refrain from saying “like ____ for ___”, even though it feels nice to glow in the reflected glory from these successful precursors.

You can do better, and you should: there’s usually something in that appealing analogy which is the concept you’re trying to convey, so focus on that aspect of the inspiring product. “It’s got the same instant gratification of Instagram, but with ___”. “It’s as disruptive to an enterprise market as MySQL was, but targeting the ___ market”. By making the analogy precise, you bring your audience along where you want them, and you show that you understand one of the many reasons why these products were successful.

If you haven’t been paying attention (and really, most people shouldn’t), there’s what feels like a real trend where startups are breaking down common tasks for web & app development, and solving them through a software-as-a-service model. So, in no particular order, you can see

stripe doing payments

disqus doing commenting

firebase, pusher doing lightweight data & realtime updates

newrelic is doing deep resource tracking

geckoboard is doing dashboards

heroku is doing processs/service hosting, relying on a bevy of partners including many of the above for slices of value

…

There are lots and lots (and lots!) of new entrants that are following this paradigm, and from a developer’s point of view it’s both exciting and daunting.

Exciting because in the right combination, these services can be combined to deliver incredible scale and agility even to very, very small teams. (I have a fantasy of someday figuring out how large a 10-person project can be. It’s pretty large).

Daunting as well, because while when they can work well together in an app, they really should be thought of as independently moving (and failing) parts. And you’re likely not going to understand them as well as you should, or as you would had you built them yourself.

Which leads me to a friday-afternoon prediction: that there will be, over the next few years, a few companies who become experts at solving the coordination problems that arise from assembling so many disparate slices of value into an offering (whether for developers, or clients, or internally). And I expect that this expertise may not be purely technological.

I’ve seen how deep one has to go to get a real understanding of the security and privacy implications of relying on a third party for handling user data; I’ve seen the horrendous chain of dependencies that emerge out of security vulnerabilities; I’ve gotten a glimpse at the regulatory issues which some (soon more) folks will have to face. Dealing with high availability, geo-distribution, etc. all result in systems whose complexity scales in scary ways.

This leads to two thoughts:

If I were a wise investor, I’d look for those folks who look like they’ll find ways to integrate value in coherent larger slices, or mitigate the pain.

As a “product person”, I probably want to work on problems that require only a few slices, done well.

Said like that, I do get a “nothing new under the sun” feeling. Oh well, it’s Friday. MFBT.

2010 will be a big year for Thunderbird. Last year, we launched Thunderbird 3, which is a huge milestone for us. In this post, I’d like to give people a heads-up as to what the coming year will look like. I’ll focus on three topics: our plans for innovation through add-ons, Thunderbird 3.1, and our first steps towards making Thunderbird self-sustaining.

Innovation through Add-ons

We believe that Thunderbird is a much better development platform than ever. This means that building innovative experiences on top of Thunderbird is easier than ever. We’ll be building on that platform ourselves and helping others innovate as well. In particular, we’re going to be using add-ons in a few ways:

If we have an idea for a change to an existing Thunderbird feature, we’d like to roll it out first as an add-on, so that we can get feedback on early versions of the idea without having to incur all of the up-front costs of landing that change into the “trunk” builds. This should allow us to validate (or reject) ideas much faster. A great example of how this can work is the Personas feature, which matured as an add-on, and is now a standard (and awesome) feature of Firefox 3.6.

We sometimes think of features that “would be cool” (see e.g. conversation arcs, tagsoup), but don’t necessarily make sense to integrate into the core product. Making an add-on here makes sense because it lets us share those ideas with others who think they’re worthwhile. Sometimes “cool ideas” become “big ideas” over time (google calendar add-on.

Having core engineers develop add-ons is also one of the best ways to ensure that the add-on platform is as good as possible.

Thunderbird 3.1

In parallel with some exciting innovations in add-ons, we’ll be pursuing more gradual change strategies within Thunderbird 3 itself.

Thunderbird 3.1 is also underway. We’ve already released the first alpha, and a first beta is getting defined. It will be focused on a couple of areas:

Making the upgrade from Thunderbird 2 as painless as possible: Some of the features that we introduced in 3.0 were confusing to Thunderbird 2 users, and some of the defaults which we think made sense to new users were quite surprising to long-term Thunderbird users. We’re reviewing the upgrade process and making sure that users get to opt-in to the more radical changes. We realize it can be quite unpleasant to have your software change unexpectedly.

Improving some of the new features in Thunderbird 3: The feedback for the new features has been both positive and constructive — look for refinements on the concepts introduced in Thunderbird 3.

Ensuring Economic Sustainability

Thunderbird deserves to be self-sustaining. Paying one’s way is a great validation of any effort, and it’s in the interest of Thunderbird users everywhere that we figure out a way to get there. As promised when we formed Mozilla Messaging, we’re starting to explore ways to make Thunderbird self-sustaining while at the same time promoting the Mozilla mission (as articulated by the Mozilla Manifesto). We’re specifically looking to identify business models that create economic value by improving the user experience of Thunderbird users. This is nothing new for Mozilla. The foundations of an open source codebase, the ability for users to opt-out of commercial relationships, and an architecture that allows plugging in alternative providers for whatever service or product we end up partnering with are non-negotiable requirements. With that as a foundation, we’re looking for ways to make the online life of our users better, and within those ways, identifying those which can help ensure Thunderbird’s long life.

This will happen through a set of public opt-in experiments. For each business model that we try, we’ll build a prototype, announce it, get data to evaluate it, solicit feedback from users, and evaluate whether it’s worth continuing. Anecdotal data suggests that plenty of Thunderbird users are happy to be offered commercial services which provide them value and help Mozilla too.

In addition, I’ll be actively soliciting input and help from what I’d like to call “business contributors”. Just like we encourage programmers and others to contributing to Mozilla through patches and other internet-mediated activities, I’m going to setup ways to “open source” the business model and business development activities. I’ve found in conversations with my peers that almost every business leader who’s aware of what we do would like to contribute, but we haven’t made it easy. Identifying and facilitating such contributions is one of my personal goals for the year.

To start, here are two possible ways for business folks to contribute:

I’ll be in the Bay Area next week for a panel at MAAWG in San Francisco and other meetings, and will be organizing a dinner/drinks event for people who want to chat about Mozilla Messaging business models. Contact me by email if you’re interested (dascher at mozillamessaging.com).

We’re hiring a business development lead to help drive this effort. If you know someone who you think understands business development and would be a great fit for Mozilla, point them to the job description.

Ashlee Vance wrote a story in today’s nytimes.com (I presume it’s in the print edition too about the business world’s supposed disappointment in the shareholder value of open source based businesses.

I suppose if you ignore all of the companies listed in the article who were sold for hundreds of millions of dollars, and you squint really hard, you can see their point: investors in open source companies in aggregate haven’t made as much money as investors in proprietary software companies. Given how short the age of open source has been, that’s hardly surprising. (Given how open source is missing the boat on services-based businesses, that’s also likely to continue, but that’s another story).

Others will I’m sure criticize the article based on proposing some better metrics for success for investors in open source companies. I don’t really care — what did strike me was this sentence:

The fight illuminates a larger truth about open-source companies: their societal and strategic importance far exceeds their financial value as operating businesses.

Exactly! It’s critical to me as CEO of Mozilla Messaging that it be a healthy business. But my requirements for “health” aren’t those of wall street. They include reaching a state of making more money than we need to operate, but they also include some variation on the triple bottom line, with some additional twists related to making sure that we operate in ways that are consistent with our values.

I was recently at a business meeting where a bunch of CEOs were “networking”. It was fascinating how quickly the conversation shifted when I answered the usual question about “exit” (the polite term for: “get rich by selling the company) with “well, no, I can’t, as we’re owned by a non-profit”. After a period of shock, it turns out that even CEOs (!) are interested in a business that isn’t all about financial rewards for shareholders. It can be about much more interesting pursuits, such as building a team of people who respect each other and work together for a common goal; it can be about providing awesome customer experiences; it can be about making the world better. There are lots of companies like that. It’d be nice if the “business” section of the newspaper spent more time thinking about that and less about how people who are merely shareholders can make money through speculation.

It’s probably healthy for Wall Street to realize that what’s interesting about open source isn’t some magically cheaper way to produce goods and services. To me, what’s much more important are the complex implications like transparency, a permeable barrier between your consumers and your staff, a built-in safeguard against complacency, and ideally a much more human relationship between your organization and everyone else. I look forward to seeing what the Economist’s new Schumpeter column on business says about it, whenever they get around to it.

In the meantime, I’m looking forward to exploring how to work with business-savvy types who are interested in how to make a deeply healthy business. Based on talking to other CEOs of open source companies, I’m pretty sure that just like we can find talented programmers, quality nuts and localizers to contribute to the products, I’ll find some smart business types who will find it rewarding to contribute to the business challenges.