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?

Attempting to transform a Chloe from being used to sitting behind a desk to becoming the front face for a potential client is not an easy task.

Challenges I had to overcome:

1. Being scared of rejection — I know I can't get a “yes” without even trying, but if I don't try, there's no chance for a “no”…
2. The tendency to mix up clients and projects — I mix things up occasionally; some of the people on different projects have similar names and others are in the same industry.
3. My relaxed approach to interacting with clients — I needed to be more proactive.

Things I learned:

1. How to communicate clearly — both in speaking and in writing. Speaking: I have some things to work on (I talk fast, I mumble, I have a tiny vocabulary, I can't ever think of the right word, I switch words around, I verb nouns and I noun verbs, just to name a few.). Writing: I was never bad at this, but writing proposal after proposal helped me learn how to communicate my thoughts more effectively. Bulletpoints became my new best friend. I honed my skills in categorization and organization.
2. People aren't as scary or as intimidating as I previously thought.
3. It's easier to execute plans when I'm involved from the very beginning.

I got one “no” pretty early on boy was it discouraging. I felt like I failed. I had one “yes” yesterday, which is awesome! …even though I missed an important deadline. I have a maybe which I'm hoping hoping hoping will turn into a yes. I want to get better at this and get more Yes answers. Can't get better at a game if I don't play, right?

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:

• Identify the hypothesis or assumptions that the client has made about their customers needs, desires, and wants - this is part of our definition work
• Design a test of the most critical (leap of faith) assumptions and execute tests with the least amount of waste possible (Minimum Viable Product)
• Enter into Build, Measure, Learn loops where the goal always is to learn if assumptions are correct by actually putting the product in front of real customers
• Get the first version of the product in front of customers as fast as possible

So, how is this approach different than what we've seen used at most agencies?

• First, most digital agencies spend months in the lab before they put the first version of a product in front of customers
• Second, most of the agencies we've worked with have built their assumptions of what their customers want entirely without actually testing their digital product with real users

(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?