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.
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.
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.
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.
- November 2013
- October 2013
- September 2013
- April 2013
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- November 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- September 2010
- August 2010
- July 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- March 2009
- December 2008
- November 2008
- October 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- March 2006
- December 2005
- October 2005
- July 2005
- May 2005
- April 2005
- February 2005
- November 2004
- October 2004
- September 2004
- August 2004