If you work for a big brand, lean principles can be a bit scary. The definitions for product development are fluid from the beginning, meaning you can’t really “sign off” on a detailed spec. Specs and deliverable sign offs are your friends in big co. It’s safe and easy. You list what you need, get sign off from the boss and then build it. It’s the tried and true Waterfall model. The priority, often, is lower risk and job security for you.
But big brands should adopt lean principles and, if you work for a big brand, you should be a lean champion. Here’s why:
I get it thought. The spec and feature lists may be safer in the short-term. You will probably keep your job. At least as long as you are protected by big co. And big co manages to stay in business. But for you, for the long-term, Lean is your friend.
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:
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?
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.
For the past few months at Fabric, we've seen several entrepreneurs pitching Internet/Software concepts in the idea stage. They have brought investment decks, paper drawings, wire frames, and product descriptions. (Thankfully no business plans). They are all pre-Seed and they are all meeting with investors. Some of them have started building their product, but 50% have not.
The few that have not started building their product give different reasons for this. Common excuses are:
While these reasons seem to make sense, they raise a few flags with our team. Here's what we worry about:
You don't need to raise money to start to build your product
If you are committed, then you should put all your cash into product development now. That includes your credit cards and whatever you can borrow from anyone. We've seen Wordpress “products” built for $2k to test a hypothesis. The first version of Groupon was a Wordpress site. Why? Many investors won't even see you unless you have something live. That's a fact. (More reasons below).
Product development is different - and much harder - than sketching
We've had many people come to us with hand drawn wire-frames with very little detail. We're happy to see these things - it's better then nothing - but it's not enough. When you work on the details of your product through flows and mock-ups, you are forced to make decisions that you don't have to make when you are in sketch mode. For instance, you have to settle on database structure and priorities. You have to make left or right decisions in areas of your product that will impact other decisions down the road. You have to be super clear on your product description and you have to communicate the nuance of your thinking. You can avoid all that when you are in sketch mode. It's different. Very different. Who's telling you this? Dennis the Foursquare founder.
Learning fast is important
Many of your assumptions are wrong. (Einstein was wrong most of the time!) The trouble is, you won't find out until you put some part of your product in front of users and test. The longer you wait, the longer you stay in never land. It's nice in never land, but you'll have to get testing sooner or later. It should always be sooner because when you learn which of your assumptions are wrong you can correct - which of course is critical to progress. This is basic science and it's shocking to see so many people get this wrong.
Strong social products RULE the world and social products are different
To win today, you need to learn how to build social products. Building social products - or community products - is really different than building, for instance, a direct marketing product. You'll need to think about how to build context into your interface and, in many cases, where your growth model is dependent on viral coefficient you have to build loops - essentially social loops - into the core fabric of your product. The challenge? It takes time to learn how to build a solid product - a social product - for your users. You'll need to start as early as possible on this journey since there are many lessons to learn.
But what if my product requires infrastructure and complex architecture to work? What if it's a transaction product with a deep back-end?
It doesn't matter. Some of the coolest products was started without a backend. You don't need any of that stuff to prove some level of product/customer fit. Besides, never put a large part of your budget into tech until you are certain that you NEED that tech. You should test, test, test, before you invest in tech. If you worry about scale, just limit growth by capping your Alpha to x users. Also, you don't need real transactions to show investors that users would likely go through with a transaction. Be creative.
Traction
Most of the entrepreneurs we work with go after consumer Internet. They all need to raise more money to get past their next milestones and most investors care about traction. It's simply impossible to show traction without a product. To get traction, real traction, you have to figure out what makes your early adopters tick. You have to understand your different user segments and you have to identify your key users - the ones that drive viral growth. To do this, you have to build, test, learn, and iterate. You have to build a culture for rapid development and you have to train your product, design, marketing, and development team members to work on the most important aspects of your product. This all takes time.
So, get started on your product now. You'll need all the time you have.
It's really fantastic to see that people are pouring energy into the LA startup scene. Several new incubators have popped up and some, such as LaunchPad LA, are offering serious cash for young startup entrepreneurs. Thanks to people like Mark Suster, who has become a top five VC blogger over the past few years, the energy in LA is real and it seems as if the city might just explode with tech startups.
Working with entrepreneurs in the early stages (pre-seed) is very exciting. We're super lucky to have the chance to work on some interesting products with some amazing people. Watch this space for the next few months. I think you'll see a few strong companies unveiled. Thanks!
We want to build great products that change the world (even if it's just for your world). Our main challenge is that today there are so many areas of innovation and so many opportunities to choose from that focus can be a problem. Where do we spend our energy? Who do we work with? What kind of products do we build?
To help answer this, we look carefully at three things:
We've already seen some big shifts in behavior over the past five years. Think about:
We also know that software is one of the key disruptive drivers of change in the world and, since web/mobile software is our passion, we pay close attention to technology innovation from hardware to software.
To sharpen our focus, we have identified a few key “investment” areas for Fabric:
Today, we think that the big challenges and the big opportunities remain in economy (jobs), health, and education.
This is why we're looking to work on projects that:
We are looking for passionate people who are building products on these macros. Despite the economic problems world-wide, we believe the opportunities to build amazing products - to make a difference - are actually expanding. It's not 1999. It's 2011. The good news? You have 10 more years of massive disruption coming your way. Are you going to be part of the past or the future?
Every day, we answer questions about how we work - our process. While our process has been adopted from our work with start ups, it's a process that has been proven to work with all kinds of digital projects - from small websites to major apps built for global brands.
At Fabric, we use a process that mirrors the “Lean Product Development” methodology. There are several core concepts at the center of this methodology that frames everything we do:
So, how is this approach different than what we've seen used at most agencies?
(An important note: I'm not saying that they don't perform research or hold focus groups during early stages of product development. I'm saying that most agencies we know spend too much time and too much of your money working in their shop on tons of features that they do not know users want or will use. After 12 weeks, they launch the app or the website with 90% of the budget spent and then realize that users don't use most of the features they built).
What we do is quite different. Fabric sets aside the (often long) feature list in RFP's from clients and identifies the specific assumptions and the core hypothesis that the project is supposed to test. After we define exactly what we want to learn, we enter into a short (as short as possible) loop:
Build > Measure > Learn (return to build)
For each loop, we build the minimum of what we have to build: wireframes, designs, HTML, of dynamic product/forms - to TEST with customers. Only when we have data - either direct customer feedback or metrics do we move forward into the next loop.
Every process, every task, every bit of code we do is entirely focused on learning. We should never design or code anything that does not allow us to learn something. This means we have to always have to clearly define what we want to learn before we build.
While most digital agencies will push you into this linear workflow. (Hey, we used to do that too.)
Phase 1: Define
Phase 2: User Experience
Phase 3: Design
Phase 4: Develop
Phase 5: Test/QA
Phase 6: Deploy
Fabric's teams will go through these steps in fast motion. We compress work into numerous cycles with intent to learn in each cycle. Each cycle of learning should be days not weeks.
Why do we do this?
Because we've found that it is the best way to build outstanding products, websites, and apps that customers will actually use and LOVE.
What's your opinion on this process? Do you think this is the right track for your company?
For the past year, we've spent most of our time focusing on a new path - a new strategy - for Fabric.
Today, we announce (officially!) that we are 100% committed to helping entrepreneurs, brands, and media build new digital products and drive key usage metrics for those products.
So why would a Startup or brand work with Fabric and not just hire it's own team?
It's fairly simple. Most startups or brands that come to have two key challenges:
What we offer is a faster and less costly route to market for those who do not have their full teams in place. We are focused on the first 6 months of the product cycle - taking a product from zero to 100,000 users. Fabric's teams and process is focused on driving key usage metrics from fast learning and rapid product iteration.
At the product development level, we bring:
We know that the most challenging aspect of bringing a new product to market is to get initial traction and drive usage. Therefore, in addition to our Rapid Iterative Product Development Process we also offer go-to-market services for new products and Startups:
If you have a new Internet/mobile consumer or SaaS product, we want to talk to you. Right now, the product we build sits within social, mobile, geo-location, and SaaS, but we're open to any project that is utility based and/or is attempting to solve a real problem. Call us!