I’m going to take a step back from our pre-launch marketing for Tastefully Driven to go over our overall launch plan – from conception to where we are now to what we have left to do. I’m not saying that there aren’t different or even better ways to deploy a site, just that this process is how we do things, in large part based upon prior failures, successes, and other professional experiences (I’d be lying if I said my engineering background didn’t play a large role in the way I structure a project).
None the less, I’ve never in my life missed a due date on a project and a large part of that is my meticulous planning so hopefully this post will help other young entrepreneurs better formulate their business plan.
You have that “ah ha” moment where your entire perspective on the world changes and you think to yourself “I’ve got to do that“. This is the start of what I call the conceptualization stage. For us, after the Detailed Image shopping cart far exceeded our expectations, we naturally asked ourselves how we could repeat the DI model in another industry. That led to us considering several similar high-end niches, and eventually the light bulb moment where we could combine those stores and a community into one large site – hence Tastefully Driven.
When I’m at this stage with a project, I’m so excited that I put a self-imposed waiting period on myself before acting (similar to my 24 hour rule). During this stage you’re likely to be so certain that you have just come up with the next big thing that you’ll ignore reality and down play very real road blocks. There’s no set time period, but I’d say wait at least a week before taking any action beyond registering a domain name.
In the case of Tastefully Driven, we conceived of the idea sometime around Thanksgiving of ’07. For the next month we discussed the pros and cons – the features we’d want and those we wouldn’t, how we would market it, how it would impact the rest of the company, and how much of our resources could be devoted to it.
Aside from preventing you from doing anything stupid, it allows you (and your team, if you have one) to refine your vision. By the end of this period for us, everyone usually shares the same vision and knows what’s going through everyone else’s head. When you finally do start the project, you start it on the same page with the same vision for success.
Making it an Official Project
By late December we had decided Tastefully Driven would be our future. At that point I consider the project an official project. During this phase we started to get more serious: would we keep client work (ultimately, no)? how would this impact Detailed Image (we would finish all DI development work for 2008 before starting TD)? when could we realistically launch with several product lines (initially, we said 8/1/2008 at the earliest).
This is where I really shine. We have a MONSTER project and we need to figure out how to start tackling it. This is also where I think a lot of people get paralysis by simply being overwhelmed with what to do next. As Theodore Roosevelt once said: “In a moment of decision the best thing you can do is the right thing. The worst thing you can do is nothing.” In this case, the right thing to do is come up with a plan.
Up to this point, we had literally written nothing down and neither should you. Don’t get caught up in the minutia when you’re conceptualizing. However, once it’s an official project there has to be extreme attention to every single detail.
We tend to convene around our company wiki, so I like to write my project plans on the wiki. Since we had agreed to finish Detailed Image development before touching TD, I focused on that first. There were around 10 additions to the cart that needed to be completed (mostly stuff for me to do). I gave each an approximate completion time and I figured it would take until the end of February or early March to complete. Somehow I caught fire and wrapped it up on 1/12, which gave us an early indication that our 8/1 launch date for TD might have been too much of a time cushion.
Once complete with that I started an in depth plan for Tastefully Driven. The site will launch with 5 or 6 e-commerce stores, a community, a blog, and full integration of accounts between the three – by far the largest project we have tackled, and therefore the most daunting to plan. I started by breaking it up in to several key categories:
- Design (mostly Mike)
- Development, which essentially involved improving and scaling the DI cart (mostly me)
- Quality testing, which could fall under Development, but I like a whole section of tests to run prior to launch
- Product selection (mostly George)
- Content creation, including writing product descriptions
- Marketing ideas
Each category had a simple bulleted list, and each task that needed to be done to launch got an approximate completion time. The latter stuff – like marketing ideas – was more of a brain dump than anything else. Even though we create a marketing plan later on, it’s important that we have a place on the wiki to jot down an idea as we come across it in the development of the site.
Setting a Launch Date
Some people like to use Microsoft Project (or similar project manager tool) to plan out due dates and choose a launch date. I was forced into using these tools in college, and to be honest I just see them as complicating the matter. I like the freeness of one large blank wiki page. I am smart enough to know that keyword research needs to be done before launching a pay-per-click campaign, so I won’t assign a due date to the PPC campaign that doesn’t allot for that. With the entire project in front of me it became pretty obvious that we could finish it by 3/1 (a far cry from 8/1). We figured with the warehouse move and a little cushion time, that 4/1 would be perfect. Any later in the year is prime Detailed Image season so if we didn’t do April we’d probably have to wait until Fall…or launch with limited contribution from George and Greg.
As I touched on a bit in previous posts, the one key thing I grossly miscalculated was how long it takes to contact vendors. I figured a month would be sufficient time to contact a vendor, get samples, place our first order, and receive it. More realistically, that stuff takes several months and I’d like at least a 3 month cushion for that alone next time. Our final order just shipped, so miraculously we will have all of our products in the warehouse for weighing and photoing by 3/14, but we cut it waaaay too close in my book.
Developing the Site
The development portion is different for everyone. Some people use open source software like WordPress or osCommerce with very little customization and this portion isn’t much more than design work to get the aesthetics right. Others hire an outside developer….which I’ve never really done so I have no clue how to integrate that into a project plan. We develop everything ourselves, so we were able to relatively accurately estimate our ~2 months of development work.
*side note – if you or your developer don’t develop with SEO in mind, this is the time to start building and structuring things properly. Do your homework – it will pay off.
When I do development work I do it with the understanding that we’re spending a few weeks solely on quality control testing at the end of the project. That means that while I’m developing I test every scenario and interaction I can think of, and once it works I move on. I usually miss some stuff, but that’s OK. In most cases there will be other interactions created later on, some of which we won’t appropriately test – which is why having a QC testing phase is so important. I also encouraged Mike to think the same way with his design. Essentially – lay it all out and get it working most of the way and fix the nitty gritty shit at the end.
I always map out the entire site – every feature and function I can think of – before touching anything. Once that’s done, I create the database that should encapsulate every single possible scenario. This is pretty obvious: you need to be able to enter test data to see if what you’re trying is working.
All of this resulted in a more detailed list of features to develop, how long they’re going to take, and what order to do them in. By far the most challenging part of Tastefully Driven was to get our login and user information to work seamlessly between our forum (built upon bbPress), our blog (WordPress), and our custom built cart. Every project I’ve ever been a part of has those “if we can just get this to work, we’ll be fine” features and this was the one thing we were really uncertain of the difficulty going in. It’s important to identify these types of issues at the start and try to tackle them as soon as possible so you know where you stand. These are the things that will throw off a time line and screw a launch date.
Announcing the Launch Date
For the reason in the last sentence, we have an unwritten policy of not announcing a launch date until the development work is nearing completion. While internally we set 4.1.08 as the date, we always knew it could be delayed if need be. Once I announced the launch on my blog, I considered it set in stone and – short of an extreme emergency – will make sure it happens.
Every company has different pressures and a lot of times those pressures dictate premature launch dates, but if you can help it I encourage you to set a date and stick to it. A launch date really forces you to buckle down and focus on the task at hand. It forces the BS stuff out of your project plan and dictates that you work on only what is necessary. We’re in this phase now, and I’ve been knocking things off of our wiki list like crazy. Some get moved to “post launch” and others get canned because they just don’t matter.
I normally work a lot more hours prior to a launch. The past few days George and I have been doing a double shift (8 AM to 8 PM type of stuff) to ensure that we get everything done on time.
Creating a Marketing Plan
Up until this morning we just had our marketing list on the wiki. We created the splash page, the pre-launch blog, and the teaser business cards, but the plan wasn’t really formulated. Today I finally created our marketing plan. Some people like to do this sooner than now (a month before launch), but I encourage you to wait to create a marketing plan because so much changes in development that much of an earlier marketing plan would be rendered useless.
I’m not going to rehash all of my favorite web marketing tactics – my free e-book does that – but I will say that for an e-commerce site we’ve pretty much got a formula down pat that we are sticking to. The majority of our marketing will consist of:
- Content creation. Articles, forum posts, podcasts, and videos where we do product comparison, tests, and case studies. Since our site is perfectly SEO friendly and we will produce quality content, over time this will suck in a ton of targeted traffic. It will also become viral and hopefully spread through social bookmarking and social networking sites (we have a “share this” button on every product page, blog post, and forum post).
- Pay per click marketing. PPC is such a simple formula if executed properly: pay $x per click, y% of clicks turn in to purchases. As long as the number of clicks/sale is greater than your margin, you win. Split testing and refining ads can push your cost per click down and conversion rate up.
- Google product search. So many sellers don’t take advantage of this. It’s free, and in about 2 hours I automated the process so that we automatically create and submit an updated product feed daily to Google via FTP. DI gets a lot of sales this way.
- Email and RSS marketing. This is really just maximizing the sales we can get out of our existing members. I’d also include great customer service in this category – every customer service email is an opportunity to positively influence someone who could become an evangelist of your site. When you’re starting with zero members, email marketing can take a while to have an influence. We see it now with DI though: every newsletter results in a wave of sales. This is one of the reasons why the pre-launch splash page is important: the faster we can build an email list, the better.
There’s other stuff too, but these are what will drive sales. Obviously PPC and Google product search will help immediately, while the other two will take time to develop. We’ve launched so many sites that we understand that you don’t truly see the impact of great content for months and even years. With this project, we know that what we’re doing works and we’ll be as patient as we need to be to make it work correctly.
Maybe it’s because I spent my engineering days as a QC engineer, but quality testing is a big deal to me. Test every single page and every single possible function of your site. Do it in every browser, every operating system, and under every condition you can think of. Test your emails in every email program available. Do REAL transactions and make sure they work. Recruit a handful of BETA testers (i.e. friends and family) to try everything out.
You’ll never catch 100% of the errors, but the difference between 80% and 97% is huge. I allot a minimum of one week for QC testing and it’s usually the week prior to launch. That means that everything else should be done at least a week before launch day.
I always create a launch day checklist. While you should pause to celebrate (for like five seconds), once you pull the trigger there’s a lot to do: announce it on your blog (if you have one), submit your product feed to Google, submit a sitemap to Google/Yahoo/MSN, activate your PPC campaign, email friends and family, etc.
You’ll likely start discovering some of those errors you missed in the QC testing phase as real people do stupid things to inadvertently challenge your software like it never was before. The better job you did in QC, the more you can focus on your first order coming through and the less you have to worry about your first users getting pissed off and leaving. When it comes to Tastefully Driven the platform is built upon Detailed Image, which we know is stable, so I’m more worried about minor integration issues than I am about all-out systems failure (which was definitely a concern of mine when we went live with DI….even if I never let my partners see it).
Bottom line: it’s a fun day when you launch, but in reality it’s just the beginning. Take a day to catch up on sleep and then get to the “real work” – getting people to actually pay you money.
I have a rule: other than fixing errors, don’t make any major development changes or additions for at least a month…three to be safe. Why? Because on the second day you’ll get an email from Aunt Betty telling you that she thinks the site would be better if it had feature xyz and you’ll think “if she thinks that, other people must be too” and then you’ll begin to hack up your code and try to rush xyz to market. Not only could this make your site worse, it’s also a poor use of your time. You’ll get emails like this all the time, and if you concede to all of them you won’t make much money and your site will suck.
If you have confidence in your project (and you should if you got this far), there’s a good chance that you launched with a pretty solid site. That’s good enough for now. Take in your customer feedback, study your analytics, and focus on sales right now: in the grand scheme of things you’ll look back at the launch version of your site as a piece of shit but you need to let those things play out so that you’ll know what you should and shouldn’t do to improve upon it.
For Detailed Image, we waited from September to January before I started on the laundry list of features for 2008. The result, however, was a million times better than if I kept programming in September. Some features were deemed unimportant and scratched from the list, some were re-affirmed by our data….justifying our time expenditure, and some became simpler to program because of everyones more intricate knowledge of the cart.
One thing I think most developers look past: just because you made the software, doesn’t mean you know it. Often times, customers will use things vastly differently than you intended. By letting those things play out naturally you save yourself a ton of headaches and ensure that the changes you do make are worthwhile.
Phew. Can you say longest post ever? I think I’ll get back to work now….after all, I’ve got a lot to get done to launch this site 🙂