The Causal Karmic Universe
I was at Vail this weekend skiing with my dad. It was a pretty great weekend Towards the end of the day on Saturday, I’m coming down towards Golden Peak and I stop on a small landing. I turn around and look for my dad, and I see some other guy coming towards me slowly. Staring straight at me. He stops a couple feet from me and just keeps staring. After about 5 seconds I put on a smile and ask him: “Hey man what’s up?” To which he responds in a very thick Brazilian accent “Did you say something?” Maybe he didn’t understand me. “Yeah man what’s up?”
Within 45 seconds we had gone back and forth about 6 times, and I found out that this kid thought I had flew by his girlfriend on the slopes, yelling at her for being a beginner skier. He was pissed. He was swearing at me: calling me a pussy and telling me I should be the bigger man and not yell at girls. My dad had arrived in the meantime and just stood there quietly confused as this dude skied at away yelling unintelligible things.
I wasn’t yelling at his girlfriend. I don’t even know who he was referring to. But here’s the kicker: at that moment he came up to me, I was in a terrible mood already. I had just gotten an email that really pissed me off, and as I skied down the mountain, I was yelling at my buddy in my head. Ok maybe I was actually yelling at my buddy outside my head — I’m sorta crazy like that some times ;) So he did hear something, and they were mad words, but it was just me crazily talking to myself.
Looking back, I feel really bad about the whole exchange. People hear the word karma and think that it has to be non-causal, i.e. if you don’t hold the door open for an old lady, 2 weeks later you’ll get a few parking tickets. This exchange reminded me how directly causal karma can be. At that moment, I was pissed and looking for a fight. And without even trying, the energy I was putting out managed to find a fight for me. It didn’t turn into anything serious. The kid skied away and I never saw him again. But I started to think about the effect it could have had on his day. He could have forgotten about it. Or he could have gone out to dinner that night with his family and retold the story of the asshole American who yelled at his poor girlfriend and was “a pussy” for denying it. Maybe that one little misunderstanding cascades all the way back to Brazil when he goes home. He friends come back next year expecting all us Americans to be assholes. They yell at an American beginner skier. The cycle continues.
I try to practice mindfulness, but I’m not perfect. This was a potent reminder that the next time I’m mad, I need to stop and think about how my energy doesn’t just affect those close to me, but also random strangers.
“Simple” Vertical Applications
There was a lot of talk on the TED stage last week about technology. Elon is building electric cars and taking us to Mars. Larry & Sergey are putting A.I.s in those cars to drive us around. In a few years , I’m pretty sure my iPhone will be replaced with some kind of wearable watch/eyeglass couplet. Technology is incredible, and while it has already drastically changed the world in my lifetime, I feel it will continue to surprise me for the next 60 years — or the next 100 years if some of this bio/nanotech comes to fruition ;)
But there is still a lot of room for the growth of the “simple” vertical application. When I say “simple”, I put it in quotes because it only appears simple. The builders worked hard to make it that way. When I say vertical, I mean specialized for a specific use case. To give contrast, a “horizontal” app would be a text editor or a spreadsheet or Trello. When I say application, I’m primarily referring to some kind of web application. It might have a website. It might be an iPhone app. It might have both. It might be a service you sign up for and never login to again. It might be a service you use daily.
I started college as a Physics major believe it or not. I’ve been fascinated by the Einstein-Planck duality since I was 14. But in my first year of college, I took an introduction to Electrical Engineering, learned what this is, and was equally fascinated:
This diagram shows two high-pass filters. You put some RF energy into where it says J1, and what you see coming out of J2 will have all the low frequency energy removed. The Cs and the Ls are capacitors and inductors. By changing the value of those capacitors and inductors, you can fine tune the “cutoff” frequency under which the signal will attenuate. You know how small headphones never have good bass response? That’s because they are high-pass filters (not on purpose, but as a result of how they are built). The low frequencies (the bass) don’t make it through. Then I learned about high-pass filters, which are equally simple. Then I learned you could chain the two together to get a band-pass filter. This is how old car radios work.
What fascinated me about all this was that there was no “technology”. There was no computer. It’s just a few passive analog components. Behind the scenes, there an absurd amount of mathematical theory, but on the surface, that was it. Just a couple components on a circuit board and suddenly you were able to isolate signals out of the RF spectrum.
Signal from noise.
“Simple” vertical applications are the band-pass filters of the internet technology world. They seem simple on the surface, but there can be a surprising amount of thought (theory) that goes on behind the scenes to figure out exactly how to build them. Their job may only be to gather & filter data in a certain way, but that doesn’t make the information coming out of those systems any less important.
I’ve been working on this thing called Ramen lately. Ramen is a fundraising platform for software startups, but instead of just allowing projects to crowdfund, we provide a robust toolbox of collaboration features that the project owners can use to work with their backers (who are really customers) to ensure they are building something the customers want.
VelocityKick is a project currently funding on Ramen. VK is solving a problem that all teams running crowdfunding campaigns run into: you want to email your friends, but your team of 4 people has some of the same friends in common. Your contacts are spread out over different areas. They have different levels of expertise. Some are potential users, others are just friends. Some are your buddies that you just need a favor from, and some are business connections that require a more formal ask. VK helps teams merge their contact lists, filter the contacts based on these various criteria, and then exports lists to be emailed.
It recently dawned on me that it is the quintessential “simple” vertical application
VK has a straightforward input phase (The J1 on the diagram):
A user creates a team by sending them invitation emails
Team members upload their contacts to VK
Team members also give VK access to their social networks
VK then sucks in all those data and gives the Team Owner a consolidated view of all the contacts reachable by the team
VK has a straightforward filter phase (The Cs and Ls on the diagram):
The team owner can filter the contacts based on a bunch of criteria (# of FB friends, total social reach of the contact, location, # of team members connected to the contact, etc…)
VK has a straightforward output phase (J2):
Click export and download a list of email addresses
It may seem “simple”, but this application will save project teams tens of hours and allow them to be more effective running their campaigns.
“Simple” vertical applications are the band-pass filters of the internet technology world. They may not be self-driving cars or rockets to Mars, but they have the ability to pull the signal out of the noise. And in todays world of ever-increasing noise, we need them more than ever. Don’t trivialize them. Respect them. Use them. Build them.
Note: Velocity Kick is currently funding on Ramen and has one week to go. If you’ve ever ran a funding campaign (actually if you’ve ever launched anything), then you probably have experienced the pain they are solving. Go throw them some cash to help make the product a reality.
 Joel Spolsky gives a great write-up of Trello, a horizontal app for managing lists of lists here: http://www.joelonsoftware.com/items/2012/01/06.html
 Passive means we don’t supply any power to them. There are no batteries in the circuit diagram above.
 Yes, I will continue to put “simple” in quotes for this entire post, because these apps are never truly “simple” ;)
The Rise of the 3rd Party
Back in 2008, the idea of using a 3rd party service in your web app was a little scary. What if the service went down? This was back in a day where all of EC2 could go down for a day. A day when CloudFront would throw the occasional 500 serving your assets. You’d even run your own Postfix instance because you didn’t trust anyone to send your emails for you. To say things have changed is an understatement.
Right now, we use a lot of 3rd party services at Ramen. Some are non-critical. If they fail, the app will continue to work:
- Google Analytics
Some are critical path. If these fail, our app degrades significantly:
- LinkedIn (authentication)
Some are outside of the app and either used 1 time or used operationally to help run our business:
There are some services that I use so often, that even though I’m currently using one (I’m writing this in a Google Doc), I forget it’s a 3rd party. Other services in this class include:
- And, by definition, I’m forgetting some :)
As part of the LAUNCH Hackathon, we received a massive amount of credit on Digital Ocean. Had we not received all that credit, there are other 3rd parties we’d be using:
- Wordpress (critical path)
- Redis To Go (critical path)
- MongoHQ (critical path)
- Memcachier (critical path)
In the not so distant future, there are other 3rd parties that we will probably be using:
- AWS Elastic Transcoder or Zencoder (critical)
- SnapEngage (non-critical)
- Twilio (possibly critical)
- Hubspot (operational)
- This list goes on….
The rise of the 3rd party will continue. While there are already 3rd parties to pretty much handle everything, overall usage of these services will continue to increase. In the not-so-distant future, a small 3-person tech startup could be using upwards of 100 3rd party services. This may sound like a massive headache to a small team:
- “Where do we save all those passwords?”
- “Are we really going to be getting 100 small charges per month on our credit card? What if the card is canceled!?”
- “This can’t be an efficient use of capital. Shouldn’t our developer be doing work instead of just spending money on 3rd parties?”
To those, and to many other concerns, I have two things to say.
First, don’t be afraid.
Don’t worry about managing all these services. Someone will come along with a service to manage it all for you :) Heroku is already technically doing this. This is by no means a supported use case of Heroku, but you can actually run an application on Digital Ocean, and still use Heroku as a 3rd party management and consolidated billing service. Instead of $30/month for a second dyno and $30/month for a worker, you can run a DO box for $5/month (depending on how much memory your application needs) that can accomplish the same.
Second, don’t fight it.
This is an efficient use of capital. Lots of these 3rd parties have free tiers. Some are as low as $3/month. Looking at it purely from a development perspective, it is worth it. If you have a pretty good full stack developer on your team, that gal or guy could be demanding over $125/hour for contract development work, so spending $9/month to save them 2 hours developing a feature is already worth it. After those 2 hours, they’ll have to maintain it. It’ll break. They’ll have to fix it. So in a year, those 2 hours could become 10 hours pretty quickly.
But you shouldn’t look at it from just a development perspective. Your team has to sit down and actually design that product too. So now you’re talking about saving designer time, testing time, and overall you save brain cycles. I don’t care how smart you are, your small startup will never build an error notification system inside your app better than the people at Rollbar. They sit around thinking about exception monitoring all day.
There are always exceptions and tradeoffs. We chose to run our own instances of MongoHQ, Redis, and Memcache instead of using 3rd parties. That is seemingly against the spirit of this post, but that decision was the result of a multivariate optimization problem regarding our specific application requirements, the price points involved, and my relative proficiency in running these services. Your situations will vary and, in general, I highly recommend services like MongoHQ for hosting your database.
Third party services are on the rise, and will continue to be on the rise faster than ever. Embrace them. Use them. Make them. Give them feedback. And, most importantly, pay them :)
Don’t say “I’m looking for developers and designers”
It’s a phrase heard often in tech circles. An entrepreneur has a great idea, has thought through the details, has even reached out to a few potential users/customers and has received feedback that “Yes, this is a great idea and it will make money.”
So naturally, it is time to go build a team. It doesn’t matter what your business is, building a team will be hardest thing you do along the way to success. No questions asked. So you owe it to your team and yourself to take the time to really think about what you need.
- Do you really need developers _and_ designers?
- Do you really need multiple of each?
- You really need multiple designers? Do you have any idea how difficult it is to manage multiple designers?
- What kind of designer? Graphical? Interaction? UX?
- Could you get away without a designer for a while?
- What kind of developer? Web? Mobile? Computer vision?
As an non-technical entrepreneur building a team, these are questions you should think about as frequently as you think about your pricing model, your market size, and your G.t.M.S.
In most communities, there are more ideas than developers, so it’s understandable that you might not find exactly what you want. But if you haven’t taken the time to properly define what you need, how are you ever going to get anywhere close?
Here are some examples:
"I need a developer who knows the basics of database-backed web-development and modest front end development skills"
"I need a graphic designer to produce a series of assets that will be used in a web-based application."
"We need a mobile developer that can create a prototype mobile application (iOS or Android) that will gather data from multiple sources on the Internet."
Your phrases will vary, but I hope you get the idea.
And don’t think people looking for other roles are off the hook. This logic applies to all roles within an organization. So, developers, the next time you want to tell someone that you “need a marketing person” or need “someone to do business”, stop and think for a minute (or a few hundred minutes) about what you really need ;)
 Go to Market Strategy
Storytelling is not just for pitching
When you have a new idea, the sky is the limit. There are a million avenues to take. There are scores of potentials users. In the early days of business formation, you want to tell your friends, and the world, what you are doing. You want to tell them everything you’ve thought of; you want to explain all the possibilities.
However, waxing philosophically and mentally dumping all your thoughts on everyone you meet in those early days is a recipe for confusion. I witnessed this at CU Boulder Startup Weekend this past weekend. It was refreshing to see all that unbridled youthful entrepreneurial energy. But that energy was a double-edged sword. Within 60 seconds of hearing these entrepreneurs speak, most lost me. Not because they were stupid or inarticulate. They just didn’t yet have the ability to succinctly describe what they wanted to build.
A business will have many narratives. In some development methodologies, narratives (or User Stories) are the core unit of work of the requirement/development cycle. But I’m not talking about those narratives. To enumerate every possible narrative for every possible use case will just put you back where you started. It’s important to define the most important, core, simplest one first.
For your first narrative, tell the story of how a customer would first benefit from your business. “Joe is in this situation. He comes to our business and the first thing he does is X.” If your idea is a marketplace, then both sides of the marketplace need to be addressed in the narrative. In that case, include the story of Sally: “After Joe does X, Sally (who is in this other situation) comes in and does Y. Eventually they do Z together.” Don’t worry about the business details in these narratives. This isn’t your one shot at pitching that awesome investor. Don’t worry about the pricing model or the market size. Don’t worry about your competitive advantage or the incredible experience among members of your team. Don’t talk about the innovative and brilliant marketing strategy that will get Joe & Sally to your business in the first place. In that first narrative, don’t talk about the secondary and tertiary businesses that Joe & Sally will be able to participate in 2 years from now. Just tell the story about what it is that Joe & Sally do first.
Narratives don’t just help you tell a story to someone else. In the early days, the most important function a narrative serves is to act as an interactive tool to help you decide for yourself what you’re actually doing.
How do you get started? Just open up a Google Doc & get a whiteboard and start drawing stick figures & lines with arrows. Write out a script in PoP (Plain’ole Prose). You shouldn’t need more than an few hundred words to get your point across. If it feels too short, you’re on the right track. If you left out several Really Important Things™ about XYZ that will happen later, you’re on the right track. But most importantly, if during the process of writing it, you have an “oh shit… that’s something we didn’t consider” then you’re well on your way ;)
Writing about the obvious
Brad Feld published a blog post today about writing. I struggle with writing. On one hand, I want to write to codify and share my thoughts. But once I start, I almost invariably start down a path :
- I’m wasting my time;
- People have heard this before;
- I’m not contributing anything worthwhile;
- Did I just change my mind?
- What am I even writing about again?
- How many times have I re-read this?
But there are two things that I (and you, if you have the desire to write) need to remember:
First, the great writers that inspire me probably didn’t get there on their first thousand words. They probably wrote for a _long_ time before getting to a point where they could succinctly describe their thoughts. Not that being a great writer should be the end point for every blogger, but being able to logically compose & succinctly present a thought should be.
Second, there are always people being exposed to ideas for the first time. For now, and for the foreseeable future, there are going to be more people younger than me than there are people older than me. And while I don’t necessarily expect to be enlightening anyone directly on this blog, I do want to be able to clearly describe my thoughts when I run into these people in person.
So for the next few months, I’m going to try something: I’m going to write a lot more. I’m going to write about all the stuff I used to think was too obvious to “waste” my time with. I’m going to write about how I think AngelList syndicates are going to decimate the lower tier of venture capitalists; I’m going to write about how every single startup team that doesn’t take team personality tests is asking for disaster; I’m going to write about how fish oil is a must have for anyone who finds themselves routinely sleep deprived. I’m just going to write.
Game Changers: Elon Musk — I really like this guy.