Case Scenario: DEVVER: HOW MISCUES IN REGARD TO THE COMPOSITION AND MANAGEMENT OF A NEW-VENTURE TEAM CAN KILL A START-UP
Devver (pronounced like "developer," not "devious") launched in 2008 to help software developers use cloud-based services to "test" their code in a more expedient manner than current practices. The firm started by focusing on Ruby on Rails software applications. one of its flagship products, Caliper, provided quality metrics to Ruby on Rails developers for their Ruby on Rails code. By using Caliper, a Ruby on Rails developer could quickly discover problems such as code duplication, complex code, and code "smells." In computer programming, a code smell is any symptom in the source code of a program that possibly indicates a deeper and potentially more serious problem. Dan Mayer and Ben Brinckerhoff are Devver's cofounders. The two met in high school and started a Web business before their high school graduations. Both studied computer programming in college, Mayer at the University of Colorado and Brinckerhoff at Washington University in St. louis. The two reunited in 2008 to launch Devver. They are graduates of TechStars, a Boulder, Colorado-based mentorship-driven seed stage investment fund. Devver operated from early 2008 until early 2010, when it went out of business. In announcing its plans to close, the company indicated that although it had worked hard to achieve its vision-to use the cloud to build tools that would change software developers' lives-it couldn't generate sufficient revenue to sustain and grow the company.
In a thoughtful blog post, Ben Brinckerhoff reflected on the reasons for Devver's failure. While the reasons were varied, the key reasons focused on the composition of the founding team, difficulties in communications, and product development. In regard to the founding team, both Mayer and Brinckerhoff thought of themselves as geeks. looking back, Brinckerhoff feels it would have been to their advantage to have had another co-founder who loved the business side of running a start-up. In reflecting on this observation, Mayer challenged the oft-repeated statement that "You can teach a hacker business, but you can't teach a businessman how to hack." This statement is sometimes used by technical founders to justify not needing a businessperson on the team. While Mayer acknowledges that it's possible to teach a hacker business, you can't force a hacker to get excited about it, or give it the proper amount of attention. According to Mayer, what hackers like to do is hack. So they measure progress in lines of code written or use a similar metric. It's equally important to have someone in a start-up measuring progress on business metrics-like number of customers talked to or how well distribution channels are being developed. Not enough of that happened at Devver.
In regard to communication, Devver embraced working remotely. The company started in Boulder, where the two co-founders worked together. Devver's first key hire worked in Pennsylvania, and Mayer later moved to Washington, D.C. The idea was that by embracing working remotely, Devver could hire the best talent available without requiring people to relocate to Colorado. In addition, they felt that by allowing team members to work remotely they would experience minimal distractions, which is important when it comes to effective code writing. Regrettably, achieving these objectives was more difficult than the founders anticipated. Communication was a challenge. It was also an administrative hassle. Mayer and Brinckerhoff found that it was a pain to manage payroll, benefits, and so forth in several states simultaneously. In addition, pair programming was difficult to do remotely-a challenge for which the Devver team never found a good solution. Finally, Brinckerhoff believes Devver should have spent more time on customer development and finding a minimum viable product.
A minimum viable product, which is a staple component of the lean start-up movement, has just those features that allow a product to be deployed, and no more. It's typically deployed to early adopters for testing. The idea is to avoid building bells and whistles into products that customers don't need or want. Instead of doing this, Devver did minimal testing of its first product, the Ruby test accelerator, and then focused intently on building out the product without additional interaction with potential users. As a result, its Ruby test acceleration and additional products never really met market needs before Devver ran out of steam. In retrospect, Brinckerhoff believes Devver should have deployed individual products sooner, and solicited more customer feedback about pricing, market size, and technical challenges. Eventually, they learned that their market was too small and their price point needed to be too low to sustain the company.
Questions for Critical Thinking
1. In retrospect, Brinckerhoff believes that it would have been to Devver's advantage to have had a business-oriented co-founder as part of Devver's new-venture team. Do you think the reverse is true? If two businesspeople are set to launch a technology-oriented firm, do you think it's to their advantage to have a technology-oriented co-founder, or is it sufficient to hire technology oriented personnel?
2. Make a list of the pluses and minuses of adopting a philosophy of allowing workers to work remotely. Is this philosophy better for some types of startups than others? What is your opinion of this philosophy?
3. The "You Be the VC 9.1" feature focuses on The Muse, a job board site that presents companies in a compelling manner, to make job listings interesting and to provide job seekers a better sense of how it would be to work for a particular company. What do you think a minimal viable product would have looked like for The Muse? How could The Muse have used the minimal viable product methodology to get user feed back about its site before committing substantial time and resources to building it out?
4. Do some Internet research to try to determine what Dan Mayer and Ben Brinckerhoff are doing today.