Good software projects have clear business goals and objectives. Everyone on the team has an understanding of what metrics will be used to define success. i.e. Implementing these changes to the sign up flow will increase paid conversion rates. Bad software projects are driven by the loudest voice in the room and based on personal preferences. Success cannot be measured because it was never defined.
Good software projects are built initially for a specific target audience based on customer development and hypotheses. i.e. We interviewed 100 used car salesmen and found out their most time consuming task is following up with potential buyers after test drives. Let’s build a mobile web app to let them take notes and send follow-ups while they are still with customers. Good software projects start by doing one thing 10x better than anyone else. Bad software projects are built for everyone. These projects are incrementally better then their competitors and try to “out-feature” them. They are everything for everyone and fall short. They are built because they could, not because they should.
Good software projects have a plan to acquire users after launch. i.e. Through our landing page we’ve accumulated over 1000 emails. We also started a influencer campaign with the top bloggers and Klout scorers in this space. We’ve also set aside $2,500 to test Google Adwords and Facebook campaigns. Bad software projects rely on hope and a ”build it in and they will come” mentality.
Good software projects have a shared sense of ownership and are built with passion and love. Everyone is willing to step outside of their comfort zone to learn new things and attack new problems. Bad software projects have people finger pointing, and people who live within their title and place. “I can’t fix this, I’m just a junior developer. Ask Joanne, she wrote this.”
Good software projects have teams who pay attention to details without getting hung up on them. They are able to make decisions quickly and move on. Everyone working on the project has context. Bad software projects are built by teams without expertise. They spend weeks arguing over the shade of green on a button.
Good software projects release software as frequently as possible and get constant customer feedback. They have product owners who have a deep understanding of their users and are able to prioritize features. Everyone tests and logs feedback. Bad software projects stay in a black box for weeks and when finally released are underwhelming. Everything is equally important.
Good software projects ship, measure and learn. Bad software projects don’t.
Debates rage on whether companies who outsource all or parts of their development can be successful or not. In a perfect world you would have a brilliant in-house team that crushes features faster then you can think them up and has previous experience building similar systems. In reality this almost never happens. While long-term reliance on a development shop probably isn’t a great strategy there are a few situations where short-term engagements make sense.
When to hire a dev shop
You need help getting to that next major milestone
The appetite for great technical talent is at an all time high. Good technologists can get multiple offers for market rates + equity in a startup. Maybe you can’t afford the superstar you want or your company just doesn’t have the same cachet as competitors. Having an outside team help you with your next major release could allow you demonstrate the traction you need to get investment or attract that elusive hotshot developer.
You need outside expertise
Sometimes your in house team just doesn’t have the right sort of skills. Need a Facebook app or help optimizing your Mongo cluster? Finding a team that has done this before could save you time, money and heartache. Ideally you can have this outside team mentor and bring your insiders up to speed.
You have significant time contraints
Want to get in the App Store before the new iPhone hits stores? Have a competitor launching a new product? Have an external deadline by a partner? Hiring takes time. Augmenting your team with outside talent in short bursts can be effective.
How to hire a dev shop
So you’ve decided to take the plunge and hire a team. How do you know which team is the right one? What do you look for? What questions should you ask? Here are some things to look for:
The most important thing when choosing a partner is finding someone you feel comfortable with who understands your vision. Do they “get” what you are trying to do? Do they listen (really listen)? Do they ask the right questions? Do they speak your language? Do they have the right “context” for the business you are trying to build? Do you have a clear understanding of their process? Many times it’s hard to get this level of comfort with an offshore team. Even though local teams will probably be more expensive, the end results are usually better because of easier communication and shared context.
Is their work awesome? Do you see multiple examples of projects they’ve done that you are impressed by? Have they worked on projects similar to yours? If not, have they worked with clients similar to you (in terms of size/stage/industry)?
Always ask for references. The company will probably send you the three clients that love them the most, but dig a little deeper when speaking with them. Ask tougher questions. What were you surprised about when working with AwesomeDevShop? How did they do compared to your initial expectations? Where were they strongest? Where were they weakest? If you could do it over again what would you do differently? Was the timing or pricing different from what you initially agreed upon? Did you need to go back to them after the project was over for more work? How was that interaction? Would you work with them again? Not everything will be glowing but you should have a realistic expectation of what you are getting yourself into.
Finally always remember that software is never complete. While a dev shop can be a great stop gap solution, you’ll be responsible for owning the code once they leave. Make sure you have a clear exit strategy and an understanding of how you will handle ongoing maintenance and support.
A year ago Startup Giraffe was born. Looking back it’s amazing how far we’ve come. Like most business, our first few months was about getting our head above water, earning enough to pay rent, tweaking our business model and learning the legal, accounting and general ins and outs of starting a new company. We made a lot of mistakes but were lucky enough to experience some successes too. Today, we have lots of good problems related to growing our business sustainably. The more startups we launch, the stronger our ability to execute and support our companies becomes.
Some quick highlights of our accomplishments from our first year:
We’ve grown our team from two to four full time giraffes plus a partnership with an awesome design agency.
We’ve launched 11 companies and empowered 25 entrepreneurs to take the leap from idea to starting their own company.
We’ve proved that partnering with the giraffes to jumpstart your initial development can lead to traction, revenue, significant business development partnerships, outside financing, and full-time job creation (including recruiting in-house technical teams).
Our portfolio companies have been featured in the NYTimes, Mashable, Forbes, Huffington Post, Fashionista, Business Insider, WWD and other major publications.
By being smarter about how we build product we’re able to do more with less. We’re now able to launch a thin slice of any idea in 6 weeks while maintaining lives and relationships outside of the office and working at a sustainable pace.
We’ve bought hundreds of dollars worth of giraffe gear including a giant stuffed giraffe, hats, dope t-shirts and cute mittens.
While we still have a lot of questions and there is a lot we don’t know, we’re thrilled about the path we are on. Final thought… giraffes are awesome:
How do you validate your startup idea and start gaining early traction, without spending a ton of time and money building software? Delay complexity as long as possible by doing things manually. “Fake it till you make it.”
Below are some examples of how successful companies smoke / ghetto / wizard of oz tested their ideas:
In 2000 it wasn’t clear that purchasing shoes online was a great business. Shoes have different fits and comfort levels and many thought they needed to be worn before they were sold. The riskiest question for founder Nick Swinmurn’s fledgling company was: ”Will people buy shoes online?” One way to answer this would be to go out and raise millions of dollars in financing, build a huge warehouse, fill it up with shoes, build a comprehensive ecommerce system, hire a bunch of folks, cross your fingers and pray people placed orders.
Nick realized there has to be an easier way to de-risk his business. Instead he went to Foot Locker and took pictures of their inventory. He put photos of the shoes online. Every time someone placed an order, he went to Foot Locker purchased the shoes and mailed them to the buyer.
Is this model scalable? Nope. Did he make money on each order? Nuh uh. Was he able to prove that people would by shoes online and get some early traction? Yes. (source: The Lean Startup)
In 2003, Marc Cenedella saw the difficulty executives were having finding new jobs online. Wouldn’t it be great if there was one place that listed only high end (in this case $100k+) jobs? Is that a service that job seekers would pay for?
Marc’s initial “prototype” involved going out once a week and browsing HotJobs, Monster and other job boards to manually collect $100k+ jobs. On Monday mornings he would send a newsletter to job seekers containing only these 6-figure jobs. He charged $25 to subscribe to the newsletter and his audience quickly grew through craigslist postings and word of mouth.
After we had been doing that for about nine weeks, I missed the 9 a.m. Monday deadline… At around 9:10 I started getting e-mails from people asking where the newsletters were. Those e-mails kept coming. That’s when I really knew I was onto something. That was the moment of validation.
Having passionate users who care when you mess up is an awesome sign of product-market fit. Once a manual approach no longer scales you are in a great position to start automating these pieces with software. (source: Sramana Mitra)
Google is really bad at answering questions like: Where should I grab a drink in SoHo after work? Should I go to business school? Which DSLR camera should I buy? On the other hand, people are really good at answering these questions. Aardvark was started as a social Q&A service. You would send Aardvark a question over instant messager. Aardvark would do some magic and get 3 people to answer your question and send it back over IM.
The most technically complex piece was the algorithm to find the right 3 people to answer your question. The folks at Aardvark realized that although there was a large technical hurdle, the riskiest question to the success of their business was not can we build it, but will people use it. Rather then spending time initially to build out the algorithm they used a Wizard of Oz approach:
Aardvark employees would get the questions from beta test users and route them to users who were online and would have the answer to the question… While it used humans “behind the curtain,” it gained the benefit of learning from all the questions, including how to route the questions and the entire process with users.
In the last 5 minutes of the video below Zynga’s founder Mark Pincus is asked what’s the best way to do market research. His answer – “Ghetto Test”. If someone wants to build, let’s say, a hospital simulator he creates an FB ad that says, “Ever wanted to run your own hospital?” which leads to a survey (or if it’s really ghetto a 404 page).
All Zynga has to do is track CTR and compare it to previous historical rates to get a pretty good idea of demand.
This works great if you are comparing multiple game concepts, product ideas, taglines, names, etc… though isn’t a good fit for testing out a new concept (without a comparison).
The folks at seamless allegedly spent their first few months without a web product. They called up law firms in NYC and asked what they wanted for lunch. They called the restaurant, placed an order, managed delivery and billed the firms at the end of the month. (source: anecdotal)
Andrew Mason and the team at Groupon launched the first version as a wordpress site. Besides posting a deal, everything else was manual.
It was totally ghetto. We would sell t-shirts on the first version of Groupon. We’d say in the [write] up, ‘This t-shirt will come in the color red, size large. If you want a different color or size, email that to us.’ We didn’t have a form to add that stuff… It was enough to prove the concept and show that it was something that people really liked… It got to the point where we’d sell 500 sushi coupons in a day and we’d send 500 PDFs to people with Apple Mail at the same time.
There are obviously situations where a lean approach doesn’t apply (i.e. google the search engine or an iPad). For the large majority of startups today the biggest question is not can we build it, but should we. Before you go ahead and spend a ton of time and money building complex technology, try to manually execute parts of your business for a small target audience. Once things are working and you are unable to scale, then invest in technology to automate.
Two years ago we were late on delivering a project, and one of the developers came up to me and told me his launch-critical piece of functionality was delayed… again. Blame it on fatigue (I’d been up for about 30 hours) and inexperience but I made a critical mistake. I got angry. I yelled for a little bit, and in front of other people too.
After the launch the resentment from that individual carried over into the next project. Until I made a sincere apology to him (and everyone else) our team was essentially dysfunctional.
I learned two valuable lessons from the experience. First is that sometimes I’m an asshole (I’m constantly trying to improve). And second no matter how much money or how critical a deadline relationships are never worth sacrificing. Treat the people you work with like gold. Whether they are clients, partners or teammates, make your best effort to have open and honest conversations (especially when they are difficult ones).
For most people the idea of launching a half-baked product is horrifying. You’ve been talking up your idea for months, been working crazy hours and even taken money from friends and family. This is the first time people will be seeing what you’ve been dreaming about and you want everything to be perfect. You feel like your entire reputation is at stake.
Unfortunately, you didn’t work with StartupGiraffe and things aren’t there quite yet. The site doesn’t work in IE (which your mom uses), crashes your browser if you click too many things too quickly (which your annoying co-worker has a tendency of doing) and is missing that killer “make my pictures look really old and cool” feature. So what do you? Launch anyway (to a handful of selected people)…
The first version of your product isn’t meant to have mass appeal. It’s purpose is to find out if you are heading in the right direction and see if you are really solving a customer need. The feedback you will receive will far outweigh the effort spent trying to “make everything perfect.”
The earliest stages of a startup focus heavily on product development. Launching early opens up a whole new world of awesome things to do for founders (especially non-technical ones). You can start acquiring customers, doing biz dev deals, speaking with investors, and planning v2 of your site (which will be much more awesome). In short, start demonstrating demand and traction.
We speak with a ton of idea stage entrepreneurs through StartupGiraffe. Many times, people think we’re going to “Zuckerberg their Winklevoss” and steal whatever brilliant ideas they have. Because of this, they speak in generalizations and vagaries (it’s like LinkedIn meets Yelp for Healthcare with Farmville-style gamification). Unfortunately if you don’t tell us the details and motivations behind your project we can’t give any feedback or really figure out if working together is possible. We feel that you should not only tell us your ideas but share them with others too. Here’s why:
Talking is the Easiest Way to Get Feedback
The whole Lean Startup movement is about validated learning. You want to accomplish as much learning, as quick as possible with the least amount of effort. The easiest way to do this is by talking to trusted people.
Validation of the Problem Space
You need to find out if this is really a problem that other people have. While you may think it’s obvious that everyone would want to rate and review their pet food, that might not be the case. Research and fall in love with the problem not your solution. Find people who feel the pain most acutely, they will be the most enthusiastic about describing their troubles and why current solutions don’t suit them.
Developing Relationships with Early Cusotmers
Mark Suster talks about investing in Lines not Dots. He doesn’t want to invest in a single meeting with you, he wants to understand how well you work over time. There is a strong parallel here between getting early customers for your startup. The more you check-in, listen to feedback and demonstrate progress the more likely early customers will advocate and stick with you.
Here’s the #truth. No one is going to steal your idea.
Everyone has their own “Great Idea”
While your idea might seem brilliant to you, until you validate it/show traction/make money, it’s just another idea. Everyone has their own set of problems and set of experiences. In Eric Reis’ new book The Lean Startup, he suggests trying to take your (third) best idea and trying to find someone to steal it. Write blog posts , email product managers at Google and Facebook, go to meetings, tell everyone! Everyone’s busy with their own priorities and ideas, no one has time for yours.
Domain Expertise and Execution Matter
If someone can steal your idea based on a 30 minute conversation your idea is not defensible. Most likely you bring some secret sauce to the table (knowing the vertical really well, knowing people in the industry that you can sell to, etc…). You’ve been thinking about this problem/solution for weeks and months, it keeps you up at night, you get all hot and bothered just thinking of the potential. Anyone who steals your idea will always be one step behind, waiting for you to lead the way while they copy features. Your experience, execution and vision matter as much as your idea.
You will have Competitors
If your idea is based on the convergence of multiple trends (i.e. daily deals, group messaging, check-ins, photo sharing, etc…) there are likely multiple people with the same exact idea at roughly the same time. Regardless if you start to show success you will have competitors. That’s not necessarily a bad thing as it validates the space, creates competition for funding and creates buzz/pr/publicity.
Anything I missed? Any reasons why you still don’t want to share your ideas?
Since the launch of Startup Giraffe I’ve had the opportunity to speak to 50+ idea stage entrepreneurs. I’ve been amazed at the diversity of good ideas that folks from outside of the startup scene have. Through conversations with them I’ve realized that many could improve the way they think about launching products. Here are some of the most common mistakes we see:
Feature Set is Too Broad for a First Iteration
Many entrepreneurs we’ve met want to build products for everyone. Successful products start by having a tightly defined, niche audience and growing out from there. Products built for everyone serve no one. If you can’t describe what your product does in one sentence, it’s probably too broad for a first iteration. It’s great to have a big vision but the v1 feature set should only be a thin slice.
Not Defining Goals & Outcomes
After the product is built how will you measure success?
Do you want to see traction? Make sure you build virality into the product (don’t just tack on social invites at the end). Make sure you can easily track how/when/why users are inviting their friends.
Do you want to raise a VC round? Talk to VC’s understand the metrics that they will use to calculate whether you are worth their investment.
Do you want to see if customers will pay for the product? Build in pricing up front, start measuring what percentage of your users convert to paid plans.
Building Functionality That Exists Elsewhere
Unless there’s a really compelling reason, most products don’t need to build their own chat, reviews, commenting, messaging, friending or following services. You should focus on functionality that only your product offers and leverage third party API’s. Don’t reinvent the wheel.
Thinking of UI Rather Than Tasks & User Stories
Many folks we speak to have done their own wireframes or have a strong idea of what the product should look like visually. While this is extremely helpful in communicating the idea of the product, a better approach is to focus on personas and tasks. Who are the archetypical users of your products? What tasks do they want to be able to accomplish on the site?
I ask folks we work with to rank each feature by priority and how frequently the user will use it. We then go in and estimate a level of difficulty for each task. Based on this we can have a great conversation around scope. Only once we understand the core feature set can we can start defining a minimal UI that addresses all tasks/user stories.
Not Speaking with Enough Potential Customers
Our team has gotten really good at trying to validate market fit before we write any lines of code. We recommend that you speak to as many potential customers as possible. Talk to real people about the problem you are trying to address not the solution. Really try to understand their behaviors and motivations. Whitney Hess has a great post about conducting user interviews.
Too Much Time Refining Details Rather then Executing
Many of the people we speak to have been thinking about their products for months. They’ve brainstormed every feature they can possible feature they can think of. They’ve understood their goals and have whittled down their feature set to a true MVP, but yet they are still hesitant. It isn’t perfect. Unfortunately, it never will be. The first iteration should be a tool to test your underlying assumptions and get you to the next level. It’s a broad stroke that you will only be able to refine through metrics and observations/conversations with actual users.
Of course, there are many ways to get your product off the ground. These are just our suggestions based on recent experience. Agree or disagree? Let me know…
Over the past few months my two buddies and I have worked on a bunch of different projects. From StoryStack to Tractorbe.am to AudioJux (plus a few others), we’ve realized a few things:
We get all fired up about new ideas
We’re really good at building the first iteration or two of a product
We love working on a wide variety of platforms and across multiple verticals.
Today, I’m proud to announce our latest venture, Startup Giraffe: a product development shop focused exclusively on translating ideas into minimum viable products. In other words, we’ll build the first version of your startup for cash and a small slice of equity.
We’ve started talking to a bunch of non-technical founders, business school students, corporate dreamers, and companies who don’t have the right type of in-house talent. We’ve realized that options for people to get a new product off the ground are extremely limited. Existing development companies are charging huge sums for builds that are far more complex and time-consuming than necessary.
Our goal is to simplify and expedite the development process for entrepreneurs. Here’s how we do it:
We work with entrepreneurs to define their minimum viable product, or the simplest product they need to test their market assumptions.
We collaborate with entrepreneurs on wireframes and graphic design
We build the web or mobile application rapidly (typically 2-3 weeks)
Once we have delivered the first iteration of the product, our involvement becomes more strategic. We offer technical, marketing and product feedback as needed. With a first iteration in hand, entrepreneurs can then begin: validating assumptions, gathering customer feedback, raising funds and finding a technical co-founder.
I’m excited about this for so many reasons and really believe this fits our teams strengths and interests perfectly.
Got a project idea? Get in touch at ak(at)amitklein(dot)com.
No one said working at a startup was easy. Although we started StoryStack with the intensity of a thousand suns we’ve hit a few bumps along the way. Through three iterations of the product and countless meetings with friends and advisors we’ve realized the product in it’s current form is unlikely to be successful. We’ve found ourselves stuck somewhere between Informed Pessimism and Crisis of Meaning. Now what? How do we turn our passion and drive into productive energy?
We have a smart, resilient team and are throwing around new ideas all the time. Should we succumb to the sweet Siren song of new ideas? Do we stick by our guns and pivot and push forward? Here are the factors we used to dictate our direction:
Addressing Pain Points – Is this a product that customers are begging for? There are a bunch of ways to test this before you write your first line of code:
B2B – Find potential customers and cold email them a brief description of your product. If you find it easy to get decision makers on the phone or in meetings you’re in good shape. If after your pitch you can get them to commit to purchasing your product when it’s ready, you’re money. If they love it until you ask them to pay… tread carefully.
B2C – Setup a landing page (like LaunchRock) briefly describing your product. If you have a little cash buy some Facebook or Google ads leading to your landing page and see the percentage of people who sign up (see Zygna’s Ghetto Testing). If you’re broke: email, tweet and FB message your way to a sufficient sample size.
Another good indicator are homebrewed/hacked together solutions for the problem your product tries to address. Are people stretching the limits of existing products or using multiple products in weird ways to get the same result? People are lazy, if you make it way easier to do something they are already doing, you’re probably on track.
Strengths of your team – If you taught yourself to be a your own technical co-founder and don’t have experience building scalable web products, tackling a mass consumer B2C web product might not be the best idea. If you’re a good sales gal and know how to manage customer acquisition through multiple channels then the company you choose to build should leverage those skills.
The right market – I loved these two posts from Elad Gil:
As you iterate in a market, you will often find that the initial idea you chose is less important then the broader market you are in. A great market will always have opportunities in it. Even if the first idea is terrible you will get to know the market and its needs and build something great on your next try. In contrast a great idea in a terrible market will often fail. ~ You don’t need a good idea to start a great company
What’s changed about the market? Are there cost changes, new distribution channels or technologies?
Is the industry and customer base growing rapidly?
Is there a lot of interest in the market?
Passion - Even if you have the product that customers would line up for, fits excellently within the strength of your team and is in a killer up and coming market the number passion is still the most important factor. Startups are hard. Are you going to be thinking about your product 24×7? Are you gonna love coming to work even when it sucks and it seems like you aren’t making progress? Do you HAVE to work on this?
So what are we doing? The short answer is that we’ve decided to delay the decision. We’ve temporarily put StoryStack on the back burner and while we work on a (soon to be announced) social, music product. We’ll do a small launch next week, quickly reach the area between informed pessimism and crisis of meeting and go through the whole thought process again…