Launch Late to Launch Often
A common theme I hope to address in this blog is accepted wisdom, especially when I think I've got a bit of a different spin on things. One piece of accepted wisdom one hears in software circles these days is "release early and often", and as you can tell by the title of this post, through the miracle of foreshadowing, I have a slightly different perspective.
Let's start off with a few hypotheses. Some of these you will take for granted and others you may argue:
- Extensible architectures generally provide more long-term business value than point solutions, although point solutions may monetize a specific market more quickly
- Software that hasn't been released can be changed in ways that become less possible N customers after launch. As N grows, so does the difficulty in refactoring some percentage of infrastructure or functionality. Additionally, as more than 1 copy of the software is released into production, these difficulties multiply.
- You have no idea what capabilities the market will want from your software in one year
- Customers generally value functionality and speed of ROI over flexibility and extensibility, however in order to maximize your chances for long-term success, your business values flexibility and extensibility over specific functionality.
Since my brain doesn't go as fast as it used to, I'll have to use an example from FeedBurner since I can't remember how we did some of these things in previous companies. Four of us started working on FeedBurner in October of 2003 and we launched around the end of February 2004 with only two simple services: a primitive v1 of our feed statistics and a format transformation service (eg, Atom -> RSS2, RSS2 -> Atom). Five months of four people working full time just to rollout something that resulted in the following initial comments: "I could build this in a weekend" and "It doesn't really do anything".
When we conceived of the idea for FeedBurner, we weren't thinking "we'll rollout these couple services and then see what else we should do based on feedback", because we could have launched something like that in a few weeks. We were thinking "the ability to provide a robust suite of feed clearinghouse services across a broad set of feeds will be a powerful service for publishers. We don't know what all of these are right now, but if we architect the system for extensibility, we'll be able to quickly provide additional capabilities and lead the market". We probably didn't say it like that. I'm sure it had a lot of "um's" and "you knows" and "yeah and then like we could do more stuff", but you get the difference between the two statements.
Sounds great, but what does it mean? If you don't know what you don't know, how do you know what you won't know until you know it? What the heck does "architect for extensibility" mean, and how do you do it without hurting yourself and wasting a lot of time?
I'll use an analogy and then provide another simple and general FeedBurner example that might paint the picture. Like most of my favorite analogies, this one doesn't really make any sense, so just bear with me. Let's say you have two brothers, Kenneth and Jake. They both decide to go into the milk shake business. Jake seems to have distinct advantage because Jake's Shakes sounds a lot better than Kenneth's Shakes, which is hard to even pronounce without giggling. Jake decides that people want vanilla shakes and he quickly deploys a set of vanilla shake shops suited to make only vanilla shakes. Kenneth decides that he's not really sure what kinds of shakes people might want, but he wisely guesses that people might want different flavors, like chocolate or wasabi. This is really a stupid analogy but you see where i'm going; Jake gets to market first and MAY have a big hit or may have limited distribution. One thing we know for sure is that people better like vanilla shakes because that's all he's set himself up for, and the more copies of his store he creates, the harder it's going to be to go back in later and change the business. Kenneth has set himself up for a number of possibilities and will be prepared to rapidly react to the market when he launches some time after Jake, even if he also launches with only vanilla shakes. IF the world loves a smartly branded vanilla shake, then hooray for jake, he's got the better name and was first to market. IF the shake market moves against vanilla, however, or the shake market for vanilla proves to be but a tiny fraction of the overall shake market, then hooray for Kenneth. He will reap the benefits of designing his product for extensibility and be able to hire somebody to come up with a better name than Kenneth's Shakes.
Much more simple to understand the FeedBurner example. We didn't spend the first five months building those two services we rolled out in February. We spent the first five months building out the architecture for feed filtering and feed processing such that we could quickly deploy any new feed service we decided to build, and then we spent about a week building out those first two services. Yes, it was true that somebody could have built a competitor to what we launched in a weekend. However, we would be able to quickly iterate and innovate on top of our release, whereas the built-in-a-weekend competitor would have to keep building one-off services that would eventually either become untenable or require an incredibly long period of underlying architecture refactoring while we continued to innovate.
The bottom line being that you want to invest pre-launch such that you optimize for innovation post-launch. This is never more true than when it seems like you are racing into a market with multiple competitors and your inclination is to hurry up and launch something! The advantage you have prior to launch is that you don't yet have customer demands. Set yourself up to be in a position to rapidly iterate and innovate post-launch and you will be in the best position to put the first movers back on their heels if they aren't in a position to react to market forces as quickly as you.
It would be very easy to misconstrue this post as "you have to make sure you have thought everything through and are ready to scale to milions of customers before you launch". That is not at all what I'm saying here. Architecting for extensibility is not about "making sure you've planned for every contingency". I'm speaking specifically about your core product or service's underlying design and how well it's prepared for speed of innovation. Other aspects of the business like"what if we need to open a facility in Nevada someday" are going to have to wait until later.
I suppose a reasonable question here would be "how do you distinguish between overthinking the architecture vs. architecting for extensibility?" That would be a good question; I frequently think my own questions are good questions, and I'll try to come back to it in a follow-up post. There are also some small things you can do to plan for future growth that I'll address in another follow-up post that I will hopefully remember to call "Planning for Success".
Comments
Agree 100%, architecture is critical particularly because you built a platform. If you are a web site, it is probably less important, but still.
The way I like to look at it is this: Ask what is your core business and then ask does your software model map onto your business. Thats how you know you got your infrastructure right.
But there is also big value in getting to the market fast. So ideally, if you are experienced engineer / business man your got will tell you when to stop generalizing.
Alex
Posted by: Alex Iskold | March 19, 2007 11:27 PM
I agree.
There is a trend in the web 2.0 circles to dismiss proper product planning and to celebrate the "get it out in a weekend" approach.
The other extreme is feature bloat and endless development of a product that never launches.
You have described the happy medium. A moderate development timeline that gets a product out reasonably quickly, BUT allows rapid innovation after launch without hurting the first customers that had the faith to sign up with you.
Thanks for really getting real.
Posted by: Mat | March 20, 2007 05:02 AM
I was going to spend next weekend building a competitive application that crushed FeedBurner, but after reading this I've switched my target to YouTube.
Seriously though, awesome article.
Posted by: MattC | March 20, 2007 06:48 AM
"I frequently think my own questions are good questions" haha, good one.
Seriously, good article that dares to go against the flow. It's all about finding balance and both extremes have major drawbacks. Thanks for the inspiring piece.
Posted by: Daniel Spronk | March 20, 2007 06:49 AM
A very thought provoking post. I'm a big believer in "release early, release often" so started reading in the defensive, but understand where you're coming from now. I don't think "release early" and what you're advocating are mutually exclusive.
If I may rephrase what I think you're saying ... you need to know what your business is before you launch, and build accordingly. Kenneth's business is about shakes and Jake's is about vanilla shakes. Similarly, FeedBurner's business is about feed processing, NOT about feature X or feature Y. It's easy to build a feature, but harder to build a platform to support hundreds of features over time.
Posted by: Ade | March 20, 2007 07:40 AM
Ade, yes, that's a very fair way of putting it; I agree with your sentiments. I was going to highlight that the two approaches are by no means diametrically opposed, but it's more fun to use hyperbole as a means of provoking some conversation.
Posted by: Dick Costolo | March 20, 2007 09:49 AM
Jake's Shake. That is a great example. People who make good examples know what they are talking about. Thanks for sharing.
Posted by: Mimo | March 20, 2007 10:29 AM
Great post as usual.
An issue that comes to my mind is that in starting a business it is often not clear what the actual technology will be to achieve the desired outcome. Feeds are clearly feeds, a discrete technology with a pretty straightforward set of components (processing, syndicating, analytics, etc). On the other hand when we started Triggit all we knew was that we were going to get into the online advertising business and focus on monetizing the long tail. Early on we rolled out three different solutions to this problem that were clearly not the right approach. Each time we took what we learned and went back to the drawing board. Effectively we scrapped each previous “launch”. If each of those had taken 3-6 months Triggit would be dead by now. What we learned in that process got us to where we are now, which is a good place.
I completely agree that once the product is figured out it makes a ton of sense to plan for the iterations, flexibility and the general assumption that the market will force you in other directions. But that first important step of getting a really good handle on what the product will be cannot be over emphasized. To play on your analogy my question is are you going to make shakes or hamburgers?
This seems like the age-old business, engineer split. The business guy starts with the business questions and asks what technology do I need to solve this problem and the engineer starts with the technology and asks what business problem they can solve with it.
My 2 cents
Posted by: Zach Coelius | March 20, 2007 11:57 AM
Very well said Dick. I wonder how much of 'architecting for extensibility' is caught by using software design patterns and frameworks like Django or RoR. I would hope that these frameworks have really helped in enabling companies to be at the same time extensible and quick to market.
Posted by: Stefan Fountain | March 20, 2007 12:32 PM
I have to disagree with you. I think your assumption is that the additional cost associated with maintaining and extending inflexible systems post-launch exceeds the additional cost of designing "flexible" systems before launch.
The problem is what constitutes a "flexible/extensible system". Counter-intuitively, flexible systems can actually harm your ability to be flexible!
The primary advantage of "release early, release often" is that you get customer feedback as you progress, which allows you to adjust your direction and re-priotize features. The whole point is that you don't really know what your customers want until you build something. To try to build a "flexible" system is to make assumptions on what customers may want.
Say that after launching their resturaunts, Kenneth and Jake find out that actually customers don't even want shakes, they actually want fruit smoothies. Jake is able to quickly adjust because he didn't outlay a bunch of cash on all those flavors and equipment - he just got the business open as cheaply as possible. So he can adjust his business quickly and without pain. However, Kenneth invested a lot of money on all this shake equipment, only to find his "flexible" solution actually had a bad core assumption. He is now faced with throwing away this large investment and starting from square one. Or maybe just re-tooling his shake machines into crappy smoothie blenders that don't quite work.
I would much rather be in the situation of having a large customer base built upon crappy tech, than having "flexible" (read: expensive) tech that can't do what customers really want.
All that said, yes, there are times where flexibility is an easy win, and that's fine. It's not like you should avoid flexibility! But I think it would be misguided to pursue flexibility in the early stages of a product.
Posted by: Dan Ogles | March 20, 2007 04:18 PM
which rule of comedy says that funny words start with "K"?
Posted by: steve olechowski | March 20, 2007 04:38 PM
Steve, see the movie version of "The Sunshine Boys" with Walter Matthau in which he explains to his nephew richard benjamin that the K sound is funnier than other letters. "Words with a 'k' in it are funny. Alkaseltzer is funny. Chicken is funny. Pickle is funny. All with a 'k'. 'L's are not funny. 'M's are not funny."
Posted by: Dick Costolo | March 20, 2007 07:57 PM
UW Entrepreneurship prof Saras Sarasvathy posits that entrepreneurship, rises from something he calls effectual reasoning -- thinking not from a goal to the means to achieve that goal, but, instead, looking to the means at hand and discovering what might be done with them. Building a platform seems to enable effectual actions, perhaps at the expense of strict causal action -- the speed and cost sacrifice of the platform mean that you can't chase a specific target as well, but that you can triangulate to emerging markets much better.
Sarasvathy has a good article up at http://www.effectuation.org/ftp/effectua.pdf
Posted by: Wade Armstrong | March 23, 2007 07:28 PM
Dick,
I think this makes a lot of sense, and recent experience seems to be bearing it out. We spent 9 months build Kayuda (http://www.kayuda.com), our visual wiki / web-based brainstorming product. We could have hammered it out in half that time, but instead we built it to be a platform on which we could build lots of information-management tools. So far we've had exactly zero negative comments (aside from "you don't support my browser and I really want to try it!"), so I'd say that the extra time was a good investment.
Thanks for putting this contrarian view out there...I admit that sometimes I was worrying that we were going to be launching too late, and it's nice to get a sanity check from outside.
Sincerely,
Dave Storrs
CEO of the Kayuda team
Posted by: Dave Storrs | March 24, 2007 06:20 PM
Enjoyed the article and as always the follow-on comments.
My take is 2 get out as early as possible but having DESIGNED the architecture 2 cater for your long-term plans. I didn't say BUILD, I said design.
So u create the framework and position the building blocks so it will cater for 3-6-12 mths and beyond (based on your master plan)
you then sprinkle in some of your magic dust that allows for flexibility in case your initial/2nd/3rd market positioning (of feature set - whatever u want 2 call it) doesn't totally gel.
U then build those blocks that make sense and can deliver the bare functionality to try beta1/alpha etc..
Launch and see what happens.
By having the framework/archtitecture in place it shouldn't b a whole lotta effort 2 change as you get the "reality" from your initial customers.
At least thats what works 4 me : ) .....
Lal
Posted by: Lal | March 25, 2007 11:02 PM
This is playing out right now in the XBOX 360/PS3 console wars.
PS3 is built for the long run while xbox got pushed out the door.
Posted by: Wally | March 26, 2007 05:46 PM
We designed Flektor (launching next week) in exactly the same fashion - instead of just building a site that let users put together photoalbums and fancy text (a'la slide.com and rockyou), we built a generic platform for authoring user-generated content. Even during our development process, we've found this to be a huge win; we've been able to add tons of new features without too much effort. Users can make a quick postcard or poll in 3 easy steps (using our quickstart wizards), use the full editor (which has a feature set equivalent to a full-app like iMovie) to make a short film, and use the content manager to upload and manage their photos, videos, and music and this is all treated uniformly throughout the application.
That said, we spent 8 months building it, and I would have loved to launch a few months earlier; we implemented a lot of features and we're not really sure which stuff is going to be the most popular (which is where we really ought to spend our efforts). There's definitely a fine line here that is easy to cross.
Posted by: Scott Shumaker | March 31, 2007 08:17 PM
See second half of Clay Shirky's:
Against Well-designed Reputation Systems
http://many.corante.com/archives/2007/01/29/against_welldesigned_reputation_systems_an_argument_for_community_patent.php
Posted by: Anon | August 17, 2007 02:39 PM