[team-arkad]

Lessons Learned Starting Our First Business

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. 

[team-arkad]

Context makes all the difference

Dr. Hansen said the problem of data without context could be summed up in a quote from the playwright Eugène Ionesco: “Of course, not everything is unsayable in words, only the living truth.”

- NYTimes

In an interesting blog post on the NYTimes on February 24, Nick Bilton briefly explains the problem with making decisions based on "Big Data."  

Google has a really cool property that predicts the severity of the flu season based on Google Searches and a fancy algorithm (I definitely checked it this winter when I heard that this would be a record flu season).  Bilton explains why Google's flu algorithm was off by a magnitude of almost 2x when it predicted that 11% of the US was infected with the flu at the height of the flu season this year.  Humans and even the smartest algorithms in the world do not understand the story that a data set is telling if they don't understand the context of that story.

It is extremely important for an analyst to know the contextual information about a data point to come to a conclusion about what it says.  

In another funny anecdote from the article, the author explains how a professor misinterpreted a data set and came to a completely incorrect conclusion about the habits of his college students.  His class used Arduino computers to conduct a small study on when students took an elevator versus walking down the stairs at a dorm.  The computers produced data that lead to a surprising result.  The students changed their behavior during the day - they took the elevator in the morning and the stairs in the afternoon.  The conclusion was that students preferred the stairs over the elevator in the afternoon and vice versa in the morning.

Fortunately, the professor started talking to a security guard about his conclusions from the study.  The guard laughed and informed the professor that he was wrong.  One of the elevators was broken in the afternoon, so the students had no choice but to take the stairs.

This very trivial example from the article demonstrates how valuable context is to interpreting data.  Without the context, we can make many different conclusions based on the same information.  

We need the words and the conversations linked to data to make the right conclusion from each data set. 

[team-arkad]

Data Deserves Context

NYTimes columnist David Brooks wrote a very interesting piece on when data is not enough to make important decisions.  At Arkad, we believe that data needs context to be relevant.  On its own, data has a lot less value than it is paired with human intelligence.  It is like trying to watch a movie on mute.  You get a good idea of what is happening, but you miss the full message.  

At Arkad, we have focused from day 1 on combining qualitative information with the quantitative data.  Our newsfeed makes this consolidation possible.  In the newsfeed, a user can ask questions and save conversations with other teams about specific data points.  The whole newsfeed is contextual.  So in 6 months, a user can return to the data and see a conversation string attached to that data point and remember what the data is not telling them.

For example, imagine this scenario.  Customers at a company have decreased over the past couple of months.  Is the company failing to execute or has the strategy changed?  Without context, I may be very concerned about this trend.  Instead, the conversation tells me that the  company chose to increase prices to target a more valuable customer segment after realizing that their customer acquisition costs were too high for the lower pricing point.  This resulted in fewer customers, but increased profitability.

This context is extremely important to understanding how the business is performing.  As Brooks says, we cannot just make decisions based on data and correlations that we may find.  There is a lot more to understand than just what the data tells us.  We need our human intelligence and context to make the right decisions.

Here is an image of a sample newsfeed on the Arkad platform:

[team-arkad]

Transparency in the Office

There is a great article and accompanying video in the WSJ today on corporate transparency.  It discusses a few examples of open book management going well and a few where an executive felt that the strategy did not work.

The overall theme of the individuals that felt positively about opening the books was that it empowered the employees.  The employees know how their decisions affect the bottom line and what they can do to improve business operations.

One common complaint was that revealing employee salaries can cause resentment and headaches as people compare themselves and ask why they are paid less than their counterparts.  

We discussed our thoughts on corporate internal transparency a few weeks ago, and our plan for running a very transparent organization.  Although we do not have employees at this time, we will likely follow the lead of companies with open books but confidential salaries.

Exposing individual salaries makes your business completely transparent, but it affects individuals rather than the business.  Many people can be very affected by such a sensitive subject.  Transparency is great, but does have its limits.  We believe that total salary information is game for sharing because it is an important factor in the success of a business.  It helps employees understand how their salaries affect the bottom line.  They know their personal contribution to that salary number, but don't need to know their peers' personal contribution.

Opening the books empowers your employees and makes many businesses more efficient and profitable.  We believe that it is an extremely valuable strategy in a world that is increasingly more transparent.

[team-arkad]

Investing over the internet

An article in the Wall Street Journal, Site Unseen: More Angels Invest Via Internet, rightly points out several issues with investing in companies via the internet.  Internet investing in private companies has recently been made popular by AngelList and FundersClub.  This financing model will become far more popular once the SEC and FINRA set the rules for Equity and Debt Crowdfunding as legislated in the 2012 JOBS Act.  

For crowdfunding to be successful, investors and lenders will need to feel comfort with handing companies money that they may not have a connection to - we actually think it will be much more likely that consumers will invest in local companies, rather than unknown internet companies, but that is another point.  Many of the basic services available for public equity investors  should be available to crowdfunding investors and lenders.  

At Arkad, we believe open transparency and communication with investors is necessary to ensure the success of the crowdfunding exemption to the 1933 and 1934 Securities Acts.  Our goal is to make this transparency available and to promote the democratization of capital and fundraising.

[team-arkad]

Enterprise Sales - SPIN Selling

This is our last post of the series summarizing the book, SPIN Selling.  We hope you learned something from our notes.  We certainly have not nailed down this process entirely, but we found the book to be really helpful and wanted to make sure the lessons are available to anyone.

This final post covers chapters 6-8.  There is less to summarize from these 3 chapters than from the others, but there are still great lessons on preventing objections (chapter 6), opening calls (chapter 7), and a practical guide to implementing SPIN Selling (chapter 8).

Chapter 6 - Preventing Objections

Features call attention to price because the customer starts to wonder if a feature is worth the price – this is where a lot of objections come from

Cure to objections

Use prevention rather than tactics on how to steer conversations after an objection

Prevent objections by building of needs - you are attacking the cause of a problem rather than the symptoms when you go for the source of the objections: great example call on page 127

There will always be objections that arise because the customer has needs your product can’t meet or because a competitor has a clear superiority

Make sure you are putting in extra effort into effectively developing the needs of your customers through implication and need-payoff questions.  These are building the value of your solution

Why you are getting objections

Objections early in the call - probably talking about solutions to early rather than spending the time to develop strong needs

Objections about value - people keep saying that the product is too expensive...you probably aren’t developing needs strongly enough

Chapter 7 – Preliminaries…Opening the Call

Not that important to success of sale

Generally a waste of time

In preliminaries you must establish who you are, why you’re there (but not giving product details), your right to ask questions – They need to believe that you have the right to start asking a lot of questions

From the beginning, it is essential that you establish your role as the questioner during the call

Chapter 8 – Turning Theory into Practice

Practice in safe situations

Try everything at least 3 times

Focus on improving one aspect of the call at a time…do not try to effectively use the SPIN method right away

Perhaps focus on asking better implication questions…once you are getting better there, move onto a new skill from the SPIN Method

[team-arkad]

Enterprise Sales - SPIN Selling

We are continuing the series from the book SPIN Selling.

Chapter 5 discusses the importance of focusing on benefits rather than features in an enterprise sale.  If you start discussing features in a larger sale, you may end up focusing your customer on how much they are paying for a specific feature set.  Customers typically may question whether that specific feature set is worth the price you are charging.

Chapter 5 – Giving Benefits in Major Sales

Features

Not as important in big sales

You start talking about a lot of features and it makes people wonder if each additional feature is really worth the cost of your product

Ads for a digital watch have lots of features listed, but a rolex never lists its features because if you compared the feature list, the digital watch would look like a better deal

Advantages

Show how products, services, or the features of a product can be used

Use early in the call, but stop talking about advantages in later calls

Benefits

Show how products or services meet explicit needs expressed by the customer

Product launches

Launch the product with the needs it solves rather than the new features

By focusing on the needs you are focusing the attention back on problem solving and on the customer rather than the product

Demonstrating Capability Effectively

Don’t demonstrate capabilities too early

It is important to develop Explicit Needs by using implication and need-payoff questions throughout the sale

The most powerful statements are those which show that you can meet Explicit Needs

[team-arkad]

Enterprise Sales - SPIN Selling

We are continuing the series from the book SPIN Selling.  It is our goal that the readers of our blog learn something valuable from what we are sharing.

Chapter 4 introduces the SPIN strategy.  SPIN selling is all about asking the right questions.  

S - Situation Questions (collecting facts)

P - Problem Questions (discovering the problem that the client is having)

I - Implication Questions (demonstrate the severity of the problems discovered)

N - Needs-payoff Questions (focus on the solutions to the problems)

Situation Questions

Find facts about customer’s existing situation

Essential, but be careful with asking too many of these questions

Buyers hate answering the same situation questions all day…do your research, so you don’t ask something that you could find online

Example - What software are you using now to manage your portfolio?

Problem Questions

Probe for problems, difficulties, dissatisfactions

You need to uncover problems to have any basis for the business relationship

Example -Is the software difficult for you and your portfolio companies to use?

Implication Questions

You uncover problems and make them bigger with your implication questions

These questions help the customer identify his own needs

Particularly powerful in high tech sales

Build up the problem so that it’s perceived to be more serious

They bring negative feelings to the table

Example- It sounds like the difficulty of using the software is causing your team to miss important insights about your portfolio companies.  Is that right? What does missing this information mean in terms of costs to your fund and success of investments?

Need-Payoff Questions

Force the focus to be on the solution rather than the problem

The customer tells you the benefits of your product after these questions

Make sure you steer any conversations away from problems that your software does not fix

Get the customer to explain to you which elements of the problem your solution can solve…Use needs-payoff to focus on the issues that your product does solve

Buyer is explaining benefits to the seller…this helps preprare the buyer for inevitably selling your software internally too

When buyer feels that their ideas arfe part of the solution, they gain increased confidence

Examples - Would you be interested in a way to measure how your portfolio companies are doing in one place? Why is that important to you? Would it help if you could see all of the cash positions of your portfolio companies in one place?

Preparing for the Call

Your role in a sales call is to be a problem solver

Write down 3 potential problems which buyer may have and which your product may solve

Write down examples of problem questions that you could ask

Brainstorm 4 implications of each problem and come up with a question to discover if that potential implication is actually happening at the customer

Avoid Need-payoff questions early in the call.  If you use them too early (before a problem has been developed into an implied need), they won’t be effective

[team-arkad]

Enterprise Sales - SPIN Selling

One of our goals with Arkad is to always help our clients learn something about their business from our service or to teach our clients something new every time they interact with us.  We recently embarked on learning more about enterprise sales from experts who have been successfully selling for years.  They told us to read SPIN Selling.  This is the second post outlining the lessons from the book.

Chapter 3 focuses on discovering your customers needs (if they don't have a need, then why are you trying to sell them your product?).  This is the investigation phase of your sales call.

Chapter 3 – Customer Needs - The investigation phase of sales.

Investigation stage most important in large sales

Needs change in larger sales

Take longer to develop

Involve elements, influences, and inputs from several people

Needs more likely to be expressed on a rational basis

Usually serious consequences for decision maker

Slight discontent is first signal of a need

You can grow this discontent through investigation

Final step of a need is transferring it into a want, desire to act, or an intention to act

Needs normally start with minor imperfections, evolve into clear problems, difficulties, or dissatisfactions, and become wants, desires, or intentions to act

Implied need - Statement by customer about a problem

Explicit need - Statement by customer that they want something

Increasing size of sale à decreasing impact of implied needs on decision

Implied needs are a starting point

You need to develop implied needs into explicit needs

Make the customer say that they have a want or desire (Explicit need)

[team-arkad]

Enterprise Sales - SPIN Selling

At Arkad, we are always looking for ways to learn.  Recently, we decided to embark on learning from others with experience in enterprise sales.  A few people suggested we read SPIN Selling.  

The basic premise of the book is that large, enterprise sales require a different sales technique from the one most people are taught.  We like the book because it is based on decades of methodical research and the conclusions are presented in a way that demonstrate the practical research that occurred.  It is also based on actual sales rather than on lab experiments.

We are going to share our notes from the book for others to get a better sense of the lessons in Spin Selling.  Examples in the notes were quickly produced based on thoughts relating to Arkad.

The main conclusion of the book is that a salesperson should be asking all of the questions to discover a need, make the customer realize his need on his own, and then demonstrate how the product being sold solves that explicit need.

Notes from chapters 1 & 2:

Big sales should be treated completely different from small sales

You should have one actionable objective for a call.  This does not have to be a sale, but it should be something that the customer can act on and follow up with you about

Investigation phase of a call is the most important in leading to a sale

Questions should build perceived value of the offering

You are asking directed questions that the person answers and reveals that their issues can be solved by your product.  “How are you managing the risk of the performance of your portfolio companies”

Questions should not be answered with one answer.  Your questions should be probing

The question phase of a call is the most important in getting information and making a final sale

Question sequence is important

Situation Questions – Collects data and facts for background

Problem Questions – Explore problems, difficulties, and dissatisfaction in areas where your product shines

Implication questions – Help the customer understand a problem’s seriousness or urgency (“How would you know if a company were on a trajectory toward bankruptcy ahead of time with your current systems?”)

Need-payoff Questions – Ask questions that result in the customer telling you the benefits that your solution could offer (“If we were able to tell you when a company is approaching a liquidity problem, how would that help you?”)

Applying pressure in a sales call has a lasting negative impact on your relationship with the customer

[team-arkad]

Backbone.js Event Logger

We wanted to build a very simple event logger for our Backbone app to figure out what was causing long load times for an interaction that involved multiple round-trips to the server. We decided to use Backbone 0.9's built-in Events as a quick, lightweight way to track our custom events. While there may be more robust solutions for this use case, this helped us pinpoint the issue.

First, we need to fire the events:

Backbone.Events.trigger('Logger', {event: 'buttonClick', time: new Date()});

This triggers the "Logger" event, with an event named "buttonClick", and a datetime that's generated when the event is fired.

Next, we need to listen for the events. We use a single Backbone's Router and this seemed like the logical place to listen for the "Logger" events:

var myRouter = Backbone.Router.extend({ initialize: function(){ this.evLogger = {1 : {name : 'start_logger', time : new Date().getTime() }}; this.listenTo(Backbone.Events, 'Logger', this.logEvents); }, logEvents: function(data) { var newKey = _.size(this.evLogger) + 1; var time = data.time.getTime(); this.evLogger[newKey] = { name : data.event, time : time, delta : (time - this.evLogger[newKey - 1].time) }; } })

Upon loading of our app, we create an object called evLogger that will store all of the events, keyed on the order that they are received by the router, each of which has the event name and time. We listen for the "Logger" event with listenTo, and send each event to the logEvents function. Each new event is then added to this.evLogger with a time saved in milliseconds and a "delta" attribute, which is the difference in ms between the current event and the previous one. 

The result is a simple hash of events that you can use to figure out where your bottlenecks are. 

The event hash will only be as helpful as your event triggers. We experimented putting them before and after every call to the server or other Backbone view, collection, or model. We cut down on log events where there clearly wasn't a bottleneck, and added more granular log events where things were taking longer.

For a less quick and dirty solution, we could integrate into our custom baseView, which is just an extension of Backbone.View, and certain named methods on every view extending baseView could automatically log events without cluttering up the views themselves. 

[team-arkad]

Transparency - Employee Retention

During a recent presentation on hiring at General Assembly, the speaker (a well known VC), said that a great question to ask prospective employees you are recruiting is: "how is your current company doing?"

That employee can answer the question in three ways:

(Positively) - Things are great! We just landed a big contract and have plans to release a new product next month.

(Negatively) - Things aren't good - we only have four months of cash left.

(Apathetically) - I have no clue.

The number one indication that an employee is ready to leave his job is if he answers the question apathetically.  This makes sense, but what is happening at the third company?  At this company, the management team is not being transparent with their employees.  They are not sharing information and metrics that might help the employee understand how the business is doing.  

The employee at the second company (things aren't going well...) knows how his company is doing.  He has signed up for the current situation, and his employers are keeping him aware of that situation.  They are all working together to accomplish something great before the cash runs out.  The employee has bought into it and is much less likely to leave because he feels like a member of the team and does not want to let his team down.

This also goes back to the topic of Flow, which we discussed in a previous post and will continue to do so.   Mihály Csíkszentmihályi explains that the two worst psychological states are boredom and apathy.  By not sharing information with employees, you are encouraging apathy at your company.  They just don't care how the company is doing because you don't have their buy-in.  You need to make each employee a part of your team by sharing financial and operational information with them and involving them in strategic decisions.  Many of the fastest growing small businesses in the country share detailed information with their employees.  

Employees are usually your most valuable assets.  Encourage their buy-in to the business by sharing your operational and financial metrics with them. 

[team-arkad]

Day in the Life of a Founder - Kenny Chan

Kenny was recently interviewed by M&T For Life - a blog that features stories about alumni of the Management and Technology Program at the University of Pennsylvania.

Here is the link to the story.

[team-arkad]

Flow and the Founding of Sony

Masaru Ibuka co-founded Sony in 1946 with a simple goal - "to establish a place of work where engineers can feel the joy of technological innovation, be aware of their mission to society, and work to their heart’s content."  

This was the first "Purpose of Incorporation" of Sony.  This goal helped Masaru lead one of the most important and successful technology companies of the 20th century.  If you read it carefully, he is talking about creating an environment where his engineers can achieve flow.  He established this environment because when his employees felt the joy of what would later be called "flow" by Mihály Csíkszentmihályi, he believed that that they would be able to invent and develop some of the world's most inspiring products.

This is just one of many situations where a company created a culture that fostered flow to help employees enjoy their work and resulted in the overall success of the business.

[team-arkad]

Flow at Work

"Work Should Flow" is one of the core values at Arkad.  We included this after reading Mihály Csíkszentmihályi's examination of optimal experiences in Flow: The Psychology of Optimal Experiences.  In the analysis, flow experiences are identified as ones where an individual is emotionally energized and experiencing enjoyment from a task at hand.  An example referred to in the book several times is when a rock climber is pushing herself to the top of a difficult climb.  The climber is mentally involved in every aspect of the experience and is completely concentrated on the task.  She has a clear objective to reach the top of the climb and gets constant feedback on her progress as each move brings her one foot closer to the objective.

Hallmarks of flow experiences are ones that have a clear objective, require full concentration, provide clear and immediate feedback on progress towards an objective, and are a difficult, but achievable challenge.  

According to the book, if you can involve yourself in experiences that have the traits listed above, you will achieve the ultimate goal of life - happiness.  

At work, it is absolutely possible to achieve a flow state, and Mihály claims in the book that many of the happiest people benefit from truly enjoying their work in a flow state.  One might argue that few jobs provide such experiences, but Mihály demonstrates that even a man working on the floor of a factory is able to have a flow experience at work because he has purposefully created an environment where flow can be achieved.

We recently stumbled on a blog post by Ash Maurya that outlines how he achieves flow in a lean start-up...very fitting post!  He creates daily and weekly flow by creating an environment that enables him to concentrate on his tasks while maintaining the flexibility to deal with unforeseen challenges.  He puts the idea of flow in the context of iterating quickly, customer development, and collecting feedback, data, and insights from customers.  His post is a few years old, but definitely worthwhile.

[team-arkad]

Implementing a Transparent Open Book Management Culture

In a 2001 Business Horizons article, Raj Aggarwal and Betty Simkins discuss the steps to implementing Open-Book Management (OBM) at a new company.  It is not enough to simply open your books and share the numbers with your employees.  It is the CEO’s responsibility to make sure that the employees understand the numbers and understand how their effort is reflected in the financial statements.  Once you get the information into the hands of your employees, you must teach them the basics of finance and business.  With the right information and the knowledge of how the financial statements are impacted by business decisions, your employees will be empowered to make the right decisions based on what they know.  Now that your employees are thinking like business people rather than hired hands, they must share in the success of the business, like a business owner.  Jack Stack, the pioneer of the OBM movement, believes that a successful OBM scheme also incorporates the employees in the planning process.  At the beginning of a planning period, the management team and the employees work together to set one critical target for the period.  This critical number could be cash flow, profit, sales, or a product’s defect rate - it is whatever number is important to the current period’s business goals.  If the company surpasses its critical number, the employees must share in the success of the business because they are acting like owners.  If the company were to miss its critical number for the period, the employees should not receive their bonus - just like a business owner would take home less profit. 

Instead of blaming management and not knowing why they did not receive a bonus, the employees understand what happened.  They have been watching the critical number all period and know that their failure to surpass the goal was the reason they did not receive a bonus.  The employees know that they have to find creative solutions to problems to ensure that the company reaches the critical number.  The entire team is focused on ways to improve the critical number, and everyone works together to achieve this goal. For a company that has just begun the implementation of OBM, it is important that the CEO maintains a patient pursuit of the goal.  It typically takes the culture of a company 2-3 years to adapt to OBM.  The patience to see the transition through the first few years is typically well rewarded in the subsequent years as the power of OBM “lies in the long-term and in its ability to change how people act and think."

[team-arkad]

Transparency - Open Book Management Drives Success

Jack Stack, CEO of Springfield ReManufacturing (SRC), is accredited with pioneering Open-Book Management (OBM) in the 1980s after he led a management buy-out of the struggling manufacturer.  Open-Book Management was created out of necessity to get his employees to understand the situation that they were facing together.   Although all of SRC’s success cannot be attributed to opening the books, the company grew from losing $60,000 on $16 million of revenue in 1983 to earning $1.3 million in after-tax profit in 1993 on $66 million of revenue.  In the 30 years since Stack implemented OBM at SRC, there have been countless successful implementations of the technique.  After controlling for other factors, the National Center for Employee Ownership found that non-employee owned companies with OBM saw an increase in sales of 1.66% per year and an increase in employment of 1.27% per year relative to what would have been expected without OBM.  These exceptional growth rates are the result of leveraging employees and empowering them to make decisions that directly affect the bottom line.  When they know how their actions affect the company’s results through weekly or monthly financial updates, their behavior changes and they develop creative solutions to reduce unnecessary costs and to increase sales.  Your employees begin to think creatively to find ways to reach goals when they are armed with the right information.