Tag Archives: lessonslearned

4th Nov, 2010

3 comments

Experiments in Software Services

I want to build useful products. I’m glad I know that about myself. Some programmers want to solve hard problems. That’s not a priority for me. Some programmers want the internals of their code to be beautiful. I consider that just a means to an end. And some other programmers just want to be on the winning team, personal contribution be damned (BTW, the winning team often pays well).

For me, it’s the building of the product and the feedback of how and why it’s useful that matters. So, it’s odd to me that so much of my company, CrowdVine, is based on providing services for setting up, configuring, and customizing our software. That’s a little far afield of how I initially imagined the company and I wanted to talk about the good and the bad of building a services company.

What are services?
I used to think software companies that sold solutions were crooked. It turns out there’s not really anything wrong with offering a solution. It just means that you’re selling your time and know-how along with the software. Your time and know how is the service part.

For example, we get asked all sorts of detailed questions and since we have a lot of experience, we can give pretty good answers. For example, a conference might ask when they should launch our software and we’ll walk them through a decision tree, when will they hit 100 registrants, are they hoping for a marketing boost, how engaged do their attendees tend to be and then we’ll just give them our expert advice. Without that advice the conference would call a staff meeting filled with people who have no experience at all and try to reason it out on their own.

Or more concretely, a lot of people want to customize the CrowdVine design to look like their existing website. Sometimes this is as simple as uploading a logo and anyone can do it. A lot of times this means customizing CSS and requires someone who’s good with HTML, CSS, and a debugging tool like Firebug. Some of our customers have such a person. But even if they do, we have someone on staff who’s the world expert on customizing CrowdVine designs. That’s all he does. He can spot gotchas before he starts. He has a quality checklist for when he’s done. And he’s 3x faster than someone who’s trying it for the first time.

Those are good examples of services.

Bad examples of services are when your service covers up flaws in your software. For example, we use a simple but important recipe for how our software is launched. We can make sure almost all of our customers follow this recipe because we’re already talking to them. But being able to rely on that holds us back from developing an even more intuitive launch system.

There are simpler examples too, like our CSV importer which choked if the last line of the CSV was blank. That bug lived a long life because the only person who ever used the CSV importer was our account manager and she knew how to work around it.

Services guarantee customer development
Providing services puts you in a situation where you almost can’t help but be engaging in customer development. You’re constantly talking to customers and they’re expecting that when they ask for something you do it. This gives you very deep feedback because you can get your customer on the phone to talk for an hour about why something is working or not. It also means you’re often co-developing a feature with someone who you know will use it.

There’s a downside too. You’ll probably be too busy to engage in any build-it-and-then-they’ll-come development. But it’s very easy to fall into a trap where you build something that only gets used once. I suppose that’s learning in a way. If the feature didn’t set the world on fire with the first customer and later customers didn’t demand it, then it’s not a feature that warrants extra development. But I look at CrowdVine and see a lot of hidden features that look more like they need to be iterated rather than abandoned.

Bootstrapping
While getting a company off the ground, you can either dip into your savings, work a side job, take somebody else’s money, or build a services business on top of your first prototype. We did the latter.

It worked. People work for me. I took vacation this year. I have clean socks. However, I don’t drive a Tesla (yet) and I feel like purchasing an SSD for my laptop would be too luxurious. That’s my way of telling you how well, in dollar terms, it worked.

The first few gigs were extreme early adopters and it really didn’t matter much that the software was in such bad shape. One early reviewer said it looked like it had been built by a 12-year-old with a learning rails book. That definitely meets the definition of releasing while you’re still embarrassed by the product.

The downside to bootstrapping by selling services is that it’s hard to look too far ahead. How do you order your product development queue? By whatever feature will close the next deal. There are plenty of features that got promised before they were built.

Running sales
I’m a terrible sales person. I’m not great at the ask. Putting together supporting material triggers severe procrastination. I’ve never written down and rehearsed my demo or pitch. And yet, I’m the absolute best sales person in the world for the niche of software that CrowdVine provides.

The lean startup theories say that the founder should always be the first sales person. That’s scary if you think being the first salesperson requires traditional sales skills. Thankfully, founders get to use what I call the founder sales process.

Unlike your average sales person, a founder gets a ton of credibility for free. You’re an authority and can give a deep explanation on whatever the potential customer needs. You’re also naturally curious about what’s working and why, and that curiosity seems to give even more credibility to the times that you’re speaking authoritatively or debunking some crazy concern of theirs. So when I need to do a sales call, I just get on the phone and focus on being thoughtful. I um, ah, stutter, make a buzzing noise when I can’t think of the next word, cut people off, and yet…

It works. There were only two places where lack of sales skill hurt, neither fatal. One, there were plenty of times where I left money on the table or didn’t pair a concession with an ask. For example, I gave big discounts to an early customer because I needed reference customers. But then they didn’t launch. The second thing that was hard to understand was the importance of maintaining relationships. I lost an early customer to a new competitor because they had feature X. We’d had feature X for six months, but I didn’t know that it was even important to this customer. The whole decision to switch was made without me in the discussion, because I’d been ignoring the customer.

Doing the work
We’ve done two types of services work.

One is where the customer provides the idea. For example, a customer might come to us and say they want to build a social network for everyone who owns a cell phone (we turned away this client). They’re talking to us because we have social network software, but the actual implementation would probably include all sorts of client-defined customizations.

The other type of services is where we’re telling the customer what we’re going to do. For example, we provide social networks for conferences. We’re constantly testing and refining our process for doing this. We’re happy to take suggestions from our customers, but for the most part the work we do for one customer is the same as what we do for the next customer.

I greatly prefer the second type of services work. It has a much higher success rate. Success means more work from the customer, more word of mouth, and more job satisfaction. You can tell your customer with certainty that they will get good value for their money.

The first type of services work has a lot of launch risk in it. That guy who wanted to build a social network for cell phone owners got his idea while working in a cell phone kiosk. To put it mildly, he was not savvy. But he was opinionated. So that job would have been either saying yes and billing for work that was never going to work, or constantly fighting, saying no, and pushing our own ideas for what might work. If he’s reading this he’s going to be pissed that he never got me to sign an NDA.

The other nice thing about having similar services that you do repeatedly is that you can standardize them and delegate them to someone you hire. That’s what we do. I do the sales call, but then other people do all of the actual work of delivering on my promises.

Growing Sales Team
The standard approach for a services business is to start piling on sales and account management employees while taking a few dollars per head for yourself. This is where it gets gross. If you’ve read this far, you’ve seen some positives to offering services. But this path puts you up against a decision: do you want to be a product company or a services company. I want to be a product company.

So, I’m running an experiment to see if I can offer services without a sales team.

There are a couple of pieces to this. One, we have a product that does generate word of mouth sales. Two, we have a self-service option. Three, we just started listing the prices of our most expensive packages ($3000-8000).

What we’re trying to do is maximize the number of people who will be happy in self-service while cutting down the sales process for people who are going to purchase our services. With word-of-mouth, people are coming to us already convinced and with transparent pricing I’ve removed most of the negotiation. So when we do get on the phone, we’re mostly talking logistics.

The transparent pricing part is the most new and I’m curious to see how it turns out.

We do have competitors, but they must already know what we charge because they charge the exact same thing. Maybe having our prices public will let them underbid us or contact all of our existing customers with lower bids. But they can already do that and don’t.

I’m a little bit worried about having a price war, although not for the reason you probably suspect. I’ve paired my prices with some consideration for margins and I’ve been trying to take as much cost out of the sales process as possible. If somebody merely drops prices without also keeping their costs in line, then they’re going to go out of business. I used to want (and briefly had) 100% of this niche market. But then I realized that nobody will take this niche seriously if there are no alternatives. It’s much better to be the best of four options than it is to be the only option. We already had one really visible implosion and the founders wrote a post-mortem giving a lot of the blame to the product category.

Another thing I’m wondering is if public prices are beneficial to marketing agencies who want to sell their own support services on top of our self-service software. We do talk to some people who seem incredibly suspicious when I tell them they could charge their client thousands of dollars. We also work with some agencies where our public prices may be exposing an outrageous amount of markup on their part.

When do you stop offering services?
The standard business advice is to try to run as focused of a company as possible. So if the self-service side is huge, then the services side has to go. Except, I don’t want to do that. I like having a few deeper relationships with customers. I like my services team. I like that if a customer gets in a bind, we can get them out. That makes us a lot smarter about our product. It also makes us a lot more valuable to customers–think about how scary it is when some key Google service dies on you and you realize you have absolutely nobody to turn to.

I feel like such a rube whenever I come up against this type of decision where it’s “standard practice for maximizing shareholder value” versus “feels like the right thing for my customers” and I choose “do the right thing.” But then I think of Matt Mullenweg and how he breaks all sorts of rules like having a company where most people work remotely or pairing support services with WordPress. They seem to be doing ok.

So that’s my answer. If you like providing services, then never shut it down. There always seems to be people who really want them. If you hate services and feel like they get in the way, then obviously, shut them down as soon as it’s financially feasible (or start raising rates as a way of gradually shutting them down).

17th Jun, 2009

36 comments

The Real Lessons From Twitter

In 2006, I was the director of engineering at Odeo, a podcasting startup notable for birthing a side project now known as Twitter. My major contributions were doing the statistical analysis that showed that our podcasting work hadn’t amounted to a hill of beans* and then not complaining when our most reliable engineer wanted to work on a side project. Still, it was fascinating to be in the building during Twitter’s conception and then to read all of the ways that people misunderstood those early days.

Here are three lessons I learned from Twitter that nobody seems to have caught on to.

1. If people use it, it’s valuable
Have you ever looked at a piece of social software and thought, or worse, blogged, that it was worthless? Here’s a trick for evaluating social software in a way that isn’t going to make you look stupid six months down the road: assume it’s valuable if people are using it. Then try to figure out what value they’re getting.

Even professionals make the mistake of dismissing social software despite active, growing communities. Consider this early TechCrunch article, Dodgeball vs. Twitter, where the author (not Arrington) insists that the way to compare software is feature by feature. Dodgeball won the comparison but within a few months was in the deadpool and now Twitter is part of TechCrunch’s everyday coverage. Why? The features that mattered were defined by social interactions, and each user had their own customized set of features based on the social interactions that were important to them. Dodgeball had more features by the traditional measure, but Twitter had the kind that mattered, loads of social interaction.

I even find that this is a good reminder for myself. I follow a startup advice blog from Eric Ries, cofounder of IMVU. The first time I heard what IMVU did I thought it was laughably stupid. They make 3D chat rooms, (like a mini Second Life without the flying), and make money by selling virtual clothing for people’s avatars. Yet he is able to explain IMVU with a straight face and then seems genuinely surprised when people express skepticism.

Here’s the reason he can keep a straight face: IMVU gets 1.3M unique visitors a month and makes tens of millions of dollars per year. He’s not judging the idea based on opinion, which is where most people get into trouble, he’s judging based on observation. Now, I feel stupid for not keeping an open mind.

2. Product, Team, Market? Team.
This is a fun little debate, what matters most the product, the team, or the market? At the time that Evan bought Odeo back from the investors, our podcasting product was widely seen as a failure. It didn’t have any growth and it certainly didn’t make any money for the investors. Here’s how Bryce at OATV put it:

Rockstar team, smoking hot market, all-star angels — and it didn’t deliver the hyper growth traditional VCs need for their return profile.

Was it the product? A year after Ev bought Odeo back, and after zero updates to the features, Time Magazine listed Odeo as one of their top fifty websites. Today, with a very similar product, Odeo.com is the only podcast directory of note. So the product was fine.

Was it the market? Marc Andreessen argues that the market is the only thing that matters for a startup. I just made the argument that Odeo was a strong product and I’m going to argue below that we had a strong team. Since no other web based podcast directory has proven otherwise, it looks like we were in a weak market. So is the answer that the market matters most?

That would look like the answer if not for Twitter, that pesky side project we launched that has had 10x growth in the last year. Market only looks like a good answer if you’re judging individual products, in this case the odeo.com podcasting directory.

A good team, that listens to its customers, is going to find a good market and put together a good product for that market. Steve Blank calls this process customer development (explained well in his book Four Steps to the Epiphany and in this Venture Hacks post).

We could see that Odeo.com didn’t have enough traction so we went looking for other ideas. You might think it was lucky that we hit on Twitter, and as a specific product, it was. If Jack wasn’t on the team, there would be no Twitter. But the team at Odeo had lots of ideas and plenty of people capable of carrying them out. Of the 19 or so people who contributed to Odeo, 13 had started or went on to start a business or major open source project**.

If Ev hadn’t bet on Twitter he would have bet on something else. Three of the companies above are currently live companies that support their founders and a few employees (Infectious is funded and doing well, Trazzler is funded by the Facebook fund, and CrowdVine is profitable). I chose a vertical route for CrowdVine, but the original idea, social networks for everyone, is an idea that’s nearly as big as Twitter (as evidenced by the size of Ning).

Because of the team, Ev had other options to overcome a weak market. So if you’re looking at it from the perspective of the company, team is most important***.

3. Rails was never the problem
Twitter had well-documented performance problems in it’s first few years. Many people, including programmers, pointed the blame at one piece of Twitter’s architecture, Ruby on Rails.

First, all Rails does for Twitter is serve up web pages. The vast majority of those scaling problems came in the back end, moving status updates around and then storing them in a way that Rails could retrieve them for display. So most people aren’t even looking at the right piece of the architecture.

Today Twitter has a much better performance track record and it still uses Rails to serve web pages. The difference is the backend.

So if the backend was such a problem why didn’t Twitter launch with a better backend or at least get it fixed earlier? That gets at the heart of the problem. I’ve never heard anyone get the blame right for all of those performance problems. They stem 100% from the way that we went about switching from the Odeo product to the Twitter product.

When a company kicks off their first project they do some long term thinking and might cover topics like architecture. But how do you launch your second project? Or fifth (approximately what Twitter was)?

Was it easy for the Flickr team to choose to double down on photo sharing, which initially was just a feature inside of a web-based multi-player game? For us, it wasn’t an orderly process at all. It wasn’t even clear that we were abandoning Odeo. We were running hackathons, which led to a condition where many people had competing ideas (and implementations!) of what our next product should be. But around those hackathons we were still continuing to develop Odeo. Twitter eventually won enough that we pulled two engineers off of the Odeo team, but the rest of us kept plugging away.

If you were thrown into a fight, would you start punching or would you open up your iphone and start browsing web pages about Karate? I’d argue that Twitter was launched in the middle of a fight for what we were going to do next, and any thought for long range planning was completely secondary to getting Twitter launched and proven. Without Rails, we might not have even given Jack time to finish the prototype.

So that’s why Twitter wasn’t ready to scale from day one. However, it took almost two years until it could scale reliably, and that certainly seems like longer than necessary. I think it’s an issue of engineering management. Until the Summize acquisition, there was no true engineering manager for Twitter. I had left before Twitter was spun out****. Everyone was a little wary of hiring middle management again since it was widely seen that we had been hired too early at Odeo. The job of middle management is to promote forward progress, and it took us awhile to figure out that wasn’t what Odeo needed. Twitter did eventually hire a VP of Engineering, but he didn’t pan out.

The result was that Twitter operated for a long time (until Summize was acquired) with a gap in engineering planning, someone who could put together a plan that everyone understood and could work from. They had people who could solve problems in brilliant ways, but they didn’t have someone who could get the entire company on the same page. That gap was just an unfortunate side effect of the jumbled team that emerged post-Odeo. So what’s the right way to change your company’s direction? It certainly had nothing to do with Rails.

* Odeo was eventually acquired and is today the only podcast directory of note. However, as a venture backed concern all we had really managed to build was a site with high page rank. We had terrible numbers on repeat visitors and our experimental features (podcast studio, send me a message, audio commenting) weren’t getting any use. Maybe we could have gone after libsyn’s podcast hosting business, but overall our stats said that if we wanted to strike out in a new direction we shouldn’t feel constrained by podcasting.

** Those remaining six include a former core contributor to Rails, Twitter’s current support lead and people that worked for Apple, Google, and Flickr.

*** The idea that Twitter is the same company as Odeo gets muddied because Ev bought the company back, laid off a chunk of Odeo and reincorporated Twitter as it’s own company. But I’d argue the difference isn’t important here. Twitter was launched and run in the early years by Odeo employees who worked at the same desks and the same office that they had when they were working on odeo.com.

**** People often ask me if I regret leaving, and I don’t. I made a list of reasons that included several that would have been sufficient on their own. Did they need me? Not at first, and I hate being idle. Was I happy? No, I was miserable. Every month I had told my team that what we were going to work on was critically important. And every month it had ended up not being important. It taught me an important lesson about what I want from work, to walk in every day believing I’m doing something important. I ended up with the opinion that the only way I could guarantee that was by owning my own company, hence CrowdVine.