What We Learned Starting Our First Business

Benjy Boxer
11 min readOct 28, 2015

--

This post was published almost 3 years ago, but I just realized that our domain (getarkad.com) had expired (pouring one out for Arkad tonight). Since we want this to be available for future generations of entrepreneurs, I’m republishing here.

We founded Arkad in August 2012 to provide companies with a simple investor and lender relationship tool. Initially, we started with venture-backed companies, but our broader goal was to change how businesses communicate their data.

Unfortunately, we officially shut down Arkad on May 1, but we want to share some of the many lessons we learned throughout the process of launching our first business.

The 80–20 Rule Doesn’t Apply to Workflow Products

The problem with workflow products is that if you don’t solve the entire workflow, you end up creating more work for your customers.

For many people, Excel has become their go-to database. This is definitely true for most financial and operating data at companies. Arkad replaced this and made it extremely easy to compare companies across the portfolio, communicate with those companies, and perform basic analysis.

The current version of our product didn’t capture the entire workflow — investors also needed to perform valuations, manage cap tables, and a variety of other tasks. We were addressing 80% of what people needed, but to get the last 20% would’ve meant at least another year of development.

One way to avoid this trap is to build something that addresses a very specific aspect of the workflow. From there, you can build other features that creep into other aspects of the workflow. Eventually, your product captures the entire workflow, and you’ve built the solution your customers wanted.

Our customers wanted every part of their workflow to be built into Arkad because we were selling a workflow solution. It was how we positioned the product from the beginning, and this hurt our ability to sell something that wasn’t a complete solution.

Building a Product vs. Service Business

From day one, we should’ve been offering Arkad as a service rather than as a product. It would’ve enabled us to make early sales and build the products with clients actually using them, not to mention we could’ve validated our idea sooner.

As a service, you can walk into the customer’s office and say we will take care of everything. Meanwhile, you can create products to scale and automate those services. This may have worked for our market initially, but the professional investor market is not large enough and doesn’t value portfolio monitoring enough to justify providing a high-touch service. Eventually, we would’ve needed to productize the services and move into other markets that didn’t need a high-touch service. We were planning to introduce our product to the small business lending, crowdfunding, and real estate investment markets.

Focus on a Deep Well

Paul Graham recently argued that businesses should aim to build a “deep well”, focusing on delivering a lot of value to a small market. We always intended to start with a deep well for professional investors and then expand into small business lending, crowdfunding, and other asset classes.

In order to dig this deep well, we should have built a product to solve a specific need in the workflow. Focusing would’ve enabled us to build something that is 10x better than the current solution. From there, we could’ve slowly added functionality to capture different parts of the workflow.

Instead, we built an entire platform that wasn’t necessarily amazing at any specific aspect of the workflow. As an entire portfolio management tool, we didn’t commit enough time to develop Arkad into a product worth changing behavior for.

Changing Behavior is Really Difficult

We were basically replacing Excel-based workflows, and to replace any existing workflow you need to be 10x better than that workflow.

Arkad was trying to change an ingrained behavior of CEOs/CFOs and investors. The companies were used to providing data in Excel files they were already using, while investors were familiar with manipulating the information within Excel. Each month, this workflow would inevitably breakdown as companies changed their financial models, were slow to respond to requests for the data, and investors scrambled to quickly pull together the monthly “tear sheets” on each company.

We believed that Arkad would improve this entire workflow, but it required a behavior change. Unfortunately, although the investors saw benefit, most were afraid to be the “bad guy” and ask their companies to change behavior.

To overcome this behavior change, we should’ve focused on making it extremely easy to get data into the platform through API calls to Quickbooks, Google Analytics, Salesforce, and other products.

Two-Sided Workflow Problem

From the very beginning, we recognized that we were building a product that would help two groups — investors and portfolio companies. At first, the investors would get the most value from the product because it helped them track all of the data spread across their companies. But we were always dependent on the portfolio companies loading their data. We strived to find ways to make the product more useful to portfolio companies, but struggled to come up with something. We ended up counting on investors pushing the product onto portfolio companies, rather than building features that were specifically useful to the portfolio company.

If your platform doesn’t return value to the person inputting information, you need to find a way to collect that data automatically and remove the person from the equation. Salesforce and Github have used different tactics to make their products valuable to the person inputting data.

Companies get a ton of value from Salesforce, but the sales people are reluctant to add information to the product. To solve for this, companies use the data entered into Salesforce to calculate a salesperson’s commission. Essentially, Salesforce resorted to the collectors of data (companies) pushing the product onto the salesperson by aligning the incentive structure of the salesperson to the goal of data input.

Ideally, the person that inputs the data gets as much value from the product as the aggregator of data. Github for companies is a great example of this. The users get an enormous amount of value through version control and companies get all of the aggregate data they want. This is all in the background for the people entering the data (the software developers), but it is extremely valuable to the aggregator (product manager or company).

Data First…Then Build the Platform

At its core, Arkad was a data collection tool. The asset that was most important to the success of the platform was the operational and financial data of each portfolio company. Some of the most exciting value we planned to provide would be on benchmarking and analysis of data. In order to provide this value, however, we needed a lot of data to be entered first — it was the catch-22 of our offering.

Essentially, we didn’t convince our potential customers that Arkad was valuable without the benchmarking that they were excited to see. We either had to go out and collect publicly available data or provide an extraordinarily simple way for users to load data into the platform. Once they loaded their operational intelligence, Arkad needed to provide analysis and insights that were not possible with the old collection techniques.

We started to believe that the key to successfully launching a product dependent on a critical mass of data is collecting as much information as possible upfront. SinglePlatform nailed this with their launch.

SinglePlatform allows small businesses to publish their menus and pricing across content sites. The product was only valuable to content sites like the New York Times if they had data from restaurants. To get the data, they could’ve built a platform and tried to get businesses to sign up and input their data. The small business would get no value from this, however, because the content sites would not partner with SinglePlatform without the data. The solution was to manually collect menus from approximately 10,000 restaurants. When a restaurant signed up to the site, they were editing their menu rather than entering the original data. The content sites loved it because they now had access to 10,000 menus on day one. It was a brilliant plan to get content sites excited while making the site valuable to its initial users — the first restaurants that paid to list and manage their menus online.

If having data is going to be the most valuable part of a platform, your first customers must get something in return when they provide you with their data. This requires seeding your database with something to begin with rather than being dependent on your first customers.

Understanding Customer Incentives

You must understand your customers’ incentives to know why they would purchase your product.

We believed that the partners would pay for a product to help them manage their portfolio and improve their internal processes. A very smart venture capitalist pointed out that the incentive scheme in venture and private equity is different from any other type of company. He said that most investors do not reinvest in their funds like a business because they don’t consider a fund to be a business.

Companies will invest in a product that improves processes to help them scale the business. A fund probably won’t make this same investment because they are not trying to grow like a normal business. One prominent exception to this rule is First Round Capital. They actually built a product very similar to Arkad in-house because processes are so important to their growth.

The majority of a partner’s income comes from his 20% carry on successful exits. Improving portfolio data collection is unlikely to improve his chances of having a large exit in his portfolio. Smart venture capitalists make the right investments upfront to earn the benefits later. Since the incentive is to find the right deal from the beginning, a product more aligned with investor incentives would identify opportunities rather than monitoring them after the transaction.

Understanding the Customer vs the Buyer

Arkad had multiple customers and one buyer. Our customers were the portfolio company CEOs/CFOs and the analysts and associates at the investment funds. The buyer was the general partner of those investment fund. As Steve Blank discusses in Four Steps to the Epiphany, it is crucial to understand the distinction between a customer and buyer early in customer development.

It took us time to realize this difference. We believe that the reason we were blinded by our customer need but not aware of our buyers’ needs was that we were so acutely aware of our customers’ needs. We were associates and analysts, and we knew the pain that portfolio tracking caused for the analysts and associates and for the portfolio company management teams.

The incentives were strongly in favor for implementing Arkad for the users. The buyers, however, did not have a strong enough incentive to implement it — all of the pain was felt elsewhere. They got the data when they needed it because an analyst or associate took care of it.

To get the partners excited, we could’ve built a product to target something that they would perceive valuable on day one.

Collecting Financial Data Only Happens After the Fact

Arkad was built to present financial and operational data at the end of each month to investors. We tried to make the argument that Arkad would help portfolio companies manage their business while investors monitored performance. The pushback was that the data collected in the system was already old and decisions were made weeks before it hit Arkad.

End of month data is ancient relative to the data businesses use to make daily decisions. One CFO explained correctly that his financial statements are important to look at and understand, but you are already one month behind when analyzing the information. To manage his business, he looks at operational data every day.

If you are building a platform for data collection, you must collect data immediately, present it in an actionable format, and make suggestions that a manager can use to improve his business that moment. Presenting old information doesn’t help someone take action and your suggestions could be 6 weeks old by the time the books are closed at most small companies.

Startups Fail Because Founders Lose Enthusiasm

We collectively believe that there is still a good business opportunity in investor and lender relationship management. In fact, this opportunity only gets better with crowdfunding because entrepreneurs will quickly realize how difficult it is to manage 100s of investors when they were struggling to manage just a few dozen. The fact is, however, that we started losing enthusiasm in our idea and company.

In March, we began discussing why we were struggling to close sales (that’s where a lot of these lessons learned originated). This discussion definitely accelerated our decision to close the business. Of course, it’s imperative that every startup reflects on why they aren’t achieving their goals. If you want the company to survive these conversations, however, it’s extremely important to also set new goals and refocus on the next tasks to accomplish.

Negativity saps energy from anyone, no matter how optimistic you are. We started running out of energy when our conversations about Arkad turned negative.

When starting a company you must realize that there will be plenty of days where you lose excitement because things aren’t going well. Make sure you are enthusiastic about your idea or mission. It will be the only thing that helps you overcome the early negative days. You need this enthusiasm about your mission or idea, so you can refocus on accomplishing your goals.

Measure, even at the beginning

Momentum early on can be deceiving. Throughout development, we continuously met with potential customers to collect their feedback and to hear if our newest features would help them manage investor relations.

Every time we met with someone, we should’ve asked, “will you buy this product?” We should’ve set a goal from the beginning that if x% of our potential customers weren’t excited to use our product, we would need to change something or pivot to another idea. We didn’t do this. Instead, we took the positive meetings and the negative ones in stride. We would evaluate the conversations, but in the end we just said “enough people are excited about this feature or that one, let’s continue to build.” When you are building a product, you cannot just accept a user saying “yes I will use this product.” The next time we start a company, we will get those users committed. If the product isn’t built, sign them up for the future. If the product is even in a simple form, sign them up and get them using your product. The feedback is tremendously valuable.

The discipline to set a goal is extremely important. It may seem arbitrary to say “50% of the people we meet with need to tell us they will buy this product, or we need to change something.” The exact metrics that are important to measure depend on your business model and market. For Arkad, our percentage of likely buyers at each stage should’ve been somewhere near 30–50%. Our market was small, and we needed to convert most of our potential customers to buyers to be successful.

Whatever your goal is: come up with a hypothesis for that goal; measure it; and evaluate what potential customers are really saying. If you aren’t hitting the goal, figure out why and either change your sales approach, product, or business plan. Don’t let the momentum of good meetings carry you forward without precisely measuring how you’re doing.

Thank you for reading this long blog post. We hope you got a fraction of the benefit that we did while writing it. If you have other lessons learned to share, let us know. We’d love to keep the conversation going to help future entrepreneurs succeed where we failed. Leave a comment below or reach out to us with a topic suggestion. Our email address is contact at getarkad.

Benjy, Kenny, and Micah.

--

--

Benjy Boxer

Founder @ParsecTeam. Former director of Product Strategy @newscred. Contributor to @forbes writing about media and technology. Teaching product management @GA