How to Simplify and Regain Control of an Overly-Complex SaaS Product

How to Simplify and Regain Control of an Overly-Complex SaaS Product

For the past month, I've been working hard to pivot Command away from being the all-in-one tool for SaaS products.

While the idea made sense on paper, in practice, it was incredibly difficult to explain to people. The product worked and the features were useful, but together they didn't make any sense to the market.

Live view of me trying to explain Command to people.

Since then, I've learned a lot about simplifying a product.

In this post, I want to breakdown what I've done to zero-in my efforts and simplify Command down to on an easy-to-explain product that—hopefully—will resonate better with the market.

Perform an inventory of features

While my initial instinct was to light a match and torch the entire app, I realized that starting over was a terrible idea.

Not just because of the time it would take, but it'd be a massive waste of some really great ideas and implementations.

Instead of starting from scratch, I made a point to take inventory. I spent a few hours going through the app, making note (in my head and in my notebook) of all the features in the app; big and small.

What this helped me do is to see the landscape of the app.

Once I understood this, it made it far easier to decide what should stay and what should go. It also helped to illuminate some of the more dillusional aspects of my vision. By zooming out, I was able to see the failed connections through a potential customer's eyes.

Figure out what your customer's questions are

A technique I've been hooked on for awhile is the idea of creating "conversational" interfaces.

This idea suggests that when you're building a user interface (UI), abstractly speaking that UI is trying to answer a customer's questions.

My favorite example of this is an Amazon product page.

While it's not the prettiest thing to look at, it's a masterclass in conversational interfaces. If you look at the content on the page, the way it's organized, and the way things are labeled it reads just like a conversation between you and someone working at a retail store:

  • "What does this thing look like?"
  • "How much does it cost?"
  • "Can I get this thing used or just new?"

Each part of the UI is answering a potential customer question.

While I was working through the inventory of features I created, I had a revelation: your product is just like this! Any customer of your product is going to be trying to answer certain questions. The goal should be to make your product the answer.

For example, one of the features on my list was revenue tracking. When I stopped and asked myself "what question is this feature answering for customers," I was initially stumped.

After a bit of thinking I found the answer! "Am I making money from this product or not?" Once I realized this, I started to apply this mini-framework to every feature in the product.

What should you do if something isn't clearly answering a question for a customer?

First, try to salvage it. Break it down into its parts and see if there's any value in re-shaping it into answering a customer question. If not?

Throw it in the trash and move on.

Identify which features have become emotional

This has been a big theme of Command's recent pivot.

I consider myself a developer's developer. I love to make stuff. I'm obsessed.

That's great when it comes to mustering up the energy to work on an idea, but it's not so great when the best business decision is letting go.

While in the past I would twist my own arm to keep things that I was attached to or thought were "cool," this time around I've been a total drill sergeant.

For example, one of the features I invested a ton of time into in the current version of Command is the cards feature.

While I'd like to believe that it's some novel creation, the truth is that it had been done before—it was essentially a dressed-up combo of GitHub Issues and Trello.

That's okay, but in the context of Command as a business, it wasn't answering any customer questions. There are a hundred and one different tools for managing work on your product already and this one wasn't special.

The reality?

I was emotionally attached to the implementation. I was proud of what I'd built. It looked cool. It worked really well.

But the harsh truth was that it wasn't so valuable that someone would reach for their wallet and pay me for it.

While it was tough to accept, I realized the feature had to go.

The benefit, though, was that a lot of cruft in the product was a result of that feature existing.

As soon as I let go and did the work to remove it? A lot of complexity in the product was removed.

Even better, thought it hurt at first, removing that feature helped to refocus me on some more valuable features—removing something helped to add value.

When in doubt, use the rule of three

Despite using all of the tools above, after about two weeks of work I was still stuck at four, core features.

By this point, I had gotten so aggressive about simplifying that I was almost eager to kill something else.

Playing around with the UI a bit, I started commenting stuff out and playing with the navigation items. Sure enough, after a bit of back-and-forth I landed on three things.

  1. Customer management
  2. Email marketing
  3. Behavior tracking

Together, these three features would allow me to create an incredibly powerful tool that helped SaaS owners answer a ton of valuable questions about their business, and more importantly, help their business to grow.

The questions being answered by the product now?

  • "Who are my customers? Where did they come from? Which customers are most valuable?"
  • "How are my marketing efforts actually impacting customer interest and revenue?"
  • "Which marketing channels bring me the most customers?"

By forcing myself down to these three features, a few things happened:

  • The amount of stuff I had to manage as a developer was dramatically reduced.
  • I found opportunities to "merge" old features together into new, more valuable ones and reduce the amount of UI clutter.
  • How to describe the product became significantly easier.
  • I've been able to really hone in on the details of the features I've kept, creating a better product overall.

What's even more interesting is that my confidence level around the value of the product has skyrocketed.

I've gone from having to convince myself that people would see value in what I've built to actually being able to see the value in plain sight.

Simplifying is a constant process

One of my favorite clips from the past few years is this interview with Jony Ive, explaining what he learned from Steve Jobs while at Apple:

While the point he's making is about focus, I'd argue that it complements this idea of simplification.

The suggestion "[y]ou can achieve so much when you truly focus" is a real gem in that interview.

Typically this sort of thinking refers to the projects you focus on, but you can take it a level deeper. Don't just focus on the one product, focus on what goes into that product, too.

Be vigilant and even obnoxious if you have to be. Accept that you will need to constantly be on guard.

Don't let your passion and fantasies become an excuse for overcomplicating your product and killing customer interest—keep it unapologetically simple.