Apple, Hopstop, Locationary

A lot of people have asked me over the last few days what I make of Apple buying both Locationary and Hopstop in the same week. As someone who founded and ran engineering at a local data company, my opinion is likely biased, but I say it’s an important move by Apple that, with effective integration, will allow them to improve Apple Maps and other local product offerings in across dimensions.

Local data is measured on three axis: breadth, depth, and quality. Breadth consists of how much data you have. This is the easiest problem for a company like Apple to solve. They can buy or license local data from various providers – essentially just throw money at this problem and solve it quickly. Depth and quality on the other hand require much more time, engineering, and multi-pronged strategy to really live up to what users expect.

The Hopstop acquisition is a direct investment in depth (or how deep can you get on one specific attribute of local data). Hopstop immediately gives Apple best of brand support for intercity transit directions – something that is required to compete with Google Maps public transit integrations. How can I get from point A to point B is a very common mobile query, and trying to build a system that answers this yourself requires going city by city, datasource by datasource, deal by deal. Hopstop has been doing a great job of executing on this for years, and will likely to continue to do so with Apple’s resources at their back.

Based upon what I’ve read since the Locationary acquisition, I assume that this is an investment in data quality. Their CEO wrote an amazing post for Techcrunch a year ago outlining the technology required for maintaining high data quality (similar to what we built at Hyperpublic), and it looks like they’ve invested heavily in crowdsourcing to ensure freshness in their data. Combining technology + the crowd is necessary to make progress on this problem.

Unfortunately you can never fully win at solving the local data challenge because you’re working within an ever changing world where the data just isn’t always available digitally. The best you can do is show constant improvement on the breadth, depth, and quality axis and use the right mix of team + technology + crowd to keep chugging along. I’m happy to see Apple recognizing the importance of investment in this area. Congrats to the teams at Locationary and Hopstop.

What Happened To JumpPost?

I frequently get emails from people looking to use the JumpPost product that we launched a year ago to help find a new apartment. This post explains what happened to JumpPost and why we aren’t running it anymore. In case you weren’t familiar with JP, the model was that we would pay vacating tenants $500 to list their apartment with us, if we found someone to sign a new lease on the apartment. Apartment hunters could search in advance, not compete with the craigslist crowd, and not pay a full broker’s fee, and vacating tenants could make $500 for doing very little work.

When Jordan and I were starting a company we wanted to build a large “local” product. At that time our ideas weren’t fully formed yet, but the vague way to describe it would be a Craigslist 2.0. We had studied marketplaces and attempts at better craigslist-type products, and we knew that you needed a unique model to create liquidity within one channel before you could just launch a craigslist with a better UI. So we looked at real estate as the most valuable vertical within craigslist, and came up with the JumpPost model as our “in”. We also knew that we would need a significant amount of capital to go after a huge marketplace, and to attract the capital we’d have to prove our team, product, and revenue generation abilities before we could raise financing.

JumpPost was quite successful for an early stage company in that it was generating revenue right away. And the whole time we were working on it, we were constantly trying to figure out how to expand it beyond just the unique real estate value prop that we were offering. Unfortunately its blessing was its curse in that the model was so specific, that if you added any more categories or even other types of real estate, people would be really confused about what to do when they landed on your site. They wouldn’t know why they could earn $500 for listing and showing an apartment, but nothing for listing and selling an old ipod or furniture.

So if we just continued on with JumpPost under the $500 incentive model, it would have likely been very successful if you measure success as owning a real estate brokerage which generates $1000+ profit on almost every apartment that you transact through the site. You have to also be excited about being “on the ground”, handholding every deal from start to finish, dealing with multiple parties on every deal, and losing out on a lot of deals you put work into. This can scale into an NYC only multi-million dollar business if you work long and hard at it.

But as Justin Timberlake let us all know: A million dollars isn’t cool…You know what’s cool….?

We’re internet entrepreneurs, developers, hackers, product designers. We want to change the world. We’re not real-estate agents. After we proved that we could execute on a local marketplace, build product, etc, we were able to pitch the big vision which was now much more fully formed. Outside investment was raised, and the seeds for Hyperpublic, a local data platform, were planted. The decision wasn’t made overnight to just shut JumpPost down. We certainly debated about modifying it, letting someone else run it, rolling the new product under the JumpPost brand, but in the end with the help of our advisors and network, we decided it best to focus on the enormous long-term opportunity.

At JumpPost we were focussed on making money in the first month, and at Hyperpublic we won’t be focused on it within the first year. But if we succeed, we’ll change the world, and that’s what gets us really fired up to work the long hard hours that it takes to run a startup.

Advice for college computer science students interested in entrepreneurship

This past Friday I took part in a panel at Penn’s computer science department designed to help students figure out what options are available to them career-wise post graduation. The panel was excellent and included representatives from big tech companies, big finance companies, graduate research programs, startups who had already grown and had a successful exit, and early stage founders such as myself. A lot of great advice was handed down through the Q&A session in particular, and I figured it would be good to summarize some of the best advice for college computer science students who are interested in entrepreneurship.

Build a web presence

This was echoed over and over again. One of the best parts about college is that you aren’t burdened by a nine to five job, and you actually have time to work on projects. In many cases, you can actually receive credit for such projects. Use your senior design project, your independent research projects, and even project based homework assignments to enhance your web presence. Spend a little extra time putting up a simple web site to collect and show off your work. If appropriate, open source your work on github and contribute to active open source projects. Start a blog to document your entrepreneurial endeavors and instincts.

Whether you’re looking for a job at a startup, or elsewhere, simply pointing to your web-based project repo or your github account will be 10x more effective than emailing over another one-page resume.

Learn systems – take the hard, project based classes

Operating Systems, Databases, and Networking should all be required for anyone looking to build applications. Why they are sometimes electives are beyond me. Take these classes, work through the projects, and what you gain in experience will pay off for your entire career.

Get comfortable with a scripting language

Many good CS programs eschew practicality in favor of teaching the fundamentals and core concepts. This is a good thing as the current popular languages will go out of style at some point, but the core concepts never will. But just because the CS departments may teach you Java or C++ doesn’t mean that you are stuck programming in them forever.

Many startups use scripting languages like Python, Ruby, and PHP, as well as the accompanying popular web frameworks that go with them. These languages, although not the most performant, contain great high level standard libraries allowing you to accomplish many useful tasks in just one or two lines of code that would otherwise take 30 in C++. You can easily and quickly write scripts to solve many of your problems, and you won’t have to worry about complicated compilation or deployment setups. Spend time learning and using one of these languages for your senior design or independent research projects if your program doesn’t use them in any of your classes.

Graduate

If you start a company during college, it might fail. Most startups do. What you learn at college, in and out of the classroom, will benefit you your entire life. Most people don’t look back on college and regret staying the full four years.

Sub-matriculation can save years off of the immigration process for international students, which can be especially helpful in working towards entrepreneurship

This was a great practical piece of advice that apparently many undergrads aren’t aware of until after the fact. I’m not familiar with all of the immigration laws and processes, but the gist of the advice was as follows:

With a bachelor’s degree you need to be sponsored by an employee to remain in the US, and you likely have to stay with that employee or find another big company sponsor for a period of 7+ years while you work to earn your green card. It’s hard to make an entrepreneurial move in the US during this process. However if you sub-matriculate into a 1 year master’s program, then you cut the process from 7+ years to about 1.5 years. If you have the flexibility to spend one more year on campus, it can be worth it just in the immigration benefits alone.

Getting funding for your college startup can be difficult if you go the traditional VC route, but there are options

Programs like YCombinator, Techstars, and Dreamit are perfect for recent college grads. You have a smart and scrappy team, no overbearing life commitments or costs, and the ability to relocate to the best possible environment to launch your company. Big-time investors will look for proven leadership teams, past experience, and market intelligence and connections when making million dollar investment decisions, and this likely doesn’t describe the team comprised of your dormmates. But the accelerators mentioned above are looking for smart teams working on hard problems. This is right up your alley, and they’ll lead you to the connections you need later.

The above is just some of the great advice that was given. If you are a college student and you have questions about working at a startup or entrepreneurship, email me anytime at petkanics@gmail.com, or hit me up on twitter @petkanics.

How long until my prototype is ready?

This post is part of the Nontechnical Founders Series – a set of posts aimed at helping would be nontechnical startup founders get answers to their questions around the technology side of starting a company.

In previous posts I’ve written about collecting the right resources in order to launch an internet product. I covered skills your technical co-founder or contractor need to possess and what technologies they should be comfortable with in order to move quickly and create a solid foundation from which to grow your company. The next logical question is, “How long will it take the team to build the product?”

As with everything, the answer is that it depends on what type of product you’re creating. Let’s assume that you’re building the usual data driven web application, and that there’s not any core deep technical IP requiring unending research. Let’s also assume that the product is being built by one core developer (either your technical co-founder or your hired contractor) with rough competency in all areas of the development stack, and a contract designer.

The short answer is that you should push for your product development to move quickly. It’s no secret that I’m a big fan of releasing early and often, and as such, it’s not necessarily important that the “release” version of your product contain every single feature which you’ve been dreaming about for months. As soon as the developers have a product that does anything, they should push it live so that early users can begin poking at it. How long should this take in the case of the basic web app? Probably about a week for an undesigned version, and probably about 2-3 weeks for a designed version. To give you an idea of the scope of what you can expect in this timeframe, let’s take the following example:

You’re building a facebook clone. In just a couple of weeks users should be able to sign up, create a simple profile with a profile photo, and add and remove friends. On one hand that doesn’t sound like a facebook clone at all (no photo albums, tagging, chat, applications, etc), but on the other hand think about the basic functionality and what’s been accomplished in just a couple weeks. After this base is in, it’s easy to add features one by one every couple of days. But if you never released this basic functionality after week one, you wouldn’t have any early users (even if it’s just your team, friends, and family), and you wouldn’t be getting any feedback about how to best move forward.

Okay, so a couple of weeks to launch a simple prototype that does something but nothing interesting. In the case of the facebook clone, maybe you’d like to get to the point where people can write on one another’s walls, create albums, and tag their friends? At that point you’d feel comfortable “launching” to the world. How long does it usually take to iterate to an interesting point?

It shouldn’t take longer than 3 months. I arrive at this rather rough estimate by looking at the startup accelerators as good examples. Programs like YCombinator, TechStars, and DreamIt generally run for about 10-12 weeks, and at the end of the program most teams have an interesting product to pitch to the media and investors. If these programs have learned through years of experience that most consumer web applications can be built and demoed in under 3 months when the founders buckle down and get to work, then this is what you should shoot for yourself if you’re launching a similar product. If you are using an agency instead of an in-house team, expect development time to be 2-3 times longer. This is due to the overhead of communication, going back and forth with changes over the span of weeks instead of hours, and the inevitable second guessing that occurs when you have one party thinking and the other party blindly responding.

If you want to move fast, then I would like to emphasize one key lesson I’ve learned: release your product as soon as possible. Immediately. Don’t even wait for it to work fully. When you keep your product behind closed doors, it tends to fester. You spend days or weeks debating key feature decisions with your team, and you use unfinished features as an excuse to delay launch. Compare this to a simple product that is out in the open being used by actual customers. If you feel embarassed that they’re not experiencing the complete product in all it’s glory, then you’ll race to enhance the product every single day. You’ll know what the most pressing need is, and you’ll get it implemented quickly to create a better experience for your users. Your product will grown organically instead of in a contrived way, and you’ll know very quickly what’s important and what’s unimportant.

Good luck, and get to work.

What technology should I use to build my product?

I often get asked by nontechnical startup founders what language they should use to build their product? Since they won’t be writing code themselves, what they really are looking for are the buzzwords to use when writing a job ad for a developer or potential co-founder. This is of course important, because if you write a job ad asking for mainframe experience and strong knowledge of qbasic, you aren’t very likely to attract the talent you’re looking for to help build your company.

I’ll start by saying that if you have a strong technical co-founder on board, then you should trust their judgement to build in whatever language and platform they are comfortable with. But for the purposes of this article, let’s assume that you aren’t so fortunate. Let’s also assume that your product is a consumer facing web application. If you’re working on something deeply technical, mobile, or embedded, then either your language choice is already made up for you, or you’ll probably need the know-how in advance. When building your standard web application however, you have no shortage of choices.

Some choices will lead to rapid development, the ability to attract A+ talent, and a large community that you’ll be able to leverage for years to come. Other choices will lead to a development team of one, unable to expand.

Background – Languages, Frameworks, Platforms

You’ve probably heard these terms thrown around a bunch, without really having any idea what they truly mean. Here’s the quick overview.

A programming language is the basic tool that a programmer will use to write your application. Each language has different strengths and weaknesses. Some are harder to program in and require more code, but run faster and use less memory. Others require less code and are easier to program in, but may run slower. Examples of languages are C, Java, Python, Ruby, PHP, Erlang, and on-and-on.

A web framework is a tool that simplifies many of the tasks that programmers would otherwise need to reproduce over and over again when creating a web application. Each language has a number of different frameworks to choose from, and the choosing a good framework is much more important that choosing a particular language.

A platform is an environment which your application will run on. It can be a server that you buy and stick under your desk (not recommend). It can be a cloud based system which will help with scaling, backups, and deployments such as Amazon EC2. Or it can even be a special purpose destination environment like Facebook the iPhone. The right platform will simplify maintaining your site and keeping it up and running.

Okay, so finally, what languages and frameworks should you choose?

The Big Boys

These languages and frameworks all are pretty trendy in the startup world, have no shortage of adept and fast moving developers, and are proven on popular real world applications. You’ll be safe with any of the below.

Ruby – The ruby language paired with the Rails framework is a popular choice these days. It favors convention over configuration which means that any Rails programmer can drop immediately into any Rails application and have a very good idea of where to get started. It’s built to support rapid development and prototyping, it has a great community working on updates and plugins, and it’s not going away any time soon. Ruby/Rails developers tend to be expensive but worth it. There are also other Ruby frameworks such as Sinatra which are suitable.

Python – Much like the Ruby community has Rails, the Python community has the Django framework. Everything mentioned about Rails applies equally as well here. Python and Ruby are both high level languages that are easy for developers to program in. Expect good things from the Django crowd.

PHP – This language runs some of the biggest sites on the web including Facebook, WordPress, and Flickr. It has the lowest barrier to entry among the three languages mentioned here, which means that programmers tend to be a little cheaper. (It also means you generally have to be more on the lookout for bad PHP coders). It has a number of good frameworks such as CakePHP and Zend.

Javascript – A developer won’t necessarily build your entire site in javascript, however it’s a skill that’s very useful to have on your team. Developers use javascript to make your web pages dynamic, and provide nice visual effects. You’ll want someone familiar with javascript working on your web app.

Safe Options But Be Careful

These languages and frameworks are fine if you have the right technical lead who knows what they’re doing and have plenty of experience. They tend to be a little more old school than the frameworks above, but they’re proven, and will get the job done. The pace of development might be a little slower, and the younger talent may not be as eager to join up to work on these projects.

Java – The java language is an old favorite in the enterprise. As such, there’s no shortage of ex-big-co employees who will have experience building large applications in java. Unfortunately java applications, and their frameworks such as Spring, have relied a lot more on configuration than the current frameworks, and haven’t quite evolved very quickly over the last 10 years. There’ll be plenty of cheap employees around to work on Java projects, but you may not be the most attractive shop in town.

.NET – Microsoft’s current platform is called .NET, and it has a number of languages to choose from, but usually pair ASP.NET with C#. Like Java, .NET is a favorite in the enterprise, and there’s no shortage of developers around who will have experience here. Developing in .NET generally takes place on a windows machine (unlike many of the above options where developers prefer Macs or Linux), and it’s accomplished inside a really nice program called Visual Studio. Unfortunately, the licenses for this suite, and the servers to run them on, are very expensive. So if you choose .NET, be prepared to pay.

Stay Away

If a developer tries to convince you that he’s going to build your web app in any other language, advise strongly against it. There is no doubt it’s possible, and the developer could even do an incredible job. However it’s not likely that you’ll attract a strong team, and be able to grow it as necessary to support an unconventional choice.

Another thing to watch out for is a developer who tells you that he’d like to use his own homemade language or framework. Again, they may be very capable, but it will be hard to find others jumping at the opportunity to join on.

Developers are generally very strong-minded about their programming languages of choice. I didn’t write this article to incite a holy war or to offend anyone. I would just like to give nontechnical founders and idea of the current landscape of frameworks commonly in use in the startup world. If you have any other suggestions or think that I’ve missed anything, feel free to let me know in the comments.

How to find a technical co-founder

So you’re committed to founding a tech startup, and you know that you need the right technical co-founder to come on board to build and launch your product, right? Good. Now where do you find this mythical co-founder, and how do you know what to look for?

I’m not gonna sugar coat this. Finding a technical co-founder to partner up with you and build your product from scratch will be a long, time consuming process. Unless you have plenty of money to offer up front in salary in addition to large amounts of equity to give away, expect to spend about 2-6 months on the hunt for the right co-founder. Since you won’t be working on your product in the meantime, the best things you can do are to get smart on your business, and to contribute intelligence to the community.

The worst thing that you can do is try and recruit a technical co-founder based solely on the idea that you came up with the previous day. If you’re not really smart on the idea, and already well connected within your market, there won’t be any incentive for a technologist to join up with you and build your product for you for only 50% or less of the business.

Getting smart on your business should be a given. Do the market research, talk to as many people with knowledge on the subject as possible, come up with a set of assumptions around a strongly crafted model that will need to be proven, and then collect data on those assumptions.

Contributing intelligence to the community is a little bit less intuitive. The easiest way to get your voice out there in the open is to start a blog. Write often about your business, your thoughts on technology, marketing, distribution, and existing business models. Comment on other well read blogs, and engage in the discussion. Aside from writing, actually participate in community events, attend meetups, speak on panels, and schedule frequent meetings with potential candidates for the co-founder position.

You’ll meet plenty of these candidates through the startup community in your city if you put the time and effort into immersing yourself into the experience. Contact people from the online communities like Hacker News, email people you’re connected to on LinkedIn, set up followup meetings after you meet a potential candidate at a meetup.

When you actually talk with technical candidates, how will you know you’ve found the right one?

First of all, look at what they’ve already built. This will be the best evidence of what they’ll be able to build again. If it looks like, sounds like, and acts like the product that you want to launch for your business, then that’s a great sign.

Secondly, ask them what their specialties are, and what they contributed to their previous projects. At the early stage of startup life, it’s important that you hire generalists and not specialists. That means that you’d rather have someone who’s built an entire application from beginning to end, instead of someone who was pigeon holed into just working on the design, or the front end, or the database, or the API. A key word to use here is the full stack. This means that they’re comfortable working in almost every area from the database all the way up through the front end design. The right technical lead for your team will have worked on all of them a little bit. They needn’t be an expert at any one area, and in fact they may be really weak at certain areas, but they need to be confident that they can at least find the right person to help them out when needed.

So if the candidate seems to get along well with you, they’ve built something interesting before, they have the commitment and tenacity required in a co-founder, and they seem to have confidence in their own technical ability, do you sign them on the spot? No. There are still two more steps that I’d recommend.

You’ll want someone technical who you know and trust to interview them to vet their technical ability. Your trusted friend will be able to dig deep on technical ability to make sure that they really will be able to live up to what they told you they will. Even if they pass this test, I recommend you’ll want to work with them at least on a trial project to see how the two of you work together. Pick a small project (it can be unrelated to your business), and you work on the business related strategy while they work on the technical side. After a few days if everything still feels right, it might be a match.

I’ll leave you with a high level checklist. All of these needn’t be fulfilled, but the more that you can check off, but more likely the long term partnership will be successful.

They’re highly technical
They have active projects online that they’ve built and can show you
You get along personally (don’t need to be best friends, but at least need to tolerate each other)
They’re a good communicator
They’re around your age
They’re located in your city
You have similar financial needs over the coming years
They come with strong references that you can check out
You both have similar goals about what you want out of the company

Good luck. As a highly technical developer who’s joined up as a co-founder with a nontechnical partner, I can vouch for all of the above from the side of the person who’s being recruited. Disagree or have any thoughts? Let me know in the comments or on twitter.

Do I need a technical co-founder?

Do you need a technical co-founder? The short answer is yes.

If I have one piece of advice for an aspiring nontechnical startup founder, it would be to find yourself a technical partner. Nothing will accelerate the process of getting your product built, shipped, iterated on, and improved than having core technical talent within the founding team. This is hardly an original idea, and it is often preached around the tech community these days.

But why is this so important? Can’t you just hire a technical employee or outsource development?

You can, but it will be slower, more expensive, and far more unreliable than having a partner who has the knowledge, drive, and incentive (being a partner in the company) to put out the best product possible.

As an early stage founder, presumably on a tight budget, your goal should be to get version one of your minimum viable product (to be discussed later), launched as quickly and cheaply as possible. Until your product is out in the open and you’re getting feedback from your users, you don’t even know whether you’ve build the right product. Sure you could get an agency to build your prototype within your budget, but after you get feedback and need to make changes, the bills will start to add up. It often takes many iterations to get the product on the right course, and iterating on a per-hour or per-project budget is not the way you want to preserve capital in the early stage. For this reason, I’d advise that outsourcing your product to an agency is the worst way to launch a business.

Hiring a technical lead, who’s not a partner/co-founder, is a slightly better alternative. If you have the funding to do so, and you find the right candidate who’s willing to be incentivized by salary instead of equity, then this can work. There are at least three reasons I can think of why this is subpar to having a technical cofounder. It’s going to be more expensive cash wise, the employee won’t be as incentivized to work above and beyond their expectations of what they consider standard, and they’ll be far more likely to leave when a better offer comes around.

But having that right technical partner will pay dividends many times over in the early stage when your product gets prototyped, released, and iterated on a daily basis. When you want to test something out or try a different direction, your co-founder will say “can-do” and you won’t have to worry about making the stressful decision about whether to put another 5-10K against an agency developed prototype feature. Imagine this scenario playing itself over time-and-time-again in the early days of your company, and trust me, you’ll be glad that you have a technical partner to go to battle with.

Of course it’s important to find the right partner, and not just settle for the first one that comes your way. What should you look for in a partner and how will you know when you’ve found the right one? More on that in the next post.

If you’re interested in following along with the Nontechnical Founders Series, or know someone who might be, you should subscribe to stay up with future posts, or follow me on twitter.

The Nontechnical Founders Series

Do I need a technical co-founder, and where can I find one?

How long will it take to launch a product?

How do I recruit and interview developers?

How do I know what programming language to build my startup’s product in?

As a technical startup founder in New York City, I get asked these questions and many like them all the time. There are a lot of smart, young, ambitious, first-time entrepreneurs without any technical background, who seem dedicated to building a tech company. I admire their ambition and their willingness to learn, so I’m always glad to help.

A large part of building a tech company is the technology. It’s very important. There is of course, a large part completely unrelated to the technology – the strategy, marketing, fundraising, recruiting, and so-forth. These are all great roles that the nontechnical founder can excel at, but I truly believe that the core of an early stage tech startup is its product, and without some semblance of knowledge surrounding the technology piece, you’ll put yourself at a severe disadvantage.

I have a technical background. A computer science education, a passion for learning and playing with new technologies, and a history of launching products quickly. As such I’d like to write a series of posts dedicated to helping nontechnical founders get up to speed on the technical issues they may be faced with in starting a company these days. Note that I say “starting” a company and not “growing and selling a company.” Unfortunately I won’t pretend to yet have had that experience, and as such I won’t get unsolicited advice about things that I’ve yet to test out myself.

Table of Contents

1. Do I need a technical co-founder?

2. How do I find the right co-founder?

3. What technology should I use to build my product?

4. How long until my prototype will be ready?

Coming soon – What should I do while I’m waiting for the product to be ready?

Every time I add a new post to this series I’ll update this page with the link.

If you’re interested in following along, or know someone who might be, you should subscribe to stay up with future posts, or follow me on twitter.

TopCoder style crowdsourcing for startups

See the full gallery on Posterous

Back when I was in high school in 2001, one of my computer science classmates introduced me to TopCoder, and there was something about it that I instantly loved. I was very competitive back then both in sports, and in the classroom, and the ability to compete in 45 minute algorithm programming contests felt like the perfect competition for someone who was experiencing a new found love for computer science. The way that a competition worked was that TopCoder would present everybody with three programming problems (easy, medium, and hard), and everyone would work for 45 minutes to submit solutions. If your solution was correct, you’d get points based upon how quickly you submitted, and your ranking would move up or down accordingly compared to other people on the site.

As someone who was young, and very new to computer science, the best I ever did back then was average. I’d occasionally be in the running for a cash prize of some sort, and I’d also occasionally deal with looks of shock and disbelief when I’d tell my buddies that I was staying home on a Friday night to participate in a “programming competition.” It was well worth it though, as nothing taught me more about algorithms and programming during those early years than working through TopCoder problem statements. As I moved on to college, and begun moving away from TopCoder’s compiled languages more towards agile practices and scripting languages, I stopped competing in the competitions frequently. Though I always had an interest in what the company was up to.

Fast forward to 2010. The company not only has algorithm programming competitions, but there are also design competitions, software development competitions, and categories for testing suites and marathon matches. They’ve turned themselves into a crowdsourcing platform where sponsors can submit components that they’d like designed, built, tested, and they attach bounties to each task. Competitors submit their best efforts, and the companies pay the winners the prize in exchange for using the components.

I haven’t used the new platform enough to how well this ends up working out for programmers, designers, and the sponsors, but it appears that in the world of big-co, big-money, long-dev-cycle, and compiled languages, Topcoder may be an easy and efficient way for a project manager to outsource a small project that they don’t have the time or ability to deal with on their fixed in-house team.

It’s a shame that this model doesn’t quite carry over to the agile development world. When team members have to wear many hats, and you don’t have the luxury of a multi-month plan/design/architect/build/test cycle, it’s difficult to crowdsource your components. Sites like 99designs, elance, and odesk can help fill empty needs, albeit at a pretty high cost of uncertainty about what you’re going to get for your money. I’d love to see a startup build a TopCoder style crowdsourcing service targeted towards agile startups with a rating system that startups can trust, and a high quality community of available freelance hackers.

Am I asking for a lot? Maybe. But wouldn’t it be useful?

My thoughts on Rework by 37Signals

Sometimes just being reminded about what you already know is the best advice you can receive.

For the first time in two years of working on startups I took over a full week off this past week as I got married and went away on my honeymoon. While I wasn't doing any coding or checking in very often on startup life, I couldn't pull myself away completely, and I decided to take in 37Signals' new book, Rework, as a little light beach reading. I always recommend taking vacation and time off every once in awhile to help regather your focus and motivation for the grind that is startup life, and it turns out that Rework was a great companion read in support of that goal.

I really enjoyed reading Rework despite learning very little "new" information from it. Generally I read books to learn something completely new that I wasn't familiar with before. Rework is a bunch of simplified and restated agile startup lore that's prevalent on VC and entrepreneur blogs, hacker news, and greater startup-related internet. But it was the simplicity, verbalization, and centralization of all the restatement that really made it great. I have yet to read a business book that felt like it was reminding me of everything that I knew deep down and truly believed in.

Rework starts off a little bit broad, which is probably a good thing to attract any non-startup-world based reader. However it quickly gets down to the meat and provides nearly 100 1-2 page essays which really hammer home valuable lessons on specific topics. I particularly agreed with the chapters on Progress, Productivity, and Hiring. While I'm a vocal advocator for launching early, iterating quickly, and staying cheap and lean for as long as possible, it's easy to stray from some of these ideas along the long road of building a startup. I'll go back to Rework every once in awhile to set me straight when I feel myself veering off the path.

The book doesn't take that long to read, and the 1-2 page essay format makes for plenty of breaking points, so I strongly recommend throwing it on your e-reader or into your backpack and taking in an essay or two whenever you have a few moments. I emerged from each chapter feeling energized and eager to get back to work on my startup and my product – to get back to doing things the right way.

The DOB

Insights by Doug Petkanics

Tag Archives: Startups