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).
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 wire frames created with Balsamiq.
When creating mockups and wire frames 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 screens hotted 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.
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.
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 multi-person 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?
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 foresee, 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 pseudo-code 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.
Business Insider Emails & Alerts
Site highlights each day to your inbox.