We had done this at a previous company I had started (with others). We were over 200 people at the time (~ 75 developers), and had created a situation where there were serious clashes between the "start-up guys" (who preferred to put ideas out there quickly, warts and all) and the "serious engineering guys" (who didn't like the idea of supporting those things, and preferred no warts to ever be shown to customers). [0]
Our solution was to create a new team, with a new VP to report to, who was aligned with their goals explicitly. The team's focus was to simply find interesting new product spaces, prototype the solutions quickly, and get 1 paying customer. The "start-up guys" were moved to this team, and they hired more like-minded developers. The normal R&D department would take up the prototype as a proof-of-concept once it was worked out that there would be enough customers to justify the longer development of the final product. While it resulted in the creation of the company's latest product, it definitely did not solve the problem it was designed to - but it did increase the understanding of the engineering team as to what would, and wouldn't work when they got to work on the problem. Which, is really what everyone needed (even if it wasn't what they wanted).
I find the "lean startup" concept to be humorous. it's like pg's y-combinator essays in MBA-ese. Build an MVP and get users to provide feedback, and iterate like crazy. As long as you're starting from MVP, the rest adheres to the principal of "JFDI". if JFDI is unclear to you, and you're looking at a flowchart to understand what JFDI means in context, then you are probably not going to understand it, ever.
"JFDI" is quite difficult to do in larger companies - unfortunately even most 200 person companies - when you're dealing with several stakeholders, potential bruised egos and such ("why was I not included in the startup?" "how can you launch a new product without the product team?", etc).
I think the article was attempting to address that specific scenario, and not about running a "lean startup" in general.
The part I find humorous is constantly redefining terms. I thought "lean" referred to budgets. In that light, I would have refuted the headline's premise with a reminder that the 'outer' company was footing the bill for salaries.
No, what they're discussing is yet another methodology (or an existing one with a tweak, requiring a new name...) for creating a product, getting it to [a subset of] customers, and refining it.
No, the 'lean startup' has never meant a small budget and while I love the concept, it is a pretty terrible name as it's not really cheap to do it properly.
I made the same mistake until I started reading about what they were actually talking about.
we've had it (and still have, just the buzzword itself somehow magically stopped flying around). It isn't lean. Process by definition can't be lean, because process itself is the fat, and once the word "process" is uttered, you may be sure that you aren't in Kansas anymore.
Plenty of people will spend years developing a product with no customers. I see small-l lean as more of a scientific method - fail fast, iterate rapidly. I'm a big fan of John Boyd's OODA loop so maybe I'm projecting.
For those of us who are in a startup and are intimately familiar with all of the issues surrounding with being in a startup, I don't have much appreciation for people working in an established company to co-op the word startup. You have a lean department, not a lean startup.
Why is the corporate structure important? I like the Wikipedia definition that "A startup is a company, a partnership or temporary organization designed to search for a repeatable and scalable business model." [0] And of course there's "startup culture" which is a group of people focused on iteration, learning, results, etc. Many startups are stand-alone companies, but it's not essential.
There are a lots of articles that explain the concept of lean startup but not as many that talk about how to apply it. Thanks for sharing. This should be helpful for anyone thinking about testing a two-sided network problem.
I actually didn't write this, Layla Foord at Envato is the OP.
I found the post particularly interesting because I am going through the same exact process at HubSpot in Cambridge.
I'm planning on writing a blog post next week on the pros and cons of a "startup within a startup". Would love to chat and share ideas, Ry. My email is in my profile if you want to reach out.
My company works with large and enterprise companies to help them implement lean startup and customer development principles into their product development process.
Would love to hear more about the talk you're working on. Email is in my profile.
It is impossible to build a startup "inside" another company. If one understands what the word startup means. Therefore, the article's author does not.
Let's assume I don't understand what the word startup means. What is it about the definition of startup prevents you from building one inside of another company?
from my reading they were trying to create a new product/service to add to an existing business's offerings
i personally think "startup = new business and/or an effort to try creating a new viable business" is the best definition. otherwise they could say, well, they were doing new product R&D. no need to use the term startup. startups often have to find investors, find employees, etc. doing R&D for a new product within an existing and already profitable business is a different kind and magnitude of problem.
Our solution was to create a new team, with a new VP to report to, who was aligned with their goals explicitly. The team's focus was to simply find interesting new product spaces, prototype the solutions quickly, and get 1 paying customer. The "start-up guys" were moved to this team, and they hired more like-minded developers. The normal R&D department would take up the prototype as a proof-of-concept once it was worked out that there would be enough customers to justify the longer development of the final product. While it resulted in the creation of the company's latest product, it definitely did not solve the problem it was designed to - but it did increase the understanding of the engineering team as to what would, and wouldn't work when they got to work on the problem. Which, is really what everyone needed (even if it wasn't what they wanted).
[0] - this is an over-simplification, of course