First things first: Why should we offer healthcare?

You’re not legally obligated to provide healthcare, so why bother? When we started, each person was on still on COBRA from our previous company, Intuit (if you don’t know, that means we were paying out of pocket for the entire health insurance premiums for same plan that we had while at Intuit) or had their own individual plan. So what’s the benefit of the company offering medical insurance?

• Cheaper premiums: Intuit basically offered only high end plans (no deductibles, cheap prescriptions, etc.) because they use good medical benefits as a recruiting tool. So now that we were paying out of pocket, we were paying the high premiums that went with it. If your startup can choose your own health care plans, you can choose from any plans the insurance carrier offers, including the (much, much) cheaper plans.
  • But… the premiums are not necessarily cheaper than individual plans. A couple brokers told me that at a small group size, the rates are basically the same. We knew we wanted to offer a group plan at some point, so we just bit the bullet now.
• Guaranteed coverage: The main difference between an individual plan and a group plan is that a group plan has guaranteed coverage; i.e., you can’t be denied for preexisting conditions.  In fact, if you have an employee with a serious (i.e., expensive) preexisting condition, a group plan might be cheaper because your rate is (basically) determined by your age and gender, not your medical history.
• It’s the right thing to do: I was going to write something about the sad political environment we live in, blah, blah, blah, but ’nuff said. We’ll move on.

Can we offer health care insurance?

Luckily, a group plan really only requires the minimum number of people that would define a “group”: 2 people. After that, it gets a bit complicated:

• You need to have at least 2 “eligible” employees to qualify for a group plan. An “eligible” employee is one who is working full-time, which is defined as at least 30 hours/week for minimum wage ($8/hr in California).
• To prove that you’re a real company, you have to have those 2 “eligible”, paid employees on payroll for at least 6 weeks in the quarter prior to the quarter you’re starting coverage. E.g., if you want to start coverage on April 1, you need to have at least two employees on payroll February 15.
• Only people “associated” with the company can be offered health care from the group. The easiest way to associate someone with the company is to pay them for full-time (minimum 30 hrs/week, $8/hr). Basically, the insurance carriers don’t want to open up group policies to everyone so you don’t just add your Aunt Mildred with her needs-to-replaced hip even though she has nothing to do with the business.
  • But what if you’re not taking salary (which happened in our case)? Owners of a company are associated with the company, but to prove you’re an owner takes documents stamped by the state and possibly proof that the owners are making income (i.e., share of profits) from the business. The threshold of proof varies for the different carriers. If you can’t meet the threshold of documentation, that employee will have to find an individual plan, or you have to put that employee on full-time payroll. Note: unpaid employees, like owners, do not count toward your 2 “eligible” paid employees from the first bullet above.

What can we offer?

Only some insurance carriers will offer policies for really small companies. Some require a minimum of 25 or 50 employees. Some only have competitive rates at those higher numbers. Our broker gave us quotes from Anthem Blue Cross, Blue Shield, and United because those were the best options for a group our size (4 employees at the time of quote).

Each of these major carriers require a minimum percentage of a small business’ eligible employees to enroll with the carrier, and that percentage is greater than 50%. And that means… do the math… you can only offer one carrier.  So you’ll pick one.

The exception is Kaiser Permanente which does not have a similar requirement (or the minimum percentage is much lower). In the end, we’re offering one major carrier and Kaiser.

Once you’ve selected an insurance carrier, you can (basically) offer as many of their plans as you want to your employees. It doesn’t cost you any more, but it’s just a management headache offer 30 plans. We chose a decent mix of low, mid, and high end plans, in both HMO and PPO varieties.

How much does it cost?

We don’t have a lot of cash (what startup does?) and we don’t intend to use “Great Benefits!” as a major recruiting tag line (we just want to do really important stuff with really cool people). So we wanted to keep it inexpensive to the company; we can always increase our contribution the better we do financially or the more important benefits are to retention and recruiting.

The cost to the company doesn’t actually have to be that much. The minimum employer contribution is 50% of the employee’s cheapest available premium or $100/month (details of that rule vary slightly for different insurance carriers but that’s basically it).

For example, let’s say you offer three plans and Joe’s premiums for just himself on this three plans is $200, $300, and $400/month. Regardless of which plan he chooses, the company’s minimum contribution is 50% of the lowest plan, so $100.  Let’s say Joe has a family he wants to insure, so his premiums are $700, $1000, and $1300.  The company’s minimum contribution is still $100 because the minimum is based on just the employee’s portion of the premium, not the spouse or family.

Of course, you can offer to pay for more than that, based on any formula you want. We chose to pay for 100% of the employee premium.

So you can reduce the minimum employer contribution by offering the lowest package possible. But don’t be a jerk; pick a lowest package that someone would actually take.

We chose not to offer HSA-based packages or other really low end packages, but we still offer a pretty cheap plan (along with the higher end plans).  Our employee premium is ~$250/month/employee and, again, we chose to pay for 100% of it. The rates were based on the fact that we’re a group of 30-something males in the California Bay Area.

All the caveats you can think of apply when you see prices on the Internet; your mileage may vary.

What do I do?

OK, if you’re like me, you probably don’t want to talk on the phone with people more than you have to when buying something.  You want to fill out a form online, get a page of options, select some, put in a credit card or account number, and be done with it.  So if you want, you can sort of do that.  You can go to each of the insurance carriers’ sites and do it.  Or you can go to eHealthInsurance and fill one form to get multiple quotes.

Don’t bother. Get an insurance broker. Why?

• It’s no more expensive. Either the broker gets the commission or the carrier keeps the commission.
• You get to deal with one person instead of different sales contacts at different carriers.
• The health insurance is still all about forms, signatures, faxes, etc. You don’t want to deal with that.  You have a business to run!

What did I look for in a broker? Remember, regardless of the broker, your premiums will be the same, so pick someone you can work with.

• Responsiveness, responsiveness, responsiveness. Duh.
• Tech savvy enough to deal with emails, scans, pdfs, etc. Even with online fax services, who wants to deal with that?
• Experienced in small businesses in your industry in your area.  Brokers don’t make a lot of money from commissions on small group policies, so many don’t bother with them; they’re hoping to make more as your company grows. Also, I didn’t have to explain why multiple employees in the company are taking no salary and why we have no revenue or income.  They get it.

I just Googled around my area for insurance brokers, sent emails to a few, then spoke to a few on the phone. Only one called me back regularly and sent me emails to remind me to send in my forms. And we had a winner!

But wait, there’s more!

There’s a lot of I’ve learned in selecting and signing us up for medical benefits, but this post is too long already.  I’ll cover more in follow up posts, including: dental/vision/life insurance coverage, worker’s comp, health statements, etc.

(photo by Adrian Clark)

The key to Jeff Bezos’ mandate was that the services would be designed from the ground up to be externalized. With that key requirement, you’ve suddenly gone from a simple API to an API with full documentation, full security, full SLAs, full Dev and QA environments, full versioning, etc.

I’ve only worked in one reasonably complex organization, and that was Intuit for three years after the acquisition of Homestead. While I was there, I saw the technical group at Intuit struggle with the problem of scaling their development community, and I think it was heading down a fairly common road: standardization on technologies and libraries (at every level of the stack feasible) to increase buying power, increase code reuse, and decrease training overhead.  But the result was also fairly common and predictable: central core groups struggling to enforce mandates while client groups try to work around the system.  There was (and probably still is) a move philosophically toward SOA, but even then, use of that SOA was often done when organizationally required as opposed to technically prudent.

In my opinion, Steve Yegge’s description of Amazon’s model is how any company of any significant technical complexity should work (including Intuit), and the benefits are profound.

1. With full documentation, security, SLAs, Dev and QA environments, versioning, etc., you remove much of the bureaucracy (i.e., meetings) that surround creating technology together. If you implement an SOA in name only, like just an API (which I’ve seen a lot because it’s considered just a technical concern as opposed to a full business concern), then you’ve just replaced an architectural design meeting with an API design meeting and not made any progress toward more loosely coupled technical teams.
2. In defining your service interfaces at a business level (including SLAs, etc.), client tech groups will be able to compare the internal service with external services.  For example, the company should encourage client tech groups to compare between AWS and corporate IT, and the client tech group should pick the best service provider for their needs.
3. The ultimate result of #2 harsh but true: if the client tech groups predominantly prefer AWS, the company should figure out how to satisfy their clients better or get out of the business of corporate IT. That is, you’ll find out very soon which of your technical projects have value and which don’t.  And I bet most of them will end up going away.

We had some general, unstated criteria that guided us:

• Community is incredibly important: In most cases, use what most other companies are using because you know it’ll be around, and there will be people out there to help you.
• Be cheap, but not too cheap: We have to run a tight ship, but where it helps productivity, pay for it.
• Lean towards what you know: We have to focus on the business, not on learning the tools.
• Cloud, when you can: It might be cheaper to host things yourself, but we don’t want to be IT guys and we want to work on the fly from any computer.
• Don’t waste too much time thinking about it: Just do it. Sometimes, you gotta just go.

1. “I just found out that Apple/Google/NewShinyStartup.com is already doing that; we can’t do that.”
   Everyone in the valley says this so often, it’s completely trite, but it still catches people all the time: ideas are pretty much worthless.  It doesn’t matter if someone else has already done it or is about to do it; if you think you can do it better, it’s still a good idea.And doing something better doesn’t necessarily mean that the product is better. You just have to believe that you can beat the competition in one business dimension: product (Apple), price (Walmart), marketing (Coca Cola), service (Zappos), etc.  If you can beat the competition in a business dimension that matters for your chosen product/service, then you’ve got something.Then there’s the flip side to this…
2.  ”NewShinyStartup.com and AnotherStartup.com are doing something like this. This validates the space.”
   Startups are a dime a dozen; they’re falling out of trees, coming up from storm drains, like zombies that you can’t shoot in the head.  And like zombies, they take up all available space, even it doesn’t make any sense. You don’t need me to rattle off hot-to-trot startups that claimed to find a new market only to run out of money in months.You need to do enough research to believe that your market exists and is big. That research might include other competitors in the space, but that is only one factor. Those competitors may be on to something or just may be smoking something…
3. “We’ve come up with this cool new technology/design/product that does ____.”
   This one’s a bit tricky because that statement sounds pretty good on its own. That is, until you realize that you haven’t said that your market actually needs or wants to do _____. This is the trap of coming up with a solution that’s looking for a problem, and many, many, many companies with really smart designers/engineers/business people failed here.Remember all of those browsers that showed your search results in a mind map you could fly through? Cool demo, didn’t solve a problem. And my latest predictions on failure on this one? Latest Techcrunch Disrupt winner Shaker. But I could be totally wrong: I didn’t think Twitter solved any problems either.
4. “You know what (insert major product/service here) needs? A better way to do ____.”
   This one’s also tricky, because what you may have discovered is an opportunity to disrupt a major player. Or you may have discovered a missing feature, not a product. It’s happened so many times: a better way to organize your contacts, absorbed into your email service; a better way to backup your computer, absorbed into your OS.My latest prediction on failure here? Lytro.  Very cool, but are you going to buy a camera from an otherwise unknown camera maker because of it?
5.  ”Our product will post to the user’s wall/tweet something out on the user’s Twitter account every time they finish a task and then all their friends will try it!”
   Just read that again. Now with feeling. Realize how silly it sounds. Move on.
6. “We just have to get the product right, and it’ll take off!”
   A lot of companies, big and small, have somehow developed a build-it-and-they-will-come attitude. Homestead had a lot of that problem early on. I saw many examples of that at Intuit. We want to be product companies, and we want to believe that in the end, the best product (design and technology) wins.This thinking often sneaks up on you because you don’t think you’re that naive. But watch out for signs: if your growth plan is based mostly on word-of-mouth, you might be headed for trouble. If you’re focusing almost all your energy on net promoter scores and user surveys, you may not grow at all.So come up with a launch plan and a growth plan. And, please, “marketing” isn’t a bad word. And that’s coming from a CTO.
7. “We’ve got a patent on it.”
   Can you tell I have issues with patents?

While throwing around ideas in an early stage, you have to remind yourself to assume a few things:

1. If you can imagine an interface for it, it can be built.
   OK, maybe we haven’t figured out teleportation yet, but in general, this is a great thing to remind yourself when your team starts spiraling into technical details.
2. Disk space is infinite and free.
   Also not entirely true, but close enough to true and heading that way.
3. Bandwidth is infinite and free.
   Like disk space, not entirely true, but it’s close enough for brainstorming purposes. I should add, though, that this is a good assumption for your online business, though not necessarily for your users, especially if your product/service is to be used on a mobile device.

   You may think that disk space and bandwidth isn’t free for little startups with no money. Even if it isn’t for you, it will be essentially free for your competitors. I can guarantee you Google and Facebook don’t think about those limitations.

4. Patent? What patent?
   Obviously, don’t dump an idea because someone else has a patent on something similar. Note I said “patent” and not “copyright”. If your idea is based on plastering Mickey Mouses all over the place, good luck with that one.
5. Consumers don’t worry about security too much.
   Unless your idea is specifically about security, I wouldn’t worry about users’ apprehensions about security. Mint.com got millions of people to give them their most sensitive credentials (financials) and weren’t backed by a big behemoth with a strong security reputation. People will give you whatever information you want, as long as they see value in your product and you look trustworthy.
6. You can get more investment than you think.
   The VCs aren’t going to throw money at anything, but they all want to find the next big thing. If they put $100K into your company, and you get acquired for $10M, they’ll be happy for you, but they’re not going to do any backflips. They’re dying to put in $100M and you getting acquired/IPOing for $10B. You just have to give them a reason to do it.
7. Think bigger.
   That all leads to the most obvious, but still understated point. Think (realistically) bigger.

One popular topic was the IE6 problem; i.e., how do we get users off IE6 onto a more modern browser with more capabilities?

Douglas Crockford of Yahoo! had the soundbite quote of the panel: “The problem is that web developers are doing a good job supporting these bastards.” (I’m paraphrasing.)

He (and pretty much the rest of the panel) put the onus of getting users to upgrade on the web developers. Web developers need to force users to upgrade by serving error pages driving them to upgrade before they can use the site. He even suggested that the web developers of major sites agree to do it all on the same day to mitigate the business damage of doing it.

Unfortunately, to me, all this smacks of “we know what’s best for you, so do what we want”. In his suggestion of a simultaneous launch of IE6 blocks, Doug is really just admitting that the natural reaction of users would be to go to another site.

Similarly, isn’t the fact that users are still on IE6 stem from the fact that the browser fundamentally does what the users, the web developers of the sites they visit, and (in corporate settings) their IT managers want? It may be an old browser with limitations but it has enough capabilities and work arounds that the modern web delivers some great experiences on it.

The onus is on the web developers to solve the IE6 problem, but not to decide to block IE6. The onus is on web developers to come up with the killer app/experience that compels them to upgrade that can’t be implemented in IE6. Until that happens, we’ll have to wait through the slow progress of upgrades we curretly have.

In the keynote he gave at Web 2.0 Expo yesterday, he added something I don’t remember seeing the first time. He said the goal is to minimize the total time for one “pivot” cycle.

The important thing is the definition of a “pivot”. Paraphrasing and interpreting, a pivot here is a change in direction caused by something you’ve learned about your business, be it your market, product, customer, whatever. And there are three steps in the cycle: build (the product), measure (the result), and learn (the reasons behind the result).

This helps illustrate the problem I’ve experienced in a large company. Minimizing time through this loop requires cross functional thinking and objectives that is ubiquitous in startups but is disappointingly rare in larger corporations where employees tend to be over-specialized.

For instance, at Intuit, there is a lot of focus in the engineering community around faster build and launch cycles. It’s all about continuous deployment, unit testing, server virtualization, etc. All good stuff, but it’s all focused on pure product cycles and not business cycles. Tracking is an afterthought.

For many designers and engineers, there’s a mental milestone (and thus, relief) when the product/version/build launches. The real milestone for the business (and so it should be as well for all employees) is when we’ve learned what we need to learn and made the right business decision on the next step.

We’re getting better. Tracking and data are beginning to play a larger role, and business interests are creeping their way into product conversations (“No!!!”). The key for any org, large or small, in minimizing the time through the loop is focusing all employees on the higher level business objective and Eric’s framework is a great way to have that conversation.

“Apple’s problem is not that what we do doesn’t work; their problem is that it does work. You can create an app that works across many devices. And they don’t like that.”

A lot of the advice is stuff we’ve all heard before: make sure you have a great product, test a lot, get user feedback, create scarcity to build buzz, be responsive and bold, focus on doing the critical few really, really well.  Even if that advice has been beaten to death, I still find startup success stories inspiring.

One thing that caught my attention was an almost throw-away statement that Adam (I think it was him) made at the end.  He said that users they acquired through PPC didn’t convert to paying at a very high rate, but they tended to refer a lot of customers who did.  He also mentioned that Zynga measures referrals through Facebook as well.  The interesting thing is not that the referrals happen, but that they measure it and account for it in the ROI analysis of their marketing campaigns.

I might be reading into his really brief comment, but if it’s true, that’s definitely an area where I could learn a lot more.

At Homestead and mostly at Intuit, we only do the first level accounting in measuring the ROI of campaigns. That is, we count the number of users who are directly attributable to the campaign.  It’s definitely easier measuring users by their propensity to sign up/purchase than measuring users by their propensity to refer others.  All referred sign ups are really just considered gravy. This first level of ROI accounting has been really successful for us as it still continues to scale.  But the question remains: are we leaving money on the table?

There are a lot of questions in the details of how you’d go about doing this “second level accounting”:

• What are the best ways to track a second level user back to the referring user and then back to the originating lead gen source?
• Assuming we would track using links of some sort, should we try to account for “offline” referrals (using untracked links)?
• What is a reasonable time frame to count the referrals from a first level user?
• Does a first level user get any credit for third level signups?
• Do you account for the speed of the referral?  For instance, you could credit the first level user with all $ collected from the second level user within 12 months of the first level user’s signup, thus rewarding those who refer faster.

I’m sure there’s more.

If we can figure this out with any reasonable amount of accuracy, this could significantly change the economics of how we do acquisition marketing right now.

My take?  It was too high-level for me and didn’t really get into a lot of details.  Maybe I’ve been living in the world of web and business analytics too much but there really wasn’t much new or ground-breaking here.  But there were some interesting points.

For example: the primary point that Sean kept referring to all day was that you should know your business goals before you embark on any social campaign, so you know what to measure and whether or not you’re succeeding.  Seems obvious and, well, is obvious.  Ryan Kuder, one of the panelists who was recently laid off from his company due to an acquisition (awkward!) harped on that point, too.  This sounds like the gripes from marketers who are asked to do work because some exec thinks it’s interesting instead of knowing why it’s important.  I feel your pain; I know I feel it all the time.  But unfortunately, that doesn’t make for an interesting presentation about communilytics.  That’s really just Project Management 101: be very clear about your goal.

In the defense of the presenters, I think they really did know what they were talking about and if I had a particular question, I think they’d be great resources.  Which leads me to believe that the lack of detail in the presentation stems from one of two things:

1. It’s difficult to create a detailed presentation with truly actionable ideas in this area for this broad of a group.
2. Communilytics really is just a flavor of web/business analytics and there really is no other special sauce.  Know your goals, translate to KPIs, and you’re off to the races.

So which do I think it is?  At the end of the day, we joined with the Lean Startup Intensive by Eric Ries.  At the end of that session, Eric said that those of us in attendance were at the cutting edge of this stuff, the earliest adopters, the trail blazers.  If that’s true, then it’s #2.  And I tend to agree.

Here at Intuit, it really doesn’t feel like we’re doing anything that cutting edge in tracking or measuring our social efforts, but Kira Wampler  told me that everyone told her that we were cutting edge, too.  Maybe I’ve been living and breathing analytics and optimization so much that I’ve lost sight of that.

I’ll just spew out my other observations… uh… now:

• Referring URLs are useless (or becoming more useless) as people follow links found in apps (like desktop/phone Twitter apps).
• Alistair and Sean defined your message as becoming “viral” when the average number of people who repeat/amplify/retweet your message is > 1.  Maybe not a new definition, but I hadn’t heard it before.
• A lot rides on your ability to get your followers/fans/users to “retweet” or otherwise amplify your message (in Facebook, would that be “like”?).  So watch and track that carefully; learn from what does and doesn’t trigger a retweet from your base.
• Successful social campaigns are not about me (the company) or you (the user) but about something else. Get the user into a safe conversation where they don’t feel they owe you anything in return (money, time, etc.). Not terribly new, but illustrated amusingly by Alistair with a story about picking up women in Las Vegas.
• Tactic: send meeting requests to bloggers to get on their calendars. Makes sense to me; that’s how to make sure I do something too!
• You can’t really A/B test Twitter messages (it’s a broadcast medium so everyone gets it). One alternative: use PPC ad copy and measure click-through rate to test your message if you really want to.  Or as Hiten Shah from Kiss Metrics suggested, just send it out and apologize if it bombs.
• Alistair predicted that we’ll go from a PPC to a PPA (acquisition) to a PP-change-of-opinion model.  That is, as social sites get better at measuring your brand value on their network, they could charge you based on that increase, not just per impression, click, or acquisition.  Interesting to consider.
• And the people who impressed me were the presenters, Alistair Croll and Sean Powell, as well as Hiten Shah, Erin Hunter, and Dave McClure.

And that’s it!  Looking forward to tomorrow!