Personally I think it would be crazy not to start with putting fake screenshots in front of users to get feedback before you invest development time and energy on what is likely to be the wrong thing. Iterations with a graphic designer are a lot cheaper than iterations with a development team, and are nearly as effective for identifying large usability issues.<p>The trouble with user feedback normally is that people can't get a sense for how it would work unless they can see it. Sure you can make them put it in writing, but if they haven't seen it they almost surely asked for the wrong thing. So you really need to get them something they can see before you get useful feedback. And you want to do that in the fastest way possible. (Albeit while generally making it clear that actually getting it will take time.)
It's surprising to me that in that entire thread, not one person expressed any misgivings about the fact that the author actively deceived his/her customers (indeed practically brags about having done so). This despite the fact that the OP added:<p><i>There has been a lot of discussion about what the anonymous poster did right. How about some things that he/she could have done better?</i><p>I just joined the group to post that surely he/she could have done better by not lying. But the thread is old and there was no Reply link, which is just as well: it would have been rude to butt in like that.<p>I've been vaguely aware of this group for a while. I've read several of Eric Ries' posts, I have Steve Blank's book, and I like Steve Blank's blog a lot. The ideas of customer development make a lot of sense. But the above makes me think there's something wrong with this community. I'd rather surround myself with people whose first reaction to something like that is WTF.<p>Edit: Obviously if the message to the customer had been, "these are just mockups as we figure out what you need," there would be no ethical objection. That's part of what I can't understand. What would have been the problem with just telling the truth?
So much good stuff in this article:<p>1. You're not your customer/user<p>2. Identify the minimum viable product<p>3. Incur technical debt wisely<p>4. Get feedback early and often<p>Pursuing angel financing with those signed LOIs is a completely different ballgame from showing up with an idea, or even working code.
Starting with prototypes and mockups? Great idea. Definitely the only way to go. Deliberately misleading customers into thinking those are actual screenshots instead of mockups? Ugh.<p>Part of the reason it's so hard to sell software is that so many people have historically sold vaporware, which makes life harder for those of us that go out of our way to be honest with customers about what's implemented, what's a mockup, what's planned, and what's promised. Customers don't trust us because they've been screwed over by decades of shady sales guys.<p>Please, let's not contribute to the horrible, shameful record of software companies lying to customers in order to get sales. (And yes, I personally count "deliberately misleading" and "outright lying" as approximately the same thing: if lying about X is unethical, so is deliberately misleading someone about X.)
This is possibly the sleaziest way to describe what most people would describe as a great paper prototyping session. Everyone should be doing this, it's super easy, you don't even need to photoshop anything, just draw out your interface on paper or use balsamiq.<p>Would have anything changed if he hadn't been shady about it? No, except he wouldn't have come off soundingly like a d-bag.
"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."<p>Couldn't he have just said: "But it doesn't look good because we can't afford a good designer."
A lot of commentary about whether this is lying/unethical.<p>Have you ever played poker?<p>Salient quote:<p><i>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.</i><p>Does paper prototyping fall inside of your dev process or outside of it? It's definitely inside mine.<p>If you bet on every round of poker based solely on the cards in your hand, you'll lose.
I have started working on something similar. I have 3-4 ideas of apps I would like to do. I figure it would be far easier and way cheaper to launch landing pages for each, with mocked up "screenshots" of the apps. I plan to include on each of the apps a form to provide your email address in exchange for an invite. Then, I would do some simple SEO and word-of-mouth marketing and see what kind of response rates I would get back through this form. I figure in the end, this would help identify which application has the lowest barrier to adoption (e.g. easier discoverability, more user interest).
<i>...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</i><p>Wait a minute, because one of you got burnt and lost 6 months of work, now you won't do <i>any</i> work? With today's technology, I have to think there's a good middle ground between 6 months of dev work and paper prototype only.<p>If I was one of your prospects, I would never sign a letter of intent based on drawings only. I'd make you come back later with something, anything I could play with for 2 reasons:<p>1. I'd want to see that you can actually produce <i>something,</i> no matter how limited.<p>2. There's a <i>huge</i> difference between playing with something and talking about something. We'd arrive at a real functional requirement much faster with a working model. Anything less is just waterfall analysis and design, and we already know how well that works.<p>Come back when you have something real to show. Until then you're no different from any other poser.
Very good example of the minimum viable product. It's the right approach (minus the lying). VentureHacks had a really good coverage of the topic at <a href="http://venturehacks.com/articles/minimum-viable-product" rel="nofollow">http://venturehacks.com/articles/minimum-viable-product</a>
Don't most industries work with prototypes? As long as no lying is involved it seems okay.<p>Besides, most of the projects I've worked on don't actually begin until after the first delivery (when the customer finally looks at the software and starts deciding what they _really_ want!).
Like some of you, I disagree with the idea of propping up stuff for the purpose of making your prospects believe that you're up to something helpful. I call it "the feel good factor" entrepreneurship is supposed to be hard work nothing simple.<p>Like the guy who used markups in the 90's, I come from the school that seeks a point of pain and then start working your way into solutions.<p>I learned this from the advertising agencies where I worked a few years ago. Client came in with a problem, specified the problem and the particular need for a solution and wrote this out in something called "a creative brief" we took this info, worked our way into sketches, prototypes and then convinced the client that we had a solution.<p>Convincing the client meant conducting independent customer research and validation.<p>Lots of iterations where done but at no point did we push, shove or even seek to misled clients for the sake of validating our ideas without hard work done.<p>I like customer validation. I use it everyday. But I want to do my research and some hard work and then let the customer guide my way. Real MVP and real customers and then we can do all the supper stuff. But you have to be willing to do the hard work and the phony part makes me uncomfortable.
Awesome case study. Totally what we did with our new pivot
(same market B2C Customers - Saas), that is now in the works (didn't do this first time around, and paid for it). Only difference, we told the customer that these were just high fidelity screen mockups for the product we will eventually be building.<p>Get your screens in front of customers before you ever code. It is mind BLOWING!<p>Wonder how well this would work for consumer web... thoughts?
I think they would be better off to have tried to charge <i></i> something <i></i>, rather than give it away.<p>It's important to validate the pricing and business model -- and you can only do that by selling it (charging for it).<p>But, a good read.
<i>"we haven't been able to find a good, dependable designer who works at reasonable rates"</i><p>I found this to be a really tough part of my project as well.. Good designers are often really hard to find and charge a shitload..
This is very interesting when working with B2B style consulting, but the real trick is to apply these MVP practices to the creation of entire new B2C markets.