We listened to the people, not the problem
And overcomplicated the hell out of both our products
I recently wrote a post called “More is a four letter word” about the pitfalls of having too many choices.
Okay, so I was talking about my embarrassing mental collapse in the cheese aisle — but the notion of limiting choices is something that we (Matt and I) have been paying very close attention to lately.
We are about to launch our second product (HookFeed), but it’s not our second launch. We’ve been doing countless mini-launches (alpha versions) for months now with both HookFeed and Minimalytics — and we keep making the same damn mistake:
Giving users too many choices…
Below, I’ve illustrated our mental excursion from key iteration to key iteration across both products in search of simplicity.
TLDR: We’ve been reminded (brutally) that as product people we need to make the hard choices up front if we want any of our products to succeed. The vocal minority isn’t usually right and ultimate flexibility isn’t really what people want or need.
Our first product launched was Minimalytics.
Minimalytics is an application that allows you to create an email containing metrics from your various apps and services (like Google Analytics, Twitter, Campaign Monitor, etc,) and schedule that email to be sent on a recurring basis with up-do-date analytics.
From the beginning we set out with a simple problem to solve: automate analytics reporting.
We knew our job as product developers was to make choices on behalf of our users.
But somewhere along the way, after many Skype calls with potential customers — discussing all of their unique use-cases—we let our early customer development fog our vision.
The temptation of flexibility creeped in — and we dropped the ball.
We listened to the person, not the problem.
If Henry Ford had made the same mistake he’d have built a faster horse carriage - not a car. And he wouldn’t have solved the real transportation problem.
As a result of listening too closely to people’s specific requests, we made some major UX mistakes, and had to learn the hard way that flexibility usually isn’t a good thing.
Mistake #1: The “Blank Canvas” UI
We did exactly what we preach against (funny how that happens right under your nose).We gave users a blank canvas.
In efforts to be flexible we thought it was a great idea to allow users to draft a plain-text email any way they wanted. (For example: sentence format with the metrics worked in, or maybe just a bulleted list of the numbers they want to track, etc.).
The steps to drafting the email looked something like this:
- Users pick the metrics they want using the Add Metric button.
- Those metrics and their shortcodes (which later get replaced with real data) appear in the left sidebar
- Users copy/paste the shortcodes into the email (which we’ve assumed they’ve drafted) in any place they want.
We learned very quickly that a lot of people either didn’t know what to do to get started, or were turned off by the amount of work required from them up front, just to get the email drafted.
The trade-off for flexibility ended up being a big road block in terms of just getting the email created and scheduled. We shifted our responsibility of creating these emails onto the user — and made them do a lot of “shit work” to get started.
The flexibility that we were trying to achieve ended up creating an overall bad experience—particularly for new users.
At this point, we saw a clear solution:
Change the email itself from a blank slate/plain text email, to a simple, cleanly formatted, non-editable template.
Not only does this solve the problem having to figure out what to do with a blank slate email, but it also gets rid of the need to drop in each shortcode one by one. Users would be able to go from picking metrics to scheduling the email in a matter of a few clicks.
Mistake #2: The “Time Warp”
Going head-first down our path of “flexibility” we agreed it would be awesome to schedule the email to be delivered any day someone wanted. Mondays and Wednesdays? Sure! Every-other Tuesday, Saturday, and Sunday? Why not!
Open source projects like GetJobber (which we used for the scheduling tool) make it really easy to focus on the wrong features since you think a lot of the work is already done for you. (Wrong). But even if you’re right, there are other repercussions to adding features besides the amount of time it takes you add them.
We put too much emphasis on scheduling before anyone asked for it. In fact, we never even added in the ability to pick a time of day (something which we thought was a huge deal) and to this day not one person has even asked for it.
So not only was this a big time-suck that created a lot of unnecessary complication on our side, but it again put the burden on the user of figuring out exactly when they wanted to get the email.
It was yet another roadblock in the way of what people really wanted: an email in their inbox with simple metrics. Period.
The right solution for this:
- Everybody gets the email at 8:00am their time either daily, weekly, or monthly. Still a choice, but a much easier one.
Not only does this simplify one more step a user must complete in order to get their report in their inbox, but it actually makes it much easier for us to do some really cool things down the road, like week over week and month over month comparisons. Something which would be much more difficult if everyone had different date range intervals set up.
Moral of the story: we realized we needed to strip out anything that required unnecessary work by the user to get the email set up and scheduled. We needed to go back to square one and solve the core problem. Then, deliver on the promise of letting people pick metrics and have the delight of seeing the email show up in their inbox.
Back to HookFeed:
Perhaps the best part about making these types of mistakes with Minimalytics is that we’re able to avoid many of the same pitfalls as we gear up to launch HookFeed.
Initially, we planned for HookFeed to be this: a live notification feed of all your apps and services. Tons of ‘em. Loaded up, with lots of sweet customizations.
Not only would this require a ton of setup on the user’s end, but we realized we weren’t really solving the problem we hoped to be solving. We struggled to see long-term value in this model.
The truth is, very few people are going to want to sit there with yet another browser tab open all day, watching a bunch of notifications roll in , waiting for the one or two that are even actionable. And if something important does stream in, you may not see it until later anyway.
So we got to thinking about what is valuable. And after a few iterations, we landed here: A streaming feed of only Stripe notifications.
We went from building a “nice-to-have” product to actually solving a big problem : the ability to stay on top of your Stripe activity. No more kitchen sink.
This was a huge deviation from the first iteration, but a giant step in the right direction.
In addition to the feed, we began planning for email alerts and digest emails for people who don’t want to have the feed open all day.
And that’s when we realized we were finally starting to solve the problem.
“ Just tell me when there’s something I should know about so I can act on it. I don’t need to sit there all day watching transactions, I need to know when someone disputes a charge or when a credit card fails.”
A few more rounds of iteration… and HookFeed no longer has a feed.
We’re launching HookFeed with instant email alerts, daily digests, and weekly digests. When key events happen in your Stripe account you need to know immediately. Everything else can be consumed in a summary at a later date.
We’re finally solving the problem the right way — and it’s drastically simplified from where we started.
The notion of flexibility is deceiving. Having flexibility isn’t inherently bad by nature. In a lot of respects flexibility is a great thing.
But having too much room, having a blank canvas, lacking direction, or even motivation to choose or do the “shit work”… that’s a problem.
When flexibility itself overtakes your solution, or worse, becomes your solution… that’s a problem.
Matt and I have found that as product developers/problem solvers it becomes incredibly hard to accept that we won’t be the perfect solution for every single person out there.
We want so badly to nail it for everyone. But there are always edge cases, special considerations, etc. And you’ll hear about them a lot because they tend to be a very vocal minority.
But we have to remember that it’s not our job to please everyone. We’re creating products that solve problems for the vast majority of our niche market. And now that we’re able to remind ourselves of that it becomes much easier to limit options, limit flexibility, and make kick-ass products that do things our way.
I’m Joelle Steiniger and I’m Co-Founder of HookFeed and Co-Host of The Rocketship Podcast. Keep up with me on Twitter: @JoelleSteiniger ☺
