When Your Product Looks Too Good To Be True
These two products look too good to be true:
- ForLoop.ai, a data infrastructure/organization app, with some intelligence baked in;
- AppBuildy, a no-code app builder.
My recommendation for both of them:
Tell the visitor what your app won’t do.
“Too Good To Be True”: One of the Anxieties to Reduce
In a recent article, I covered how, when making a convincing landing page, it’s easier to reduce anxieties than it is to try to add attraction.
That’s because as your visitor considers “hiring” your product for their job-to-be-done, hesitations will pile up, despite all the nice things you claim your app will do.
No matter how many “my app is great because”, visitors will have “yeah but’s”:
- Yeah but will I have to change the way I work?
- Yeah but what if I end up deciding I don’t want to use it, will it be complicated to move my stuff out?
- Yeah but what if I have to learn a whole bunch of new features I don’t think I’ll use.
- Yeah but it looks too good to be true.
Today, we’re addressing the last one.
Example #1: ForLoop.ai
ForLoop.ai promises to help take disparate sources of data, clean them up, and make it easy to make sense out of that data. Plus, there’s some intelligence baked in.
One situation it could be useful to solve:
When I’m getting pressure to reduce the costs of data preparations, I want to find ways to streamline the process so I can be seen as valuable to the company.
The app promises to use smart constructs, conventions and some “intelligence” to deliver on that promise.
It seems too good to be true.
They do a high level summary of how the product works. Maybe they could explain it in more detail, but if they do, a competitor could swoop in and replicate their process.
What to Do?
It does have FAQs for Who it’s for, How it works.
But I’d go further.
I’d re-assure the visitor by disqualifying who the app isn’t for. Telling it up-front.
- If you’re heavily invested in dbt, you might as well continue using that.
- If your data is coming from systems like this one or that one, we’re not setup to handle those unless you build your own separate preparation step.
But isn’t that handing the visitor to the competition? You’d think that dbt is ForLoop.ai’s main competitor, but it’s important to remember that everybody’s largest competitor (by far) is “I’ll just”, the choice of not purchasing.
The result: less “too-good-to-be-true”, more “yes, this is legitimate and it’s for me”.
Example #2: AppBuildy
AppBuildy makes it possible to build a mobile app right from the browser, get your data from AirTable, change the theme, adapt the layout. It’s, well, promising.
And judging by the intro video, it looks like it delivers.
But here’s the problem. You know it doesn’t do everything. And you don’t know if it’ll help you make the app you envisioned. Will it handle your edge cases and your special considerations. Surely not.
It’s probably too good to be true. Skip.
But It’s Free to Try, So Who Cares?
AppBuildy doesn’t have any information on pricing. That’s suspect. The anxiety?
Will this thing be here when I need it, in a year’s time. Probably not. Skip.
Even if you can try before you buy commit to using it for your project (the true “cost” of AppBuildy so far), there’s still the underlying hesitation.
Is it even worth my time to try it out if it might even be around in a year’s time?
What to Do?
I’d put a public price that communicates “we’ll have you covered because we’ll be around” and I’d find another way to quell any hesitations about “will this app handle my special case”.
I’d tell the visitor up front what it can’t do.
- It can’t connect to a normal database
- It can’t handle information posted by visitors
- It doesn’t come with user logins
“Yeah, but that will discourage the visitors from buying AppBuildy.”
Maybe. Maybe you should discourage them… on purpose.
Being Bolder: Discouraging the Visitor, on Purpose
There’s a technique when doing consulting work that works like a charm. You start off by discouraging new leads from hiring you. It isn’t to be coy or to be manipulative. You just want to get to understand the real value your service can provide them by addressing the topic of money or cultural fit right at the start. “I probably won’t be a good fit for what you’re looking for – I won’t be the cheapest option, and so if you’ve got other options that are affordable and do the job, I’d go with those. Or do you want to tell me a bit about what you’re trying to achieve?” Those who are looking for a cheap price will stop there. Those who are looking for results will sense that you’re serious. You serve.
You can do something similar with a product page. Make it discourage your visitor from buying your product unless it’s a great fit.
Your product page has one job. It’s not to convince or to convert or to remove “friction”. It’s to help your visitor make progress on a struggle. To help them decide that the past needs to be in the past and that there’s a better future should they choose to move into it.
So start your page by reflecting back the struggle your product aims to solve. Waste (so-to-speak) the top portion of your page by not talking about your product. Instead, talk about the struggle your visitor is experiencing.
Struggle-first Copy for ForLoop.ai
You’ve started building this data pipeline setup, and although it does the job, you’ve built something that’s going to be hard to maintain, and you’ll need more staff than you can afford.
This sort of paragraph makes it clear that you’re not there to help everyone. Just the people who know just enough about what a successful data pipeline/preparation infrastructure looks like, but finds the current one to be too expensive.
Struggle-first Copy for AppBuildy
You want a simple app built, but everybody you talk to gives you an exhorbitant price.
What you want isn’t fancy and you can’t afford a high-priced developer.
You just want to test a concept with some real people, if it works, you’ll see about building something more robust.
That’s where AppBuildy comes in. Before introducing AppBuildy, you can even use a “Maybe you’re looking for…” section to connect to the visitor’s aspiration.
Maybe you’re looking for something that will let you build a prototype real quick, no coding required, which lets you take data from a spreadsheet, and where you can make small edits.
Then you introduce AppBuildy.
And then you’re quick to say what it doesn’t do.
AppBuildy won’t connect to a custom database, it won’t handle information posted by visitors, it won’t handle user logins. Don’t need those? AppBuildy will do great (and we’ve got some new things we’re working on, no promises.)
No, You Don’t Need Social Proof
You’re probably asking: “But what if I add social proof? That should help sales and I won’t need to be open about what my app won’t do.”
If you’re going to add some testimonials, make sure they’re not phony. Make sure they communicate the job the app was hired to do.
By doing this approach, it’s clear to your visitors that you’re not boasting to be something you’re not. You’re up front. You address possible anxieties. You make sure you don’t deceive. That builds trust. Maybe you won’t get a ton of users, but you’ll have users that know what they’re getting into, that will self-select, and that you won’t need to convince.
They’ll say “yes, this, now” because your product helps them make progress. And they’ll show their friends.
It won’t be too-good-to-be-true. It’ll just be true.
Stay sharp.
—
Pascal Laliberté
@pascallaliberte