The other day Yanik Silver and Noah Kagan were discussing the value of paying for things. Their conclusion: it can give you a slight advantage.
"I pay for things cause I want that slight edge over others." - @yaniksilver— noah kagan (@noahkagan) January 30, 2012
@yaniksilver 10000% agreed. starting to do more of this. thanks and hi-5 you soon.— noah kagan (@noahkagan) January 30, 2012
These days the things that separate you from the top of the pack and the second tier are so small that anything you can do to get a leg up on the competition is worth it.
Even as a bootstrapped startup we've definitely noticed this as well and it's why we've found it worth it to pay for things that makes us more successful.
Obviously, it's easy to take this too far. If you're bootstrapped you can't start throwing money around like you've raised $10MM from a few powerhouse VCs.
But if you can make a solid return on investment or stay ahead of the competition without heavy expenditures then it's worth the cost.
Using Olark will let us launch our app months sooner and we have way more confidence in success because of the number of people we've had the chance to talk with.
For a measly $50/mo we have better support than 99% of web apps and one of the fastest ways to do customer development. That's an advantage we can take to the bank.
Our upcoming Backbone.js frontend is quite complex. When you consider the fact that we are relatively inexperienced with Backbone, it made sense to start off with an easier, smaller project. This allowed us to focus more on getting the models and collections correct before worrying about views (which, arguably, are the most difficult part of implementing Backbone apps).
So we decided to build a simple Chrome Extension to test the waters and learn a little about Backbone.
To our knowledge, this is the first published case of using Backbone inside a Chrome Extension. Jeffrey Iacono has a published Github repo featuring a Chrome Extension and Backbone from about a month ago.
Part of our design philosophy is that the entire backend be accessible via APIs. This allows us to build different and device-varying frontends which all leverage the same data source. We have a lot going on behind the scenes with Zapier and creating an exposed backend API creates a very clean separation of concerns. We can easily create a desktop application, Android app, iOS app, or even, a Chrome Extension from this API.
As mentioned above, views tend to be the most difficult concept when getting acquainted with Backbone. They are "more convention than code" and as such, you the developer are left to fill in the details. For our Chrome Extension, we have a simple Viewport view which controls the loading and unloading of content views. You can see an example of the first content view loaded in the screenshot. Also note we are writing our Backbone code using Coffeescript, RequireJS, and the Use Requirejs Plugin.
A single corresponding content view might look something like this. Note the element which the content view renders into is passed in from the Viewport view.
There were few surprises developing the Chrome Extension. We only wanted to generate a popup and Chrome can handle this automatically with a browser_action definition inside your manifest.json file.
You simply define an HTML file as the default to load into the popup when your extension icon is clicked. Chrome automatically draws the white bubble background.
One gotcha (especially with regards to Backbone) is that each time you close and re-open the popup, the code is entirely unloaded and then re-loaded. This means if you are using a lazy loading method for your models and collections, they will be pulled from the server fresh each time you click the extension icon.
In a typical Backbone application, you would preload your model and collection data (to be transmitted to the client with the initial website load). This is not applicable to extension popups, though, because all the HTML is stored locally inside the extension. To get around this, I recommend taking advantage of Chrome's LocalStorage API to cache your model and collection data to persist between extension loads.
Another alternative is to persist data into your extension's background page. More details on background pages can be found here. It might even make sense to load the entire Backbone app into the background page when the browser starts and re-render the Viewport view into the popup each time the popup is loaded.
Once you've got your Backbone project completed and rendering via a single HTML file, you can simply package up your Chrome Extension using the built-in extension packager. The extension root directory is the folder which contains all your code and you do not need to define a Private Key. See the Chrome Extension help guide for more information.
Overall, the quick aside to building the Chrome Extension was easy and painless and demonstrates the power of a separated backend API and the general applicability of Backbone to many different frontend views.
UPDATE: There is further discussion over on Hacker News, here
Bryan and I recently attended the REDI Entrepreneurial Summit in our home town of Columbia, Missouri. Since we spend a ton of time interfacing with folks from New York and the Valley we sometimes forget that what seems like common knowledge to us might not be so common for people just getting into tech entrepreneurship.
And since there aren't as many tech startups in the Midwest as there are on the coast there tends to be misconceptions about what is important when starting a tech company.
Most entrepreneurship in Columbia is focused on Biotech and Life Science where IP is a huge deal so most first time entrepreneurs are told to be worried about it.
In reality IP plays a very small role in most tech startups. Sure it's something to keep in the back of your mind, but in a startup you have a million other things more important than IP.
To quote Aaron Sorkin's Mark Zuckerberg from The Social Network.
If you had invented Facebook. You would've invented Facebook.
I think we can agree that most of us would rather be Zuckerberg than the Winklevoss twins.
You need a business plan before you get started. Usually said business plan must be a behemoth 20 page document outlining plans and ideas for starting and growing a business culminating in millions in sales by year five.
In reality plans never work out especially in a startup. The market shifts, your assumptions about distribution are all wrong, beta customers hate v1.0 of your product, and what you thought would be true turns out to be totally wrong.
Instead focus on planning not plans. A good place to start is Alex Ostewalder's Business Model Generation book.
Create a one sheet business model and iterate until you've found something that works.
A lightweight, one-sheet business model feels much easier to change than a bulky 20 page business plan and you'll be much more agile because of it.
Many first time tech founders feel like all they need is a few developers to build the app and then they'll be ready to make millions of dollars.
Most developers are busy and have a million ideas of their own. Convincing them to work on your idea is going to be really tough. As a first time founder with little experience it's going to be even harder.
In the above scenario the developer is also taking all the risk. Why should they be required to spend months on a product that may never work?
Instead, it's best for a first time tech entrepreneur to either a) learn how to code well enough to build out a prototype or b) generate enough pre-sales that a developer can be sure that when the product is built money will come through the door.
First time tech founders love to talk about seed rounds and angel funding as a launching point.
There are hundreds if not thousands of good deals for investors to invest in. Why should they invest any amount of money on a first time tech founder with no product and no customers?
Instead spend your time building out a prototype and selling your first customers. An investor is much more likely to give money to someone who has proven they can build something without money in the first place.
So if you aren't spending time on these things what should you be spending time on?
Two things: Product and Customers
If you have a product built that customers are willing to pay for all of the four issues above will take care of themselves.
- Sure someone might try to steal your IP, but you've got a product and customers with the market cornered.
- Business Plans? You've managed to build a business already!
- Need more tech help? Hire it. Plus you know a thing or two about building a product yourself now.
- Investors love to knock down doors to fund an idea that is already generating revenue.
So get out, sell those first customers, start building a product and the rest will follow.
If you spend any time doing SEO or PPC you're bound to have spent time in Google Analytics pouring over keyword data. However, if you're like me and mostly spend time doing product development, keyword data can be a bit foreign.
Sure you might crack open Google Analytics and take a peek at traffic sources, major keywords or trending data.
However, if you take a closer look at your keyword data you might find a treasure trove of information you can use right away to improve your product or site.
When a user can't figure out how to use your site guess what happens? They turn either to 1) your help forums or 2) Google.
To find these issues you'll need to dig deep into your keyword data. I always toggle "show rows" to 500 so I can see as many keywords as possible at one time.
Then just scan quickly over keywords to see what might indicate a usability flaw in your application.
For example, keyword #317 in the Zapier analytics account is "Zapier guid." At first I didn't recognize what "guid" was so I thought perhaps we have a spelling typo somewhere and misspelled "guide" with "guid."
On closer inspection I realized we had a form field for our Evernote Integrations called "guid" that was confusing users.
We quickly changed the label so that users weren't confused about form. A five minute fix.
If your site has been around for a few months and has a decent amount of content it's probably starting to rank for some long tail keywords. Check your keyword data to see if people are finding your site by asking questions (i.e. "how can I...." or "does this do...." or "where can I....").
Using this method I can see that Evernote Jira Integration is one of the most popular integrations that we don't yet support. Guess what we'll do next?
Similar to new feature ideas you can also find completely new product ideas using the same methods as above.
What to look for is any keywords that might demonstrate a pain point in the market. For instance I notice lots of people finding our site searching for a bug tracker with Google Calendar support. One might conclude that a bug tracker with a better calendar system baked in could do quite well.
The key to doing this sort of research is patience. You need be willing to scan potentially thousands of keywords to find some gems. The good news is it doesn't take much more than a few minutes to scroll through a page of 500 keywords so you can cover ground quickly.
You also don't need to do this all the time. I only dig deep into keyword data once every few months, but each time I do I find something that can help us out.
These are just of a few of the tactics I use to find product development ideas in keyword data. If you have any more please share!
Get new articles about productivity, company building, process delivered to your inbox once a week.