Hacker News new | comments | ask | show | jobs | submit login
Sell your product with fake screenshots (groups.google.com)
141 points by jmorin007 on Oct 12, 2009 | hide | past | web | favorite | 57 comments

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.

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.)

Back in the 90s, when I worked in consulting, it was business as usual to have a meeting with the client and the next day be back with a mock-up of the application features or interface discussed the day previously. It might have been VB, just GUI with nothing behind it, but clickable. It might be a few flat HTML pages (that would be connected to a database if it were real). There would be no graphics or "polish", it might be literally just black and white and maybe a little line drawing or clip art. The user could play with it and say yes, build this for real and make it look pretty, or let's change this bit, and we would and be back the next day. We even had a fancy name for it, which I can't remember offhand, like Rapid Prototyping Workshop or something. Competitors of ours did this by sending it offshore and having it worked on overnight but we never did 'cos it was as much work specifying it in enough detail to do that that we might as well just hack it up on laptops ourselves in a hotel room.

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).

It makes sense to show potential customers pre-development screenshot mockups but I find it mildly sleazy to deliberately lead them to believe that these are screenshots of an actual working system.

Yes you'd at least want to tone down the language and call it a prototype, or a work-in-progress.

Right, it isn't good business practice to start out a new potential contract with dishonesty on your part.

A few years ago I found myself working 70+ hour weeks for nearly 2 months because the client whose project I was put on had sold their software product to a large telecommunications company before it was even specced out, let alone developed.

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.

I must say that while I agree, I think that in this situation you (or your company) greatly profited from the bad planning of your client.

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.

I agree. W/ B2B sales you need to iterate on your pitch as much if not more than your product.

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:

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?

OP did tell the truth. Your interpretation adds judgment.

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

I don't consider this telling the truth:

"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.

Development of the codebase might not have been but development of the product clearly was.

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.

Development of the codebase might not have been but development of the product clearly was.

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'm with mst. It's not lying when you fail to point out the flaws in your own pitch. If the prospect asks, "do these screen shots actually exist in code" and you say "yes", you're a liar; if they don't ask at all, they don't care.

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.

I can't really argue with that. Blast you.

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.

Deciding which facts are "relevant" to the customer is a pretty dicey proposition: why do you assume that the fact that no code has been written is irrelevant to the customer? Just because the sales guy wants it to be irrelevant doesn't mean that the customer shouldn't have the right to make their decisions based on the actual facts, rather than what's convenient for the seller.

No, if the facts are important to the prospect, the prospect asks about them. I didn't read anything in this post about them supplying false answers to direct questions.

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.

Fair enough; you're not obligated to disclose everything up front if they don't ask. But that's a world different from making a deliberately misleading statement.

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.

Change the words "actively developing this" to "actively designing this". Can we stop debating it now?

Calling them "screenshots" and using the word "development" both in the present tense when talking to potential customers is telling them implicitly that not only do you have the skills and competency to deliver this functional piece of software, but that you are already in the process of doing so. Unfortunately none of that is actually proven explicitly by what you're showing, as all of the functional coding implied doesn't actually exist.

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.

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.

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.)

So much good stuff in this article:

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.

Except the LOIs in this case are utterly meaningless. I've been on the customer side of LOIs that were signed on request, knowing that it obligated us to nothing.

They just mean you have a sales pipeline, nothing more.

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 very easy to "convert" a prospect to an LOI, because it doesn't cost anything for the prospect to do so. Once so converted, you have license to go dark for many weeks to build a first cut product, and the LOI-bearers are all going to light right back up again when you reach out, because you secured an agreement that they would.

It's a pretty smart play.

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.

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.

I love Balsamiq. Demo of it here: http://www.balsamiq.com/demos/mockups/Mockups.html

"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."

Couldn't he have just said: "But it doesn't look good because we can't afford a good designer."

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).

A lot of commentary about whether this is lying/unethical.

Have you ever played poker?

Salient quote:

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.

...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

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.

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 http://venturehacks.com/articles/minimum-viable-product

Don't most industries work with prototypes? As long as no lying is involved it seems okay.

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!).

Don't most industries work with prototypes?

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.

Yes, I agree. It would be tough to keep going to a customer with screenshots but without an actual demo app.

I love the line about how they can't find a designer who can follow directions. Ah, creatives.

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.

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.

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.

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?

Is this unethical?

Seems so to me, and somewhat pointlessly, too. You're working closely with companies who are willing to sign letters of intent and stick with you after a botched install, but you think you have to lie about having code written? There's a disconnect there...

i don't think so, no, as long as money isn't exchanging hands until a product is actually available for sale/use.

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.

It is legal but it is not ethical. They gave the customer a false impression. Lets say customer A got an impression of the app from screenshots.

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.

perhaps. three things:

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?

how is this different from posting up a splash page asking for email addresses for a future public release?

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?

could you point out where they lied? maybe i missed it.

They implied they were writing code by telling the customer that "development was progressing". Could you argue this was not a lie? Yes, if you are a weasel.

well, i think i could justify it if i wanted to. but i don't want to continue down this thread, sometimes i like to argue for the sake of arguing and i think i should stop now.

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.

Is selling any unrealized concept unethical? Is pitching you an idea for a company in trade for your money wrong?

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?

Is selling any unrealized concept unethical?

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?

A good set of evolving screenshots is nice progress in development.

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.

A good set of evolving screenshots is nice progress in development.

It is, but that's not what they were referring to.

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.

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.

FTFA: Once we secured a meeting, we told our potential customers that we were actively developing our web app (implying that code was being written)

Sounds like lying to me.

edit: removed HTML.

I think they would be better off to have tried to charge something , rather than give it away.

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.

"we haven't been able to find a good, dependable designer who works at reasonable rates"

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.

It was almost Microsofts story at the beginning.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact