Building a successful startup is a combination of many factors. First and foremost, it requires an incredible amount of hard work and dedication. A startup simply cannot beat out a big company in a market if it is not working harder and working smarter than the big company. Secondly, it requires great timing. If the technology or the market that the business is relying on is simply not sophisticated enough, it will be near impossible for the company to succeed. Finally, it requires a deep understanding of the market, the product, and a thorough knowledge of which tactics worked for startups in the past and which did not. During this past semester, Kirill Klimuk and I have spent countless hours applying Lean Startup Methodologies to our startup, Campaign Compass.
Lean Startup Methods help bring structure to a chaotic startup environment. For a company to be successful, it must be building a sustainable business around a set of products or services. The central vehicle for figuring out whether customers actually want the product or service that is being built is the MVP, or Minimum Viable Product. The MVP allows startups to engage in validated learning, which results in data-driven company direction. Validated learning follows the infinite loop of “build, measure, learn,” to help a young company grow in the right direction. Focusing a young company on being data-driven instead of driven by assumption helps it grow smarter, faster, and with less capital (The Lean Startup Methodology). Eric Ries, a pioneer of the Lean Startup Movement, explains how “planning and forecasting are only accurate when based on a long, stable operating history and a relatively static environment” (Ries 9). Startups have neither a stable operating history nor a static environment. The Lean Startup methodology has flourished in very recent history because it does not make sense to apply classic business strategy to a startup.
Every startup must be built with driven, passionate people, or else it “is dead the day it opens its doors” (Blank 44). “The people leading almost every successful startup in history are just different. They’re a very tiny percentage of the world population, and their brains are wired for chaos, uncertainty, and blinding speed” (44). Kirill and I have an insatiable desire to change the world, and we believe that we can do it. Last summer, Kirill and I worked at startups or recently acquired startups, but we both felt that we did not have enough impact on the company as hired employees. We really wanted to be the drivers of change, not just the executors of our managers’ plans. Kirill and I find incredible satisfaction in building beautiful products that change lives, and we believe that we can do it.
At the start of the semester, Kirill and I were working on a startup called MailBadger. Essentially, MailBadger was a two-fold enterprise software solution. It helped companies automatically follow-up with their clients, and it displayed these results in a simple, user-friendly interface organized by client or by reminder. MailBadger was going to solve the problem of requiring employees to remind themselves to follow-up with their clients. Instead of reminding themselves to remind others, employees would simply set a reminder with MailBadger for their clients, and MailBadger would send an email reminder at the specified date and time.
Steve Blank, one of the leaders of the Lean Startup Movement, consistently stresses that young startups need to learn more about their customers and their market. Kirill and I did exactly that, and we talked to countless accountants, procurement professionals, and members of the executive team of Fortune 500 companies. The reason why the founders need to be the ones initially doing customer development is because it is much easier for the founder to pivot the product than a VP of sales or a VP of marketing to do that. It is more likely that the founder will simply think that the customer development team is not doing a good enough job selling the product instead of realizing that there are large flaws in the product (Blank Lecture 1.5). We realized that we were not the ideal team to enter this market, and we also learned that every team had vastly different feature set requirements.
One of our customer discussions was with a procurement professional at the Wall Street Firm, Jefferies & Company. Procurement is the division of a company that interfaces with all of the vendors that the company has relationships with. These vendors can be selling office supplies, raw materials, or general equipment. In a finance firm, they are not usually receiving raw materials, but they constantly are ordering office supplies, computers, printers, etc. When we talked to the procurement professional, he outlined a few specific places where a product like MailBadger could be helpful. One very specific place where he would have liked to use it is for vendor fulfillment. When a vendor sends a massive shipment of goods, there is no requirement on the vendor to verify that the goods have actually been delivered to the correct employee within the organization. Often, a few packages are misdelivered within an organization, and some of these misdelivered packages can mean hours or days of lost productivity for employees. The procurement professional suggested that MailBadger could be a simple way to follow up with an employee within an organization to make sure that a package has arrived. He also suggested that MailBadger could be used to follow up with vendors to make sure that ordered products have shipped. Sometimes, a vendor will only ship part of an order on a specific date, but will not tell procurement that some of the order will be delayed.
It was shocking to us that an employee is often not notified when packages that they have ordered are delayed. Initially, Kirill and I were excited about this market, but we quickly realized that larger companies already have software that mostly fits their needs, and smaller companies do not have much money to spend on procurement software. Building a product for medium sized companies with procurement needs just seemed like too small of a market to be excited about. Also, if we were helping procurement at Wall Street firms, we would have to comply with all of their communication and security regulations, which are very expensive and time intensive.
Another market that we were interested in was accounting, and specifically accountants that handle taxes. We talked to an experienced independent accountant and an accountant at Morrison, Brown, Argiz, and Farra, which is a large firm in Miami. Both of them echoed the organizational challenges of being an accountant. During tax season, it is very time-intensive to make sure that all of an accountant’s clients have sent the accountant all of the legal forms that the accountant needs to do the taxes. What often happens is that a secretary will keep a huge Excel document with client names on one axis and documents required on the other axis. Then, the secretary will mark off which clients have submitted which documents. When clients do not submit documents in a timely manner, the secretary has to constantly follow up until the client has sent all of the required documents.
Kirill and I saw accounting as a huge opportunity to digitize the receipt of documents and automate the following up with clients to send required documents. However, we realized very quickly that CPAs are slow to change, are not particularly skilled with technology, and value the personal connections that they have with their clients. Many accountants are Excel power users, and do not like using products that are not tied into Excel. Additionally, because many accounting firms are run by multiple partners, it can be difficult to get all of the partners to agree on a new technology product to implement throughout the company. Finally, many clients stay with accountants because of the personal connection that the clients have with their accountants. Some accountants saw MailBadger as a product that would make communication less personal, and could translate into lost clients at an accounting firm.
Talking to potential customers during the development process is critically important to building a successful startup. Before Lean Startup Methodologies were popularized, company building often took the “waterfall approach,” where executives or managers would write requirements of what the product should do, and then the engineering team would figure out how to implement those requirements. However, the central assumption in this kind of development is that on day one of building the product, the executive team and managers understand the customer problem precisely and know exactly what customers need. Building a product without extensive customer input more often than not results in a product that nobody or very few people want to buy. Steve Most companies go out of business, not because the company could not build the product, but because the company did not have enough paying customers (Blank Lecture 1).
For months, MailBadger was in the “analysis paralysis” (Ries 90) stage, where we were constantly talking to potential customers, but were not making any progress on building our company. Kirill and I would spend lots of time trying to figure out exactly what our customers wanted without iterating at all on the MVP that we had built. We were hearing many conflicting features that customers wanted, and could not find any feature sets that would be quick to build and test. During this period “talking to customers, reading research reports, and whiteboard strategizing are all equally unhelpful. The problem with most entrepreneurs’ plans is generally not that they don’t follow sound strategic principles but that the facts upon which they are based are wrong” (Ries 91). Unfortunately, these kinds of errors cannot be found by simply talking to customers and strategizing without building a product or iterating on a product; to truly do validated learning, a startup must continue building while learning about customers.
Kirill and I decided to pivot away from MailBadger because we simply could not find enough potential customers that wanted similar feature sets. We got the inspiration for our current company, Campaign Compass, from Mitt Romney’s failed “Project Orca.” Obama had real-time election day vote tracking software that helped Obama’s “get out the vote” operation. Romney tried, and failed, to build a platform that would rival Obama’s; unfortunately, Romney’s servers overloaded on election day. Kirill and I realized that if a presidential nominee did not have access to high quality software, then the software in lower levels of government must be terrible. From talking to politicians ranging from the Mayor of Chapel Hill to the Campaign Manager of Corey Booker’s Senatorial Campaign, we realized that too many down ticket races are not highly contested, but every campaign must deal with campaign compliance. We looked into the current software solutions for campaign compliance, and saw that there is a real need in the market.
Once the general idea of Campaign Compass was decided, we used Steve Blank’s Business Model Canvas to hash out our business plan and outline our assumptions. The Business Model Canvas is attached.
Our Value Proposition is significant. Accountants, who function as treasurers for campaigns, can have more clients by making their work more efficient, if they use Campaign Compass; the OCR technology speeds up their compliance time and makes manual data entry virtually nonexistent. Additionally, campaigns that use Campaign Compass are able to make informed decisions about where their money goes. Instead of filing non-electronically, campaigns that use our product can see exactly where their money goes and how their money comes in. Campaign Compass can also generate beautiful charts on the fly, so that campaigns can see trends in their contributions and expenditures very easily. Thirdly, counties and cities that use our platform are able to monitor campaigns in their jurisdiction more efficiently. Currently, most counties and cities do not have any software to manage their local candidates, and they must double enter all of the data that the politician entered into their databases, wasting lots of valuable time.
We have many potential customer segments. For the next few months, we will be going after city and county election boards. The overwhelming majority of cities and counties in California do not have software to manage the politicians in their jurisdiction; we see this as an enormous opportunity. Our biggest competitor, Netfile, charges cities and counties at least $10,000 per year. We plan on selling our higher-quality product for less, which will be more affordable to many more election boards. Later in the year, once California state politicians have formed their campaigns, we will try to sell them the campaign version of Campaign Compass. Ultimately, we plan on building out Campaign Compass for all fifty states, and selling the product to counties, cities, state politicians, national politicians, lobbyists, and nonprofits. We also hope to make inroads with the Democratic National Committee or the Republican National Committee, which would vastly speed up our sales cycle and increase our number of sales.
Our key resources and cost structure are related. OCR is a key component, or resource, of Campaign Compass, but will also be expensive. However, we see this cost being completely justifiable with our clients because it will save them incredible amounts of time. Heroku is also a key resource and a significant cost. Heroku is a cloud platform that makes it much simpler to use Amazon Web Services, a scalable hosting service. Using Amazon without Heroku is much cheaper, but also takes much more time to set up servers, security, and to maintain. Heroku is vastly simpler and has a nice interface to help users configure their servers. We believe that is absolutely necessary to have the highest level of security because we are storing very sensitive financial information. Some of the other resources that we provide are automatic PDF creation and simple configuration files, which we have built in-house. Some of our additional costs are Adobe Acrobat, which helps us configure PDFs, our time, and general living expenses. As Lean Startup Methods preach, “working in small batches ensures that a startup can minimize the expenditure of time, money, and effort that ultimately turns out to have been wasted” (Ries 188). We will be able to greatly reduce the amount of wasted code that we produce, and therefore we will be able to have more affordable products for our customers.
In addition to outlining our business plan, we also wrote down the assumptions we are making. One of our key assumptions is that customers will be willing to purchase Campaign Compass for close to the same price as Netfile, our biggest competitor. Another assumption is that politicians and election boards want the features that Netfile provides. A third assumption is that the software will require minimal training and minimal maintenance. If too much training or maintenance is required, it will be difficult for us to scale.
We hope that Campaign Compass will have the “last mover advantage,” just like Google had over Yahoo! or Facebook had over Myspace. Last Spring, Peter Thiel, one of the founders of PayPal, taught CS 183 at Stanford, which was essentially a class about how to build a startup. One of the students in the class took very thorough notes and put these notes on the internet. Thiel talks about the last mover advantage as the leverage that a latecomer company has in a market. These late movers will have had the time to fully understand the market, iterate faster in the market, and bring radically new ideas to the market (Thiel Lecture 4). One of the classic examples of this advantage is how Google changed Web Search. Initially, Yahoo! did search by making a directory of the internet, and users were only able to search pages in that directory. Google realized that search would be much more powerful if web crawlers could index the entire internet and use an algorithm, called PageRank, to rank the usefulness of websites. We think we can have an advantage over Netfile because we are building the product in an age of cheaper and higher quality technology than when Netfile build their platform. We are integrating OCR, or optical character recognition, into our product so that politicians do not need to waste countless hours typing expenditure and donation data into the computer. We are also building a flexible validation system that can validate whether expenditures or donations are compliant immediately after they are entered, saving politicians the time of reading 100 pages of campaign compliance documentation.
We have strategic partnerships lined up that will help both Campaign Compass and the partnering company. We have talked extensively with Shoeboxed, a local Durham company that has successfully built an incredibly accurate and scalable OCR infrastructure. Shoeboxed uses OCR to do the initial scan of the paper text, but after the initial scan, Shoeboxed employs people who look over the digital text and verify that it is 100% correct. High quality technology companies, such as Evernote and Intuit, have partnered with Shoeboxed to eliminate paper clutter for its customers. We will use the Shoeboxed API, or Application Programming Interface, which will allow us to dump the digital data that Shoeboxed creates into our database. Using Campaign Compass, politicians will be able to send scanned copies of checks and receipts to Shoeboxed, which will then convert these into digital text. Campaign Compass will then call the Shoeboxed API and dump any newly digitized data into our databases, therefore eliminating most of the need for politicians to enter data manually. We will be providing Shoeboxed with more customers for their business, and will allow them to break into the political space more, which is something that Shoeboxed has wanted to do. Political campaigns have tons of paper clutter, besides the receipts and checks, and Shoeboxed would like to be used to organize and digitize this clutter.
Partnerships can bring turmoil to the startup, which we will be cognizant of. One potential problem is that large companies run on a very different schedule than startups and are focused on many different things. This combination can slow the growth of a startup that is relying on a partnership that is not working out (Blank Lecture 7). Luckily, Shoeboxed is still a relatively small company and is so excited about our partnership that they are giving us early access to their API. Another potential problem is that in a partnership, there might be no clear ownership of a customer (Blank Lecture 7). Campaign Compass is able to “own” the customer because the Shoeboxed service is only a small part of the Campaign Compass system. Finally, the member of the company who initially agreed to the partnership could leave the company, which can dissolve the partnership (Blank Lecture 7). Campaign Compass has talked to the CEO, the CFO, and software engineers at Shoeboxed, and they all are in favor of the partnership, which makes the previous scenario unlikely.
Campaign Compass will be priced using a variable pricing model that depends on the size of the political campaign, city, or county. Election boards or campaigns will pay a subscription to use Campaign Compass so that we can constantly improve the product, insert any new regulation laws, and save a politician’s data for the required 4-5 years outlined in California’s political compliance documentation. As for pricing the product, we will not price on cost, but will instead price on value (Blank Lecture 6). We know how much value campaigns and election boards get from the product by looking at what they currently pay to file compliance forms. For state campaigns, compliance costs are approximately $5,000 per month if the work is being outsourced to an accountant. For national campaigns, the cost balloons to more than twice that because the campaign has to hire full-time people to do compliance work. Many engineers price the product on cost, and then add a little bit of profit, but from understanding our market, we understand how much value our customers get from the product, and can price accordingly.
One of the critical aspects of building a Lean Startup is to build only the features that a customer absolutely needs and would not buy your product without. These features, when combined into a product, is called the Minimum Viable Product, or MVP. The basis of the MVP is that in the early days of a startup, the founders are mostly guessing which features the customer needs, and most of what is built is based off of the founders’ assumptions about the market. For a majority of the time, the first product that is built is not a product that people actually want. The goal of the MVP is just to get customers to use it and for the founders to get data about how customers use the product. Once founders begin to get data about how customers use the product, the founders can iterate on the product rapidly and can constantly adjust the product based on customer feedback. As Eric Ries says, it is vital to “learn what customers really want, not what they say they want or what we think they should want” (Ries 38). Unfortunately, when a founder is building a new product category, he or she is unable to iterate on customers, but the founder can still learn how customers would use the product (Blank lecture 1.5). Ultimately, as more iterations pass, the product should get better, unless the initial assumptions were very incorrect. The goal of the MVP stage is to get to a point where “people are literally trying to force their money on you” (Blank Lecture 1.5).
Kirill and I have found that an MVP in a consumer startup is very different from an MVP in an enterprise startup. In a consumer startup, the MVP can be very minimal, and through a series of iterations, can become more complex. Consumers make their own decisions, and can decide to sign up for a service or buy a product even if it does not have everything that the consumer desires. In an enterprise startup, like Campaign Compass, the relationship is very different. For a company or an organization to purchase a product, it has to be approved by many parties and has to be more thoroughly analyzed than a consumer purchase. Thus, in Campaign Compass, we are forced to build a very sophisticated product as our MVP and have a longer development time before we can start selling the product. With this situation in mind, we are trying to partner with a customer while we build the product so that we can get feedback before the entire platform is built. We are very cognizant of the fact that if we “are building the wrong thing, optimizing the product or its marketing will not yield significant results” (Ries 126).
Campaign Compass is building a product for an existing market. There are already products that help politicians do their campaign compliance work, but those products are not as easy to use or as helpful as Campaign Compass. In an existing market, the customers are known and there are competitors in the market. Existing markets can be challenging because a startup might not only need to compete with the existing product, but may also need to compete with all of the third party products that are built off of the competitor’s product. In an existing market, the sales curve should not look like a hockey stick; that type of growth is often only for a new market. Instead, the goal should be, year after year, “to take share away from the incumbents.” (Blank Lecture 6)
Just like in MailBadger, Campaign Compass required us to talk to potential customers. We decided to build the product to comply with California regulations because California is a large state, is open to new technology, and has elections next year. Unfortunately, California politicians have not yet formed their campaigns for next year, so initially our target market is county and city election boards. Many cities and counties purchase campaign compliance software for all of the politicians in their jurisdiction so that less time is wasted doing compliance work. We have cold called about half of the county clerks and many of the larger cities in California, with the main goal of securing a web demo. During the demo, we will show them the current state of the product and what our vision for the product is. Our ultimate goal of the demo is to build a partnership with a city or county, where every other week we would talk to them about what we had built and any problems that they had with the product. By constantly validating our assumptions while building the product alongside a potential customer, we are using Lean Startup methodologies. After the partnership is over and the product is built, we hope to get the city or county to pay for the product. Exploring a customer’s “willingness to pay is a critical part of the customer discovery process” (Blank 58). We do not plan to give out our first version of the product for free because the goal of the MVP is to iterate on the product until customers are almost begging to buy the product.
The City of Long Beach in California was the first demo that we booked. We hoped to show a quick PowerPoint about what we were building as well as a short demo of the current state of the product. Unfortunately, the City of Long Beach was unable to see the web demo on their screen, and it was a failed demo. We have thoroughly researched Web Demo software and have found that Cisco’s webex software is much easier to use and professional than using a Google+ Hangout.
Our initial distribution strategy is direct sales to election boards and state political campaigns. In politics, the phone numbers of these kinds of organizations must be public information, which is very convenient for Campaign Compass. We will be cold calling these organizations, trying to get them to partner because we would like them to critique our product as we build it. Ultimately, once the product is built, the campaign or election board will have a custom solution that they really like, and will hopefully want to purchase the product.
At Campaign Compass, we take distribution very seriously. Peter Thiel, one of the PayPal founders, explains that most startups overlook distribution, and it is the single aspect of building a startup that is often understood least, especially for engineering-driven startups like Campaign Compass (Thiel Lecture 9). “In engineering, something either works or it doesn’t. The surface appearance is irrelevant. So engineers tend to view attempts to change surface appearance of things-that is, sales-as fundamentally dishonest” (Thiel Lecture 9). Engineers often believe that “if they build it, people will come,” but this is too often not the case. We understand that we can be biased towards not doing enough sales, and we always schedule sales calls into our calendar. Thiel also explains that the company with the best product does not always win. The company that wins has a combination of a great product and a successful sales strategy. Thiel outlines how he built the virality into PayPal by incentivizing users to create PayPal accounts; every new user to PayPal got $10 for free in their account. This strategy worked for PayPal because a customer’s lifetime value is greater than $10.
Kirill and I will be working on Campaign Compass full time this summer. We will be moving out to San Francisco in late May and will be focused on building the agency version of Campaign Compass that will be sold to counties and cities. Our agency version of Campaign Compass will be very lightweight, simple to use, and cheap. Netfile, our largest competitor, sells their agency edition for tens of thousands of dollars per year; we are going to sell ours for between one and three thousand dollars per year, making campaign compliance software affordable to many more counties and cities in California. After getting data on how our customers are using the software, we will sell our premium version of Campaign Compass for agencies, which will incorporate software for both the agency and the politician. We are very excited to implement this strategy this summer and make campaign compliance a simpler and less painful process for all.