Hi there! First, I wanted to thank everyone who’s discovered this little series. The claps, comments, and even a few emails are incredibly motivating and it means a lot!
Today was heavy on backend development, working hard to get everything in place to where I can fill in UI components we need for screenshots. I don’t mind mocking up the UI for an early landing page, but I do want it to be an honest representation of what we’re getting into.
But stepping back and focusing on some technical challenges gave me breathing room to let validation ideas stew throughout the day. And I decided we’re going to make a small pivot in our strategy here!
It’s still incredibly early of course, and we’re not abandoning the channels I outlined in day 2, we’re just changing our strategy some to see if we can improve our response rate.
The timing for a small pivot couldn’t be better, with tomorrow being Thanksgiving in the U.S. (and I don’t want to cold email folks who are trying to spend time with their families!) it will give me a few low pressure days to get ahead on content and push through a few of the hard technical challenges I’m facing.
Our goal is to redefine the core of the Bystander.io idea we outlined in day one, and then hammer out three new strategies to reach our target audience.
Now that we’ve spent a few days trumpeting the idea, and really digging into a few communities, let’s see if we can better define our product.
Back on day one I defined Bystander.io as:
Bystander.io a tool to track visual user-facing errors, how much they’re costing you, and a framework with the accompanying analytics to reduce the cost those errors.
In terms of an elevator pitch, that could use a little work.
And to start with improving that let’s take a look at how we define Bystander.io’s benefits. In Indie Hacker’s interview with Brendan Dunn he boils down a company’s purchasing decision nicely:
[…] businesses pay for things if they can either make more money or lose less money.
We’ll fit into the “lose less money” side of the coin. But how? Here’s a simplified version of the user flow were assuming when a customer faces off against an error in your app:
So, we’re looking to recover costs companies by:
How will we do that?
So what is Bystander.io in this iteration? Remember we’re looking to get the concentrated version of:
Bystander.io a tool to track visual user-facing errors, how much they’re costing you, and a framework with the accompanying analytics to reduce the cost those errors.
That’s the long answer — and I can understand people getting bored by the first comma.
We’re Optimizely + Logs for your errors.
Great! But how does distilling our product hope define the direction of our validation efforts?
No we have (hopefully!) a clearer picture of who stands closest to the tangible pains we’re looking to solve.
So we’re going to sneak in as close to the problem as possible, and offer immediate value instead of asking for a discussion.
Let’s stop our error message from reducing long term customer value and increasing customer support costs.
Let’s never give them this again:
Now, dear readers, I have a favor to ask! If you work at a SaaS company large enough to have a customer support team, or are friends with some folks who might benefit, ask your customer support teams if there’s an error message users are writing in about.
Until tomorrow, and if you’re in the U.S. and busy eating Turkey tomorrow — have a great holiday! (And the rest of you have an amazing day too!!)
As always feel free to email me or message me, my email is on my homepage where this was originally published. 👋