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.)
Anyway, not only is this approach nothing new, but at no point was it ever claimed that anything existed that didn't, and clients were very happy with this approach (esp. if they'd been used to "business analysts" drawing "data flow diagrams" on paper then coming back a year later with a steaming pile of crap that did nothing anyone actually wanted).
I don't mind faking screenshots to drum up business and test how viable an idea is, but if you accept money for software that doesn't exist, and then demand a ridiculous turn over time from your development team (whether in-house or outsourced), then you're scum.
Put another way: your client also paid a lot of money for their jumping-the-gun, but I'm sure this was calculated into their sale price, and was probably not bad planning at all, from their perspective.
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 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.
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.
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?
The relevant facts to the listener (prospective customer) are:
- "This is a picture of software to buy"
- "This software to buy will solve your problems."
Here is what you added:
- "These are just..." we ourselves do not believe that this software to buy is valuable despite we are here to convince you that this is software to buy is valuable
- "figure out..." we ourselves do not believe that this software to buy will solve your problems despite that we are here to convince you that this software to buy will solve your problems
"Each time we would come back with a few more 'screenshots' and tell them that development was progressing nicely"
No doubt you could come up with some hair-splitting interpretation under which it wasn't technically lying.
And the use cases. And the commercial viability of the market so their company had a chance to be around to support their customers. And the business understanding needed to support those customers properly.
Not all development is programming.
The hair-splitting begins. The phrase "software development" in my book, and I suspect in most people's, implies code. If you just mean any old development, well, sure, the customer development was proceeding quite nicely. Maybe that was what they meant?
Try a simple thought experiment. If the customers learned that there was no code and the product consisted of nothing more than the printed "screenshots" they'd been shown, would they care? I'd guess that one's answer to that is pretty correlated with whether or not one thinks deception was involved here. My answer - not about these particular customers, but in general - is yes, they would care. As a customer, I certainly would. (Not, of course, because of any objection to paper prototyping as such, but because a critical piece of the situation had been hidden from me.)
I got a little skeeved out at "development is coming along nicely", just like you, but the solution to that is just to choose better words. They could simply have said "design is coming along nicely", nobody would have cared, and they'd have the exact same outcome. So while you're right that those were unfortunate words, it's hard for me to get too bent out of shape about them.
There isn't enough information in the story to know what was really going on. Some possible contexts are a lot more venial than others. I think what irritated me was just the gloating tone of "we sure put one over on them"... but perhaps they didn't mean it that way.
You are not obligated to provide SEC disclosures along with your pitches. I do that, and it's a horrible habit and something I've been trying hard to break. It communicates nervousness and lack of confidence.
Again: you can't just make stuff up. If the prospect asks, "how much of this stuff actually works", you need to be clear --- "we're still in the design phase". But if the prospect doesn't ask, the prospect doesn't care, and you let it go.
If someone says "We're actively developing this" I'm not going to just assume I'm being mislead and say, "Sure, but do you have code?" The statement implies an answer to the question, so I'll feel like I already have an answer to the question, and I'd be wrong.
So no, it's not a direct answer to a question, but it's meant to imply an answer to the question so people don't ask anything further. Deliberately attempting to mislead people is just as bad as outright lying in my book, and I can't see the way that statement is worded as anything less than an attempt to mislead the potential customer.
Unfortunately for everyone involved, if all you've done is paid a designer to give you some visual and functional mockups, well, that means absolutely nothing about your ability to actually code and deliver the product.
Also the fact that they could write the code to support the designs isn't the issue. The issue is that they didn't, and didn't say so. It's giving the impression that they are operating at what seems to be an amazing speed supporting what presumably appears to be a fully fleshed out user experience, etc, when all that exists might be a design/pitch doc and some jpegs. Programmingprowess is implied. Frontend to backend functionality is implied. Progress is implied. When you leave things implied, then blame your customer for not catching the fact that you weren't explicit about details and therefore you weren't lying to them after all, you're doing it wrong.
It's like that episode of Arrested Development where they go to show clients a model home, only to have one of the walls fall down to reveal nothing inside but a bunch of air, and two people who thought they were hiding inside making out.
They may not be lying with this approach -- they do have screenshots, the same way the guys in that sitcom really did have four walls and a roof -- but they're also setting themselves up for a pretty killer "I don't think you've been entirely honest with me" conversation with a client if one of those walls happens to fall over a bit and reveal what's inside.
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.
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.)
1. You're not your customer/user
2. Identify the minimum viable product
3. Incur technical debt wisely
4. Get feedback early and often
Pursuing angel financing with those signed LOIs is a completely different ballgame from showing up with an idea, or even working code.
Imagine you're an investor. Two guys with ideas of similar merit come in front of you. One has three signed (and admittedly meaningless) LOIs from potential customers and knows what to build. One has a prototype but is really unsure of the marketplace.
The investors I know pick the LOI guys every time, all other things being equal. It's the execution side of the "ideas vs execution" debate.
It's a pretty smart play.
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.
Couldn't he have just said: "But it doesn't look good because we can't afford a good designer."
Have you ever played poker?
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.
Does paper prototyping fall inside of your dev process or outside of it? It's definitely inside mine.
If you bet on every round of poker based solely on the cards in your hand, you'll lose.
Wait a minute, because one of you got burnt and lost 6 months of work, now you won't do any 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.
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:
1. I'd want to see that you can actually produce something, no matter how limited.
2. There's a huge 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.
Come back when you have something real to show. Until then you're no different from any other poser.
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!).
A screen shot != a prototype
A prototype = code that runs
echo "there are data from our distributed, fault-tolerant cloud-based backend"; # TODO: Insert actual code here.
is much better.
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.
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.
Convincing the client meant conducting independent customer research and validation.
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.
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.
Get your screens in front of customers before you ever code. It is mind BLOWING!
Wonder how well this would work for consumer web... thoughts?
the letter of intent isn't legally binding, so its just a way to gauge business interest.
i mean, i'd be willing to sign a non-binding LOI if it meant someone would make use of it to independently develop an application that i would find beneficial.
You keep talking to him/her and 6 months later the app shows up and it is a piece of crap (not as advertised). The customer doesn't buy it. Yet, you have stolen 6 months of valuable time from the customer which he could have used on productive things (or searching for another app that meets his needs).
Not illegal but definitely unethical.
1) if i were in the shoes of the customer, and i didn't have a prototype in front of me, i'd either ask for one or assume it didn't exist.
2) how is this different from posting up a splash page asking for email addresses for a future public release?
3) is the false impression the only thing that matters to you? if they instead implied that they were designing it and there was no implication of cut code or working prototypes, would that make this somehow a better situation in your eyes?
You really don't see how lying to a customer's face about having code written is different from putting up a splash page saying something might exist in the future?
i'm not really here to agree with how they went about doing things with respect to how they claim to have pitched the product.
the process that they took would work the exact same if they were completely upfront about what they were doing, though, and i think its worth learning from.
I think it becomes unethical when you begin lying: "Production of the app is coming along nicely! Here are a few more screenshots from development this week."
So the question might be more accurately: do you position this so you don't have to lie to a potential customer, but have them assume it exists? Is that positioning unethical? What do you say if they ask you point blank?
Of course not, if you disclose that it's unrealized.
Is pitching you an idea for a company in trade for your money wrong?
Of course not, if you disclose that it's an idea.
I think it becomes unethical when you begin lying
Which they were doing. They have your example of what would cross the line almost verbatim: "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."
How do you position this so you don't have to lie to a potential customer, but have them assume it exists?
You don't. Creating the impression it exists when it doesn't is the unethical part. Why not just be up front with your customer and win them over with your design, insight, and ability to turn around real prototypes?
With just a little other investigational programming on the side, everything in their presentations would have been truthful, to the level of detail that a customer cares about.
It is, but that's not what they were referring to.
Which is a big reason why I think it's unforgivable that they chose to lie instead. They crossed a brightline in their relationship with their customer without any real benefit from doing so.
Sounds like lying to me.
edit: removed HTML.
It's important to validate the pricing and business model -- and you can only do that by selling it (charging for it).
But, a good read.
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..