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.

We left the email completely blank, expecting people to spend time drafting out a personal email and hand-placing each metric in-line wherever they wanted it to appear.

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.