Since then, I've been moving as fast as possible to iterate on the app, tweaking features in an effort to re-release Command with a different focus.

In this post, I want to share some tips about what has sped up that process the most and how you can leverage that when rapidly iterating on your own product.

Learn to be ruthless about throwing away work

This is hands down one of the hardest things to do when you're building a product.

The reality is that, every second we invest into our products is a second we're taking away from our life. You can't get that time back.

The problem this creates is that, the further we get into a project, the more we get stuck in our ways. Whether it's conscious or not, you think to yourself "well, I've already gone this far down the road...I should just keep going."

Maybe.

There are two sides to this:

I've already gone this far and I have traction.

I've already gone this far and I don't have traction.

If you're in group number one? Stop reading! Whatever you're doing is working.

If you're in group number two like I was a couple of weeks ago, really stop and think. Are you continuing down this path because you've gotten feedback—directly or indirectly—that this is the right path?

Or are you just doing it for the sake of ego and emotion?

Look, I get it. It hurts to throw stuff away. The time you invested building it is not coming back. But what's even worse is that if that stuff isn't going to work anyways, digging in further is just spending more precious time.

A spin I've put on this that helps: if you wouldn't have invested that time in the first place, you wouldn't have found out that you were on the wrong path.

Even better? It's likely that in building in the wrong direction, your skillset improved which is not a waste.

If you're going to iterate quickly, you have to detach all emotion from your process and kill your best ideas if you know they're not resonating with customers.

Reduce your scope

I'll be honest, in a lot of ways Command was a flex 💪.

For the majority of my development career, my time has been spent either building things for other people or teaching other people how to build things.

Save for a few bits here and there, I never really had an opportunity to execute.

That frustrated me. Mostly because people would talk to me as if I couldn't build something significant.

My reaction? "Oh yeah, watch this!"

That was the wrong move. While I am proud of what I accomplished, it was done for the wrong reasons and ultimately meant that I led myself away from my goal instead of towards it.

What I should have done (and am doing now) is significantly reduced my scope. Scope, here, being the amount of work you're doing.

Instead of building 8 features, build 3 features.

One of my favorite quotes which I hate to say I neglected while building Command was:

“The less you do the more of it you can do. Don’t invite more of what you don’t want.”

- Scott Hanselman

The point here is that you should focus on depth not breadth.

The reason why is that your scope ultimately dictates how your product is positioned in people's minds. Too many features means too many things to talk about means a confusing message.

Instead, reel it in. You want to be able to say "X is an X for X."

If you can't do that, you should really pump the brakes and figure out where you can trim some fat.

Use patterns and keep your code organized

This was one of those happy accidents that I'm glad I stumbled into.

When it comes to writing code, I cannot stand disorganization. It drives me nuts and makes me extremely uncomfortable.

While at times this tick can be frustrating, occasionally it produces some helpful things that end up saving me a ton of time.

Throughout the development of Command, I made a point to take my time when it came to the code and not just rush through the implementation to get it done.

For 99% of the features in Command, I followed the exact same pattern:

Wire up a React component using the class-based method for the user interface.

Connect that React component to GraphQL using the higher-order-component method from the Apollo library.

Write the GraphQL query or mutation being run on the client and call it.

Wire up a resolver on the GraphQL schema to either retrieve some data from my database, or, perform some business logic.

If the code can have some unpredictable behavior or I want some extra certainty that it works, write some unit, integration, or end-to-end tests.

Even if all of that sounds like gibberish, the point here is simple: this consistency means that I can make changes quickly while barely thinking about it.

If my code was a mishmash of different patterns (or no patterns at all), every time I wanted to change something I'd have to stop and think.

I'd have to be more careful and deliberate about what I did, potentially wasting time on fixing bugs created in the process.

Using patterns? I've already iterated on Command significantly in just two weeks. While things have visually changed on the front-end and the work being done on the back-end is different, the way it's all done is 100% the same as before.

What's most important here: once you've committed to a pattern, don't change it unless doing so is fixing a bug or major performance issue.

If it's just to stay up to date with trends or to get some perceived performance, be honest with yourself: you're focusing on the wrong things.

Build what people are asking* for

Last but not least, this is my favorite love/hate relationship when it comes to building products.

There are two camps: people know what they want and you should ask them or people don't know what they want and you should just build your idea.

What I've learned? Both of these are 100% correct.

When it comes to people knowing what they want, it's indirect: you have to learn how to listen for what's driving people nuts. What's making their life difficult? Where is the pain?

That pain is the seed of want.

Unless they're a masochist, most people want pain to go away. If you can learn to listen closely to others, they will tell you what they want you to build without you needing to have a conversation.

This is where "you should just build your idea" comes in.

Once you've identified an honest-to-goodness pain and can back it up with evidence (for example, people griping in a chat, a negative Reddit thread, or a "this sucks" thread on Twitter), then you can start to build a solution.

Your own personal experience is valid here, too, but you want to be careful not to convince yourself that something is more painful than it actually is.

Tony Fadell from Nest and Apple fame makes this point a bit clearer in the above clip.

He's talking about fact-based decisions vs. opinion-based decisions and how asking for feedback before you've built something doesn't work.

Instead, you have to build the thing based on your opinion of what's right (what will solve that pain) and then ask for feedback and iterate from there.

Why? Early on the in the development process, it's difficult for people to understand how you're trying to solve their pain. Until there's a finished thing sitting in front of them, there are too many variables and you end up getting low-quality feedback that can steer you in the wrong direction.

The point: make sure that you're building things that you know are painful for people, not just what you think is painful.

Get comfortable with being uncomfortable

If there's one piece of wisdom that came out of all of this, it's to get comfortable with being uncomfortable.

Until you find that thing that just "clicks" for others, you have to accept the risk and the cost of time invested to make it work. That's it.

The tips above will help to make that experience less painful and work toward ensuring you stick with it through each iteration until you find product-market fit.

Small SaaS Stories

Read tactical tips and insights on building a small, bootstrapped SaaS business from a solo founder trying to find the path to self-sustaining success.