paint-brush
[Day 5] Zero to MVP in 30 Days — Rethinking validationby@modette
250 reads

[Day 5] Zero to MVP in 30 Days — Rethinking validation

by Matthew OdetteNovember 23rd, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

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!

People Mentioned

Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - [Day 5] Zero to MVP in 30 Days — Rethinking validation
Matthew Odette HackerNoon profile picture

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.

The (small) validation pivot

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:

  1. Reducing the number of Customer Support hours errors add
  2. Reducing customers downgrading or canceling plans as a result of errors

How will we do that?

  1. Improve errors to be actionable in places that make sense. Errors should be iterated on and tested similar to our Call-to-Actions, marketing copy, etc.
  2. Have error messages that work maintain trust instead of degrade it
  3. Use analytics to help identify and fix new or troublesome error messages efficiently, and have a framework in place for your team to document internally for customer support or improve the error

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.

  1. While reaching out to user experience professions, I’ll ask that they in turn reach out to the customer support team for an example error message that’s causing customer contacts. Then I’ll research it in a way that our SaaS ultimately would. I’ll help them recover value from an error causing them pain right now. Do things that don’t scale.
  2. Tenured customer support frontline: they may not have buying power, but we’ll try a more traditional sales funnel of creating a fan within a target company, offer the frontline similar value as we do to the UX professionals. And work from there.
  3. Company social media accounts: it’s easy to keep a pulse on trending errors. And this will give me a timely error to offer value on, and every @mention to a company gets read so I’d like to test if this works.

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


Back to day 4Forward to day 6