Don’t code: 5 steps to an outsourced MVP

by Matthew Thurmond

Don’t spend months learning to code or looking for a technical co-founder. My interviews with Harvard Business School entrepreneurs and outsourcing industry experts reveal a new playbook for early-stage ventures that replaces the “shut the door and learn to code” ethos with an “outsource early and hire late” strategy. A handful of web-based tools and services are enabling this shift and savvy entrepreneurs are using them to quickly and cheaply bring minimum viable products (MVP) to market.

The 5 steps below describe an easier way to create MVPs:

1) Mock it up
First things first. What, specifically, do you want to build? If it’s a website, skim similar sites and draw up the main pages with your desired logo. After a few iterations on paper, you should have a general outline. Now use Balsamiq to do a more formal mock-up. The end result will be a shareable pdf that looks like a pencil sketch.

2) Design the graphics & specs
Now you want to add color and interactivity. Use Adobe Photoshop or Fireworks for this. You can download a trial version and can take lessons on Lynda.com if needed. The end result is a pdf that looks like the actual site or app and has clickable links that allow you to experience the navigation.

3) OR, skip 2 and outsource the design
If you have no interest in design you can just skip step 2 and outsource the process entirely. DesignCrowd and 99designs let you run “design contests” based on the product specifications you set. Multiple designers will submit graphical ideas and you pick the best. The process can take 3 days – 2 weeks and costs $250-$750. In return, you get a professional pdf prototype of your MVP that is colorful and clickable.

4) Hire a freelance developer
Now go to oDesk or Elance and post a job with your design linked to the description. Expect 10-20 developers to apply and proactively send your job to 5-10 others on the site. Each developer will have feedback from previous buyers and you can conduct a few interviews to narrow it down. Most of the bids will come from off-shore developers and the good ones will charge $20+/hr. You can also outsource complex MVPs to a U.S. development agency like Elm City Labs. The work quality is higher but these agencies cost more or want equity.

5) Manage the developer
You will need to manage the development process and constantly convey what features/bug fixes you want the developer to accomplish. Use Pivotal Tracker to manage the work queue and use Word and/or Photoshop to send visual aids with clear instructions. Make sure you have ownership of the code, hosting service and domain and set up bonus payments that line up with quality targets and deadlines.

That’s it. If you’ve done the process right you should have a functional web site or application. Now you can test the product with customers and, if successful, start approaching technical co-founders and angel investors. Expect the entire outsourced MVP process for basic websites to take 1-3 months and $1,000-$5,000. Expect more complex apps to take 3-6 months and $5,000-$15,000.

For examples of recent HBS startups that have outsourced development via oDesk and Elance, check out Vaiad and Northwestern University Store.

Read More

Launching a Tech Venture, One Iteration at a Time

by Rosemary Kendrick & Aleem Mawani

It’s been, well, a very rewarding semester working on Rewardly.  As we reflect on the main tools we employed this semester—merchant interviews, business model generation, generating mockups, and developing a prototype—we have a few takeaways we’d like to share.

First off, when it comes to interviewing local businesses, be prepared to throw enough darts.  Local business managers are tough to pin down with understandably ever-shifting schedules, so we found ourselves juggling a bunch of cancellations and rescheduling.  It’s helpful to remember that the customer discovery process is a sales process: you start with a lot of cold leads, eventually secure enough interviews, and then ultimately score a few letters of intent.  A corollary to the throw-enough-darts mantra is the realization that you don’t know what you don’t know.  It’s hard to predict which local businesses will be the most helpful to talk to, and it’s even harder to anticipate what insights will emerge.  This is particularly true in the diverse landscape of locally-run shops.  So don’t spend too much time calibrating who to target: just get out there, get in front of business owners, and listen.

With experience, we learned what made the best pitches and meetings.  Often, having a letter of intent signed was a particularly big barrier for local businesses.  Managers varied in their familiarity and comfort with signing what seemed like an official contract.  We tweaked our strategy accordingly and approached the letter of intent as the end goal of a long sales funnel.  Some of the most useful questions we asked were incremental, along the lines of ‘what would you need to see next in order to sign this letter of intent?’  Additionally, with our meetings—and likely any sales process—a product demo speaks louder than an idea.  This is certainly true when you’re a startup trying to tackle the initial customer acquisition hurdle (we imagine it might be different for algorithm-based tech startups).  Our initial concept-based interviews were extremely useful in generating feedback, but our most promising conversations started when we were able to put a product in front of businesses.  The prototype was very rough, with many features and mechanics ‘faked,’ but it was nonetheless an extraordinarily powerful communication and sales device.

This leads to an even larger takeaway about the entrepreneurial process.  Throughout HBS, we often hear that cash is king, but we propose that in some tech startups product is king.  For a startup at Rewardly’s stage, pitching to investors (at least to non-seed investors) was not the best use of time.  Most meetings became coffee chats and yielded few concrete next steps -- the time would have been better spent just building and refining the product.  This is especially true for a startup with first-time founders.  It may be that entrepreneurs with deep domain expertise, an all-star team, or a strong track record can gain much more traction with investors early on in the concept stage. 

As we learned more from our customers and our product, we spent a lot of time refining the business model.  Like so many other steps in the startup process, we found that business model generation was an exercise in prototyping: expect a lot of iterations.  But perhaps more interestingly, we realized that we first needed to reframe our goal.  Given our wide range of potential customers, one size didn’t fit all.  Providing a suite of different payment options was key to meeting the wide array of small business needs.  More established businesses often preferred the regularity of a budgeted monthly flat-fee, whereas newer and scrappier business wanted a pay-as-you-go, performance-based plan.  All local businesses, given their relatively small size and budgets, insisted on a risk-free introductory option.

Building the product is the next step for Rewardly.  We were able, though, to complete wireframing and product prototyping this semester, and we learned a lot in the process.  Our wireframe evolved from a low-fidelity product (paper sketch) to a higher-fidelity rendering (a professionally designed mockup).  When it came to our first interaction with the designer, we discovered that it was important to be specific about the goals and agnostic about the exact details.  The professional designer had a toolset of specific methods; what they needed from us was a clear articulation of the goal of each page and the type of work we wanted completed (e.g. user interface exploration versus graphic design).  Once we had a first cut of the designed wireframe in hand, we could then go back and forth with the designer, incorporating feedback and tweaks through several iterations.

All the steps we took with Rewardly this semester—through interviewing, business modeling, product prototyping, and wireframing—reminded us of the power of iteration.  As hackneyed as that may sound given lean startup mania, it is important to reemphasize as it is distinct from much of what we learn at HBS.  Business school often focuses on the end-points, the funding pitch, the polishing, the analyzing.  But with Rewardly, we learned that the first step in starting a startup is often, well, just taking a ton of steps, and seeing where the customers, product, and business lead you.

Read More

Le Petit Prototype: From Little Questions to Big Ideas

by Riva Bakal, Emily Kramer, Namrata Patel

Eric Ries told us on the first day, “launch early and launch often.”  But, what can and should be done before launch? How do you think about Ries’ advice for an early-stage product (something that’s not even ready to launch)?  For our fledgling mobile application, the iterative approach really took hold in customer discovery interviews and usability tests.  We learned first hand the power of talking to users, customer-centric hypothesis testing, and “launching” with paper sketches and wireframes.  Users may not always know what they want and can’t tell you exactly what product to build; they can, however, share potential use cases and latent needs, ultimately describing exactly what the market looks like.

We started the semester with the plan to build a mobile application from scratch.  With lots of app ideas floating around, we whittled our way down to one: mobile safety.  The first version of Checkmat.es was born.  The application aimed to make students safer by keeping them in contact with friends or parents in the event of an emergency.  Aside from creating a product, the process taught us about applying lean techniques to startups in their nascence.

Having a Hunch

As classic founder-users, we brainstormed use cases initially based on our experiences as college students.  We certainly had a hunch as to how the app would work, but how could three HBS students who all attended college in Cambridge, MA – Harvard, MIT, and Tufts –really understand the safety needs of students in diffuse urban campuses or sprawling state universities?  Having a hunch is great for the beginning phases of development, but customer interviews kept us from assuming that everyone had the exact same needs as us, from falling victim to confirmation bias, and from building an app that served the needs of a small minority.  

Talking to Users Early

There is no good reason to wait for high fidelity prototypes.  Talk to users early.  There’s a temptation to “wow” users with an aesthetically pleasing, fully-baked prototype, but in reality, you can’t let users anchor to a prototype. Thinking creatively and expansively about the problem is paramount.  Wireframes were more than sufficient to coax such feedback from users and validate or challenge our hypotheses. In the early hand drawings, we sketched out the core interactions and use cases.  We transferred those onto an iPhone outline and created buttons and messages with the basic PowerPoint tools.  PowerPoint then gave us enough flexibility to make quick modifications to the wireframes, especially during the usability tests.  A high fidelity prototype doesn’t give you the flexibility you need to act quickly on what you hear.

User discovery interviews also revealed the importance of privacy to users.  We were surprised by users’ false concern that the app would track users’ location at all times or automatically push notifications to parents or campus security.  While we had designed the app from the beginning so a user can self-select an appropriate contact, we had underestimated how much this concern could prevent user adoption.  Users latch onto preconceived notions of how things have worked in the past or how they think they will work.  Though we reframed the interaction design to emphasize privacy and choice, these interviews helped us understand the real needs and preferences of our users, rather than just the features they need in our application.

Keeping it to the Minimum

We also learned that “minimum” is the key word in minimum viable product.  Jamming the app with additional ‘bells and whistles’ confuses users more than anything.  Clean design tugs at their intuition so that they can see how to navigate through the product on their own in order to capture its value.  We took the design advice that “in anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away” to heart[i].

Minimum also doesn’t mean cheap.  Development estimates for Checkmat.es ranged from $7.5 to $10k.  “Lean” necessitates bootstrapping and hustling to find resources.  If we had a do-over, we would apply for MVP funding.

So, What Does Lean Mean?

We were scrappy and process-oriented.  We tried everything that we could to push the product forward without throwing tons money at it.  All the techniques we deployed – user discovery interviews, usability tests, and a minimum viable product – were geared towards testing whether our product met the users’ market.  At each juncture we reflected on our initial hypotheses and revised our approach.  While luck may be another way to get there, customer-centric hypothesis testing is more of a sure-fire way of building something that people care about.

---

[i] Antoine de St. Exupery. Wind Sand and Stars. Trans. Lewis Galantiere. New York: Harcourt Inc

Read More