BeaglesLoft

image source: paul.li

We get a lot of clients asking us to design an "MVP" that they can show to potential users, investors and partners to get feedback or raise funds. In most of these scenarios, the hardest challenge is defining what is the minimum set of features that will prove there is something viable in a product that solves a need for the target user. 

Here is our process of designing an MVP. 

1. One line definition of the product

We work with the client to define the product in one (short) sentence. The shorter this line is, the more clear the product is. This helps in filtering out the toppings from the doughnut.. Contrary to what most people expect, this is the hardest challenge. 

2. Branding

An MVP does not mean a poorly designed prototype. It means what is the minimum representation of the product that clearly and effectively communicates the usefulness to the user. In order to do this, we find that an MVP should still excite the user about the product. It should tell the story in a concise, appealing manner. The tag line, the logo, the typography, the wireframes, the designs - all of these are very important in telling the story and assessing the user's excitement to use the product when it is built out with all the promised features. 

image source: socialmediasocialmarketing.com

Very often in our design process, we find that the images that we sift through for branding impact us hugely in deciding what is minimal, what is viable and what the wireframes should flow like. We find that this is an often overlooked aspect of building an MVP, and we think this is critical. 

3. Wireframes

Once we have a good idea of what we want to put in front of users to get feedback and see if there is something viable or not, we build the wireframes. We sketch on paper or design using photoshop and we put these into prototyping apps like Marvel or InVision or POP.

After several iterations of putting wires into these apps, showing the flow to friends of the company, early adopters, and folks in communities like meetup groups, we then get onto designing the refined visual designs. 

4. Design

The actual design is only a third of the effort, since by this time the wireframes and flow are defined in detail, in collaboration with some feedback from early adopters. The branding exercise also makes designing easier and more effective since a lot of the visual and aesthetics are already well thought through. Once the designs are done, they are uploaded again into apps like Marvel/POP/InVision and these are again iteratively demonstrated to early users and improved upon. 

5. Feedback

A good chef tests his dish every step of the way. Similarly we think feedback is critical at every step of the design process. It's important to have original thought and a strong opinion, but this should be edited with user feedback. Once the designs are completed, we try to get these up on some user forums to get some feedback from people who are not friends of the company. Nothing like some honest criticism. We improve the designs again through a couple of iterations. 

Yahoo is laying off nearly 500 engineers in its Bangalore Software Development Center. But we should take this kick to change the technology and entrepreneurial climate in Bangalore. 

1. Made in Bangalore - not outsourced to Bangalore

We have to start building products in Bangalore for a global audience, and not just be an outsourcing hub for American or European companies. If these software development centers, like Yahoo's, were building really innovative products, then these jobs would still be held.

2. Technology Vs Globalization

There are companies that build technologies that will create a completely new sector globally, and those that expand the market for an existing technology. A lot of the startups emerging in Bangalore are really good at the latter. We think that is definitely very admirable, but we hope to see more of the former coming out of Bangalore as well. What better than a group of engineers who have seen how Yahoo operates from the inside, and who have a nice little severance package to fall back on, to start these new ambitious tech startups?

3. Aversion to risk taking - Join a big company young man/woman

We are all told by parents, uncles, teachers and others to join a big company - for the security that a big company provides. If we look at what's happening at HP, Yahoo's recent news, Ebay spinning off Paypal, how Motorola got crushed over the last years - now is as good a time as ever to prove that working for a startup is not more riskier than working for a big company. 

....and everyone perks up to hear.

Apple had their big event last week where they announced several product news in their usual well rehearsed theatrical performance.

We haven't played with the iPhone 6, nor have we laid hands on the Apple Watch. So we can't comment on those, expect that we can't wait to have them in our hands...or on our wrists. We want to write about some of the other announcements made by Apple.

1. Over 1.3 Million Apps

Apple announced that there are now over 1.3 million apps in the app store. You have 20 apps on your home screen and an average user probably uses about 40-50 apps on a regular basis (no matter which smart phone one uses). The apps that you have on your home screen are all Unicorn companies.

What about the apps that don't make it to your home screen? They can't make a significant ad revenue if they don't have enough eyeballs. We think this will drive more transaction and commerce based business models in the app ecosystem. Businesses that provide security, user loyalty, payment processing, user support and other such services through an API for apps should see increased adoption.

2. Default Apple apps falling behind

Apple prides itself in providing the best user experience. We think they succeed in doing this like no other company in the industry when they combine hardware, software and services. But in just software apps, they fall behind. There is a startup or a large company that makes a better app compared to every single one of the apps that Apple ships on the iPhone. Some that we use on our phones -

Sunrise over Apple calendar

Mailbox over Apple Calendar (we have some extra betacoins for the Mailbox mac beta. Ping us if you want one).

Evernote over Apple Note

Google Maps over Apple Maps

Here's a complete list from Digital Trends Link

This ties into the rumor that Apple might acquire Path. Path probably has the best design and user experience among mobile social network/messaging apps, but is struggling for adoption compared to Whatsapp, Facebook Messenger, Snapchat and other mobile messaging apps. 

3. Apple Pay

NFC technology has been around for a while, and has been integrated with phones and payment terminals for a while. But Apple Pay will finally give this payment technology the kind of commercial success that it has lacked with the integration of the fingerprint scanner, and the adoption by several of the popular apps in the Apple ecosystem. Most importantly, Apple is working with the credit card companies and not trying to replace them.

Unlike several of the payment solutions which try to store the user's data and build seemingly clever business models around the data, Apple has taken a different approach. They don't save the user's data, and focus instead on the security and the user experience.

4. Music Albums delivered right to your phone

Even without making much hype about it, Apple might have just changed the music delivery game. By putting U2's new album directly (and freely) available on iTunes, Apple has created a new model. With their acquisition of Beats, Apple also has access to Beats' superior curation in the music streaming service, and Dr. Dre's knowledge and connection of artists.

Spotify, Pandora, Rdio, Google Play and others have good music businesses and products, but Apple just upped the bar again for all players.

5. Partnership with IBM

On receiving non-stop requests and updates for the events happening at BeaglesLoft, we decided to solve all your queries  in one go. 

Bringing you our very first weekly event newsletter, your one stop gateway to all things BeaglesLoft as well as to the most happening events in and around you in the startup community, under the three tracks Design, Tech and Entrepreneurship

Besides events, our newsletter also serves as a guide to all activity in the VC circle, as well as Job postings in various startups in Bangalore.

Here’s a sneak peek !

Want to get onto our mailing list?

Building on our attempt to conquer machine learning, we will add more complicated tools to our repertoire. We will start off regression with simple linear regression. Simple linear regression helps us predict the value of one variable based on the value of another variable. The variable we are predicting is usually plotted on the Y axis and the variable driving the prediction is plotted on the X axis.

Let's take an example problem of predicting a wife's age given the husband's age. Just as in the case of Bayesian reasoning, we will start off with a previous sampling:

Husband : 36 72 37 36 51 50 47 50 37 41 Wife        : 35 67 33 35 50 46 47 42 36 41

Visualising this in a scatter plot:

Hmmm, seems like the two variables show a linear relationship. Pearson's Co-relation (r) gives us an estimate of how "linear" this relationship is. r ranges from -1 to +1. A value of -1 implies a negative linear relationship, 0 implies NO linear relationship and +1 implies a positive linear relationship. The r value for this sampling is 0.97, and it does fall in line with our observation that the 2 ages have a positive linear relationship. (I have left out the r formula and calculation but encourage everyone to learn about r and do the calculation)

Now, given a new value for X (husband's age) how do we predict the value for Y (wife's age)? Since we are anyway assuming a linear relationship, will we be able to fit a line which roughly defines this relationship? Linear regression gives us a nice way to come up with an equation for such a line which has the least errors in "prediction".

Let us first derive the equation of this "best-fitting" line and then see what least errors in prediction means. The line equation is given by Y = bX + A. The slope b is given by r * (std_dev(X) / std_dev(Y)) The intercept A is given by Mean(Y) - b * Mean(X)

Following the formula, the equation of the regression line Y = 0.81X + 6.183. Now, plotting this line along with the scatter plot, we can define "error" in prediction.

It is simply the difference between the actual Y value and the predicted value Y' which lies on the regression line. This regression line is best-fitting since it has the least sum of squared errors in prediction.

July 9th, on a rainy Bangalore evening, we launched our first VentureWednesdays event. Many brave souls, from the startup and VC circles, overcame the elements and headed over to BeaglesLoft to learn and nit pick about Fundraising.

After a quick ice breaker over crackers, cheese and soda, we got comfortable on some bean bags and arm chairs to pick each others brains.

Niranjan started off with a brief intro about BeaglesLoft and what our mission and goals are. Then he deep dived into the travails Haggle underwent while raising money.

The session continued with Prayank from Accel partners and Nagaraja, an Angel investor, weighing in their insights and experience at every major point. The discussions ranged from Accel’s past experiences to how things are different in the social impact sector.

We also had Jackie from ESSMART global, another startup to have successfully raised funds, educating us with her journey so far. Overall, we all felt 10 years wiser.

Nagaraja then took the stage and spoke about the inner workings of a VCs mind. With his passion for innovative startups he exhorted all to look at the millions of problems that exist in our own backyard and to work on them. His advice to not follow valley startups, on tech crunch and implement them here in Bangalore could not have possible come at a better time!

Aruj, and his Bhukkad crew, played the perfect caterers by serving some delicious hot sandwiches, a perfect accompaniment for the cold beers! Like always, our rooftop played the perfect platform for networking and building relationships!

The Bangalore Random Hacks of Kindness is a community built with the principles of innovation and openness. We believe technology has a huge impact in solving humanitarian Issues. Hence, twice a year experts from development areas pitch real world problems to the hackers/tech­experts after which hackers form teams choose their problems and hack over the weekend to create a proof of concept to solve part of the problem with technology.

The June 2014 RHoK event was held on 28 ­& 29th. The event this time was hosted in partnership with a set of communities like Beaglesloft, Arduino India , Breakthrough and Saakshin (The Bachchao Project ). This collaboration brought in various expertise ranging from developmental hardware to other expertise of usability on the table, facilitating effective solutions.

Here's a gist of what went down during the weekend long overnight Hackathon :

It was attended by around 25 hackers on day 1. We witnessed around 8 pitches, some of which were posted before on the hackathon event page. After 3 reviews the hackers worked on 6 solutions at the end of day 2.

The Problems that were pitched :

Enable India:

Training a visually impaired person to learn to use a computer requires them to become familiar with a keyboard which usually takes a while. How about a better way of handling this.

Doctors without Borders :

Meeting Water and Sanitation needs of displaced people in emergencies is a top priority in order to avoid outbreaks of diarrhoea and other hygiene­ related diseases. This is however not known to all. Hence we need a digital system to share this information .

Taarifa.org :

Taarifa Platform is an open source web API, designed to close citizen feedback loops. Recently they created a water point management application for Nairobi. Taarifa needed an Extrapolation on the platform to work in new contexts and places .

Breakthrough :

We do not know which police stations are women friendly / sensitive to women who are coming to register a complaint. It would be great if we can find a solution that can help the public know about the friendly police stations and thereby encouraging other police stations to take measures to be more gender sensitive.

Pausch Initiative :

Underage labourers and street kids are one of the pressing issues in urban india.They miss out on education and rights because of poverty. Hence there is a need to create a platform to solve this issue involving citizens passively ,actively or anonymously to erradicate this .

NGO Reach :

Lack of interactive platforms to connect the NGO and volunteers makes it hard to find the desired volunteers with right skill set.

Farmalution :

In India, a set of farmers are connected to a supervisor. He helps in educating them with better agricultural techniques, what type of crops to grow in which season, insights about what fertilisers and pesticides to use, irrigation etc.,After the supervisor educates the farmers, it has been a challenging job to monitor the farmers, But there is no feedback mechanism to understand if methods are being implemented or not and are working in a manner intended.

Project Child Care :

Indian Government spends huge sums of money to provide children with education. They have introduced the midday meal scheme and also provide clothing, bicycles, bus passes, scholarships etc. But there is rampant corruption by middlemen which prevents the intended from getting the help .Hence there is a need for cost effective,efficient, simple solution to effectively track these freebies from government, so that it reaches the intended.

The Problems that were worked upon were :

Farmalution :

After the supervisor educates the farmers, it has been a challenging job to monitor the farmers, if they have implemented the technique or if they need any help etc. Hence a solution where a outbound call(VOIP) is made to a farmer in his local language, and feedback is got based on choosing the desired option. This is later analysed to get statistical information about the implementation.

Team : Satvik Jagannath , Akash Nidhi , Sharath R

Git Hub link : https://github.com/bozzmob/RHoK2014

Tolk :

The solution was done in two ways;

1. Proof of concept for talking keyboard via hardware cracking ­ by developing overlay ­with braille on top of existing keyboard, which could talk when key is touched

2. Working prototype on raspberry pi with usb keyboard & earphone with rasbian OS, Python, espeak TTS. ­They bypassed login & ran espeak login script­ so when a key was pressed on the keyboard it read out via head phone.

Team : Muthu Raj , Anil Prasad M N , Rishi Gaurav Bhatnagar , Rohit Shetty

Project Child Care :

Since the technology chosen should be simple, should have ease of use and be cost effective .QR Code was chosen to be used on school ids. These are generated with the details of the students. A basic smartphone with QR Code Reader app is used by school representatives to scan, after the student receives the benefit thus preventing misuse.

Team : Srikanth Mattihalli , Preetham Hegde

Git Hub Repository: https://github.com/srikantmatihali/childcare

NGO Reach :

A platform was created to create and publicise the events at the click of a button . Such a repository will help those interested in volunteering to help find events happening in their localities.

Team : Varun Vadigeri , Brateesh Kumar , Chandrahas M , Gagan K, Anoop Chandra

Pausch Initiative :

A platform where one can download crowd sourced tutorials was created. This can be downloaded and used in an app which serves as a tutorial for volunteers to teach illiterate people. A case of child abuse can also be reported through this app.

Team : Rohit Shetty , Anoop Chandra

Police Station Safety Audit :

There was no pre­existing data available hence a data collection and display mechanism was created during this event

Team : Ankita H

Farmalution , TolK and Project Child Care were chosen as top hacks among those presented.

Sponsorship :

We would like to thank our sponsors for showing us so much love and support.

Our sponsors are;

Venue : Beaglesloft

Food : Nithin R and Saakshin Technologies

Prizes : Baishampayan Ghose

Printed Bragging Rights : Yogesh Londhe

Banners : Breakthrough

Sandbox collective provided a much needed break after all the intense brain buzzing, by performing “Rosencrantz and Guildenstern are dead”.

Once you get a term sheet, more often than not, it materializes into actual funding. Unless you are this guy here. 

image source: duediligence.com.pe

Don't fear the due diligence. If you haven't blatantly lied in your pitch to get a term sheet, this is more of a mechanical process to get through, than a stressful one. It is normally a young principal or associate at the VC firm that does th diligence. So think about it this way - if a young pitbull of an associate is coming after you to verify everything you've claimed, will your assertions hold true? You should ask yourself this questions before the pitch and not only after getting the term sheet. 

The diligence usually involves two things. 

Checking your reference

Verifying if all the numbers add up

Some VCs have a portfolio company management team member or an in house expert look at the technology/IP claims

For the first, make sure the reference contact you've provided is someone who can quote practical examples of your past experience and your abilities and preferably someone who's been an investor in your past company or worked closely with you. We always think someone who knows you deeply is better than just a big name person. 

image source: web.checkster.com

For the second, go over your finance projections, business plans and any other numbers in your pitch deck thoroughly. Finance projections are always a guesswork, but a demonstration of how the business and numbers will scale is what the VC is looking for. A common mistake to avoid is showing revenue projections or user base increasing but not the burn rate. Ensure that the finance statements (balance sheet, P&L, cash flow) are correct.

Lastly but probably most importantly in an early stage, make sure the technology claims are valid. This is mostly what the VC is backing at the early stage. If you have filed patents, or shown how your technology innovation improves a certain standard/metric - then make sure these all check out correctly. False claims or exaggerations in these are a big red flag.

A good process to follow is to agree on a list of documents with the VC firm, so it's clear at the outset what documents you're expected to produce. 

Usually a term sheet has a certain number of days of validity, during which period the due diligence is conducted, culminating in a definitive agreement and funding. In term sheet series, we'll go over all the nuances of the term sheet, whether you can haggle with multiple VCs when you have a term sheet in hand and what kind of legal documents the process results in. 

BeaglesLoft has kick-started its tech building initiative with TechBuilders 1.0. as we reiterate the need for innovation and disruption in the startup capital of India. This past Saturday saw a healthy turnout of tech-enthusiasts and we decided to try something crazy: a hackathon without laptops.

There were no frameworks or APIs or programming language wars; just good ol’ pen, paper, probability and perseverance.

While The Loft Team knew there would be plenty of challenges, the attendees did not make it any easier for us with their brain buzzing questions. After a brief introduction and a refresher on Probability Mass functions, we broke out into smaller teams.

Each team was challenged to find ways to apply Bayesian Reasoning to real life problems and make Thomas Bayes (and probably our mothers, too) proud.

 The problems we worked on ranged from serious topics like out-foxing evil spammers to the downright hilarious question of how to tell if someone likes you when they walk by and smile at you. After a few hours of laughs mixed with intense table banging and brain busting, each team presented their solutions, bracing for the brickbats. It was great to see how each team tackled the same data in radically different ways.

When the event "ended," participants hung around the Loft and bonded over more ‘real-life problems!' Bayesian Reasoning permeated throughout. In a short afternoon, strangers had begun to form a tight community. Many participants volunteered to help take TechBuilders to the next level. 

  The overall response from our first meeting is a validation in part for our vision at BeaglesLoft. There is a growing need for hardcore computer science and math within the tech community in Bangalore. BeaglesLoft is incredibly excited to be a pioneer in this community, and we can't wait to grow the community and host more incredible events in the future.

In the field of computer science, Bayes' theorem is most often used in "classification”. Classification deals with the problem of assigning a label or a tag to input (and thereby classifying it). 

Let us revisit the problem of "classifying" someone as belonging to a certain city. To keep matters simple, let us limit ourselves to 3 cities: Bangalore, Chennai and Kolkatta.

A classification task, generally begins with an input data set.The input data set gives us more information about the classifier labels and their features. Let us build a sample data set for our problem:

City             Beer Drinker | Not    || BJP | Not || Curly Hair  | Not | Total  _______________________________________________________________

Bangalore   |  700      |       300    || 650  | 350   ||   300       | 700 | 1000

Chennai      |  100      |     1900    || 300  | 1700 ||   1300     | 700 |  2000

Kolkata       |  50         |      450    || 100  | 400    ||   25         | 475 |  500

The general idea is to progress as follows: 1. Treat each classifier label as a hypothesis 2. Construct prior probabilities for each hypothesis (agnostic of its features) 3. Each feature is treated as evidence and what we learn about the input data is used to update our prior beliefs 

Looking back at our data set, we see that there are 3 features for every city. Let's say you learn that someone is a craft beer drinker, has curly hair and did not vote for BJP.  Which city is he most probably from?

Now we are dealing with encountering multiple evidences which we haven't dealt with before. To be able to apply Bayes' theorem, we will have to make one crucial assumption. We will have to assume that the series of evidences we see are "independent" of each another.

This allows us to apply the following algorithm to update our beliefs: 1. Construct prior hypothesis from the input data set, irrespective of the features (let’s call it priors) For ex. P(Bangalore) = 1000 / 3500 2. Convert the evidences you have encountered into an array (let's call it evidences) 3.For evidence in evidences:          For hypothesis in priors:                    Calculate P(hypothesis | evidence) as we have done before                   Update probability for hypothesis in priors 4. Now, priors will contain our updated beliefs, after learning a set of features about the input data

Generally the hypothesis (classifier label) which has the maximum probability in the ‘priors' array wins and input data is classified as that.This algorithm gives us a very rudimentary skeleton to be able to implement a Bayesian classifier.

It seldom happens in real life, that we encounter data which is independent of each other.However, the Bayesian classifier does give surprisingly good results in many cases. This implementation of a Bayesian classifier raises a few questions: 1. Are there any strategies for picking priors, if we do not have a data set like the one we just saw?  2. Is the best strategy for classification picking the label with maximum probability? 3. Why does the evidence need to be "independent" of each another?

This concludes our series of posts on Bayesian Reasoning. We cannot wait to apply all that we have learned at our first TechBuilders event on 7th.

Before we start employing Bayesian reasoning into software systems, I wanted to dedicate one blog post for some of the philosophical implications of Bayes’ theorem. My intention is to demonstrate how elegantly Bayes' theorem expresses reasoning in a mathematical and computer-program friendly way.

1. Closing gaps in reasoning: In the cancer problem in the first post, most people guess 98% because they fail to consider 2 key factors: a. The fact that only 1 in 100 people actually develop cancer. Bayes' theorem covers this in the prior probability. b. Considering the fact that a person has tested positive under ALL hypothesis. Yes, 98 out of 100 people with cancer test positive, but, what about the fact that 2 out of 100 people without cancer also test positive?  The normalising factor of Bayes' theorem makes sure we take this into account while reasoning.

2. Dangers of having a high prior probability: Referring back to Bayes' theorem derived in the second post, it is interesting to see how the terms of Bayes' theorem affects the posterior probability. Prior probability and likelihood have a direct effect, while the normalising factor has an inverse effect. If you have a high prior probability, your belief in the initial hypothesis will not change by much, unless you see data which is true in a lot of other hypothesis. Therefore, it is highly unlikely you will come across data which will make you adjust your previous belief by much. Giving it some thought, this almost seems like a mathematical representation of the very human attribute of stubbornness.

Before we dive into Bayes' theorem, we will have to understand two basic concepts:

1. Conjoint probability: What is the probability of two events being true? Written as P(A & B). 2. Conditional probability: What is the probability of one event occurring given another has already occurred? Written as P(A|B) So what is P(A & B)? That depends on the type of events A & B. If they are independent events, meaning if A has no bearing on B, it is simply P(A) * P(B). For example, coin tosses are independent events. The output of your first coin toss has no bearing on the output of your second coin toss. Predicting if I will run today is a dependent event. If I run today, the probability that I will run tomorrow is much less. Probability that I will run on a given day, depends on what I have done the previous day. If A is the event that I will run today and B corresponds to I will run tomorrow, then: P(A & B) cannot be written as P(A) * P(B). It should be written as P(A) * P(B|A).

Generalising, P(A & B) is written as P(A) * P(B|A). For independent event P(B|A) == P(B) It is interesting to see that the direction of dependence does not matter. P(A & B) can also be written as P(B) * P(A|B) Equating the two, P(A) * P(B|A) = P(B) * P(A|B) Which gives us, P(A|B) = (P(A) * P(B|A)) / P(B)   This is where the creativity and genius of Laplace and Bayes comes in. They equated A to an original hypothesis and B to new evidence presenting itself.

To think that Bayes’ theorem is just: P(A|B) = (P(A) * P(B|A)) / P(B) Is equivalent to the kid staring at Bruce Lee’s finger, and not the “heavenly glory” it points to.

Bayes’ theorem gives us a framework, a means of reasoning, to update our beliefs in the light of new evidence. It gives the ability to think of a future event not as whether or not it will happen, but to associate a degree of belief in its occurrence. Everyday we encounter problems like the ones listed below, and we either come to erroneous conclusions about them or just fail to incorporate new evidence as it presents itself:

1. You are in another country and you meet a fellow Indian. You begin wondering if he is from Bangalore. Without any evidence, the degree of your belief (read: probability) that he is from Bangalore is Population (Bangalore) / Population (India). If you discover that he voted for BJP in the 2014 election how do you update the earlier probability? What is a systematic, rational and correct way of going about it? 2. Say 1 in 100 people develop cancer. Tests that detect cancer are 98% accurate. If you meet someone who has tested positive, does it mean that there is a 98% chance that he/she has cancer? While 98% is intuitive, the right answer is 33%.

To employ Bayesian reasoning to these and other problems, we follow these steps:

1. We start out with a belief (formally speaking hypothesis) and associate a probability to its’ occurrence 2. We encounter new evidence or data 3. Assuming our initial hypothesis is true, we calculate the likelihood (probability) of this data being true, conditional on our hypothesis being true 4. We calculate the likelihood of this data being true under ALL hypothesis Once the basic components are calculated we can employ Bayes’ theorem to combine them and give us the updated probability of our hypothesis being true given the new data.

Let us take the more serious example of cancer. 98% is the wrong answer because it totally ignores the fact that 1 in 100 people actually develop cancer. Bayesian way of reasoning, gives us the right way of arriving at the correct answer:

1. You meet person A, you hypothesize that he has cancer and the probability of your hypothesis being true is 0.01 2. Then, you learn that he has tested positive, now how do you adjust your belief that he has cancer? 3. First, the likelihood that he has tested positive given he has cancer is 0.98 4. The likelihood that anyone (regardless of whether or not he has cancer) will test positive is 0.0296

Applying Bayes’ theorem we see that we will now have to adjust our original belief from 0.01 to 0.32. I have kept the math out of this blogpost; we’ll address it in the upcoming posts.

So you got a pitch meeting with the Partners of a VC firm? Congrats. This is the real test. Much like what we wrote about in our post on Fundraising 1.1 - The pitch the pitch meeting is also a process of triage. The more time you spend pitching the three important things - You, your idea and your vision for the market, the better you will do with the VC. 

Typically the pitch meeting will be with one or more (usually) General Partners (who are the real decision makers) and couple other Partners/Principals/Associates. Be respectful to everyone and answer everyone's questions to the best of your abilities without discriminating based on who the question comes from. 

A good VC will try to get to know you and your co-founder well early on in the meeting. Focus on telling your story of what made you become an entrepreneur, why you came up with the core idea for the company, and especially what makes you scrappy. Things always go wrong with companies, and the VC wants to see if a bright eyed kid with potential like this 

can become a scrappy champion fighter like Rocky who can go the distance.

Once they get to know you, they want to learn about the product and the idea. Is it well designed, does it solve a need that lots of users or enterprises have, have you thought about how to get it in the hands of lots of users or clients, is there a competitive moat that protects the company from other upstarts or established players? These are the main questions they'd like to get answers for. So rehearse these well before the pitch meeting. 

Lastly, but most importantly, a VC wants to understand if the company is going after a large market or a small one. VCs are in the business of supporting entrepreneurs who want to disrupt large markets. So if they can see this clearly, it improves the chances of getting a term sheet. 

You'll know usually at the end of the pitch meeting if the VC is interested or not, and if they are, you'll get a term sheet soon. 

Have you tried to cold email a VC? Got a VC's business card at a conference and tried to cold pitch him/her? This probably was the result. 

image source: memegenerator.net

VCs are not the 'Soup Nazi' from Seinfeld. You probably didn't get a response purely because of the number of emails that VCs get on a daily basis. Here are some things that have worked for us in the past in getting meetings with VCs.

1. Do your research

Most VCs have a strong online presence. Read their blog posts, articles, tweets, Quora posts, watch their interviews on youtube. This will give you a good idea of what they look for in potential investments and how to pitch them. Write thoughtful comments on their blog posts, interact with them on twitter - and the quality of your interaction will get them in your radar. 

2. Find a strong mutual connection

Look at the VC's linked in connections, who the VC follows on twitter, groups that the VC is part of, and find a strong mutual connection. VCs like deals that come to them through referrals for a simple reason. It is hard to build a startup and often you're competing against a larger company with a very competitive CEO. If you can't even get a connection to refer you to the CEO, its a strong indication that you probably can't compete with competing CEOs. 

3. Quality of referral matters

The quality of the referral to a VC makes a big difference. If you're building an e-commerce startup, then a strong referral from an e-commerce company CEO who has worked with the VC will go a long way in establishing your credibility with the VC. 

One trick that has worked well for us in the past is to get referrals through CEOs of portfolio companies of the VC. When a VC is speaking at an event, quite often, portfolio company CEOs are also at the event. Network with these CEOs and try to get them to refer you to the CEO. This is probably the best way to get a meeting with the VC. 

Despite all of its benefits, developers shun away from Google App Engine (GAE) without giving it a second thought. In the developer community, GAE is perceived to be useful for nothing more than proof of concepts. And yet, we have built almost the entire Haggle backend on GAE. Its safe to say we’ve been very happy customers for over 2 years now, read on to see why.

At Haggle, GAE manages infrastructure administration, which means we get to concentrate on the stuff that matters the most: building the application logic. We run pretty intense map reduce and distributed computing jobs to be able to sweep restaurants in a city, pull user data every night, compute scores for every user vendor combination, generate reports, etc. All these jobs end up employing 10s to 100s of machines, and store data which runs into the giga bytes. And we were able to achieve all of this with a devops team that’s a grand total size of: zero!

Google App Engine is perceived by the developer community to be useful for nothing more than proof of concepts. Lets delve into three prevailing reasons why GAE is seldom considered and see if we can debunk them.

1. "GAE's sandbox is very limiting and I cannot run many custom libraries and frameworks.” This is very true, and could be a very severe limitation. This is also the reason why we have had to buy instances on Amazon to be able to do our NLP. That being said, GAE does offer a wide enough range of services from OAuth to XMPP to MapReduce. Many startups that are just taking off would find that these services are sufficient to fit most of their needs. For the parts of the app which require libraries that are not supported by GAE's sandbox, one can always delegate it to instances running on AWS/Compute Engine, and still leverage GAE's automatic scaling, distributed database, etc.

2. "It gives me no configuration control over the DB, web server etc." Right again, and you have to play by GAE's rules when using their services. However, these web servers and db servers are Google configured and are able to support google's scale of operation. This is something our configurations aspire to, so why not just make use of it now? Yes, this involves effort in understanding how these systems work and the rules you need to play by, but it also eliminates a LOT of days spent in setting up web and DB servers. GAE also eliminates the need to write chef scripts. The code that you upload to app engine is automatically available to any instance which your app might use. With this feature, you’ll never worry about ensuring every machine has the same code base and configurations. 3. “But It can done on AWS as well." Most certainly yes. But I’d rather use GAE's MapReduce, than setup a Hadoop cluster on the cloud. I’d rather use GAE's BigTable, TextSearch, Task Queues than set it up myself. Amazon also has started offering these services, but GAE is much more simple. Take for example how scaling is automatic on GAE; web request handlers are spawned and torn down in a matter of few milliseconds. This really keeps your instance hours cost down and is a lot more efficient than using your own scaling scripts.

Overall, we really urge startups to start considering GAE. The ease with which you can build web services, MapReduce jobs, solve big data problems distributively is un-paralleled in the platform-as-a-service world.