How To Go From Idea To Launching With Paying Customers In 8 Steps
Quick Personal Update: I just started writing with Dharmesh at OnStartups. I’m completely honored to be contributing there. You can check out my first post: Lessons Learned From Startup Bootcamp 2010. A good portion of my writing will be going on there along with the awesome posts that Dharmesh has been delivering to a great community over the past 5 years. You should subscribe via RSS as I’m already writing an awesome article to be released there next week. I’m also now based in Boston and you should say hi if you live here or plan on being in town.
Real entrepreneurs ship, don’t ever forget that. An idea is worthless until it has been translated and executed into a tangible product that your potential customers can use. Getting from inception of an idea all the way to shipping it seems like a pretty straight forward process, but so is war- get guns, tanks, draw a strategy, invade, and take over. When you get caught up in the heat of a battle, I’m sure what seemed simple on the surface, isn’t so simple after all. Gunfire has a way of doing that. Shipping a product that customers want is kind of the same thing. The gunfire of confusion, resisting feature creep, and not having a defined process can make taking an idea from inception to shipping it terribly difficult. I was guilty of this with my first startup, Publictivity. Never ever again. I often get asked about the topic, so here’s the exact blueprint I follow. This is how I go about taking a product from inception all the way to shipping it as well as having paying customers lined up. I will use examples from two products I’m currently working on PadPressed (shipped, profitable, 100+ customers, and version two on its way) and Cloudomatic(flow) (early alpha testing, shipping soon for mass consumption, 150+ customers lined up for launch).
Step 1: Define The Problem
The biggest problem with ideas is the fact that they don’t really solve a problem. All too often entrepreneurs go about creating cool things that don’t solve a real problem. By defining the problem, it helps you clarify what you’re building and why. Defining the problem gives you constraints around feature creep. It lets you say “Does this feature or functionality add anything that is core to solving the problem?” You would be surprised how many features make it into products that have absolutely nothing to do with solving the problem.
Example 1: I just bought my iPad, started blogging more heavily, and wanted to make sure my blog was optimized for the tablet format. I certainly wasn’t going to make a native iPad app. At first I thought I would just modify my existing theme by removing dropdowns, increasing the size of the font,etc. Well yeah, that did not work out too well. Problem: No easy way for publishers to make their content Tablet friendly using their existing CMS (in my case WordPress).
Example 2: We created Cloudomatic.com in a weekend. Revenue model was simple: drive traffic, integrate affiliate links, make a very nice commission as SaaS has a very nice ARPU. It turns out that very few SaaS developers had an affiliate program. As former SaaS guys ourselves, we looked around and understood why: existing stuff was too complex, didn’t work with subscription services, and devs were too busy to build it themselves. Problem: No easy way for web app developers to get setup with a simple affiliate program in under an hour.
Step 2: High Level Overview Specifications and Mockups
At this point you probably know what you want to build and specifically what problem the app is meant to solve. From here you start to define the solution to the problem stated above. How will the app specifically solve this problem? What is the secret sauce? The high level specifications should be 1-2 pages at MOST. This is something that a normal human being should be able to read and define specific important features. It’s really the skeleton for the technical outline of your app. In short, it should be enough for photoshop mockups or even just wireframes created with Balsamiq.
When creating mockups and wireframes don’t focus on fleshing out every last detail or every last little screen ie- the reset password screen or some obscure settings page. Instead, pick maybe 4-5 different screens that show the key functionality of the app. You’re prepping yourself for initial customer feedback and validation, so pick the screens that are going to convince them and get the point across that your solution is solving the problem you have defined.
Example 1: With PadPressed , I spent a fair amount of time looking at the native iPad applications major publishers had put out such as USA Today, BBC, Financial Times,etc. I also had a list of specific functionality that I knew was crucial. Simple page design, large fonts, accelerometer aware, touch navigation, swiping to advance were some of them. I also defined the way that integration should work with WordPress. This was more of a technical issue, but it was also key to adoption. For mockups I basically screenshotted from my iPad, photoshopped a bunch of different things together, and also took videos of the touch interactions that were key.
Example 2: With Cloudomatic(flow) we basically locked ourselves down for an entire weekend to get through steps 1-3. I defined everything that was needed from the both the developer standpoint and the affiliate end. From there we translated that into the 4 most important separate screens that had an overview of what the app would do- overview dashboard, define payment plans coordinated with your app, and what the interface looks like for an actual affiliate.
Step 3: Initial Customer Feedback and Validation
This is a really crucial step and it might be a really depressing or exciting step. At this point you now have something that you can show potential customers to have them say: “This is interesting, I would use it and/or would pay you for it.” You should probably synthesize the simple specs into some type of sales literature or at least something a normal person can read. The mockups should be fine as is. If you’re using wireframes, just explain that this is for feedback purposes only and a very rough idea of what is being built.
Example 1: With PadPressed we kept things really rough and also took a risk by playing things close to the chest. We basically explained what the app would do in simple terms: Take your existing WordPress install, if a user accesses your blog from their iPad web browser, it behaves like a native iPad app. We highlighted major features that drove this point home and showed what were some God awful mockups. They were frankshops of many different apps we thought made sense, but it got the point across. Enough bloggers told us this would be useful and that they would pay for it. So we soldiered on.
Example 2: Cloudomatic(flow) was an interesting beast from this perspective. It went way better than we thought it would. This was a very public customer feedback/validation phase using what’s called an MVP smoke test ie- the product isn’t fully built, but gauge consumer feedback as if it is there. The goal was to see if we would get sign-ups, but we also indicated in the confirmation email that if you wanted to be fast tracked into the beta that you could email us indicating so. This let us do a few things a) see how badly some people wanted the product b) have some initial individuals we could reach out to in order to make sure we were building the most critical features first c) set priorities for sending out actual invites when the time came. The site at flow.cloudomatic.com is the same exact site, screenshots,etc. that we used for this phase if you want to see what was actually there.
Step 4: Be An Axe Murderer
Guess what? You’re probably doing too much even with the simple initial spec and mockups that you put together. Besides validating the problem and your specific solution, talking to potential customers allows you to find out which features are really crucial and which ones are nice to have. Start killing off things you don’t need right away and leave them to Version 1.1,etc., but also make sure the really important ones have a very high priority. By doing this, your app will be left to the most core and essential features. This will make it easier to get the product in the hands of your customers AND it will also make you laser focused on the things that truly matter to your customers.
Example 1: With PadPressed we kept the features that stuck with the core vision of making the app feel native as opposed to adding things that would have been publisher/blogging specific. We don’t have comments right now and probably won’t until we can do them right to integrate with the experience. We could have easily just included the comment div, but it wasn’t worth keeping a half assed feature.
Example 2: Cloudomatic(flow) is really really simple. We reduced it down to a few API calls and a Javascript embed. There are a lot of features we’ll add in the future for conversions, advanced affiliate management, reseller management,etc. We basically only went with features that focused on the core problem at hand: a) Specifically working with recurring subscriptions for SaaS b) Making integration take less than an hour for SaaS developers by reducing things to a few simple API calls. We also reduced the payout options from every provider under the sun to the most requested one: PayPal
Step 5: Detailed Specifications
Detailed specs are like your blueprint for the app, and shouldn’t be rushed. You can’t think of every scenario until you start building + testing it, but you can certainly try. When you’re working with a multiperson team, you don’t have time to wait for email responses, second guess, or hold things up. If it’s in the specs, you know where to go. It also helps keep scope creep away. My specs also include the database structure and design as well.
Example 1: PadPressed’s specs were pretty straight forward and were more of a design spec than a technical spec. The really hard part was figuring out how to make it extensible as we plan to release more themes and keep it as a plugin.
Example 2: As we’ve been building Cloudomatic(flow), we haven’t strayed a one bit from the specs or added a single feature. If there’s something we think that’s cool or should be there, we add it to the queue after we get feedback from our first customers. I divided the specs for Cloudomatic(flow) into three parts:
a) General app – this is where users/SaaS developers login to see stats, add plans,etc.
b) API Integration- how do devs integrate and how does the API work? It’s a beautiful and simple REST API.
c) Database Design- What does the data architecture look like?
Step 6: Build It
This is the fun part as things start getting built. From here, it should be pretty straight forward as you know what the app looks like and what all of the functionality looks like. The goal at this point is to have the war won before you ever fight/code it. Yes yes, there are things you cannot forsee, but for the most part, you will know what to do. You’ve also spent so much time thinking and noodling on how to build the app, that a lot of pseudocode is subconsciously in your brain.
Example 1: PadPressed went to the building phase really fast. It took about 40 days to go from 1 LOC to finished with Armando. The hardest part was redoing the touch interfaces. We originally set out to use JQTouch, but it just didn’t work well enough. Instead, we created our own JS libraries for most of the interactions.
Example 2: We’ve spent a ton of time building Cloudomatic(flow) . Honest truth? More time than I’d like. The problem with developing something that is infrastructure, especially infrastructure that deals with money comes in the form of the small minute details. Yes, you know they’re there in the specs, but actually building for them is really hard. Your API has to be designed right from the start. We thought we’d be done in 60 days, when it’s more like 150 days. Lesson learned: Make sure you keep things in the earlier steps, because they always take longer. If we had a more complicated spec and didn’t throw things out, I can guarantee you, the product would be dead in the water due to bloat creep.
Step 7: Test For Critical Mishaps Internally and With Confidants
There are bugs, then there are “holy shit this is a critical error”! It’s the difference between handing in a paper to your teacher with a spelling mistake or two and leaving out the answer to 2 out of 5 questions. Find people you trust as well as your internal team to give the app a good run for critical bugs.
Example 1: PadPressed was in testing for a good two weeks on my blog and a few other WordPress installs and only accessible if you were logged in. I just sent a tweet out and had people willing to test. People love to test iOS stuff and it usually isn’t hard to get your network to reach out. We found a major bug through this that the swipe to advance feature didn’t work in portrait mode.
Example 2: This is where we’re at with Cloudomatic(flow) right now. We’re really testing the following two things heavily: the tracking works well AND that the API integration is easy/works well. If we nail those two things town, we have the most critical things taken care of. Kevin Hale said: build as if you had to support that shit. I say: build as if you had to test that shit hardcore. The more stuff you add, the more stuff you have to test. The more stuff you have to test, the longer it takes to get to market.
Step 8: Launch It
This is where the t’s get crossed and the i’s get dotted. Make sure all the documentation is there, support is setup, and the marketing front end is good to go. If you did an MVP, you can actually use a large portion of that site as your marketing site for copy. Step 3 was all about customer feedback and validation. You should have been keeping in touch with your customers throughout re: pricing and updates. Make sure you have the merchant processing in place too. Also be ready to transition from what is most likely a development server to a production server. For more press, marketing, sales,etc. launch related/non-product stuff, I suggest reading: If you have been doing customer development along the way and planning for a launch, you will have customers on your first day.
Example 1: PadPressed was a fairly easy launch since it wasn’t a SaaS product. It was setting up the merchant account and the digital delivery that took a lot of time. The demo videos also took a couple of days as well. We had 30+ customers pay us on our first day.
Example 2: Cloudomatic(flow) will launch in the next 30 days. We have a list of 150+ interested customers and another 250 SaaS developers we’ve built relationships up with. We’re planning on modifying the existing site copy, adding in more concrete pricing details, and that’s it. Out of that list of 150+ “interested” customers, we have a handful who have already given us their billing information.
By all means this isn’t a definitive list or some sacred cannon like many people try to preach. It’s what I’ve found works really well for me as an entrepreneur. At the end of the day, I hope it serves as a nice point of reference for those technical AND non-technical who want to bring a product into the world with paying customers. You can also follow these steps with or without funding. We’ve gotten to where we are today without a cent of outside money, though having a little bit more manpower could have been a help once we started building the product.