Coupons in Web 2.0

As the "great recession" either lumbers on or quietly gives way to economic recovery, the proliferation of Web 2.0 sites which provide information to their user base about every offer or coupon code in existence on the web has forced us (and presumably other businesses) to rethink some of our marketing strategy. In my opinion, it's safe to assume that any general offer you send out to your email list, or otherwise communicate in a limited fashion will show up on CouponCabin, RetailMeNot, SlickDeals, Deals.Woot or their counterparts for the whole deal-obsessed portion of the consumer market to see in a few hours.

Of course smarter technology can let you limit these offers with unique discount codes or business rules enforced in your ecommerce platform, but generally should you? There are a handful of sites out there with highly dedicated audiences who may be exposed to your brand for the first time through one of your discounts. (Think Groupon without the restrictions and outrageous cut of your sales.)

Damn You Snow Leopard...

We recently finished our upgrade to Exchange 2010, which set off a chain reaction of events that destroyed my development environment. I had been using IMAP to connect Apple's mail client to our Exchange 2003 server. IMAP is turned off by default in Exchange 2010, and Snow Leopard supports natively connecting to Exchange. As such, I thought it was a perfectly good excuse to upgrade from Leopard. This was not a great idea.

Apple bundles an update version of Ruby (1.8.7) with Snow Leopard, which clobbered the rather messy development stack I'd been running on my laptop. (Having started really working with Ruby and Rails back when you had to run everything in Webrick, moving to nginx, mongrel clusters, and finally settling on passenger over a span of at least a few ruby and rails versions, it was rather fragile.

I spent somewhere on the order of 8-10 solid hours trying to fix it. (Installed RVM in the hopes that I'd get some help from a clean version of Ruby. Nope. Rebuilt almost everything. Nope.) Ultimately I decided it would likely be easier to start over with a fresh install of Snow Leopard on a blank drive and rebuild a clean stack from scratch.

So here's what I ultimately ended up doing. (Note that this would be what you need to do in order to get started with Rails on Snow Leopard. I'll add command line snippets shortly, but most of this is pretty straightforward stuff.)

1. Back up everything to a time machine drive
2. Insert the Snow Leopard DVD
3. Boot up for an installation
4. Use disk utility to wipe my hard drive (scary.)
5. Reinstall a clean version of Snow Leopard
6. Install XCode from the "Optional Installs" on the Snow Leopard DVD
7. Update Rubygems
8. Download and install MySQL binary
9. Create .profile and add /usr/local/bin to my path
10. Install the mysql gem with 64 bit archflags directive
11. Install rails 2.3.
12. Install the passenger gem
13. Configure passenger [sudo passenger install-apache2-module]
14. Install the passenger preference pane
15. Success!!

Rework

I got my copy of "Rework" by the 37signals guys today - just in time to take it on the plane with me to Buenos Aires! I'm exited to read the latest by David + Jason.

Setting User Expectations

We are currently nearing the end of a few day process to transition our email server from Exchange 2003 to Exchange 2010 and it's gone relatively well from an end-user upset perspective. (The rationale behind staying with on-site Exchange instead of moving to the cloud will follow in a separate post.)

I have it easier than many because my "customers" are generally the employees of our company, so it's easier to set and manage their expectations. Regardless, it still needs to be handled delicately to minimize their upset and resistance to change.

I think a few key factors really helped in the process

1. (Self evident) Let everyone know what to expect out of their experience during the transition
2. (Self evident) Work around the customer's schedule. In practice this meant scheduling downtime for our 9 to 5 employees from 8pm to 6am and scheduling downtime for restaurant managers from about 2am until 8am
3. Be honest about the fact that you'll run in to problems and fix them immediately

Finally, I have to give Microsoft props for ensuring that Outlook 2007 will automatically recognize the new 2010 server without any user action. For our office users, this should make the transition go essentially unnoticed.

Schedules

I used to go by the mantra that schedules were bullshit. I wouldn't give people deadlines or commit to them unless I knew we could deliver something on time.

However, I've revised my stance: schedules are just a guess. We can learn a bit about how long it takes us to write a given type of app and make slightly better guesses in the future.

So why make a schedule at all? Communication. If the other department heads who rely on my team for both day to day and project support don't have a clue what I'm working on, it's hard for them to understand why I'm not working on whatever they need. A schedule helps to explain why everything can't be done for everyone all at one.