Continued from: Start-up Series (Part I): What we do for the start-up entrepreneurs that hire us

Last time, we talked a bit about what we do for entrepreneurs that come to us with an idea for a consumer web or mobile start-up. Today, we’ll quickly go through the process we use to get to BETA.

First, it’s important to remember that there are usually two challenges that most startups face when they start building their BETA.

1. Somewhat blurred product vision
2. Limited capital

Having blurred product vision is pretty common. This comes in many shapes and forms. For instance, we often see a fairly decent vision, but a long list of features. Parts of the product may have been worked out, but other key parts, such as the user experience is full of holes. This is OK. It is often the reason why entrepreneurs come to us in the first place.

Having limited capital is a given. Sometimes though, there are also limited resources available as an entrepreneur may not have the time available to put 100% into the startup and often is not familiar with the large work load that comes with starting something from ground up. This is where our process comes in handy.

The basic steps are:

1. Entrepreneur provides all documents to Fabric for review
2. Q&A session with entire team – including product leads, design, experience, marketing, and tech
3. Fabric will produce a high-level estimate (Scope of Work)
4. Entrepreneur Funds Project
5. Definition: Detailed definition is developed for the first release of the product
6. User Experience Design: Wireframes and Functional Specifications
7. UI Design: Making it look great!
8. AJAX (or Flash is you are crazy)
9. Development: Database and Programming
10. Hooking to 3rd parties (most web startups are full of API hooks)
11. Admin Tools and such
12. Deliver website or application on Staging Server
13. Testing & QA
14. Deliver Alpha or BETA website/app to Production Server
15. Deployment: Tell everyone you know about your amazing product!

This is the quick and dirty work flow. In some cases, we have to work hard on concept development while other times it's more a matter of focusing on key user experience challenges. There are two rules we always follow:

Keep it simple and focus on the one thing you have to get right for users

Get your BETA up fast!

Once the BETA is up, we start working on the Product / Market fit, which is really just all about user feedback loops and product iterations. In our experience, this is really the hard part, but it's also the fun part. There's nothing as exciting as getting real people to give you feedback on your invention!

Next time, we’ll look at what kind of documentation we are looking for when we start working with you (hint: it’s not your business plan).

Start-up Series (Part III): Where is your business plan?

You think about the future? Can you see it?

• The tablets are here. iPad is just the beginning.
• My 18 month old son is using a touch screen every day.
• Social networks are not going away. They will grow.
• It's true: The Semantic Web will change everything.
• The Cloud is real and powerful. Where is your data?
• Think your industry is different from music and publishing?
• Are you really thinking for a living? I hope so.
• Do you like to do what you did yesterday? You will loose.
• Don't like the 30 second spot? You can make it go away.
• I will choose my advertisements. I pull the information I want.
• Change is not optional. Commuting is. Ask for change. Today.

Working with entrepreneurs before they launch their first product is often exciting and challenging. For many, the most difficult part of building the first product is launching. Pushing the button. Saying “OK, this is it, now we'll put this in front of people today.” It's hard because your vision of what the product should be and what you've built in that first version will be far far apart.

You fear that the product won't work. That no one will use it. You fear that people will talk about you and your product in some negative way. You believe you won't get a second chance. That no one will care.

Of course, on some of these points, you are right. Few people will care. Most of those who see your product will maybe use it once and never again. Some people might even tell other people that your product suck (although few will remember to do so since they are too busy to be going around complaining to friends about this Alpha product they tried once.)

The fear of launching to “the market” seems reasonable enough. However, we've seen this fear of launching even with closed Alphas. For instance, we've seen weeks of tinkering with the first version of a product before pushing it in front of just 30 users. Yes, even at that stage, people are afraid of what users will think. They choose to hold off on user testing until the product is “in better shape.” We've seen products be in 100% stealth for six months. Most of the product works fine and we have 3 tests we could run with users right now, but because the design or experience is not “good enough” the product/user testing never begins.

This is human nature. Many entrepreneurs, especially successful ones, are perfectionists. They want the product to be really strong before they show it. They want to be proud of it. They want the design to be smooth, the experience to flow seamlessly, and they want optimized technical performance.

Lean Is Better But Not Everyone Gets It

The Lean Methodology was partly designed to tackle such issues, but it has been met with some resistance. For instance, in the past few months, we heard from one seasoned Internet/Mobile entrepreneur that this lean methodology is just hype. They don't buy it. They think “it works with some products, but not with ours.”  Some believe that you have to build most of the product before you put users in. Some have even mentioned Steve Jobs as proof that the way to go is to have a vision and then build exactly what you want - not what users say they want.

This is bullshit. First of, Steve Jobs was entirely in tune with the customer. He listened to users all the time. He was the user. He was also more in tune with design, product, and marketing then anyone else alive. He knew exactly what was needed to bring about success, but remember the first version of many of “his” products? Even he had to go through a lot of trial and error. It won't be any different for you.

So if you build 80% of your product before you bring users in, you are in deep deep trouble. The point of lean is not to build a poor product fast and launch it. The point is to figure out which of your core assumptions are right and wrong. The point is to learn - fast and early - what to build and how to build it, where to focus your resources, and what not to build.

To minimize waste and get answers from users - you must launch early. You have to get one version of your product in front of one group of users so that you can get to testing. Something magical happens when you talk to people who are using your product for the first time. You'll discover that they won't behave the way you intended. You'll find that people will do things that you didn't even think of. They will ask for features that you don't have on your product roadmap.

The fear of launching is irrational. Once you launch, you'll realize that most people won't care. They won't care because you didn't get the product right. There is only one way to get the product right: Launch early, test, measure, and iterate. Repeat. It takes time, but it's the only way.

We get a lot of questions about this, so we thought we should just do a quick summary of what we’ve done and what we’re interested in doing for you entrepreneurs out there.
First, we’re just really passionate about start-ups because we enjoy the process and we love to see new underdogs challenge the big boys. Some of the people on our teams have done their own start-ups in the past including the fun task of raising capital from investors. Some would say we’ve learned the hard way. You can take advantage of all that learning so you don’t make the same mistakes we made. (Good right?)

We are mostly focused on consumer web start-ups because that’s what we know. For instance, right now, we’re working with three consumer web start-ups in BETA. Through our agency business, we’ve learned how to work with big brands and we understand how small start-ups can become valuable to potential acquirers or partners – such as big media or publishing.
Our Product Group has years of experience developing actual web products and this experience has made our team a perfect partner for two different scenarios:

1. The entrepreneur is technical, but needs help with product, user experience, and design
2. The entrepreneur lacks the product or technical team to build the BETA version of her dream

In most cases, we come in to build the Alpha – or first release (BETA) version of a web or mobile product. Fabric’s Product Group adds what is needed to the mix and usually delivers a complete product. During our process, we work with the Entrepreneur from the initial concept stage, through experience design and development and into Alpha or BETA. Once the first release is out, we often help entrepreneurs get to their first 1,000 or 10,000 users.

Next, we’ll go through our process in more detail and we’ll tell you what we look for when we consider new projects:

Start-up Series (Part II): BETA Build Process

Start-up Series (Part III): Where is your business plan?

Creative agencies such as advertising and design firms must deliver high-quality sites and apps on aggressive schedules for big brand clients. Unfortunately, agency teams often have limited technical expertise and few engineering resources. Agencies are driven by creative. They have amazing creative, art, and design teams. However, they seldom have deep technology experience and they often lack depth in software development. Driven primarily by creative marketing people, agencies seldom have creative technologists on staff and they struggle with technical documentation, process, and software development discipline.

This is why Fabric are the preferred development partner for agencies when they need to deliver social sites and apps for major brands. We add layers of expertise, skills, and proven execution ability to agencies in need. We've done it for Carmichael Lynch, David & Goliath, and even for interactive agencies such as Rocket XL.

We help agencies with technical expertise, writing functional specifications and UX documentation. We offer integrated development teams and our battle-tested process to deliver large scale social sites, complex API integrations and data aggregation solutions. Custom CMS builds or complete transition or integration of CMS solutions such as Silverstripe, Wordpress, and OneSite.

But most of all, the main reasons agencies hire Fabric is to make sure that important projects are delivered with top quality, on-time, and on-budget. Agencies smile. Clients are happy. That's what you want, right?

Brands and startups tend to compare Fabric to other development shops. Some of this is fair. Often, we add engineering resources or act as an extension of existing in-house teams. Much of our work is in user experience, design, and almost always front and back end development. This is what we do, but it is not the core of the value we bring.

Let's talk about startups. While Brad Feld, Fred Wilson and other VC's are right when they say you should have your core product team, your engineers, your experience designers, and your designers in-house, the truth is that most pre-Seed stage startups cannot find quality talent in all these positions. From the pool of startups we've worked with, most are somewhat inexperienced entrepreneurs and often lack deep product development experience. Often, startups that do have technical co-founders often lack customer development experience or user experience design knowledge.

Most importantly, it is very difficult for startups to hire and develop strong teams fast and to adopt a solid grasp on the chosen development methodology instantly. When founders are young, as they often are, many product development mistakes are often made. This “learning on the job” can be very expensive.

These are some of the reasons Fabric is a good collaboration partner for many pre-seed stage startups. Unlike most development shops, we contribute experience and talent in several areas:

We Add Complete Product Focused Teams With Experience Working Together

Everyone on our teams have worked together for at least one year. That means they have strong communication and faster execution paths than a new team. They are strong collaborators producing more output per Sprint than a new team who just met or have never completed a project together before.

Proven Methodology = Successful Products

You don't have to buy into everything we preach. We're still wrong about stuff all the time. That said, we have spent years optimizing our Product Development process and, if you follow along, you're guaranteed to learn more faster with less waste. We've also seen what happens when you don't have a solid process. Very expensive.

We've probably made more mistakes than you - we'll help you avoid all those

We can spot mistakes early. We've seen success and we've seen failure. We have been “in” failure and we've been “in” success. Our teams have made 100's of mistakes and learned from it. You will also make mistakes, but with us, you will not make the mistakes we made. This can save you 500 hours of programming time or 100 hours of design time. Fewer mistakes also is less expensive.

Development shops build what you want them to build not always what you should build

We ask hard questions. We challenge your assumptions and push hard on the edges of your idea. Will it stand up or fall down? What are the major assumptions that have not yet been tested? How many customers have you talked to? Throw away your feature list. Throw away your spec. Now, let's start over: what is the minimal product we can build to test the #1 assumption?

One question we always ask is: How can we do that for LESS? It seems counter-intuitive right? Shouldn't we just build and bill? No. That is what most development shops do. That is what agencies do. That will not help you raise money, which for most of you, is what you need to do. To raise money, or get to profitability for some of you lucky bastards, you need product/market fit and traction. To get that, you need to spend the minimum amount possible on things that don't matter. What are those things? (Polish your design… probably. Feature #13? Definitely.)

Venture Development and Startup Experience

We have raised capital and pitched VC's. We've run our own businesses and we've started several companies between us. We've been through the hard times, we've run out of money, and we've been in “partner fights.” We have created business plans, 100+ pitch decks, financial plans, and jockeyed CAP tables. When you work with us, you tap all this experience. You can get it from others too. Incubators, accelerators, and entrepreneurs all add this value. You won't get it from most development shops. It's not in their “wheel-house.”

Deep Brand, Media, and Agency Relationships

Most other development shops are deep on the engineering side. That's great. However, they have limited or no relationships with brands, media, and agencies. We've spent 10 years working with some of the biggest brands in the world: IKEA, Toyota, Redbull, and Hachette. We understand selling to these brands and agencies. For all our startups in our family, we've been able to make direct introductions to C-Level contacts sometimes enabling the startups to win major contracts - a major value add for any early stage startup.

We're different. To find out how different? You should call us now.

We spend a lot of time working with web/mobile entrepreneurs and we're super lucky to be working with amazing people with cool ideas, tons of energy, and a lot of passion. For the past six months, we've tried to pull our clients, both startups and brands, into following our methodology: Lean Product Development. The benefits with Lean are clear: better products from a science/testing approach, less time to market (or less time to get in front of users), and less waste.

For our clients, the “trouble” with Lean is that you never really know “what you will get.” You don't know what you will eventually build even when you've spent 25% of your budget. You cannot, and you should not, estimate the “entire” project up front and you should not spend time on specs and documentation of “features” that you may or may not build.

This can be unsettling to clients. We understand why. The traditional model, most often used by agencies is very clear and straight forward. It goes like this:

1. You make a range of assumptions - maybe 20 - about your users needs and then create a list of “features that fulfills those needs”
2. You build a detailed spec, estimate, and schedule of the exact hours/cost and timeline to build “it”
3. You then start by wiring up the experience, design the screens, develop the features, before you launch “it.”

In the traditional model, because you “know what you are building” up front - you can tell how much it will cost and “what you will get.” This is a great feeling. It seems less risky. I can touch it. It's a “deliverable.”

The problem is that this “method” does not work at all for consumer web/mobile product development of any kind today. The reasons are many, but the main one is: You will most certainly be wrong about “what you need to build” and you can be sure that what you build - the whole thing - won't really work or connect with users until you are well into future releases.

Despite this, this “waterfall” model, is the standard among most agencies and many development shops. Most of our clients who have interactive or agency experience are familiar with this model. We understand why it seems to “work.” The problem is: We cannot build products that way, because it is wrong. We know that it doesn't work.

The truth is that you never know what you will build

You don't know what you need to build in the beginning of the project and you don't know what you have “left” to build when you are 50% “there.” It is wasteful to do big estimates and loads of documentation up front - before you get users engaged. It is wasteful to spend time on spec writing and requirements that does not center on specific assumptions, test cases, data from learning, and/or user feedback.

It is true, neither you nor we know “what it will cost” and exactly “how long it will take.” You don't know when you will be “done.” In fact, being “done” is not a possibility. You will never be done. (Unless you sell your product or exit in some way.) You have to get used to it. There are no “complete estimates” and no “complete specs.” You don't need it.

You should focus on what matters. That is not documentation. That is not estimates. Those are wrong always. What you need is what every scientist spends her time doing every day: EXPERIMENTS. Well structured experiments.

This is what we try to do with every client. We do it because we have tested the traditional model vs the Lean model and Lean wins hands down every time. We hope you do it too. Do you?

Right now, we're working with several clients who are asking: Should we do a native (iOS or Android) mobile app or a mobile web app in HTML5?

Naturally, you'll always have to consider the business objectives such as experience, speed, and hardware feature advantages of native, but often the final decision comes down to budget. Curiously, we've found that a large portion of iPhone apps could have just been done in HTML5 and reach would have doubled. (I suppose iOS developers made the decision to go with what they know.) There are of course frameworks such as Appcelerator that allows native development and deployment to iOS, Android, and Blackberry, but such frameworks have natural limitations and may not work for your needs or turn out to be too expensive still.

For those of you on the fence, we found this to be a good primer on HTML5 vs Native mobile development. It gives you a fair idea of what the cost vs benefits are and it's a good framework for thinking about your priorities when making this choice.

Happy weekend!