I received this case study from an LSC reader who asked that I post it to the list anonymously. This is fantastic information, and I hope that more people are willing to share their experiences in such detail in the future.
---
My partner and I had an idea for a web app. The app is a B2C platform that we are selling as SaaS to organizations for use with their constituents. We decided from the get-go, that while we clearly saw the benefits and necessity of our concept, we would remain fiercely skeptical of our own ideas and implement the customer development process to vet the idea, market, customers etc etc before writing a single line of code.
My partner was especially adamant about this as he had spent the last 6 months in a cave writing a monster, feature-rich web app for the financial sector that a potential client had promised to buy, but backed out at the last second. They then tried to shop the app around, and found no takers. Thousands of lines of code, all for naught -- as is usually the case w/ o a customer development process.
We made a few pencil drawings of what the app would look like which we then gave to a graphic designer. The graphic designer created a PS file. We had him create what we called our "screenshots" (which suggests that an app actually existed at the time) and had him wrap them in one of these freely available PS Browser Templates (http://piksels.com/photoshop-browser-templates/).
Now armed, with 4 "screenshots" and a story we approached our target market. Some of which were through warm introductions, some, very literally, were through simple cold-calling.
Once we secured a meeting, we told our potential customers that we were actively developing our web app (implying that code was being written) and wanted to get potential user input into the dev process early on. Looking at paper print-outs of our "screenshots", no one could tell that this was simply a printout of a PSD, and not a live app sitting on some server somewhere.
We walked them through what we thought would be the major application of our product. Most people were quite receptive and encouraging. What proved to be very interesting was that we quickly observed a bimodal distribution with regards to understanding the problem we are solving and our proposed solution. People either became very excited and started telling us what we should do, what features it needed and how to run with this OR they didn't think there was a problem, much less, a needed solution.
We ruminated on this for a while. The vehemence of those that didn't get it surprised us. Perhaps we had a super-duper-hyper-ultra-cool idea --- but not enough customers existed to make it worth the effort.
We visited each potential customer a minimum of twice, if not usually, three times. Each time we would come back with a few more "screenshots" and tell them that development was progressing nicely and ask them for more input. We also solicited information as how they were currently solving the problem and how much they paid for their solution.
On the third visit, we pressed those who saw merit in the idea to sign a legally non-binding Letter of Intent. Namely, that they agree to use it for free, if we deliver it to them and it is capable of X, Y and Z. And not only do they use it, but that they intend to purchase if by Y date at X price, if it meets their needs.
[BTW this LOI was not written in legalese. 3/4 page of simple everyday English. In fact, we customer dev-ed the LOI itself. The first time, we asked them to sign it before we had written it. When they agreed to sign it, we quickly whipped it up while sitting in a coffee shop and emailed it off to them.]
This would help us separate the wheat from the chaff when it came to determining interest and commercial viability. Once we had two LOIs signed and in-hand, we actually began to write code.
We also implicitly used the LOIs for price structure and price discovery - which we are still working on. We backed into prices from all sorts of angles, estimating the time-cost of equivalent functionality, competitive offerings, other tools we were potentially displacing -- but in the end, we lobbed a few numbers at them and waited to see if they flinched: Customer X got X price, Customer Y got X + Y price, and so on. So far, our customers have never mentioned price as an objection, which suggests to me that at this point we are very much underpriced.
The LOI was also useful as we leveraged it by approaching the competitor of one of those who signed by simply letting them know that their competitor will be using our app. They returned our cold intro email within 8 mins.
We have two customers that have balked at signing LOIs, but want to use our product. This has been somewhat of a quandary for us. When we decided to go the LOI route, we thought that we would not bend and only service customers who would sign the LOI. In the end, we decided that these two were large enough to help us with exposure, provide good usage data and worth the risk of them wasting our time. We'll see.
Right now, the app itself is pretty ugly, a bit buggy and slow. And doesn't even do a lot. It is borderline embarrassing. Don't get me wrong, it does the few necessary things. BUT it definitely does NOT have the super-duper-hyper-ultra-cool Web 2.0 spit and polish about it because we haven't been able to find a good, dependable designer who works at reasonable rates. We have found plenty of designers who are happy to ignore our direction and put in 25 hours w/o our permission and go off on a design tangent and then ask for reimbursement for work we didn't need or didn't authorize. But I digress....
Interestingly enough, our ratio of positive comments to negative comments from actual users is about 10 to 1. One of our first customers had a disastrous launch with it, yet, has signed on to try it again. (Granted, they did get it for free and we did offer it for free for this next time.) But they didn't hesitate to try it again. I thought we would have to plead, beg and beseech. But for them, it was a no-brainer. So, we have to be doing something right.
Our feature set is very limited and being developed almost strictly from user input. While I personally have all sorts of super-duper-hyper-ultra-cool Web 2.0 ideas --- we are holding ourselves back, and forcing ourselves to wait for multiple, explicit and overlapping user requests. We have seen our competitors whose feature sets are very rich to say the least, but we think, in some cases, as overwhelming as they are feature-rich.
Only time and the market will tell if they are innovative and we are slow, lazy pigs or they have gotten ahead of the themselves/market and our minimalistic solution will be better received.
Would love any and all thoughts on our experiences.
thx to the reader who submitted this - just a quick read on my phone
has got me thinking about a new way to move out on a side venture i am
working on. thx for the great case study.
thx again
john
Sent from my iPhone
On Aug 7, 2009, at 4:23 PM, Rich Collins <richcoll...@gmail.com> wrote:
> I received this case study from an LSC reader who asked that I post it
> to the list anonymously. This is fantastic information, and I hope
> that more people are willing to share their experiences in such detail
> in the future.
> ---
> My partner and I had an idea for a web app. The app is a B2C platform
> that
> we are selling as SaaS to organizations for use with their
> constituents. We
> decided from the get-go, that while we clearly saw the benefits and
> necessity of our concept, we would remain fiercely skeptical of our
> own
> ideas and implement the customer development process to vet the idea,
> market, customers etc etc before writing a single line of code.
> My partner was especially adamant about this as he had spent the
> last 6
> months in a cave writing a monster, feature-rich web app for the
> financial
> sector that a potential client had promised to buy, but backed out at
> the
> last second. They then tried to shop the app around, and found no
> takers.
> Thousands of lines of code, all for naught -- as is usually the case
> w/
> o a
> customer development process.
> We made a few pencil drawings of what the app would look like which we
> then
> gave to a graphic designer. The graphic designer created a PS file.
> We had
> him create what we called our "screenshots" (which suggests that an
> app
> actually existed at the time) and had him wrap them in one of these
> freely
> available PS Browser Templates
> (http://piksels.com/photoshop-browser-templates/).
> Now armed, with 4 "screenshots" and a story we approached our target
> market.
> Some of which were through warm introductions, some, very literally,
> were
> through simple cold-calling.
> Once we secured a meeting, we told our potential customers that we
> were
> actively developing our web app (implying that code was being written)
> and
> wanted to get potential user input into the dev process early on.
> Looking
> at paper print-outs of our "screenshots", no one could tell that this
> was
> simply a printout of a PSD, and not a live app sitting on some server
> somewhere.
> We walked them through what we thought would be the major application
> of our
> product. Most people were quite receptive and encouraging. What
> proved to
> be very interesting was that we quickly observed a bimodal
> distribution with
> regards to understanding the problem we are solving and our proposed
> solution. People either became very excited and started telling us
> what we
> should do, what features it needed and how to run with this OR they
> didn't
> think there was a problem, much less, a needed solution.
> We ruminated on this for a while. The vehemence of those that didn't
> get
> it surprised us. Perhaps we had a super-duper-hyper-ultra-cool idea
> --- but
> not enough customers existed to make it worth the effort.
> We visited each potential customer a minimum of twice, if not usually,
> three
> times. Each time we would come back with a few more "screenshots" and
> tell
> them that development was progressing nicely and ask them for more
> input.
> We also solicited information as how they were currently solving the
> problem
> and how much they paid for their solution.
> On the third visit, we pressed those who saw merit in the idea to
> sign a
> legally non-binding Letter of Intent. Namely, that they agree to use
> it for
> free, if we deliver it to them and it is capable of X, Y and Z. And
> not
> only do they use it, but that they intend to purchase if by Y date
> at X
> price, if it meets their needs.
> [BTW this LOI was not written in legalese. 3/4 page of simple
> everyday
> English. In fact, we customer dev-ed the LOI itself. The first time,
> we
> asked them to sign it before we had written it. When they agreed to
> sign
> it, we quickly whipped it up while sitting in a coffee shop and
> emailed it
> off to them.]
> This would help us separate the wheat from the chaff when it came to
> determining interest and commercial viability. Once we had two LOIs
> signed
> and in-hand, we actually began to write code.
> We also implicitly used the LOIs for price structure and price
> discovery -
> which we are still working on. We backed into prices from all sorts
> of
> angles, estimating the time-cost of equivalent functionality,
> competitive
> offerings, other tools we were potentially displacing -- but in the
> end, we
> lobbed a few numbers at them and waited to see if they flinched:
> Customer X
> got X price, Customer Y got X + Y price, and so on. So far, our
> customers
> have never mentioned price as an objection, which suggests to me
> that at
> this point we are very much underpriced.
> The LOI was also useful as we leveraged it by approaching the
> competitor of
> one of those who signed by simply letting them know that their
> competitor
> will be using our app. They returned our cold intro email within 8
> mins.
> We have two customers that have balked at signing LOIs, but want to
> use our
> product. This has been somewhat of a quandary for us. When we
> decided to
> go the LOI route, we thought that we would not bend and only service
> customers who would sign the LOI. In the end, we decided that these
> two
> were large enough to help us with exposure, provide good usage data
> and
> worth the risk of them wasting our time. We'll see.
> Right now, the app itself is pretty ugly, a bit buggy and slow. And
> doesn't
> even do a lot. It is borderline embarrassing. Don't get me wrong, it
> does
> the few necessary things. BUT it definitely does NOT have the
> super-duper-hyper-ultra-cool Web 2.0 spit and polish about it
> because we
> haven't been able to find a good, dependable designer who works at
> reasonable rates. We have found plenty of designers who are happy to
> ignore
> our direction and put in 25 hours w/o our permission and go off on a
> design
> tangent and then ask for reimbursement for work we didn't need or
> didn't
> authorize. But I digress....
> Interestingly enough, our ratio of positive comments to negative
> comments
> from actual users is about 10 to 1. One of our first customers had a
> disastrous launch with it, yet, has signed on to try it again.
> (Granted,
> they did get it for free and we did offer it for free for this next
> time.)
> But they didn't hesitate to try it again. I thought we would have to
> plead,
> beg and beseech. But for them, it was a no-brainer. So, we have
> to be
> doing something right.
> Our feature set is very limited and being developed almost strictly
> from
> user input. While I personally have all sorts of
> super-duper-hyper-ultra-cool Web 2.0 ideas --- we are holding
> ourselves
> back, and forcing ourselves to wait for multiple, explicit and
> overlapping
> user requests. We have seen our competitors whose feature sets are
> very
> rich to say the least, but we think, in some cases, as overwhelming as
> they
> are feature-rich.
> Only time and the market will tell if they are innovative and we are
> slow,
> lazy pigs or they have gotten ahead of the themselves/market and our
> minimalistic solution will be better received.
> Would love any and all thoughts on our experiences.
> I received this case study from an LSC reader who asked that I post it
> to the list anonymously. This is fantastic information, and I hope
> that more people are willing to share their experiences in such detail
> in the future.
> ---
> My partner and I had an idea for a web app. The app is a B2C platform
> that
> we are selling as SaaS to organizations for use with their
> constituents. We
> decided from the get-go, that while we clearly saw the benefits and
> necessity of our concept, we would remain fiercely skeptical of our own
> ideas and implement the customer development process to vet the idea,
> market, customers etc etc before writing a single line of code.
> My partner was especially adamant about this as he had spent the last 6
> months in a cave writing a monster, feature-rich web app for the
> financial
> sector that a potential client had promised to buy, but backed out at
> the
> last second. They then tried to shop the app around, and found no
> takers.
> Thousands of lines of code, all for naught -- as is usually the case w/
> o a
> customer development process.
> We made a few pencil drawings of what the app would look like which we
> then
> gave to a graphic designer. The graphic designer created a PS file.
> We had
> him create what we called our "screenshots" (which suggests that an app
> actually existed at the time) and had him wrap them in one of these
> freely
> available PS Browser Templates
> (http://piksels.com/photoshop-browser-templates/).
> Now armed, with 4 "screenshots" and a story we approached our target
> market.
> Some of which were through warm introductions, some, very literally,
> were
> through simple cold-calling.
> Once we secured a meeting, we told our potential customers that we were
> actively developing our web app (implying that code was being written)
> and
> wanted to get potential user input into the dev process early on.
> Looking
> at paper print-outs of our "screenshots", no one could tell that this
> was
> simply a printout of a PSD, and not a live app sitting on some server
> somewhere.
> We walked them through what we thought would be the major application
> of our
> product. Most people were quite receptive and encouraging. What
> proved to
> be very interesting was that we quickly observed a bimodal
> distribution with
> regards to understanding the problem we are solving and our proposed
> solution. People either became very excited and started telling us
> what we
> should do, what features it needed and how to run with this OR they
> didn't
> think there was a problem, much less, a needed solution.
> We ruminated on this for a while. The vehemence of those that didn't
> get
> it surprised us. Perhaps we had a super-duper-hyper-ultra-cool idea
> --- but
> not enough customers existed to make it worth the effort.
> We visited each potential customer a minimum of twice, if not usually,
> three
> times. Each time we would come back with a few more "screenshots" and
> tell
> them that development was progressing nicely and ask them for more
> input.
> We also solicited information as how they were currently solving the
> problem
> and how much they paid for their solution.
> On the third visit, we pressed those who saw merit in the idea to sign a
> legally non-binding Letter of Intent. Namely, that they agree to use
> it for
> free, if we deliver it to them and it is capable of X, Y and Z. And not
> only do they use it, but that they intend to purchase if by Y date at X
> price, if it meets their needs.
> [BTW this LOI was not written in legalese. 3/4 page of simple everyday
> English. In fact, we customer dev-ed the LOI itself. The first time,
> we
> asked them to sign it before we had written it. When they agreed to
> sign
> it, we quickly whipped it up while sitting in a coffee shop and
> emailed it
> off to them.]
> This would help us separate the wheat from the chaff when it came to
> determining interest and commercial viability. Once we had two LOIs
> signed
> and in-hand, we actually began to write code.
> We also implicitly used the LOIs for price structure and price
> discovery -
> which we are still working on. We backed into prices from all sorts of
> angles, estimating the time-cost of equivalent functionality,
> competitive
> offerings, other tools we were potentially displacing -- but in the
> end, we
> lobbed a few numbers at them and waited to see if they flinched:
> Customer X
> got X price, Customer Y got X + Y price, and so on. So far, our
> customers
> have never mentioned price as an objection, which suggests to me that at
> this point we are very much underpriced.
> The LOI was also useful as we leveraged it by approaching the
> competitor of
> one of those who signed by simply letting them know that their
> competitor
> will be using our app. They returned our cold intro email within 8
> mins.
> We have two customers that have balked at signing LOIs, but want to
> use our
> product. This has been somewhat of a quandary for us. When we
> decided to
> go the LOI route, we thought that we would not bend and only service
> customers who would sign the LOI. In the end, we decided that these two
> were large enough to help us with exposure, provide good usage data and
> worth the risk of them wasting our time. We'll see.
> Right now, the app itself is pretty ugly, a bit buggy and slow. And
> doesn't
> even do a lot. It is borderline embarrassing. Don't get me wrong, it
> does
> the few necessary things. BUT it definitely does NOT have the
> super-duper-hyper-ultra-cool Web 2.0 spit and polish about it because we
> haven't been able to find a good, dependable designer who works at
> reasonable rates. We have found plenty of designers who are happy to
> ignore
> our direction and put in 25 hours w/o our permission and go off on a
> design
> tangent and then ask for reimbursement for work we didn't need or didn't
> authorize. But I digress....
> Interestingly enough, our ratio of positive comments to negative
> comments
> from actual users is about 10 to 1. One of our first customers had a
> disastrous launch with it, yet, has signed on to try it again.
> (Granted,
> they did get it for free and we did offer it for free for this next
> time.)
> But they didn't hesitate to try it again. I thought we would have to
> plead,
> beg and beseech. But for them, it was a no-brainer. So, we have to be
> doing something right.
> Our feature set is very limited and being developed almost strictly from
> user input. While I personally have all sorts of
> super-duper-hyper-ultra-cool Web 2.0 ideas --- we are holding ourselves
> back, and forcing ourselves to wait for multiple, explicit and
> overlapping
> user requests. We have seen our competitors whose feature sets are very
> rich to say the least, but we think, in some cases, as overwhelming as
> they
> are feature-rich.
> Only time and the market will tell if they are innovative and we are
> slow,
> lazy pigs or they have gotten ahead of the themselves/market and our
> minimalistic solution will be better received.
> Would love any and all thoughts on our experiences.
> Our feature set is very limited and being developed almost strictly from
> user input.
This probably isn't the right thread to mention this, but I couldn't
help thinking that this illuminating case study represents an attitude
almost diametrically opposite to 37signals's, who often boast about
ignoring feature requests and just doing what they think is right.
Which makes me wonder how many failed 37signalses there are, and how
many companies like the above are making money precisely because they
don't assume what they think is right will sell.
On Sat, Aug 8, 2009 at 4:07 PM, Mark Wilden<m...@mwilden.com> wrote:
>> Our feature set is very limited and being developed almost strictly from >> user input.
> This probably isn't the right thread to mention this, but I couldn't > help thinking that this illuminating case study represents an attitude > almost diametrically opposite to 37signals's, who often boast about > ignoring feature requests and just doing what they think is right.
Yes, I agree. I have generally come to feel that the idea that we know better than users is more pride than I can stand.
"We have found plenty of designers who are happy to ignore our direction and put in 25 hours w/o our permission and go off on a design tangent and then ask for reimbursement for work we didn't need or didn't authorize."
I'd really like to get to the point, as a developer, where I can serve people like the author of that statement in an honest way, yet still make a living. "I've sold you 40 hours. Use them as you need them over the next 3 months. You can always buy more. I will communicate before and after each feature is built, more or less as we agree, but always with the intention to help you discover your customers."
With regard to the 37 Signals approach (as defined below) and the "miserly"
LSC/customer dev approach, I think we should eschew dogmatism and keep in
mind that these two approaches don't necessarily have to be mutually
exclusive.
[mailto:lean-startup-circle@googlegroups.com] On Behalf Of Mark Wilden
Sent: Saturday, August 08, 2009 1:07 PM
To: Lean Startup Circle
Subject: [lsc] Re: Detailed Case Study
> Our feature set is very limited and being developed almost strictly from
> user input.
This probably isn't the right thread to mention this, but I couldn't
help thinking that this illuminating case study represents an attitude
almost diametrically opposite to 37signals's, who often boast about
ignoring feature requests and just doing what they think is right.
Which makes me wonder how many failed 37signalses there are, and how
many companies like the above are making money precisely because they
don't assume what they think is right will sell.
I've thought about the 37s approach vs the customer dev approach quite a
bit.
I initially came into web dev being a huge fan of 37s, but after a few
months of trying to have a business and then reading Eric's
blog I started to follow them a bit less, but I still read/watch
everything they put out.
One key difference is that 37s makes products that they themselves use every
day for their own problems. They initially built basecamp as an *internal* *
tool*.
So, in terms of validating that the problem exists, they "validated" it
based on the fact that they themselves had the problem. It turned out that
others did as well.
This means that they did discovery/validation internally, if that's even
possible using how customer dev defines those words. Since they were a
design firm and they were building a tool for themselves to manage design
projects, this worked out well. It turned out that other people had the same
problem as them, and that their solution worked for others as well.
Furthermore, since David was only working about 10 hrs/week on it, they had
very little time, since they were simultaneously trying to do projects for
clients afaik. I.e. they probably didn't sit around a whiteboard dreaming up
what people would pay for. They solved their own problem. Since they had
other things to work on, they probably build somewhat of an mvp.
For example, I think I remember from one of the svn posts that they
initially had some feature x in campfire, but then decided to remove it b/c
they, as the potential customers, found it to be useless.
As another example, 37s' advice on pricing is to price your product based on
your answer to "What would I pay for this?" This assumes strong domain
expertise (which steve blank said was totally necessary in a recent talk).
As another example, their lead designer, ryan singer, has written that he
basically only includes elements in the page that are absolutely necessary
and have a purpose. If you look at some of the features in their products,
they are basically mvps.
As a final example, they seem to be moving towards being increasingly
metrics driven. They occasionally release data about how buttons / text /
design changes affect conversions. My suspicion is that they are actually
even more data driven than they let on.
Sorry to drag on, the 37s vs lean startup questions are really interesting
for me.
M
On Sat, Aug 8, 2009 at 6:40 PM, Patrick at Intraevent
<intraev...@gmail.com>wrote:
> With regard to the 37 Signals approach (as defined below) and the "miserly"
> LSC/customer dev approach, I think we should eschew dogmatism and keep in
> mind that these two approaches don't necessarily have to be mutually
> exclusive.
> -Patrick
> -----Original Message-----
> From: lean-startup-circle@googlegroups.com
> [mailto:lean-startup-circle@googlegroups.com] On Behalf Of Mark Wilden
> Sent: Saturday, August 08, 2009 1:07 PM
> To: Lean Startup Circle
> Subject: [lsc] Re: Detailed Case Study
> > Our feature set is very limited and being developed almost strictly from
> > user input.
> This probably isn't the right thread to mention this, but I couldn't
> help thinking that this illuminating case study represents an attitude
> almost diametrically opposite to 37signals's, who often boast about
> ignoring feature requests and just doing what they think is right.
> Which makes me wonder how many failed 37signalses there are, and how
> many companies like the above are making money precisely because they
> don't assume what they think is right will sell.
I was actually being really specific in talking about the case study's customer-driven approach and 37signals's. I agree that 37signals shares a lot of the lean startup philosophy. And as someone who makes their living from Ruby on Rails, I'm a fan of DHH, "Getting Real," and 37signals.
However, I do think it's important to consider the differences, too. Basing decisions on what you as a customer would want is quite different from lean startup (as I understand it), which uses other means than introspection to determine the value of its product.
37signals is successful because of their dogfood consumption, coupled with the fact that others want their needs filled similarly. That's certainly better than trying to predict a market you don't belong to. I'm just saying that they are not especially "customer-driven" in the lean startup manner.
Not that there's anything wrong with that. :) But, in general, using yourself for validation has a lower success rate (I believe) than a customer-driven approach.
> I was actually being really specific in talking about the case study's
> customer-driven approach and 37signals's. I agree that 37signals
> shares a lot of the lean startup philosophy. And as someone who makes
> their living from Ruby on Rails, I'm a fan of DHH, "Getting Real," and
> 37signals.
> However, I do think it's important to consider the differences, too.
> Basing decisions on what you as a customer would want is quite
> different from lean startup (as I understand it), which uses other
> means than introspection to determine the value of its product.
> 37signals is successful because of their dogfood consumption, coupled
> with the fact that others want their needs filled similarly. That's
> certainly better than trying to predict a market you don't belong to.
> I'm just saying that they are not especially "customer-driven" in the
> lean startup manner.
> Not that there's anything wrong with that. :) But, in general, using
> yourself for validation has a lower success rate (I believe) than a
> customer-driven approach.
Presuming one wants to "provide value," one needs to be careful to not
subjugate "vision" to customer taste. People make crappy movies to
make money, but who cares? If your only goal is to make money then
that approach works for awhile. (Not to say those motion pictures do
that, I have no idea.)
If you have a vision to solve a particular problem, my belief is that
you choose customer requirements that lead to the vision. This may or
may not apply to 37signals. Again, I have no idea. ; )
Brant
market-by-numbers.com
On Aug 8, 6:58 pm, Robert Fleck <rfl...@socal.rr.com> wrote:
> A good example of building to what the market has shown it will buy can be
> seen in the motion pictures ³Cabin Boy² and ³Gigli.²
> Trying to second guess taste is useless.
> Adjusting a product to demand is why we don¹t still drive cars with
> tailfins.
> RMF
> > I was actually being really specific in talking about the case study's
> > customer-driven approach and 37signals's. I agree that 37signals
> > shares a lot of the lean startup philosophy. And as someone who makes
> > their living from Ruby on Rails, I'm a fan of DHH, "Getting Real," and
> > 37signals.
> > However, I do think it's important to consider the differences, too.
> > Basing decisions on what you as a customer would want is quite
> > different from lean startup (as I understand it), which uses other
> > means than introspection to determine the value of its product.
> > 37signals is successful because of their dogfood consumption, coupled
> > with the fact that others want their needs filled similarly. That's
> > certainly better than trying to predict a market you don't belong to.
> > I'm just saying that they are not especially "customer-driven" in the
> > lean startup manner.
> > Not that there's anything wrong with that. :) But, in general, using
> > yourself for validation has a lower success rate (I believe) than a
> > customer-driven approach.
I think the phrase "begin with the end in mind" applies nicely here. I think
the "vision" the entrepreneur has in the beginning is the "value" they'd
like to bring to the customer. Exactly how the entrepreneur figures out how
to provide that value (whatever it might be) depends. In the case of
37signals, and other dogfooding corporations, they understand what needs to
be built to provide a certain value because they're one of the prime
customers. In other cases, you might not understand how to provide the value
as well so you'll rely more heavily on early users who feel the pain much
more acutely than you do. In all cases I think as was mentioned early,
the entrepreneur has to be be a domain expert because otherwise it's very
hard to get subtle nuances right. But also as Steve Blank emphasizes, many
of your early users will understand how to deliver value much better than
you.
In my case, I'm creating social learning tools for universities. As a soon
to graduate student, I understand very well how to build the tool for
students but much less so for teachers. So relatively I'm spending much more
time talking to teachers to try to understand their needs than to students.
I have a very strong vision for the value I'd like to deliver to both
teachers/students but /how/ to deliver that value to teachers I much less
understand than for students.
And, to be fair to 37signals, they do listen to customer feedback and do add
new features, just with great care. In Get Real I remember they say they
don't bother keeping track of feature requests because if it's a genuine
need, people will keep requesting it over and over again.
On Sat, Aug 8, 2009 at 8:50 PM, brantcooper <br...@brantcooper.com> wrote:
> Presuming one wants to "provide value," one needs to be careful to not
> subjugate "vision" to customer taste. People make crappy movies to
> make money, but who cares? If your only goal is to make money then
> that approach works for awhile. (Not to say those motion pictures do
> that, I have no idea.)
> If you have a vision to solve a particular problem, my belief is that
> you choose customer requirements that lead to the vision. This may or
> may not apply to 37signals. Again, I have no idea. ; )
> Brant
> market-by-numbers.com
> On Aug 8, 6:58 pm, Robert Fleck <rfl...@socal.rr.com> wrote:
> > A good example of building to what the market has shown it will buy can
> be
> > seen in the motion pictures ³Cabin Boy² and ³Gigli.²
> > Trying to second guess taste is useless.
> > Adjusting a product to demand is why we don¹t still drive cars with
> > tailfins.
> > RMF
> > > I was actually being really specific in talking about the case study's
> > > customer-driven approach and 37signals's. I agree that 37signals
> > > shares a lot of the lean startup philosophy. And as someone who makes
> > > their living from Ruby on Rails, I'm a fan of DHH, "Getting Real," and
> > > 37signals.
> > > However, I do think it's important to consider the differences, too.
> > > Basing decisions on what you as a customer would want is quite
> > > different from lean startup (as I understand it), which uses other
> > > means than introspection to determine the value of its product.
> > > 37signals is successful because of their dogfood consumption, coupled
> > > with the fact that others want their needs filled similarly. That's
> > > certainly better than trying to predict a market you don't belong to.
> > > I'm just saying that they are not especially "customer-driven" in the
> > > lean startup manner.
> > > Not that there's anything wrong with that. :) But, in general, using
> > > yourself for validation has a lower success rate (I believe) than a
> > > customer-driven approach.
"If you have a vision to solve a particular problem, my belief is that
you choose customer requirements that lead to the vision."
This is classic confirmation bias. Why do startups drastically change
directions? They listen to the market. Your vision has to adapt and
evolve. How often does your vision correlate with reality? Customer
Development / Lean startup is the reality check you need.
The real issue is, perhaps, trying to come up with a 1 size fits all
rule that doesn't really exist! ; )
First, IMHO, the vision needs to be validated. Initially, you test
the vision w/r/t the problem being solved, rather than your
assumptions on exactly how the problem is to be solved. This creates
the context within which you listen to your customers requests. In
many cases the vendor has a better ability to see the varied nuances
of a particular problem segment-wide, or even industry-wide, than 1
single customer can see, because they are rightly focused on solving
their internal issues and not their competitors'. Further, anyone who
has experience gathering requirements from constituencies, be they
internal or external customers, knows that the customer's "vision" is
unable to ingest what is technically feasible. In other words, they
don't know what they don't know.
It is not uncommon for early stage companies to face competing feature
requests from equally important customers. How do you choose? What
often happens is that startups seek opportunistic revenue from
companies who make divergent demands on the engineering team. This
is a non-scalable situation.
So yes, some startups drastically change directions, but not because
of customer requirements per se, but because the right pain is
unearthed or because of a confluence of requirements from a number of
companies that represent a market segment. And among these customers,
myriad requirements are not accepted because they don't directly
resolve the core pain that the customer is trying to resolve.
> "If you have a vision to solve a particular problem, my belief is that
> you choose customer requirements that lead to the vision."
> This is classic confirmation bias. Why do startups drastically change
> directions? They listen to the market. Your vision has to adapt and
> evolve. How often does your vision correlate with reality? Customer
> Development / Lean startup is the reality check you need.
On Sat, Aug 8, 2009 at 1:07 PM, Mark Wilden <m...@mwilden.com> wrote: > This probably isn't the right thread to mention this, but I couldn't > help thinking that this illuminating case study represents an attitude > almost diametrically opposite to 37signals's, who often boast about > ignoring feature requests and just doing what they think is right.
No! What you're referring to has a totally different context - and I took the time to find it because it's a really important distinction that I find myself bringing up all the time:
"When you launch your products, customers will send you hundreds or thousands of feature requests... We encourage it and we want to hear what they have to say. *Most everything we add to our products started as a customer request.*
So ...*How do you track all these requests? You don’t. Read them and then throw them away.*
*The ones that are really important will keep bubbling up.* And those are the ones you’ll remember. Those are the important ones." - http://37signals.com/svn/archives2/getting_real_forget_feature_reques... 1) You need to launch a product and have an initial vision first. In 99% of cases, your customers will not provide you with a vision. They may express needs that spark your vision (all of my best product work was *inspired by*talking to customers) but they will not define your vision.
2) Do not maintain a "feature request backlog". Once you have it, you will spend time prioritizing it, worrying about it, revisiting it, and (worst-case) developing features that were totally relevant six months ago when the request was made but are pretty stupid now.
> It is not uncommon for early stage companies to face competing feature
> requests from equally important customers. How do you choose? What
> often happens is that startups seek opportunistic revenue from
> companies who make divergent demands on the engineering team. This
> is a non-scalable situation.
Having made a lot of the typical mistakes of a would-be-entrepreneur
and then discovering Customer Development, MVP, etc and eventually
this list, I can relate to a lot of this discussion. I love the
insight I get from this list. In this case, I'd like to argue against
the last sentence above though.
In our case we started out with a vision of competing with what is now
our current customer base. We build hosted "semi-turn-key" solutions
for a market demographic thats currently being sold square pegs for
round holes. It was only after we started trying to sell our product
that we realized the thing that our customers wanted most was
customization.
Yes, it costs us a lot in terms of engineering but with limits on how
far from the base product we're willing to diverge and a continual
refactoring and modularizing of our code, these costs seem (for now at
least) to be getting cheaper over time. In our market at least, our
competitors are offering a generic product suitable for a variety of
tasks and we've found what we believe to be a niche market of clients
willing to pay more for something that suits their unique
requirements.
We haven't had a great deal of sales just yet but things look on the
up and up. As our product slowly becomes more and more modular, we can
see our initial divergent development turning into lego-like building
blocks that will eventually lead to very low development build times
and higher operational returns.
Thoughtless divergence is clearly a waste of resources and, as you
say, a non-scalable solution. But in our case, the ability to meet
more than just the average needs of a wider market segment gives us a
significant edge.
>> It is not uncommon for early stage companies to face competing
>> feature
>> requests from equally important customers. How do you choose? What
>> often happens is that startups seek opportunistic revenue from
>> companies who make divergent demands on the engineering team. This
>> is a non-scalable situation.
> Having made a lot of the typical mistakes of a would-be-entrepreneur
> and then discovering Customer Development, MVP, etc and eventually
> this list, I can relate to a lot of this discussion. I love the
> insight I get from this list. In this case, I'd like to argue against
> the last sentence above though.
> In our case we started out with a vision of competing with what is now
> our current customer base. We build hosted "semi-turn-key" solutions
> for a market demographic thats currently being sold square pegs for
> round holes. It was only after we started trying to sell our product
> that we realized the thing that our customers wanted most was
> customization.
> Yes, it costs us a lot in terms of engineering but with limits on how
> far from the base product we're willing to diverge and a continual
> refactoring and modularizing of our code, these costs seem (for now at
> least) to be getting cheaper over time. In our market at least, our
> competitors are offering a generic product suitable for a variety of
> tasks and we've found what we believe to be a niche market of clients
> willing to pay more for something that suits their unique
> requirements.
> We haven't had a great deal of sales just yet but things look on the
> up and up. As our product slowly becomes more and more modular, we can
> see our initial divergent development turning into lego-like building
> blocks that will eventually lead to very low development build times
> and higher operational returns.
> Thoughtless divergence is clearly a waste of resources and, as you
> say, a non-scalable solution. But in our case, the ability to meet
> more than just the average needs of a wider market segment gives us a
> significant edge.
Like I said, a 1 size fits all rule doesn't exist. A couple of
thoughts:
1) For most startups, a wider segment is NOT a good thing. Narrow and
focused is better. The wider the segment the less replicable are all
of your process, engineering, marketing, sales, operations, etc.
Customers in different segments often have different requirements,
varied buyers and buying processes, are found, converted, and service
differently. It's not scalable.
2) Switching from a products company to a services company is
difficult. (BTW, services companies are very difficult to scale.) A
services company successfully converting to a product company is even
more rare!
3) Product companies with a professional services arm is very common
and can be quite successful. Prof svcs can often sustain a company
while its products mature. (In Crossing the Chasm, Moore assumes that
product will be customized for the first "visionary" customers.)
Great care must be taken, however, to ensure that for a products
company, products lead services and not vice versa. I worked for a
company where Prof Svcs was required for every product sale. Early on
this was great and sustained the company. In the end, however, it
didn't scale. You couldn't hire enough engineers to customize enough
product to keep up with sales.
With respect, you say that "We haven't had a great deal of sales just
yet," so it may be premature to say you've found a scalable model.
But, I sincerely hope you prove me wrong!
Brant
On Aug 10, 10:45 am, Aaron <aaron...@gmail.com> wrote:
> > It is not uncommon for early stage companies to face competing feature
> > requests from equally important customers. How do you choose? What
> > often happens is that startups seek opportunistic revenue from
> > companies who make divergent demands on the engineering team. This
> > is a non-scalable situation.
> Having made a lot of the typical mistakes of a would-be-entrepreneur
> and then discovering Customer Development, MVP, etc and eventually
> this list, I can relate to a lot of this discussion. I love the
> insight I get from this list. In this case, I'd like to argue against
> the last sentence above though.
> In our case we started out with a vision of competing with what is now
> our current customer base. We build hosted "semi-turn-key" solutions
> for a market demographic thats currently being sold square pegs for
> round holes. It was only after we started trying to sell our product
> that we realized the thing that our customers wanted most was
> customization.
> Yes, it costs us a lot in terms of engineering but with limits on how
> far from the base product we're willing to diverge and a continual
> refactoring and modularizing of our code, these costs seem (for now at
> least) to be getting cheaper over time. In our market at least, our
> competitors are offering a generic product suitable for a variety of
> tasks and we've found what we believe to be a niche market of clients
> willing to pay more for something that suits their unique
> requirements.
> We haven't had a great deal of sales just yet but things look on the
> up and up. As our product slowly becomes more and more modular, we can
> see our initial divergent development turning into lego-like building
> blocks that will eventually lead to very low development build times
> and higher operational returns.
> Thoughtless divergence is clearly a waste of resources and, as you
> say, a non-scalable solution. But in our case, the ability to meet
> more than just the average needs of a wider market segment gives us a
> significant edge.
I hope we prove you wrong too but you have got me thinking about this
now.
We were bitten early on by the false assumption that what a customer
says they want is not necessarily the same thing as they are willing
to buy. When we did our about-turn and started targeting businesses,
the most eager customers were all in a variety of slightly different
industries to our original target. They seem to love us because we
listen to their individual needs but as I said earlier, we don't have
a lot of these customers yet.
I'm sure other startups that are targeting businesses will also have
this sort of question - Where do you draw the line? A wide segment
requires more resources than you can spare, but pick too thin a niche
and you don't have enough market substance to bite into. I feel like
we've identified a set of splintered niche segments that alone don't
offer a lot of value but if we can accommodate them with a core
product and minor customizations, is that worthwhile? Would someone
with more business experience than me walk away from this due to
things I don't yet understand?
I believe I understand the value in a high-tech startup is generally
found in the gaps left between bigger established players but what
about an opportunity that exists as a localized cluster of gaps that,
combined, seem to offer a good opportunity but individually provide
minimal returns. Sorry if this seems a bit abstract but to me (still
wet behind the ears) these still are quite abstract concepts.
On Aug 11, 5:39 am, brantcooper <br...@brantcooper.com> wrote:
> Like I said, a 1 size fits all rule doesn't exist. A couple of
> thoughts:
> 1) For most startups, a wider segment is NOT a good thing. Narrow and
> focused is better. The wider the segment the less replicable are all
> of your process, engineering, marketing, sales, operations, etc.
> Customers in different segments often have different requirements,
> varied buyers and buying processes, are found, converted, and service
> differently. It's not scalable.
> 2) Switching from a products company to a services company is
> difficult. (BTW, services companies are very difficult to scale.) A
> services company successfully converting to a product company is even
> more rare!
> 3) Product companies with a professional services arm is very common
> and can be quite successful. Prof svcs can often sustain a company
> while its products mature. (In Crossing the Chasm, Moore assumes that
> product will be customized for the first "visionary" customers.)
> Great care must be taken, however, to ensure that for a products
> company, products lead services and not vice versa. I worked for a
> company where Prof Svcs was required for every product sale. Early on
> this was great and sustained the company. In the end, however, it
> didn't scale. You couldn't hire enough engineers to customize enough
> product to keep up with sales.
> With respect, you say that "We haven't had a great deal of sales just
> yet," so it may be premature to say you've found a scalable model.
> But, I sincerely hope you prove me wrong!
> Brant
> On Aug 10, 10:45 am, Aaron <aaron...@gmail.com> wrote:
> > > It is not uncommon for early stage companies to face competing feature
> > > requests from equally important customers. How do you choose? What
> > > often happens is that startups seek opportunistic revenue from
> > > companies who make divergent demands on the engineering team. This
> > > is a non-scalable situation.
> > Having made a lot of the typical mistakes of a would-be-entrepreneur
> > and then discovering Customer Development, MVP, etc and eventually
> > this list, I can relate to a lot of this discussion. I love the
> > insight I get from this list. In this case, I'd like to argue against
> > the last sentence above though.
> > In our case we started out with a vision of competing with what is now
> > our current customer base. We build hosted "semi-turn-key" solutions
> > for a market demographic thats currently being sold square pegs for
> > round holes. It was only after we started trying to sell our product
> > that we realized the thing that our customers wanted most was
> > customization.
> > Yes, it costs us a lot in terms of engineering but with limits on how
> > far from the base product we're willing to diverge and a continual
> > refactoring and modularizing of our code, these costs seem (for now at
> > least) to be getting cheaper over time. In our market at least, our
> > competitors are offering a generic product suitable for a variety of
> > tasks and we've found what we believe to be a niche market of clients
> > willing to pay more for something that suits their unique
> > requirements.
> > We haven't had a great deal of sales just yet but things look on the
> > up and up. As our product slowly becomes more and more modular, we can
> > see our initial divergent development turning into lego-like building
> > blocks that will eventually lead to very low development build times
> > and higher operational returns.
> > Thoughtless divergence is clearly a waste of resources and, as you
> > say, a non-scalable solution. But in our case, the ability to meet
> > more than just the average needs of a wider market segment gives us a
> > significant edge.
> I hope we prove you wrong too but you have got me thinking about this
> now.
> We were bitten early on by the false assumption that what a customer
> says they want is not necessarily the same thing as they are willing
> to buy. When we did our about-turn and started targeting businesses,
> the most eager customers were all in a variety of slightly different
> industries to our original target. They seem to love us because we
> listen to their individual needs but as I said earlier, we don't have
> a lot of these customers yet.
> I'm sure other startups that are targeting businesses will also have
> this sort of question - Where do you draw the line? A wide segment
> requires more resources than you can spare, but pick too thin a niche
> and you don't have enough market substance to bite into. I feel like
> we've identified a set of splintered niche segments that alone don't
> offer a lot of value but if we can accommodate them with a core
> product and minor customizations, is that worthwhile? Would someone
> with more business experience than me walk away from this due to
> things I don't yet understand?
> I believe I understand the value in a high-tech startup is generally
> found in the gaps left between bigger established players but what
> about an opportunity that exists as a localized cluster of gaps that,
> combined, seem to offer a good opportunity but individually provide
> minimal returns. Sorry if this seems a bit abstract but to me (still
> wet behind the ears) these still are quite abstract concepts.
> On Aug 11, 5:39 am, brantcooper <br...@brantcooper.com> wrote:
> > Like I said, a 1 size fits all rule doesn't exist. A couple of
> > thoughts:
> > 1) For most startups, a wider segment is NOT a good thing. Narrow and
> > focused is better. The wider the segment the less replicable are all
> > of your process, engineering, marketing, sales, operations, etc.
> > Customers in different segments often have different requirements,
> > varied buyers and buying processes, are found, converted, and service
> > differently. It's not scalable.
> > 2) Switching from a products company to a services company is
> > difficult. (BTW, services companies are very difficult to scale.) A
> > services company successfully converting to a product company is even
> > more rare!
> > 3) Product companies with a professional services arm is very common
> > and can be quite successful. Prof svcs can often sustain a company
> > while its products mature. (In Crossing the Chasm, Moore assumes that
> > product will be customized for the first "visionary" customers.)
> > Great care must be taken, however, to ensure that for a products
> > company, products lead services and not vice versa. I worked for a
> > company where Prof Svcs was required for every product sale. Early on
> > this was great and sustained the company. In the end, however, it
> > didn't scale. You couldn't hire enough engineers to customize enough
> > product to keep up with sales.
> > With respect, you say that "We haven't had a great deal of sales just
> > yet," so it may be premature to say you've found a scalable model.
> > But, I sincerely hope you prove me wrong!
> > Brant
> > On Aug 10, 10:45 am, Aaron <aaron...@gmail.com> wrote:
> > > > It is not uncommon for early stage companies to face competing feature
> > > > requests from equally important customers. How do you choose? What
> > > > often happens is that startups seek opportunistic revenue from
> > > > companies who make divergent demands on the engineering team. This
> > > > is a non-scalable situation.
> > > Having made a lot of the typical mistakes of a would-be-entrepreneur
> > > and then discovering Customer Development, MVP, etc and eventually
> > > this list, I can relate to a lot of this discussion. I love the
> > > insight I get from this list. In this case, I'd like to argue against
> > > the last sentence above though.
> > > In our case we started out with a vision of competing with what is now
> > > our current customer base. We build hosted "semi-turn-key" solutions
> > > for a market demographic thats currently being sold square pegs for
> > > round holes. It was only after we started trying to sell our product
> > > that we realized the thing that our customers wanted most was
> > > customization.
> > > Yes, it costs us a lot in terms of engineering but with limits on how
> > > far from the base product we're willing to diverge and a continual
> > > refactoring and modularizing of our code, these costs seem (for now at
> > > least) to be getting cheaper over time. In our market at least, our
> > > competitors are offering a generic product suitable for a variety of
> > > tasks and we've found what we believe to be a niche market of clients
> > > willing to pay more for something that suits their unique
> > > requirements.
> > > We haven't had a great deal of sales just yet but things look on the
> > > up and up. As our product slowly becomes more and more modular, we can
> > > see our initial divergent development turning into lego-like building
> > > blocks that will eventually lead to very low development build times
> > > and higher operational returns.
> > > Thoughtless divergence is clearly a waste of resources and, as you
> > > say, a non-scalable solution. But in our case, the ability to meet
> > > more than just the average needs of a wider market segment gives us a
> > > significant edge.
I've been really inspired by this case study and the resulting
discussion. I get asked all the time for more examples, more case
studies, and more implementation details of lean startup techniques.
Are any of you interested in collaborating on a regular series of case
studies like this one, for presentation on my blog (and other venues
where I am asked for guest posts).
Here's what I am thinking. On a regular basis, maybe once a month,
we'd work as a group to develop a new case study. We'd have an open
discussion, just like this one, and then one volunteer would attempt
to produce a summary, maybe on a wiki, so we could all edit and add
additional comments. I'd add my own take and try to produce a version
suitable for a blog-post format, maybe linking to the original wiki
page, for those that want to see the original or keep discussing. All
comments could be used with attribution or made anonymous, depending
on what folks would like.
> The real issue is, perhaps, trying to come up with a 1 size fits all
> rule that doesn't really exist! ; )
> First, IMHO, the vision needs to be validated. Initially, you test
> the vision w/r/t the problem being solved, rather than your
> assumptions on exactly how the problem is to be solved. This creates
> the context within which you listen to your customers requests. In
> many cases the vendor has a better ability to see the varied nuances
> of a particular problem segment-wide, or even industry-wide, than 1
> single customer can see, because they are rightly focused on solving
> their internal issues and not their competitors'. Further, anyone who
> has experience gathering requirements from constituencies, be they
> internal or external customers, knows that the customer's "vision" is
> unable to ingest what is technically feasible. In other words, they
> don't know what they don't know.
> It is not uncommon for early stage companies to face competing feature
> requests from equally important customers. How do you choose? What
> often happens is that startups seek opportunistic revenue from
> companies who make divergent demands on the engineering team. This
> is a non-scalable situation.
> So yes, some startups drastically change directions, but not because
> of customer requirements per se, but because the right pain is
> unearthed or because of a confluence of requirements from a number of
> companies that represent a market segment. And among these customers,
> myriad requirements are not accepted because they don't directly
> resolve the core pain that the customer is trying to resolve.
> On Aug 8, 11:07 pm, Arthur Klepchukov <arthur.klepchu...@gmail.com>
> wrote:
>> "If you have a vision to solve a particular problem, my belief is that
>> you choose customer requirements that lead to the vision."
>> This is classic confirmation bias. Why do startups drastically change
>> directions? They listen to the market. Your vision has to adapt and
>> evolve. How often does your vision correlate with reality? Customer
>> Development / Lean startup is the reality check you need.
On Mon, Aug 17, 2009 at 13:50, Eric Ries<e...@theleanstartup.com> wrote:
> I've been really inspired by this case study and the resulting
> discussion. I get asked all the time for more examples, more case
> studies, and more implementation details of lean startup techniques.
> Are any of you interested in collaborating on a regular series of case
> studies like this one, for presentation on my blog (and other venues
> where I am asked for guest posts).
> Here's what I am thinking. On a regular basis, maybe once a month,
> we'd work as a group to develop a new case study. We'd have an open
> discussion, just like this one, and then one volunteer would attempt
> to produce a summary, maybe on a wiki, so we could all edit and add
> additional comments. I'd add my own take and try to produce a version
> suitable for a blog-post format, maybe linking to the original wiki
> page, for those that want to see the original or keep discussing. All
> comments could be used with attribution or made anonymous, depending
> on what folks would like.
>> The real issue is, perhaps, trying to come up with a 1 size fits all
>> rule that doesn't really exist! ; )
>> First, IMHO, the vision needs to be validated. Initially, you test
>> the vision w/r/t the problem being solved, rather than your
>> assumptions on exactly how the problem is to be solved. This creates
>> the context within which you listen to your customers requests. In
>> many cases the vendor has a better ability to see the varied nuances
>> of a particular problem segment-wide, or even industry-wide, than 1
>> single customer can see, because they are rightly focused on solving
>> their internal issues and not their competitors'. Further, anyone who
>> has experience gathering requirements from constituencies, be they
>> internal or external customers, knows that the customer's "vision" is
>> unable to ingest what is technically feasible. In other words, they
>> don't know what they don't know.
>> It is not uncommon for early stage companies to face competing feature
>> requests from equally important customers. How do you choose? What
>> often happens is that startups seek opportunistic revenue from
>> companies who make divergent demands on the engineering team. This
>> is a non-scalable situation.
>> So yes, some startups drastically change directions, but not because
>> of customer requirements per se, but because the right pain is
>> unearthed or because of a confluence of requirements from a number of
>> companies that represent a market segment. And among these customers,
>> myriad requirements are not accepted because they don't directly
>> resolve the core pain that the customer is trying to resolve.
>> On Aug 8, 11:07 pm, Arthur Klepchukov <arthur.klepchu...@gmail.com>
>> wrote:
>>> "If you have a vision to solve a particular problem, my belief is that
>>> you choose customer requirements that lead to the vision."
>>> This is classic confirmation bias. Why do startups drastically change
>>> directions? They listen to the market. Your vision has to adapt and
>>> evolve. How often does your vision correlate with reality? Customer
>>> Development / Lean startup is the reality check you need.
I'd be happy to help with this. Sounds like something that would
really benefit the lean startup movement. If examples and real life
execution of these concept helps people understand the concept, there
is probably no better group to help contribute to such documentation.
> I've been really inspired by this case study and the resulting
> discussion. I get asked all the time for more examples, more case
> studies, and more implementation details of lean startup techniques.
> Are any of you interested in collaborating on a regular series of case
> studies like this one, for presentation on my blog (and other venues
> where I am asked for guest posts).
> Here's what I am thinking. On a regular basis, maybe once a month,
> we'd work as a group to develop a new case study. We'd have an open
> discussion, just like this one, and then one volunteer would attempt
> to produce a summary, maybe on a wiki, so we could all edit and add
> additional comments. I'd add my own take and try to produce a version
> suitable for a blog-post format, maybe linking to the original wiki
> page, for those that want to see the original or keep discussing. All
> comments could be used with attribution or made anonymous, depending
> on what folks would like.
>> The real issue is, perhaps, trying to come up with a 1 size fits all
>> rule that doesn't really exist! ; )
>> First, IMHO, the vision needs to be validated. Initially, you test
>> the vision w/r/t the problem being solved, rather than your
>> assumptions on exactly how the problem is to be solved. This creates
>> the context within which you listen to your customers requests. In
>> many cases the vendor has a better ability to see the varied nuances
>> of a particular problem segment-wide, or even industry-wide, than 1
>> single customer can see, because they are rightly focused on solving
>> their internal issues and not their competitors'. Further, anyone
>> who
>> has experience gathering requirements from constituencies, be they
>> internal or external customers, knows that the customer's "vision" is
>> unable to ingest what is technically feasible. In other words, they
>> don't know what they don't know.
>> It is not uncommon for early stage companies to face competing
>> feature
>> requests from equally important customers. How do you choose? What
>> often happens is that startups seek opportunistic revenue from
>> companies who make divergent demands on the engineering team. This
>> is a non-scalable situation.
>> So yes, some startups drastically change directions, but not because
>> of customer requirements per se, but because the right pain is
>> unearthed or because of a confluence of requirements from a number of
>> companies that represent a market segment. And among these
>> customers,
>> myriad requirements are not accepted because they don't directly
>> resolve the core pain that the customer is trying to resolve.
>> On Aug 8, 11:07 pm, Arthur Klepchukov <arthur.klepchu...@gmail.com>
>> wrote:
>>> "If you have a vision to solve a particular problem, my belief is
>>> that
>>> you choose customer requirements that lead to the vision."
>>> This is classic confirmation bias. Why do startups drastically
>>> change
>>> directions? They listen to the market. Your vision has to adapt and
>>> evolve. How often does your vision correlate with reality? Customer
>>> Development / Lean startup is the reality check you need.
> I've been really inspired by this case study and the resulting
> discussion. I get asked all the time for more examples, more case
> studies, and more implementation details of lean startup techniques.
> Are any of you interested in collaborating on a regular series of case
> studies like this one, for presentation on my blog (and other venues
> where I am asked for guest posts).
> Here's what I am thinking. On a regular basis, maybe once a month,
> we'd work as a group to develop a new case study. We'd have an open
> discussion, just like this one, and then one volunteer would attempt
> to produce a summary, maybe on a wiki, so we could all edit and add
> additional comments. I'd add my own take and try to produce a version
> suitable for a blog-post format, maybe linking to the original wiki
> page, for those that want to see the original or keep discussing. All
> comments could be used with attribution or made anonymous, depending
> on what folks would like.
>> The real issue is, perhaps, trying to come up with a 1 size fits all
>> rule that doesn't really exist! ; )
>> First, IMHO, the vision needs to be validated. Initially, you test
>> the vision w/r/t the problem being solved, rather than your
>> assumptions on exactly how the problem is to be solved. This creates
>> the context within which you listen to your customers requests. In
>> many cases the vendor has a better ability to see the varied nuances
>> of a particular problem segment-wide, or even industry-wide, than 1
>> single customer can see, because they are rightly focused on solving
>> their internal issues and not their competitors'. Further, anyone
>> who
>> has experience gathering requirements from constituencies, be they
>> internal or external customers, knows that the customer's "vision" is
>> unable to ingest what is technically feasible. In other words, they
>> don't know what they don't know.
>> It is not uncommon for early stage companies to face competing
>> feature
>> requests from equally important customers. How do you choose? What
>> often happens is that startups seek opportunistic revenue from
>> companies who make divergent demands on the engineering team. This
>> is a non-scalable situation.
>> So yes, some startups drastically change directions, but not because
>> of customer requirements per se, but because the right pain is
>> unearthed or because of a confluence of requirements from a number of
>> companies that represent a market segment. And among these
>> customers,
>> myriad requirements are not accepted because they don't directly
>> resolve the core pain that the customer is trying to resolve.
>> On Aug 8, 11:07 pm, Arthur Klepchukov <arthur.klepchu...@gmail.com>
>> wrote:
>>> "If you have a vision to solve a particular problem, my belief is
>>> that
>>> you choose customer requirements that lead to the vision."
>>> This is classic confirmation bias. Why do startups drastically
>>> change
>>> directions? They listen to the market. Your vision has to adapt and
>>> evolve. How often does your vision correlate with reality? Customer
>>> Development / Lean startup is the reality check you need.
think it would also make sense to break down examples based on stage (idea
looking for initial validation to bootstrap, attempt to leverage an
established customer-base to expand a business, techniques to identify/ &
refine product ideas, etc. etc.), as well as market (B2C, B2B, ).
On a personal level (getting back to the list after a few weeks away), would
be happy to share my experience thus far on building a business idea using
customer-development/lean methods.
On Mon, Aug 17, 2009 at 1:50 PM, Eric Ries <e...@theleanstartup.com> wrote:
> I've been really inspired by this case study and the resulting
> discussion. I get asked all the time for more examples, more case
> studies, and more implementation details of lean startup techniques.
> Are any of you interested in collaborating on a regular series of case
> studies like this one, for presentation on my blog (and other venues
> where I am asked for guest posts).
> Here's what I am thinking. On a regular basis, maybe once a month,
> we'd work as a group to develop a new case study. We'd have an open
> discussion, just like this one, and then one volunteer would attempt
> to produce a summary, maybe on a wiki, so we could all edit and add
> additional comments. I'd add my own take and try to produce a version
> suitable for a blog-post format, maybe linking to the original wiki
> page, for those that want to see the original or keep discussing. All
> comments could be used with attribution or made anonymous, depending
> on what folks would like.
> > The real issue is, perhaps, trying to come up with a 1 size fits all
> > rule that doesn't really exist! ; )
> > First, IMHO, the vision needs to be validated. Initially, you test
> > the vision w/r/t the problem being solved, rather than your
> > assumptions on exactly how the problem is to be solved. This creates
> > the context within which you listen to your customers requests. In
> > many cases the vendor has a better ability to see the varied nuances
> > of a particular problem segment-wide, or even industry-wide, than 1
> > single customer can see, because they are rightly focused on solving
> > their internal issues and not their competitors'. Further, anyone who
> > has experience gathering requirements from constituencies, be they
> > internal or external customers, knows that the customer's "vision" is
> > unable to ingest what is technically feasible. In other words, they
> > don't know what they don't know.
> > It is not uncommon for early stage companies to face competing feature
> > requests from equally important customers. How do you choose? What
> > often happens is that startups seek opportunistic revenue from
> > companies who make divergent demands on the engineering team. This
> > is a non-scalable situation.
> > So yes, some startups drastically change directions, but not because
> > of customer requirements per se, but because the right pain is
> > unearthed or because of a confluence of requirements from a number of
> > companies that represent a market segment. And among these customers,
> > myriad requirements are not accepted because they don't directly
> > resolve the core pain that the customer is trying to resolve.
> > On Aug 8, 11:07 pm, Arthur Klepchukov <arthur.klepchu...@gmail.com>
> > wrote:
> >> "If you have a vision to solve a particular problem, my belief is that
> >> you choose customer requirements that lead to the vision."
> >> This is classic confirmation bias. Why do startups drastically change
> >> directions? They listen to the market. Your vision has to adapt and
> >> evolve. How often does your vision correlate with reality? Customer
> >> Development / Lean startup is the reality check you need.
|
