Why I Love Talking With Customers

“This has been an easy process and it’s been a pleasure working with you. I will recommend Speechpad to my other colleagues.”

I admit it. I love getting this kind of feedback. It’s a great feeling knowing we made a customer happy–especially since we get a lot of new business via referrals. And it doesn’t hurt that it helps keep us on track to 400% revenue growth this year.

Many of our customers go to Speechpad.com, sign up, enter their credit card info and get great, high quality transcriptions back.

But there are also those customers who want to talk to us on the phone. They have larger orders, special requirements, or just want to speak with someone about their specific needs. Our account managers will often refer a customer to me in these cases.

Talking with these customers is awesome. Simply put, there is nothing like direct customer interaction. And in the transcription business, time matters — a lot. Customers want to see that we’re responsive, and most already have a well-defined need. They’re ready to buy. They want responsive answers to their questions, a process that’s easy, and fast turnaround.

Friday evening I got just such a message. We had a potential customer with 25 one-hour interviews who wanted to talk to us on the phone.  I called this customer myself. She uploaded her first file for transcription as a test and by this morning we had the transcription turned around and delivered to her. She’s now uploading the rest of her files.

Calling this customer ASAP not only made the customer happy–it also gave me insight into questions she had that were not answered by our web site. And it helped me understand her use case in detail so we can continue to expand the market. If you’re not already talking with your customers and users — whether via email or on the phone — I highly recommend it. There’s just nothing else like a happy customer.

Why Video Transcription Is White Hot

Steven Levy’s article today, Living on a Stream: The Rise of Real-Time Video reminded me of a post I’ve been meaning to write about Speechpad.

Speechpad turns audio and video into text. If you’ve ever gotten a crappy (or funny) voicemail transcription, you know just how far machines still have to go till they’ll be able to transcribe as well as humans.

In fact, better voicemail transcription was one of the original reasons for Speechpad. We knew the existing transcription market was a big one, measured in tens of billions of dollars. Speechpad serves companies large and small in verticals such as recorded statement transcription (for the insurance industry), business meetings, and legal recordings (depositions, trial recordings, and the like).

Speechpad got into these large, established markets by offering a product that is better/faster/cheaper. Speechpad uses a unique and  proprietary workflow model, which, combined with our web site, means Speechpad is easier to use, provides faster turnaround times, and is cheaper than most other offerings, while delivering very high quality transcriptions.

Yet one of the largest and most exciting areas of growth has come in a relatively new market–video transcription. It’s what’s causing the company to go into hyper-growth mode, on track to 4X revenue this year. It’s because, as Levy describes it in his article, we’re seeing an “explosion of video.”

Hollywood production companies have been getting video transcribed for years. They need it for pre-production of movies. Movie and TV producers need transcription post-production for closed captioning. That was a big market, and one that we serve, but still a relatively niche one.

What really accelerated our growth is the broad use of video transcription for online search combined with the ability to create that video and get it online more easily than ever before.

As anyone who’s done Internet marketing knows, content is a must-have. The challenge with video, though, is that in its native form, it’s not searchable, not indexable by the search engines. What’s more, users have to invest the time to watch entire videos when they really just want to find the key content they care about. And in the past, producers have had to wrestle with high costs of video production.

But with smart phone growth outpacing regular phone growth, tens of millions of people now have easy access to a hand-held video recording device–their phone. And thousands of web sites are using these devices and others to record marketing videos, interviews, product reviews, and lots of other content. They’re then using Speechpad to turn that video into high-quality text.

That text is useful to their customers–they can read it. It’s also great for the search engines, which can now index and search the videos.

Can’t you use machines for that? We’ve tried. And they do a great job getting 75% or 80% of the transcription right. But when it comes to delivering high quality, readable text that has the full meaning of what was said–humans are still the only way. That’s why video transcription is white hot.

The Magic of a Y Combinator Pitch

For the past while now, I’ve been advising the founders of SendHub. Before Ash and his cofounders got into YC, we’d get together and work through various ideas. We’d talk about fund raising, about applying to YC, about how to go big. I remember going through the team’s very first slide deck and helping them rework it into a fund raising pitch as they started approaching investors.

Today I got a preview of the pitch the team will be doing on Demo Day. All I can say is–wow! If you’re out raising money, or thinking about it, there’s a lot you can learn from a YC pitch. I’ve been to a bunch of Demo Days, but it’s a real eye opener seeing a team evolve from way before YC, through YC, to Demo Day.

Here are some key takeaways:

1. You can convey a lot in two minutes. I’d say the team’s pitch provides a lot clearer picture of the market, the team, and why SendHub is going to be big than dozens of other pitches I’ve seen that have been much longer. Think about what you would say if you only had two minutes — literally two minutes. And then try it. Have someone cut you off after two minutes. And then do it again until you can give your pitch in two minutes.

As the old saying goes, “if I had more time, I would have written you a shorter letter.” Get your pitch down to two minutes, then expand. You can always say more, but it’s hard to say less.

2. Pacing. The pacing of the pitch is fantastic. There’s a certain rhythm that comes with a YC pitch, a certain flow. Every sentence, every phrase counts. There’s a pause after each slide so the presenter can breathe and so you can digest the info. It provides a level of familiarity and comfort that many pitches try but fail to achieve.

3. Content. The deck is short and sweet. Each slide has a few words and a graphic or two. It reflects a powerful piece of advice I got before I gave my first presentation to Bill Gates, Steve Ballmer, and the exec team at Microsoft.

I was 23 or 24. I had prepped and prepped. Cut it down to seven or eight slides someone said. Keep it simple. A few words, a few graphics, and then the decision. That’s it. At the time, I couldn’t believe it. How could I present something so short? The advice is as valid and powerful today as it was then. Cut to the chase. If they want more detail–they’ll ask.

But the real transformation isn’t in the deck or the pitch itself. It’s in the team. It’s incredible to see a team I’ve been advising for months turn into a well-oiled machine. Their pitch isn’t just a pitch – it really reflects how far they’ve come and how capable they are of going after a very large opportunity.

What really shines through is the team’s story and their ability to tell it. The story of seeing a huge unfilled need and filling it and the story of why they are the right team to back.

If you’ve never seen a YC pitch, find a way to see one, or a few dozen. It’ll change the way you pitch your story for ever.

Seven Ways To Hire A Great Product Team

I’ve started six companies and sold three of them (this just published: EMC Acquires Storage Software Partner Likewise). I’ve been developing software since age 12. Building great product teams has become second nature to me. So when a friend of mine yesterday at Facebook and another friend last week at Salesforce asked me how I put teams together, I had to think hard about the answer.

A crucial topic in these times of highly competitive technical hiring, that answer merits a full blog post.

1. Embrace a distributed workforce. The short version is that I don’t build 100% local teams. In fact, I’m currently building one product completely outside the bay area—way outside. “How do you find developers in the Ukraine?” my friends at Salesforce and Facebook both asked me. I’ll answer that question in detail, below.

For another product, the core team is local but certain parts of the system are built elsewhere – we have a fantastic developer in Syracuse, NY for example.

There simply isn’t enough software engineering talent in the bay area, regardless of whether you’re starting a new company, scaling up, or trying to build out a product team at an established leader like Facebook, Google, or Salesforce.

The other question I often get asked is, “would the development team move here?” In January, it was 68 and sunny in San Francisco. In the Ukraine, it was a good forty some degrees colder. Weather isn’t everything. Proximity to some of the world’s hottest tech companies is another big attraction, of course.

2. Get critical mass. There is a big advantage to having everyone in the same place. So when it comes to distributed teams, the same rule applies—put together an entire team in one place.

For my engineers in the Ukraine, I have two teams of developers, one team of four and another team of two. We sync up frequently over e-mail and IM. The developers then work closely together hour to hour and day to day. When they get stuck, they help each other out. And they have a team so they’re not working in isolation.

How I work with the individual developers depends on the specifics of the team. From a strategic perspective, I set the priorities, design the product, and specify the roadmap—and you should too.

From a tactical perspective, for the two person team, I have a development lead who writes code and who manages the other developer. For the four person team, I have a senior architect who does the database and system design. The three other developers work for me directly.

I often try to hire people that have worked together before. This isn’t easy, but it’s amazingly effective when I can do it. First, a great developer tends to work with other great developers. Second, they already know how to work with each other, so they have good chemistry. Third, it’s a lot faster than trying to find people one at a time.

3. Hire a great architect and a great designer. For a system and team of any significant size and scale, an architect is critical to ensure design consistency, scalability, and that seemingly simple things like—where and how does data get stored—are done in the right way.

Databases have a funny way of growing out of control. Another table here, another table there, and before you know it you have lots of inconsistent tables and no idea how they all work together.

The same thing happens with code. Say you’ve got a function for sharing a link to an image. It’s the same functionality all over the product, but without an architect and solid design guidelines and principles, that same functionality could be written a dozen different ways. That means when you want to improve the functionality a little bit, you have to change it in 12 different places—a nightmare.

A great architect ensures that this does not happen and lays out the coding principles, technologies, and guidelines the rest of the team needs to follow. He or she also thinks about the big picture—what does it take to scale the database and the system and how performance continuously improved so things are fast and users, as a result, have a great experience.

A great designer is just as critical. Great developers write great code. Just as the architect thinks about the product implementation as a whole, the designer thinks not just about individual icons but about the whole product design.

A great designer not only produces a design that wows your users due to its simplicity and intuitiveness, but also ensures consistency of icons, popups, fonts, colors, and the like across your whole product. That’s the difference between a product that feels like it has rough edges and one that feels clean and makes your users have that “wow” experience.

4. Focus on product. Problem is, I didn’t want to go out and raise $5M or $10M from the get-go. Having both boot-strapped and raised venture capital multiple times, I first wanted to spend some time in boot-strap mode, making the hard tradeoffs that entails. I wanted to get back to product. I wanted to make users really happy before I poured the gas on user acquisition, hiring, and scale.

Now don’t get me wrong. When it comes to starting a company, having millions of dollars in the bank is really nice. It’s comforting. You can hire a lot faster and you can pay yourself and other people. But as I wrote about in my book Why Startups Fail: And How Yours Can Succeed, raising too much money too early can all too often be a recipe for disaster.

A lot of the bad distributed team experiences I hear about are because people assumed the product would turn out the way they wanted. Building product requires day to day if not hour to hour participation in and leadership of the product. It means testing out the site yourself to make sure everything works, not just assuming that it does.

5. Start with a product background. People who tell horror stories of working with remote or offshore development teams all too often don’t come from product or technical backgrounds. They have no idea how to design and build product, manage developers, or prioritize features. They end up hiring poor engineering talent, getting poor product, and having a miserable experience as a result.

Remote, distributed, and off-shore development teams can work amazingly well, but you have to have the skillset and knowledge to manage them effectively. If you don’t, team up with someone who does. Or go spend a year or two working on a product somewhere else. Learn the ropes. Then build your own.

6. Hire on performance. When I tell some people that some of my best developers and managers are people I’ve never met in person, only talked to on the phone, on Skype, or over email and IM, they are amazed. They ask me questions like, “How can you trust those people?” “How do you know they do good work?” Or they just look at me with wide eyes that say, “Seriously?”

At one of my companies, Speechpad, the leader in crowd-sourced audio/video transcription, we’re creating work for thousands of people around the country. While we’ve never met many of these people in person, they’re some of the hardest working, easy to manage, and most communicative people I’ve ever worked with. Some of our best transcribers have become transcription managers and account managers. Rather than having to evaluate them based on a job interview or a resume, we can evaluate them based on their performance, on the quality of their work over time.

When it comes to software engineering, I’ve experienced a similar phenomenon. Not every hire I make works out. In fact, I fully expect that many will not work out and am pleasantly surprised when they do. I have new developers work on well-contained parts of the product until they prove themselves.

At media hub Onepo.st, I look for developers who:

- Write lean code

- Write code fast

- Produce code that’s maintainable

- Work well in a team

- Think about scale

- Can communicate

Developers who write great code consistently I have work on the core product. They take on larger and larger ownership. And, of course, I get a feel for who is good at what. One person excels at user interface while another person excels at database and scalability. That helps determine who I assign to work on what.

Unlike companies that have to hire purely on job interviews, I don’t. Because I look for engineers that have worked together in the past, and I evaluate new engineers through their actual performance, I have a much better sense of performance than a job interview or a coding problem can provide.

7. Leverage online marketplaces to discover undiscovered talent. Great developers are hard to find anywhere. But Internet marketplaces are changing the nature of work. Marketplaces like Amazon Mechnical Turk and oDesk, while very different in the nature of the work they support, provide an incredible avenue for discovering undiscovered sources of talent.

Finding great talent isn’t always about going to where the obvious talent already is—Silicon Valley. In today’s world, it’s just as much about finding great pockets of undiscovered talent and then forming that talent into virtual or real-world teams. And in some cases, it means relocating those teams to the Valley once they are built.

Building great teams is hard to do. Over the years, I’ve found lots of great individual contributors. But putting together a team remotely takes a certain amount of patience, skill, and luck.

There are three keys to keeping distributed teams (or any team) engaged:

- Build up a long-term relationship with engineers and designers over a period of time. That creates trust and chemistry. That chemistry is key to nimble and efficient product development. Frequent two-way communication over IM, email, and sometimes Skype, is critical.

- Provide steady work. Always be ahead of the curve on feedback and new work items; don’t let things linger. Pay on time.

- Provide interesting work. If the work you have is mundane, that is fine for a while, and a part of every product development cycle at some point. But the most talented engineers want to work on products and technologies that are current and interesting. Make sure yours is.

As always, if you want to talk further about building distributed teams—or building product teams in general—please drop me a line.

Seven Ways You Can Be Drawsome

There’s a lot to be learned from Draw Something, the simple but fantastic mobile game that’s making hundreds of thousands of dollars a day. And yes, I did just include the word Drawsome in the title of a blog post. But hey, you’re reading it.

1. It’s viral. You play the game with other people, friends you know, or random players.

2. The content (drawings) is user-generated, so production costs (other than supporting multiple mobile platforms) are low.

3. It takes something social that people did offline (Pictionary), combines it with Words with Friends, and voila – a fun game that combines words and pictures.

4. It’s fun! The game is easy to learn and easy to play. Games are quick and two-sided. You’re either drawing or guessing. It’s creative.

5. Simple yet great gaming dynamics. Simple graphics and sounds that are well done. The quick dopamine hit of solving the puzzle, combined with seeing coins on screen.

6. It takes advantage of the capabilities of your mobile device, that is, the touch-screen. There were lots of drawing apps for the iPhone and Android, but none turned drawing into a game the way Draw Something has.

7.  It makes money by charging for the app and by letting users buy items in the game – color packs and other items.

And, of course, it has a nice, self-explanatory name — Draw Something. It’s simple, catchy, and it’s already become its own word, Drawsome. As Draw Something shows, the best products, more often than not, come from focused, great ideas, really well executed.

BusinessInsider Covers My Book

Check out 13 Reasons Your Startup Will Fail and learn how to succeed on BusinessInsider!

The Dopamine Effect

Entrepreneurs spend a lot of time building great products. But in today’s competitive startup environment, it’s not enough just to build a great product. You have to build a product that keep users coming back to your site.

I met with an entrepreneur I advise and the question came up–how do we get users to keep coming back to a site?

The answer is dopamine. Dopamine is a chemical in the brain that is associated with rewards. You get a little dopamine rush when you click on the coins in a Zynga game. You get it when you see a news item on Facebook. And, as recent studies have shown, when you tweet.

So the key to getting users to come back to your site is figuring out what is going to give your users the reward–the dopamine rush that will get them to come back to your site.

It could be seeing new faces, a numerical score that tells users how they’re doing relative to others, receiving more storage space for inviting new friends, or simply sending out a short message. The ideal action not only rewards the user’s behavior, it also encourages inviting more people to the site. That creates a network effect.

When it comes to raising money, investors care less about what causes the dopamine rush. They just want to know that you’ve cracked the code on what causes it. Because if you’ve done that, you’ll have millions of users engaging with your site–and millions of dollars wanting to get into your deal.

Your Acquisition Signature

I was speaking with a Product Manager at a large tech company today. He’s looking for small, local development teams he can plug into his existing projects/teams. In talking about potential acquisitions, he described what he called the acquisition “signature.”

The term signature is an excellent way to characterize how to think about acquisitions, if you are considering being bought.

While a startup, in its early days, is trying a hundred mini-experiments to see what works and what doesn’t, big companies have multi-year plans they’re executing on. They have annual planning and budgeting sessions that require lengthy preparation, lots of slide decks, and no end of meetings.

One big company exec once said to me, “year end is a terrible time at [his company], the budgeting spreadsheets are flying everywhere!” But the planning, budgeting, and roadmapping exercises also give big company execs excellent visibility into what they want to acquire.

The characteristics of a potential acquisition can be summed up as the “signature.” The signature defines the key characteristics the company is looking to purchase: a team, a technology, or revenue.

Revenue acquisitions are a non-organic way for a big company to increase revenue. The company needs to augment the growth it’s getting through its own marketing and sales efforts. One way to do that is to buy revenue through an acquisition.

Technology acquisitions provide big companies with key intellectual property or technology that they can’t build or that they need to build faster than they are. Perhaps a competitor is beating them on a particular feature and they need that feature fast to stay competitive.

Finally, team acquisitions provide a way to hire a fully built out team without having to recruit the individuals one at a time.

Regardless of which one you are, figure out what signature your buyers are looking for and you’ll have a much easier time making your sale–and getting the price you want.

Hiring Criteria

Last week I got an email from an Interaction Designer at oDesk who wanted to meet with me to understand how oDesk “fits into my life.” oDesk describes itself as changing how the world works. It’s a marketplace for finding outsourced software developers, writers, video producers, and online marketers.

I’ve been using oDesk for product prototyping and software development, so I welcomed the opportunity to meet with the Interaction Designer—Larry—and talk about oDesk. I had some specific usability feedback about the site I wanted to provide. Give me easier access to the things I do regularly, for example. I was also curious to see what questions he would ask.

Larry recorded the interview and we transcribed it at Speechpad. Speechpad is a leader in crowd-sourced audio/video transcription.

Speechpad’s work model is a little different than oDesk’s. Whereas on oDesk buyers and contractors connect and then the buyers are responsible for working directly with the contractors, Speechpad uses a crowd-sourced workforce but takes responsibility for delivering the final product—a great transcription—to the customer.

During the interview, we covered a lot of ground, from how I use the site, to how I work on specific projects. When do I go back to the site? Would it make sense to integrate ticketing and communication tools like chat directly into oDesk or are there external tools that are sufficient?

At the end of the interview, we got to a discussion of how I go about hiring. What filters do I use? Ultimately it came down to one thing, for both Speechpad and oDesk. I’ve included an excerpt of the transcript here:

“We have an interesting thing in our business [Speechpad], which is we have really high-quality people who do great work and we rate them and check their work and lots of other stuff to QC their work but, ultimately, they care about the work that they do. They’re proud of the work they do.”

What do I filter on when I’m hiring, whether directly or through crowd-sourcing? People who are qualified to do the work, of course. But then what? People who don’t view their work as a transaction. People who care about their work.

My Love-Hate Relationship With Bill.com

And now for a few words on that most painful yet critical of startup topics, billing and payments!

Working on billing and payments feels incredibly far from strategic objectives like product and sales. It’s not something that differentiates one company from another. And yet it’s critical to the ongoing operations and success of a business.

Most recently, a company I’m closely involved with starting using Bill.com.

The company was really looking for was a simple way to pay everyone electronically, which seems straight-forward enough.

First up were the services offered by the bank. Everything had to be manually entered into the bank web site and then sync’d to QuickBooks. Plus, the mechanisms for synchronizing with QuickBooks required a download and… well, that was enough of that.

Soon came Bill.com. Here’s what I love:
- Signup is quick
- The site is fast
- Entering vendors is easy
- Vendors can enter their own info to get paid electronically

Here’s what I hate:
- No way to run payroll right from within Bill.com. This has to be done separately. No problem if you have hundreds of employees, but a real PITA if you only have a few.
- Signup is confusing for vendors because the site is terse on instructions and next steps.
- Roles are limited. Suppose I want to have someone enter bills to be paid, but not have visibility into other bills that have been paid. There’s no easy way to do that. And just finding where to setup new roles is hard to do.
- No easy import function. Can’t upload a CSV or Excel file with items to be paid.
- Every bill has to be entered manually. While a user can forward bills to the system via email, one can’t specify the amount due and have that automatically entered into Bill.com. So someone still has to enter the amounts.

Not really a Bill.com issue, but a more general one—the company still has to work with a number of different web sites and repositories to run the business—from the bank account to QuickBooks to Paypal to Bill.com. But it would be great if it all could just happen in one place.

I never thought I’d find myself writing a passionate blog post about invoicing and payments. But Bill.com is a big step in the right direction—I just hope the company will take a few more steps to make payments, invoicing and accounting much, much easier!