CableLabs sponsored Boulder Startup Week this year, and with that in mind we thought we'd take a look at a startup approach that could have value for business of all sizes and in all stages. Ken Fricklas, who has extensive startup experience, provides his take below:

What is Lean and Why Do We Care?

A term that’s been getting a lot of hype lately is “lean development” – and the related term, “lean startup.”  This post is meant to give an overview of what exactly we mean by both of those terms, and introduce various concepts that we can use in our daily work to succeed more quickly and more directly than we typically do in a product or technology development process.

The term “Lean” can be confusing, as it’s used to mean at least two different things which combine to create a “Lean” organization.  The first meaning, frequently called “lean startup,” is a group of methods used to develop business models in as short a period of time as possible, with the lowest risk (and spending) possible.  The second, “lean development,” is defined by two things: Continuous deployment  and managed queues.  We’ll be discussing all of these in future blog posts.

The idea of Lean is to eliminate waste wherever it’s found.  When you look at a typical waterfall development process, the phases of development are Requirements Analysis, followed by Development, Testing, and finally Deployment.  That doesn’t change in the Lean world – what changes is how we implement them.  In that traditional process, you take an idea, and start with all the requirements analysis – a marketing group, typically with no developers involved, talks to the customer, finds out what they say they are interested in, and asks them what they would pay for it.  This group writes up a bunch of functional requirements, at which point the leads in development estimate what it’ll take to build it.

After signoff, user experience engineers interpret the feedback (though none of them were there, so there's probably some mistranslation), and pass it through some designers, who produce a prototype. The next step is low level requirements, and then you spend 18 months or more developing a product, at which point real customers get it, and we get to see if it actually succeeds or not.  If we are missing something, or there’s a gap between what we originally viewed as the most important product features and what users really want (as is likely, given how far removed from the customers we are at this point), we ask the customers what we’re missing, and implement their top features using the same process.  But of course we can’t remove any of the functionality we already created – even if it’s confusing to the users.

So what’s happened? You just made a huge bet that the most important features that a user wants and is willing to pay for are the ones you implemented, and if you have another go-round you’ve delayed the critical mass of what a user is going to pay for until version two or three of your product – and you really delayed your time-to-market by months or years.

So What Does Work?

What we’re doing is reducing waste – that means not implementing stuff before we need it, testing, and picking the next small subset of stuff that provides a measurable impact on the user interaction with the product.  Keyword – measurable.  Lean is all about removing what you think is happening and replacing it with measurable results.  If you can’t test it, you don’t know if what you’re working on is succeeding or not.  It’s actually applying the scientific method to the development process itself.

One term we hear a lot in the lean startup world is MVP: Minimum viable product.  What an MVP is not is the minimum feature set a user is interested in – rather, it’s the minimum set of features we can present to a user to ask them if what we implemented is what they are looking for.  For a complex product, this might literally be an animation or slide deck, with a description of what it does, or a prototype with no actual code behind it.

Let’s say we’re developing a portal that allows users to order Internet service upgrades more easily.  Step one of an MVP might be showing a few users a form drawn in an application – no code involved – and the test could be interviewing them to see if this would be something they are interested in. We would them work on improving the form based on their feedback.

The next step could be implementing a web form on a website, which just produces an email that sends someone a note that the user is interested.  No back-end yet – no product! This time we test various forms to see what improves understanding of the “fake” portal – and if no one uses it, we kill the product before doing all the back-end development to make it work.  Have we failed?  Well, if doing the full project cost $200K, and this cost us $15K to get to this point, we just made $185K by not creating the product. We’re reducing risk.

So, what exactly are we doing here?  We’re testing “product-market fit” – we are checking at every step to see if the product we’re building is the one that customers care about, as opposed to the one we care about.  We’re not just testing the idea, we’re testing the implementation.  We’re developing as small bits as possible to adjust what requirements are the most important to our customers.   We’re applying an agile development process to the business plan – the requirements development process -- not just the development phase.

After implementing an MVP, we should take a look at what has worked, what has not worked, and try to figure out why what didn’t work, didn’t work.  As soon as we know, we reexamine our requirements based on what we measured – and if we’re way off, we “pivot” – change the product or the business model to reflect the reality we just measured. This learning is the most important part of the whole process – the purpose of lean is to maximize learning at each stage, and let our learning affect the product as early as possible to avoid developing to the plan instead of the real world.

In future entries, I’ll be talking about using a business model canvas, a tool to easily see what the current status of the project is, how lean and agile fit together, and how to apply this process to the development of technology and pure research instead of end user products.

For more in depth reading, I recommend the Harvard Business Review article, “Why the Lean Startup Changes Everything” by Steve Blank, available at http://bit.ly/SB-Lean.

Ken Fricklas is a Director of Application Technology Development at CableLabs, and former CTO of PlaceWise Media.