Step-by-Step Instructions

Click to print worksheet.

Problems it Solves

• What if you don't code?

If you don't code, and your product requires software development, how can you assemble the best team of engineers to automate your solution?

• Can you get a free dev team?

Turns out, the best way for your to automate your solution may be by assembling a dev team that takes no money, or equity at all. You'll learn if and how that's the right solution for you in this exercise.

• Where can you go to find devs that will be a good fit for your team?

If you're not a developer, you may not know where to find them. You will once you complete this exercise.

• How do you attract the best devs?

How do you go about assessing the quality of a developer so you can tell if she'll be a good addition to your team?

Types of Development Teams

Throughout this exercise I'll refer to three categories of development teams:

• Outsourcing

Outsourcing is any scenario where you are hiring out to another agency to do your development work for you. The company could be located around the corner from you, or around the world - either way, if they aren't your employees, they are considered an outsourced development team.

• You-Sourcing

You could do the work! You can learn to become a developer and write the code yourself, or use some of the incredible tools that are available today to make this much easier for non-engineers to create products.

• Friend-Sourcing

Alternatively, you can work with friends and colleagues to automate your solution. If you don't have these kinds of folks in your network at the moment, this exercise will teach you how you can get some.

Let's walk through the pros and cons of each.

Outsourcing

Pros

The main advantage of outsourcing your development work is that it's the the fastest way to get a product built. Though outsourcing it is not fast - automating a solution is never fast, which is why you built a manual solution first - it's faster than any of the other options.

You will probably get moderate quality, depending on which company you work with. By not overseeing the development yourself, the devs you hire will not have the same inside insight about what you are building as you would - though you will be able to get a certain level of quality as you are paying for this service. More about this in the "cons" section.

Outsourcing is typically a good short-term solution. When you know exactly what you want to automate, it's not complicated, and you are okay replacing what the outsourcing company builds within a couple of years with your own code (when your company grows, when your feature set needs to grow, etc.) outsourcing is ideal.

If, however, you're looking for a more long-term solution, outsourcing may not be the best option.

Cons

On the cons side, outsourcing can get very expensive very quickly. If you have those resources, outsourcing might be a good fit, but it's hard to argue it'll be the best use of those resources.

Another con is that communication is often not very good - and more often, it's bad. There's a few reasons for this.

First, logistics can be difficult. For example, time zones can interrupt the flow of your work: if something is wrong and you send your devs an email, they might not receive it for many hours. If they're on the other side of the planet, you may only get a chance to communicate for an hour a day with each other.

Second, you are probably not good at defining your requirements. Unless you've done this before (as a product manager, for example) your vision of what you're looking for will be difficult to describe to someone who has not been intimately involved in the process. Through no fault of anyone, you will likely have to go back and forth a few times to get it right. Of course, each iteration of the requirements takes much longer when you're not in the same time zone.

Another logistical hurdle are language barriers. If you are outsourcing to another country, you may be working with someone who is not native to your language. While general communication may be good, detailed and nuanced communication is difficult.

Outsourcing may also result in poor long-term quality. When you have contracted someone for a short time, they are not necessarily invested in the long-term maintainability of your product. If your project is simple, outsourcing may be a good solution; however, for any type of complexity, an in-house development team may be best suited building long-term solutions.

Another challenge is that someone else's work is difficult to change. Once the project is finished, if you figure out something needs to be changes or tweaked a few months down the road, it can be difficult to track down the person with whom you were working in the outsourcing scenario, or you may have to wait for them to be available.

Finally, maintenance is expensive. Again, when you outsource, you will have to pay someone's salary again and again as you get your features right.

Overall, outsourcing is a good solution if you have a specific, short-term project, know exactly what you want, need it quick, and have the funds to pay for it.

A Note About Where to Outsource

In my experience, I have had various levels of success depending on where I look for my devs. While I am excited to share my experience with you, I want to acknowledge that this is my personal experience, and subject to gross generalizations. There are a number of exceptions to what I am about to say.

Your own experience may vary - please always go with what works best for your company.

In my work creating various types of companies, I have always had the best experience outsourcing developers from companies based within the United States. The quality of communication and deliverables has been very high.

I have also heard great things from others who have had positive experiences outsourcing to developers in the Ukraine. The organizations may be a good balance of less expensive than developers in the United States, but also returning a high quality of product. Communication may be taxed due to language and time zones.

Outsourcing with organizations in India and China is likely to be your least expensive option. At the same time, I have not had great success with the quality of code or communication about projects and timelines. While others have had good experiences with these companies, that has not been my experience to date.

You-Sourcing

You can learn how to code!

However, there are pros and cons to this method as well.

Pros

It is free(ish)! You can learn to code without spending any money, but it will cost you time. It can take a long time to learn how to code, but there are many resources out there to teach you. If you're short on funds, this may be a great way for you to be able to automate without taking out a second mortgage.

Another pro is that it's fun! If you like puzzles, logic, problem-solving (and don't mind spending hours in front of a computer) you might find you enjoy programming. If you are already in the sciences, engineering, accounting or legal fields, it may even come naturally to you.

There are also a lot of great tools out there that can do the heavy lifting for you. For example, WordPress is a great open-source platform that allows almost anyone to build an entire application or webpage using their plug-ins. At that point, you might be able to pay someone to do some tweaks to fill in the gaps.

If you build the product yourself, it will have the appropriate level of quality. That is, you have complete control over the requirements and will be able to determine when you need to take it to the next level based on your customers' response.

You-sourcing is a good medium-term solution. You can probably get the skills to create a solution that will last for a good chunk of time. It may not last forever, but it will take you a good ways in scaling your solution. Eventually, you may need to hire someone to do this full-time, but in the interim it can benefit you much longer than an outsourcing solution will at this stage in the game.

Finally, it is easy to make changes and maintenance is easy(ish). Since you built it, you have the capacity to make any tweaks that are necessary and can keep up with any upkeep needed.

Cons

Programming is hard. It requires a lot of time in front of a computer, a lot of time alone, and a lot of attention to detail. It may not be a great fit for you depending on your personal strengths.

It takes a long time. Learning a new skills simply takes time. If you are on a timeline of any sort, this could delay the timeline significantly. On top of that, building software can be complicated (and takes a long time even for experienced developers).

It is distracting. You have been doing a lot of work trying to understand your customers, determine your optimal price point, manually design a solution to the problem - for you to take time out of this process to go learn how to code could take you away from what is more important to your business. It is possible that it could take you six to nine months to build something, and by then, perhaps your customers have changed.

Overall, You-Sourcing is a great option if the tools you need to meet your Scaling needs are available, if this work is compelling to you and if you can automate what you need to in a short enough time period. We'll talk about how to make this decision, and if it is cost-effective in the next exercise.

Friend Sourcing

The third approach to product development is Friend-Sourcing. This is my favorite by far.

Friend-sourcing means you work with a group of friends to build your automated solution.

Although you may not pay these friends with cash or equity, it's worth noting that friend-sourcing is not:

• Friend-exploiting
• Friend-bribing
• Friend-taking-advantage-of

Friend-sourcing is a group of colleagues coming together to build something they're all excited about. It turns out this excitement, and the opportunity to collaborate with people they like, can sometimes be more motivating than cash or equity.

If you have these sorts of friends, below you'll learn how to recruit them. If you do not have these types of friends, you'll learn how to find them!

Pros

First, it can be very inexpensive - sometimes free!

It can be extremely fun and you can build great relationships with others this way. There's nothing quite like working with a great group of smart people to achieve a common goal.

It is a potential long-term solution, because you can actually find your co-founder and first employees this way. Ideally the team you put together becomes so enthralled with you, your customers and your product that they'll want to help you long-term.

Friend-sourcing has the potential to be the highest quality. This is because you have people on your team who are invested in the product, and invested in you. These folks will also be thinking about the long-term, which helps increase product quality.

It's also a little easier to make changes because you've built real relationships with people who are interested in helping you to solve your problems.

Cons

Of course, there are also some downsides to Friend-sourcing.

It can take a long time to build your Friend-sourcing team. It is a big investment - though not as distracting as learning how to code yourself.

The team you put together will only be available for very short-term projects. There is not often a middle ground here: either you have a partner for the life of the company, or a very short-term investment (measured in weeks).

Friend-sourcing team members can be flaky. You are doing this with friends, which means that there is no contractual obligation holding them down:

• personal things can come up
• other projects may pull them away
• or this may be a stop-gap between jobs

People can come and go, which means that you will have to be mindful of how to use people strategically.

Finally, the truth is you may need to start over. These are friends and a group of people who are doing things for little or no money at all. This means that they may end up building something that you can't use moving forward: it may be good enough for now, but then you'll need to revise or start from scratch as you move forward.

In other words, the viability of Friend-sourcing solutions can run the gamut from very short-term, to the life-time of the company.

How to Make Friends

As I said, despite the challenges, Friend-Sourcing is by far the best way to get your dev team rolling. Let's dive into this Friend-Sourcing idea and how to go about making it happen.

First, I'll share a couple examples from personal experience. I've used Friend-Sourcing on a number of occasions, one of which was called OnCompare.

OnCompare

OnCompare had 11 people on the team. With these 11 people, we built a fully functioning product from nothing, in 3 weeks.

These 11 people included:

• 6 developers
• 2 researchers
• 2 designers
• and myself

We had an a wonderful time building one of the best products I've ever created.

If you'd like to read more about our time together, we documented the entire process beginning to end at: http://3weekstolive.wordpress.com.

How did I get 10 people to join my team?

First, I was working in an office space with a number of developers. It so happened that 4 of them were laid off when their startup moved their development off-shore.

At the same time, I had an idea: a "Yelp" for online services.

It just so happened that these developers were in between jobs - which allowed me to pitch them this idea: let's build something fun that solves a problem for us (choosing the best online services can be hard) while you're looking for another job. It turns out they were really excited about it.

From there, it grew. We knew another guy in our community who was in a similar in-between spot. A couple of months earlier I had met a designer after selling him a Sounders ticket. I reached out to him and it turned out he, and another of his designer friends weren't loving the projects they were building at their day-jobs, so they wanted to join in.

Similarly, the team grew until we reached 11 people, all of whom were basically in a transition period. This provided an opportunity to come together, network and, most importantly, build something. Creative people like to build things, and love to work on things they can be passionate about.

It is worth noting that this idea, the Yelp for online services, spoke to a problem we all understood: we had all experienced the pain of looking for the best online service. The momentum, excitement and energy attracted high-quality, creative people -especially since they knew it was a short-term gig while they were in-between their other pursuits. At least from inside our circle, and inside the building, this was a solution we could all get behind.

While the creative part of this was a draw, there were also a number of other experiences that created an attractive environment for Friend-Sourcing. A few cool things happened along the way. First, we were invited to the Launch Conference down in San Francisco - our company was based in Seattle so this was a big event.

We also got to partner with Twilio to create a launch party which had a line around the block to get into, and provided us an opportunity to rub elbows with some big names and network at a level we would not have been able to otherwise.

And the software was bad-ass.

However, ultimately we did not do what's in FOCUS - we did not do what you have done.

We built a bunch of amazing tools - a piece of software that I wish was around today - but it turned out, we never found our Victory Currency. OnCompare didn't solve a problem our customers had that they were willing to pay for.

Since we didn't take the time to talk to our customers, we built something amazing that was not able to survive.

This company was a failure from a business perspective; but it a success from a development perspective.

R.I.P. OnCompare.

Things We Start

ThingsWeStart was a service designed to help people see the Kickstarter campaigns in their area, so that individuals could look for local campaigns ideas they wanted to support.

This was another random, unvalidated idea - however, I present it as an example because similar to OnCompare, the opportunity brought together a number of talented people, passionate about building something.

In this project, we put together a 7 person team. Again, these were people who were in between gigs or looking for something to be excited about outside of their regular work.

Like OnCompare, ThingsWeStart had a blog too (although it's not as comprehensive as the former): http://kickmapper.wordpress.com

This project took about 6 weeks to launch and got a ton of great press (see my press hack to see how we did this).

Let's look at a few of the similarities between these two Friend-Sourcing examples:

• Free

First, all of the development was done for free. In OnCompare, we did talk about eventually discussing equity if the project took off, but for the 3 weeks everyone donated their time. This worked because everyone was super excited about building something, and launching it, together. There are a lot of things that you can offer as a founder besides money, that can motivate talented people to work with you (e.g. a great team, the chance to call the shots for the components of the project they are responsible for, the exhilaration of launch, to help people they care about, etc.).

If you add up the total time that was donated for these projects, I've been able to harness over a person-year of time across these two projects, all because we were doing something that people could get passionate about.

• Short-term

When building these teams, I was explicit about the fact that these were short-term experiences. If we found success, a few folks may have stayed on longer, but by and large everyone only committed for a short amount of time (3 and 6 weeks respectively).

Definitely think about this when designing a Friend-Sourcing experience:

Set your commitment expectations in terms of weeks - not months.

If it works out, you can also ask people to sign on for additional time, but if you ask for too much time in the beginning, it'll likely feel overwhelming.

• Amazing products

We built amazing software. It is exhilarating to be part of something that is high quality and of which you can be proud. These two companies had some of the best software that I have ever seen - passionate people build amazing things.

The value of passion is extremely high. It is not something you can buy. Think about what you can do to harness the passion of the people you're working with to automate your solution.

• Failures

Finally, I want to point out that these companies were both failures.

I want to make this very clear.

They were failures because we did not do what is in FOCUS. We did not talk to customers, we did not offer test, we did not currency test - we went straight to product development, which is why they both failed.

You, on the other hand, have not made this error; you won't repeat our mistakes.

FOCUS, in fact, evolved in part out of these failures. These are experiences that I took to heart, dissected, and figured out how to fix.

Keys to Friend-Sourcing

Treat Your Team Like Your Customers

I can't stress this enough. You need to be thinking about how you can serve your teammates, as you think about serving your customers.

These aren't people you're trying to trick into working for you. Your job is to figure out how you can help them on their path. By doing so, they will be committed to working with you because you are helping them to solve their problem.

Treat your teammates like your customers: solve their problems.

Your job as the leader of a team is to understand the problems your teammates are trying to solve.

Maybe they are trying to find a job and this is an opportunity for them to build their portfolio, or develop some new skills they can discuss during interviews. Maybe this is a way for them to show that they were still occupied during their transition time. Maybe they have a current job and they would like to play around with a startup without having to quit their job. Maybe they are bored and would like to do something new and interesting...

There are lots of problems that developers and designers have that you can solve.

The best leaders are those that enable their employees. Again, the products I mentioned were some of the best I've ever seen because they were built by people who were passionate about the experience, not because I offered high (or any) payment.

Traction is More Powerful than Money

Developers are in such high demand, they are constantly getting asked to join new projects. Whether its friends and family asking them to "build an app", a recruiter stalking them on LinkedIn, or a startup trying to attract their attention, developers are hot commodities and have multiple suitors.

That said, you will have something that no other person approaching this developer has.

As a developer, I get approached by folks all the time who are passionate about their vision - but that is all they have to offer me. It turns out, other people's passion doesn't make me passionate. Like everyone else, I am most passionate about solving my own problems.

On the other hand, you will approach developers with all the work you've already done through FOCUS:

You will have validated that customers care about your product and are willing to pay for it!

You are offering your developer a chance to make something awesome that will be a success. Everyone else who is approaching them hopes their idea will be a success, but you have the data to prove it will be!

You're offering developers a seat on a rocket ship...they'd be a fool to turn you down.

This prospect, that they can be a part of an impactful, successful project, is far more powerful than a huge salary. There are many people who will offer this developer money - you will not be able to compete on that front. Very few people will be able to offer them the opportunity to work on something that is proven to actually solve a problem and make money.

Developers love to solve problems. Prove that you're offering them an opportunity to do that, and more likely than not, they'll respond to you positively.

Keep it Short-Term

If you are asking someone to invest anything more than 6 weeks, you are shooting yourself in the foot. Ask for a 2-4 week commitment. That'll be enough to build something substantial, but not so much that it feels like another job.

Now, if it turns out you love working together, you can always keep going but for your first go-round, keep it short.

Payment

How do you pay these people?

As I've said, in the two scenarios I presented, I did not pay my friends. I had a lot to offer - passion, excitement, help in the in-betweens - but I didn't offer any cash.

In another scenario, I was asked by a founder of a company to join his team as a co-founder. Our agreement was that we would work together for 3 months. At the end of 3 months, we would decide if we wanted to keep working together.

If we decided to keep going, we agreed that we would back-date the vesting schedule of my shares to my original start date (3 months prior).

If we decided that we did not want to pursue a long-term relationships, then he would simply pay me an hourly rate for my time through those 3 months.

It was a great arrangement because it gave us the opportunity to work together for an extended period of time before we committed to one another for the lifetime of the company.

We gave it a shot. It turns out that about 6 weeks in, it became clear I wasn't passionate about serving our customer segment. Because we had this agreement, I was able to back out without any hard feelings - and we're still good friends today.

This is an alternative strategy to consider:

Create a contract that is dependent on the development of your relationship, not the product.

Making Friends with Devs

The exercise for this chapter looks a lot like an exercise you've done before: How to Interview Like a Pro.

In that exercise, you took a week to intentionally practice your interviewing skills at specific events:

• at a networking event
• a social event
• and an event with family and friends

Now you're going to leverage the networking skills you've gained to make friends with developers!

The same techniques you use to understand the problems of your customers (listen more than you speak, ask about their problems, pay attention to emotions, etc.) apply here.

Of course to network with developers, you need to know where they are. Here's a hint:

If you haven't been running into a lot of them during your normal networking events, they are elsewhere.

A lot of business-oriented founders think that there aren't a lot of developers out there because they are going to startup events. It turns out most developers don't go to startup events...they go to developer events!

Just like with your customers, ask yourself:

Where are developers with problems?

Where are the developers that are taking some action to solve a problem they have with their "developer" situation. These problems may include boredom, looking for a new job, needing an in-between gig, wanting to make an impact, wanting to try a startup but don't want the risk, just out of school, etc.

There are a lot of developers with problems and you are in a unique position to solve them. But where are they? What's your channel?

Here are some ideas:

• Coding and User Groups

Developers like to learn new things and may be attending a group where they can learn a new skill. If you attend some of these events, you can not only go to try to learn code (You-Sourcing), you could also meet other developers looking to share in the process.

• Hackathons

Developers like to build stuff for fun. Attend a hackathon and join a team. Even if you don't have an idea for something to build over a weekend, you'll be able to lend a hand on someone else's project and in doing so, meet some amazing developers and designers.

• Startup Weekends

Developers and designers often want a taste of the startup experience. Even those who can't yet take the risk of starting something on their own, they still want to learn what it's like. They might not be satisfied with their current situation, and they are looking for other things to do - or they simply what to see what the excitement is all about.

Either way, Startup Weekends are a great place to meet potential teammates, and they are run around the world. Check them out here for more information: https://startupweekend.org/

Networking Interviews

Once you get to these types of events, what do you do? Use the customer interview script with them!

Step 1

As you remember, the keys to customer interviewing is to ask 5 question before answering them. Ask them about what project they are working on, what they like and don't like about it, and what the hardest part is about their current situation. They will love to tell you about their pet project!

During your conversation, see if you can figure out what brings them to the event. What problem are they trying to solve?

• Socializing
• Learning something new
• Want to have a positive impact (by helping others)
• Working on a side project
• Looking for a new job

Once you understand the problem they're trying to solve, you're in a unique position to help them solve it. Perhaps, you can solve their problem, and yours, at the same time.

Steps 2-4

Like the Interviewing Like a Pro exercise, you're going to choose a timeframe and three events with developers that you'll attend.

For each of these events, you'll talk to at least three people and find out the project they are working on, and a problem they are trying to solve.

At the end, you will have 9 people who you can potentially bring on to your team. This is literally the same process I used to build my 11 and 7 person development teams.

Great networking is all about:

• Being interested in what other people are working on.
• Understanding the problem they are trying to solve for themselves.
• Helping them solve that problem.

What's Next

With that, you've solved a number of problems for yourself!

You now know what to do if you don't code yourself. You can out-source your automation, you can you-source and learn yourself, or your can friend-source and find a way that you can help someone else along their journey.

You now know how you can get free development - by bringing your validation to the table. Validation is something they can't get anywhere else:

The opportunity to work on the ground floor of a successful project.

You also now know where to find your team. Just like you found your customers, go to the place where developers with problems go to solve their problems.

Finally, you now know how to attract the best devs:

Treat developers like your customers and solve their problems better than anyone else can.

Up next, you will learn what features you want your new development team to implement first in Scaling Your Solution.