I couldn't figure out his/her comment either!
1,590 karma · joined July 22, 2010
CTO of Endgame.io, ex-founder of Keen.io
made @hipsterhacker, @techcrunchonion, and some other tech comedy stuff that would be more incriminating were I to share it ;)
I couldn't figure out his/her comment either!
What do you think of it?
We'll edit the blog post to add a bit more background
update:
here's the working copy:
--
We make three kinds of APIs:
-data collection APIs
-data analysis APIs
-data visualization APIs
For instance, if you had a social-local-mobile shopping app for the iPhone, you'd probably want to insert a rich event into Keen every time a user does one of the following actions: opens the app, does Facebook connect, likes/comments/shares an item, adds an item to their shopping cart, and completes a checkout. You send us this data using the collection APIs (https://keen.io/static/docs/data_collection/data_collection....)Once your app is sending us stuff, your product manager may ask you to make her a little analytics dashboard, so she can agonize over it every morning. For instance, this dashboard could have answers to questions like "How many people opened the app each day over the course of the last week?" That question (and many way more advanced ones) can be answered using one of our analysis APIs (in this case, the Series API https://keen.io/static/docs/data_analysis/series.html)
Finally, suppose a few weeks later she's tired of staring at numbers and wants to see this information graphed visually in a line graph. That can be done using our visualization APIs (not yet released).
If, as a founder, you give up so much equity that your option pool is totally depleted at the next funding round, then 10-20% will need to go to an option pool top-of -- and there's that much less equity to sell to the new investors, meaning less cash can flow into the coffers. Spending equity costs the company cash.
Meanwhile, if you spend double the cash of another startup in the same stage, your runway depletes doubly fast, and you need to raise sooner. Spending cash costs the company equity.
A lot of people merely clicked the "up" arrow and refrained from comment, and so far about 3000 of the post's readers have clicked through to our main site ;)
If you're curious about Michelle's reasoning, check out one of her other posts, "Why I Left Consulting and Joined a Startup": http://blog.keen.io/post/26096112831/why-i-left-consulting-a...
I actually had this issue bite me in the ass at my first startup, where I was offered a flat # of shares.
I was pretty much fresh out of college, but for the record, I did realize it was important to find out what percentage I was actually getting. When I asked what the total # of shares outstanding was, the company snaked its way out of answering the question directly. The job had a lot of perks (a big title, very respectable pay, work-from-home, greenfield development), so I took the offer rather than press the issue.
Eight months later, we were acquired. I was the only engineer. You could say I was a bit peeved to learn how little of the company I really owned.
Our reasoning:
All else being equal, people often choose a longer daily commute, usually to save money. But, as research* has shown time and time again, once basic needs are met by compensation, the factor which correlates most strongly and consistently with unhappiness is commute time.
What we're attempting to do with the proximate living bonus, then, is to incentivize happiness: We're intentionally designing our bonus structure to incentivize the better decision, which employees might otherwise neglect for a number of (irrational) reasons.
*Here's a good intro into the research on this topic: http://www.huffingtonpost.com/kirsten-dirksen/happiness-rese...
In my mind, startup-ness is not about size, but about culture. You've got invaders and you've got occupiers. Invaders have to improvise, have to be agile, have to seek out a better way because they have no incentive to uphold the status quo. Occupiers just keep doing what they already do, optimizing it perhaps, but never truly innovating. There are 40-person companies out there who've already become occupiers, and there is one 400 billion dollar giant who is arguably still in invasion mode.
I also like Eric Ries' definition: a group of people operating under conditions of extreme uncertainty.
I'm not sure the OP understands that fact.
How many of these cold emails have you sent? To what extent have you varied the copy in those emails? Are you just asking for something, or are you offering something as well? Have you gotten advice from other successful hustlers (concretely, talk to some seed stage founders for hustle ideation; abstractly, read How to Win Friends & Influence People at least once per year) on what you might want to put in the email?
What about non-email channels? Have you gone through Twitter (This is how I've met multiple investors and advisors, totally cold, with no friendly introduction.)? How about crawling toward them meticulously through LinkedIn? How about networking via HN? Have you tried hanging out on relevant IRC channels? Have you contributed to their questions & answers on Quora?
I don't mean to be overly critical here. The OP is a great example of inbound marketing hustle, and I commend you guys for it. Two of the key ingredients in startup success are determination and resourcefulness. Clearly you're resourceful, now crank up the determination a notch. Right now it sounds a bit like you've found good excuses not to keep trying. If you can't land a Skype call with someone who might be able to help you get noticed by YC, what evidence do we have that you're going to land a Skype call with a key distribution partner in six months?
Keep trying. Keep swinging and striking out. You'll see patterns. You'll improve. Eventually, you'll start making contact.
All good points. You're not alone: I think most teams apply to accelerators for some blend of validation, cash, and credibility. In my mind, however, none of those facets is as important as education.
If a seed stage startup only has 2-3 people, they're certainly missing some competencies, contacts, and personality types that could greatly increase their chances at success. Nothing beats having the engaged mentorship of super smart people, people who have seen the world from other angles and can pinch-hit to help round out the team.
In our case, we're three capable software engineers, and we're building something really cool... but had we not gotten exposure to TechStars, our deficits in areas like go-to-market strategy (we had thought, "But it's applicable to every vertical!"), varied communication ("Our customers are excited about it, so of course investors will be!"), plus a million things to come, would've been much more encumbering at best, fatal at worst.
But it'll be hard to convince politicians that the voting booth is in play directly. In fact, after seeing Lessig on the Daily Show last week, it'll hard for me to be convinced:
http://www.thedailyshow.com/watch/tue-december-13-2011/lawre...
The GoDaddy victory is a red herring.
That GoDaddy reversed its SOPA stance (or at least its PR stance) about SOPA in the wake of our boycott is good news, but it's also distracting news. While it does demonstrate that we, the citizens of the righteous internet, can have P&L impact as consumers in the B2B world, the real and massive culprits have been B2C companies.
A very small proportion of a normal B2C company’s revenues come from policy-aware internet citizens. Tactics like the GoDaddy boycott simply will not have an impact (any more than the ongoing boycott of Wal-Mart among the idealistic).
_I don't want us to get distracted from that fact._
_Here are the questions we should be considering._
What can we do to flex our muscles before the many (far more evil) consumer-facing companies out there? How do we legally channel our energy into harming their P&L statements in an unequivocally attributable manner? What about the B2B companies over whose procurement processes we regular citizens have no control?
The companies of greatest concern should be those with contractual and/or infrastructural lock-in:
* telecoms like AT&T and Verizon
* ISPs/media pipes like Comcast and Dish Network
* top-down sales companies like Microsoft and Symantec
* conglomerate-monopolies like Adobe and Autodesk
Unless and until we find a way to hamstring those attacking monsters, the internet will always be in peril -- even if we somehow win this battle like we _barely_ won the Net Neutrality battle a few short years ago. http://hackermonthly.com/xmas/hackermonthly-issue00{1..9}.zip
http://hackermonthly.com/xmas/hackermonthly-issue0{10..19}.zipPythonic code is meant to be modular, which leads to extreme explicitness. For example, while `string_utils.capitalize(my_string)` is a bit more longwinded than `my_string.capitalize()` in JS or even `my_string.capitalize` in Ruby, this minor bit of ongoing typing overhead will yield a beautifully explicit codebase over time.
By comparison to other dynamic languages like Javascript and Ruby, Python codebases scale effortlessly and beautifully and without the limitations of "How much freaking online documentation do I need to read to locate the imperative code that's actually running?". While that sort of necessity is the mother of beautiful documentation design you'll find in (and the ascendance of great doc writers among) the Ruby and Javascript communities, I believe its technical risks outweight those tertiary benefits. Extensive and explicit documentation is a necessity that Python does away with entirely, because the code is itself explicit. Python does this at the cost of some convenience and developer happiness. Whereas I give Ruby a 10/10 in the "day-to-day comfort" scale for us dynamic developers, and where Javascript has perhaps a 7/10, I place Python squarely at 9.
By comparison to static high-level languages like Java and ActionScript (and some dynamic languages like Perl and PHP) classical, Python is of course a breeze to write.
As a result of this explicitness, when using a Python framework, you'll rarely need consult documentation or outside advice just to find out what's happening: It's all in the code, and you just have to follow the imports and method calls down the stack.
This modularity also means Pythonists totally avoid collisions in namespacing: whereas the global namespaces of Ruby and Javascript tend to lead to headaches in large codebases, Python is built on the idea of package-as-namespace (directories) and module-as-namespace (.py files)