Over the past few years, one of the things I've grown to dislike is email marketing.
What was once a simple, enjoyable experience devolved into a confusing mishmash of features. Things that used to be simple—setting up a list, embedding that list in your site, and collecting emails—atrophied.
And for the most part I ignored it. I went with the flow.
At least, that's what I did until Command launched.
Then it became a bit more obvious. I started to shop around for a better solution that would combine basic newsletters with sequences. The solutions I found were either messy, too expensive for an early stage product, or lacking features that would help me grow a SaaS business.
Then I started to see other people echoing the same feelings I had about everything. There was a noticeable discontent with how email was taking shape.
Having decided from feedback and introspection that the initial direction of Command was a bit off, I started to think.
Looking at the existing feature set, I realized: "hey, with a few edits, there's a pretty compelling CRM and marketing tool here."
A CRM and Email Marketing tool that's specific to SaaS
The lightbulb came on when I realized that the things I had subconsciously invested the most time into within Command were: managing your customer list, emailing those customers, and tracking the revenue earned from those customers.
What was missing was the connection between all of those things along with some badly needed context.
A few questions I started to ask:
How do I know where a customer comes from?
How do I know the value of a customer?
How do I know if I've communicated with a customer?
The answers to those questions were either non-existent or inconvenient to find at best.
But, the data was there.
Now, I can get a quick snapshot of how my SaaS business is performing in context of my customers.
If I want to get more insight into a specific customer, I can jump into their profile. If I want to build our relationship, I can start conversations and review how we've communicated in the past.
Making email less messy
While direct messaging is important, the other side of this equation that's important is communicating with a lot of customers at once.
But email campaigns, frankly, have gotten messy.
Because a lot of existing solutions are not focused on a single industry, they take a generic approach which sometimes works and sometimes doesn't.
When it came to going live with Command, my list of demands was short-and-sweet:
Identify who is a beta signup
Create a campaign introducing the product
Target that beta list and monitor their engagement
I'd be lying if I said this didn't exist in my existing setup. But was it enjoyable? No. Far from it.
Instead of being a quick, few minutes, my time was wasted navigating sloppy menus, poorly designed UIs, and what I can only describe as half-built features.
It was a bummer and certainly not reflective of the products I want my own customers to experience.
So, I fixed it. No need for fancy, convoluted UIs. Just get to the point: write an email to your customers and send it.
The other thing I didn't like was the templating process.
When I consider the emails I personally engage with most, it's the ones that are simple.
Not quite plain-text. Just enough formatting to get the points across. No over-the-top "this may or may not work in your email client" HTML templates.
I'm putting my foot down. Aside from possibly adding the ability to set a logo, I'm keeping things simple.
The focus will be on the content. Write great emails that engage your customers or don't—don't use a fancy template as a crutch.
Getting people in from different places, fast.
Another big issue I had was getting people onto my list. As I saw it, there were two ways this happened:
Signup forms on marketing sites
People I add manually that I meet in person or find while doing customer discovery research
On the forms side, just like the "sending an email" problem above, the experience was messy and frustrating.
I wanted the forms experience to be lightning fast and simple. No confusing UIs to shuffle through. One form with easy-to-understand customizations.
When it came to manual data entry, the other thing that frustrated me was...the data entry. In order to really know who a customer is, you need context.
With Command, just provide an email address and it will try to find as much info on that customer as possible.
Not only does this speed things up quite a bit, it also makes the customer discovery process enjoyable—it's enlightening to find out who is interested in your product and using it.
The long-term vision
Admittedly, there's a lot to fill in here, but as a true-blue nerd that's exciting! This is just the tip of the iceberg and there are a lot of ideas brewing.
Do I have a launch date for this new version? Nope.
My focus right now is on getting things right so SaaS teams can immediately extract value vs. meeting some arbitrary date. I can say, though, that my opinion on shipping fast has changed dramatically in favor of as fast as possible.
At some point I'll write some more thoughts on what that process looks like so others can inform their own work.
As part of my marketing strategy, every week I make a point to go and participate in communities related to Command.
I answer questions, provide feedback, and try to be helpful however I can.
Earlier this week during one of my morning check-ins, I saw an interesting question about "Why would you NOT use Firebase?" Unexpectedly, my response became the top post in the thread.
This got me thinking about how this seems to be a recurring stress-point for developer-entrepreneur types. I shared in that same struggle early on in my work and I thought it'd be a good idea to outline how I've grown to think about the role of technology in a product.
In this post, I'm going to share a few of the mental models I keep in mind when making choices about technology in a product.
Be extra-cautious with vendors
As part of my teaching work at my other business, Clever Beagle, I routinely come across developers who have been burned by vendor lock-in.
If you're not familiar with the phrase, vendor lock-in describes being in a situation where you're so dependent on a third-party's technology that you can't function without it.
In other word's: you're stuck in quicksand.
Everything that vendor does, you have to do. Every mandatory API change they make, you have to follow suit. Every price change they make, you have to fork over the cash. If they decide to close up shop? Sorry dude! At least we had a great journey!
The problem with this is that your product's underlying technology inadvertently steers your product's roadmap (and distracts you and your team from moving forward). And sometimes it can steer it right off a cliff.
This is why I avoid basing my core technology on third-party tools. They may be convenient, but they can also be deadly. One of my core maxims never trade control for convenience.
Ideally, the things you want to look for when choosing technology for your product:
Control of data. Your data is essentially your product. Without control of that, you don't have control of anything. If you can't export it easily or map it to another database technology: put down that cookie and panic.
Flexibility and portability. How similar is the code you're writing to other APIs and technologies? How easily can you move it around (e.g., changing hosting services to save costs)? Is it just a framework built on top of another technology, or a proprietary system with no escape hatches?
Learning opportunities. One of the least talked about downsides of betting your stack on a third-party is that it limits your worldview and skillset. Because you're missing out on the challenge convenience displaces, you fail to cultivate valuable problem solving skills.
While taking the DIY approach can be more time-consuming, if your goal is to build a product long-term (beyond a prototype or MVP), you'd be foolish not to make that investment.
Trust the battle-hardened tech
One of the more interesting aspects of software development—and arguably, life—is that nothing lasts forever.
No matter how much time you invest, no matter how good something is, eventually it will decay and wither.
That said, there's an important thing to understand here: the longer a technology has been around, the more likely it is to stay around. More things are built with it, more time is invested in its iteration, and less uncertainty surrounds its best practices and purpose.
There's a theory for this known as The Lindy effect:
The Lindy effect is a theory that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining life expectancy.
This is why I always chuckle at the "X is dead!" type of statements coming from inexperienced developers. A technology may not be as popular or revered as it once was, but as long as it still works as intended when it was first created, it's not dead—at best it's just out of favor.
When you're building a product, you want to select technology for functionality, not fashion.
The more fashionable the tools you rely on, the more you should be cautious as these are the tools most likely to change or go away. What you want is staying power so that your focus remains on your product as much as possible.
PHP or Ruby on Rails might not be "cool" to some people now, but hell if they don't work. And it's worth saying, too: all technology can scale if you know what you're doing—avoid the "but X doesn't scale!" trap at all costs.
Delivering value has nothing to do with technology
This is the key to this entire issue.
Early on in my career, I wasted significant amounts of time and energy chasing technology. Worrying about what others were using, whether or not something was going to stick around, constantly jumping ship between technologies.
A harsh truth is that there is no perfect technology that's going to make your product better.
That's up to you.
Very rarely if ever does a product's value have anything to do with the technology its created with. Rather, it's about the product itself and what it can help others to do that they couldn't do before.
Here's The Godfather laying it out:
As long as their problem is being solved, no customer will ever ask "but wait, did they build this with _____?"
The only caveat to this is how well a technology enables your ability to move quickly. And more often than not, this isn't really a feature of the technology as much as it is your level of experience with it.
More than anything, when choosing technology focus on enabling value creation. Don't get stuck in the tech echo chamber and distract yourself from doing the work.
A world of trade-offs
When you work with technology, you're working in an environment that is all about trade-offs.
There is no perfect technology.
No matter how hard you look, no matter how hard you try, you will struggle to find the thing that's going to magically solve every technical problem your product has perfectly.
This is where your own skillset comes in. This is where your own experience comes in. If you intend to build products long-term, you have to learn to deal with this reality.
The only way I've found to make constructive use of this truth is to just pick a technology and stick with it. Don't panic when it falls out of favor, but instead, really learn it. Understand how it works and why it works that way. Know what it gets right as well as what it gets wrong (and how to right those wrongs yourself).
With that knowledge and experience you start to understand that most of the drama around technology is unfounded.
That the thing most likely to mess up your product isn't technology: it's you.
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.
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.
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.
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.
I've been a stubborn mule for as long as I can remember.
As I've learned to build software over the past 13 years— starting with front-end development in 2007 and transitioning to full-stack in 2013—my siren song has always been that "customers don't know what they want."
Funny enough, a lot of technical people think this way.
And, honestly, that's fair. When you can build anything, the cost of changing your course is relatively cheap.
But at some point, you do need to factor in outside opinions.
And when you do, it can be a bit intimidating. "Talk to customers" is easy advice to parrot, but what exactly does that mean?
This week, I did my first customer call for Command. What I learned is that it's not about talking...it's about listening.
I realized that, while customers may not know what they want in terms of explicit features, they do know what they want in respect to their business and their life.
In this post, I'm going to share three phrases to listen out for which signal a customer desire that you can respond to with your product.
Right now I...
One of the best words to hear as a product maker is "and."
When you hear this word, it means that extra steps are being taken that may not need to be. There's some inefficiency that needs to be solved.
"Right now I use MailChimp, and Intercom, and Baremetrics, and Twilio..."
My ears perked up. Hmm, that's a lot of stuff. I listened closer, asking questions about how those tools were used and why.
After a bit of back-and-forth, wouldn't you know it, lying in the answer were a set of features.
But, this is the important part: the customer didn't tell me what those features were. He didn't say "Ryan, I want you to build these things."
No, what he said was "here is what I'm doing right now, here's what that costs me, and here's what I'd like to be able to do."
By listening I quickly realized in my head "oh, you don't have to do all of that, you can just..."
Boom. You just figured out what to build.
I want to understand...
Another good set of words to watch out for is "I want to understand." This is usually delivered as "I want to understand how I..." or "I want to understand why X causes X."
Admittedly, these requests are a bit more abstract. But, if you can listen, there's a ton of value here if you're willing to put in some mental sweat and think up a solution.
You see, "I want to understand" is another way of saying "I know I need to know this thing, but I can't get to it right now." That limitation could be for a a number of reasons:
No existing solutions.
Existing solutions that require too much time and skill to set up.
Existing solutions that are clunky and require more effort than their price justifies to use.
A little secret I learned: a customer may already be paying for one of the sub-optimal solutions, but don't let that scare you away!
Remember: everybody likes to save time and money. If you can help a customer to understand something faster and for less money, you may have a killer feature on your hands.
How do I...
This one is arguably the easiest. When you're talking to customers and they ask "how do I do ___ with your product," there are only two answers:
Let me show you.
It can't do that yet.
If your product already does that thing, great. If not, though, there is a ton of potential.
Talking about Command's current set of features, the customer asked "how do I get my existing customers into Command?"
I answered that, as of right now, the methods are limited. You can use the form in the app or you can use the API. That's it.
But instead of stopping there, I asked "what would make it easiest for you" and listened closely.
He explained that being able to import all of the data he had on existing platforms would be a huge timesaver.
With very little effort, he told me exactly what to build. All I had to do was ask "what platforms do you need data from" and let him speak. That's it.
Listen close and then listen closer
Talking to customers may sound scary, but just think of it as having a conversation with a friend who needs someone to listen.
Instead of thinking about what you'll say next, really dial into what's troubling them. Give a damn about their business and their success.
Take notes as you go, writing down any interesting tidbit that sounds like a problem you could solve. Make a point to ask "why" more than you ask "what."
Understand that everything your customer wants and needs you to build is right there if you listen.
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."
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.
If you've had any conversation with me over the past few years surrounding products, it's likely that I've dragged out my soapbox and started to protest against his most famous quote:
If you are not embarrassed by the first version of your product, you've launched too late.
To me, this always seemed antithetical to what you'd want to accomplish. You want your products to be good...great, even.
Why would you want to be willingly embarrassed by what you create?
Accepting that you're not a genius
While it's frustrating to admit, my own stubbornness and self-assuredness left me blind to the point of this message for over a year.
The point isn't to encourage you to ship a piece of junk (arguably, any honest creator would be embarrassed to do that), it's about not being convinced of your own ideas.
As you delay your product's release, you stay stuck in your bubble. You start to convince yourself that what you see is what others will see. This is shockingly easy to do, especially when you have experience building things.
The difficult hurdle to get over is understanding that your product may...
Solve a problem
Work incredibly well
Be aesthetically gorgeous
...and still be a flop with customers. But why?!
Because the most important piece is missing: a group of people who actually want what you've built.
That underlying want is what you're building for, not solving a grab-bag of needs.
Hiten Shah's three questions
Want may seem like a very difficult thing to quantify, but it's incredibly simple: people want something if they're willing to trade the money they have in hand for the thing you're selling right now.
Coming down from the high of launching last week, I came across some videos from the wonderful folks at MicroConf.
Going to town on my well-earned launch sandwich, I watched this interview with Hiten Shah and Rob Walling:
About halfway through the interview, Hiten makes the point that you're trying to find a product that...
Customers will need to use highly frequently.
Solves a problem that's highly painful.
Solves a problem that is highly urgent.
Using this model as a filter, you can see why he chose the problem he did for his product FYI.
There's a subtle gap here: want vs need. Need is practical. Want is emotional.
This is what I overlooked with the first version of Command. I built the app to be the solution to a lot of different needs:
Managing work on your product
Creating knowledgebase articles and documentation
Sharing your changelog with customers
Now that I'm out of the fog of creation, I've quickly realized that I overshot.
These things are all perfectly valid needs, but there's not a lot of want here.
These are two responses I got from people who took a look at the product.
Pay close attention to the language here. "A lot of feature set" and "very full featured."
Those do not express a want. Roughly speaking, what you're going for is one of two responses to your product:
Wow! This would make my life a lot easier, take my money.
I know someone who would love this!
Not "wow, that looks like a lot of work."
I have to admit that this was all a bit disheartening, but not a surprise.
When I was starting to work on the marketing for Command, I quickly realized that I'd overlooked who would want the product. I was flat out struggling to communicate who the product was for, even though the features were tailored to a specific industry (people building products).
..they are so desperate for...uh...this, umm...for this kind of...I'm, I'm losing the word *sigh and awkward chuckle* control panel...or, um, dashboard! There we go, dashboard!
Do you hear those sirens going off, too? 🚨
Iterating as quickly as possible
Late Friday evening as I sat back in my chair, my head tilted upward at a sign I have taped to the wall above my desk: don't allow your ego to cause unnecessary mistakes.
In my head—and in conversations with others—I had already been preparing to take a short break on development and just focus on content marketing for a bit.
In that moment, though, I realized that I couldn't stop yet. I had to iterate. I couldn't just pacify myself and say "it's okay, they just don't get it!"
No, I quickly understood that if this was going to work, I have to find something that people actually want.
I pulled out my sketchbook and started to click through the app. I asked myself those three questions from Hiten "what here is painful, urgent, and frequent?"
As a whole? Nothing. In the parts, though, there was a lot of potential. The pieces were there. They just weren't organized in a way that was meaningful enough to encourage a want response.
Ironically, after spending some time over the weekend hacking the concept a bit further I got a second burst of energy.
I started to make connections that I hadn't throughout the entirety of the development process (read that with this tone of voice).
I saw what needed to be done.
Keep moving, quickly.
The moral of this story? It takes time to find the right thing and that's okay.
What you don't want to do is sit still and get stuck in sunk cost bias. It's far too easy to get emotional and say "but I've already spent so much time going in this direction!"
It doesn't matter. Consider it the cost of doing business; the cost of getting to the right thing. Instead of getting discouraged by not getting it on your first swing, you have to refocus and iterate.
About ten years ago, on any given day, at least a few hours a day were spent in some sort of fog—laughing with friends, eating munchies (much to my detriment), and generally wasting time.
One of the more organized rituals that inevitably led to a coughing fit was sitting in my best friend's driveway late at night. In his parents retired, dimly-lit Ford Windstar, my best friend and I would put on a record and hot box his van far past midnight.
"There are too many ways a man can go...one leads to money and the other leads to soul."
- Jim Morrison
One night, without explanation, The Doors: Backstage and Dangerous was put on, prefaced only by a coy smirk.
That little snippet of rambling by Jim Morrison has always stuck with me...one leads to money and the other leads to soul.
Whenever I've found myself on the edge of some major life decision involving money vs. doing what I wanted to do over the past decade, that lyric zips through my thoughts. "Money beats soul, every time." Debating with that beat as a sort of devil-on-the-shoulder, I've always nodded along and thought "don't do it for the money."
The Alternative Path
Admittedly, that sounds like pandering. I like money. Everybody likes money, no matter how holier-than-thou they might get on their Twitter account.
But it's true. That one line has impacted a surprising number of "go this way, or go that way" type of decisions in my adult life. Instead of cashing in, I decided to take the chance. Go with my gut. Give it a try.
Are there days where I regret that? Well, yeah, duh.
But fortunately, for the most part, I've managed to go unscathed. Looking back, each of those decisions—and don't be fooled, some were more difficult than others—has led to an opportunity. Each time I learned something. Each time I got better. Each time I saw the mistake that led to the unsatisfactory result and corrected it to achieve the inverse.
Throughout all of that, there's been one thread that really stuck with me: I've always wanted to build software.
The one thing I didn't know how to do, though, was make those interfaces actually work.
Back in 2010, desperate to bring an idea to life that I'd come up with while completing my final internship at a local television station (interestingly, an all-in-one tool for managing news broadcasts), I set out to find a developer to team up with.
Posting on an earlier version of the designer-meet-developer site Build it With Me, I got lucky and got a response from a high school student in Arizona. Within a few days of back and forth over email, we set up a Campfire chat and got to work.
Surprisingly enough, we kept up work on the idea for over a year. Eventually, my partner got busy with his first year at college, I got distracted by freelance work, and the idea fizzled.
I wasn't satisfied and was frustrated. I was eager to build something beyond a website. And I realized that I didn't want to have to depend on someone else to make it happen.
Eight years of mistakes and practice later
Within a few months of that project withering away, I remember sitting up late one night, procrastinating on some freelance work, watching a Ruby on Rails tutorial, eager to figure out how to build my own app. When that didn't work, I toiled with another course on Node.js for a few weeks; I was confused beyond belief.
It was all a no go. I struggled to understand how the pieces fit together.
I got discouraged. I went back to my bread-and-butter HTML and CSS, reluctantly making pseudo-dynamic websites with WordPress and sprinkles of jQuery (gasp!).
Eventually, though, I got lucky.
I'll never forget thinking "wow, this is exactly what I've been looking for!"
Blindly digging in, I had no idea that I'd be charting a course for the next eight years of my life.
An overwhelmed octopus
This is what I'd always wanted!
At that point, I was confident enough to take a swing at an entire app. For about four months starting in June of 2013, I put together an idea for a tool to help me manage my freelance projects, Proper.
For the first time, I was able to take an idea and bring it to life.
I felt invincible.
But then reality hit. After launching, while things worked, they didn't work well. Due to my lack of experience, the underlying code base was a mess. Working on the project became a chore.
One year after launch, not terribly excited by the idea and struggling to work on an improved version, I shut it down.
I realized that while the idea was good enough, my execution wasn't great. Even worse, that was the first big project I'd worked on by myself—I was exhausted.
Despite all of that, I decided that I'd had fun working on something beyond my usual freelance work.
Hard-pressed for another app idea, I decided to roll my effort invested in learning Meteor into a new site: The Meteor Chef.
A pretty good teacher
One of the problems that I had toward the end of Proper was figuring out how to export data. Despite my so-so execution, I'd managed to acquire 10 paying customers during the course of my first year.
As I was shutting down, I wanted to make sure they got access to their data (contracts, invoices, and project timelines that they'd created using Proper).
The problem was, there was no clear way to do it. No tutorials. No Stack Overflow posts. Nothing.
A little bit panicked, I scraped something together last minute—enough to make it so customers were able to download a ZIP with some .txt files with their data inside.
Scraping all of that together, I realized "hey, that was kind of fun." I'd really enjoyed the process of struggling my way to a working solution.
Eager to spin up a new project to replace Proper, I realized "I can teach people how to build their own stuff!"
And to my surprise, what had started out as a fluke at the end of 2014 grew into a happy accident. By 2016, The Meteor Chef had grown to see 100,000 page views and 25,000 active users per month. I felt like the king of the world.
Eventually, though, Meteor started to fade from popularity and it took The Meteor Chef along with it. Around the start of 2017, I'd realized that I needed to replace the income that I was getting from memberships.
At about the halfway point of The Meteor Chef, I'd also started offering 1-on-1 coaching sessions as, The Chef's Table.
Between membership subscriptions and these coaching sessions, I was able to pay the bills.
With an active roster of coaching clients, I started to think about a new business that could leverage what I'd learned.
Who doesn't like cartoon animals?
"You're not really going to call it Clever Beagle, are you?"
That reluctant text message came in about four weeks before I launched Clever Beagle: a spin-off of the coaching sessions I'd been doing for a couple of years at The Meteor Chef.
The idea was to formalize how I worked with clients, giving them a toolkit for building their own products and then coaching them step-by-step to build and ship their own software.
After a couple months of work, in June 2017, I launched.
I got lucky. Readers of The Meteor Chef found the idea compelling.
One person signed up. Then two. Then three.
Eventually, after about six months, I realized that I could run Clever Beagle full-time. I didn't have to supplement with freelance projects and contract work like I'd done while I was running The Meteor Chef.
Flash-forward three years and Clever Beagle has managed to become a six-figure business.
Too many things, too expensive, too confusing
Despite that initial success, though, the whole time running Clever Beagle, I've had the itch.
I wanted to build something of my own. I tried to build things that I could sell to customers at Clever Beagle (an ill-fated extensions library for the boilerplate I had built or courses to distill what I taught in my 1-on-1 sessions to others).
I enjoyed teaching others—and coincidentally, spending all day every day teaching others really helps to build your skill set—but I wanted to own something.
I wanted to apply what I was teaching others to my own app. I secretly felt guilty because I was teaching people how to build a software business without running my own.
While teaching others at Clever Beagle, I started to notice a trend. People were overwhelmed. As if learning how to make the code work wasn't bad enough, the idea of managing the product as a whole was too complex for one person.
"How do I organize and plan my work? How do I track user behavior? How do I..."
I quickly realized the problem: it's too much stuff and not enough structure. Having to think about and make decisions on all of these things simultaneously was a serious mental blocker. Despite my best efforts and encouragement, it was enough for some folks to give up entirely.
Curious and interested in building a product, I started to think. "Could I build a tool to help people manage their products and alleviate some of this stress? What does that involve? Is there a unique way to do all of this instead of creating another 'me too' product?"
As it turned out, yeah, there was.
Beyond just bringing all of those tools together, too, it worked out that having all of the data those tools generated side-by-side without the need for integrations would make for a pretty compelling product—especially for solopreneurs and small teams who were already overwhelmed.
Starting in December of 2018, I set out to take a crack at building it.
Why I'm bootstrapping my own SaaS and not putting my feet up at a cushy job
That brings us to today, and, for those loyal folks who have read this far, a why.
Why am I building Command?
Because eight years ago, I set out as a naive, ambitious computer geek eager to learn how to build his own software.
With consistent hard work, I was able to figure out how to do that.
I see now as the time to apply what I've learned, help others on a bigger scale, and take a swing at building the biggest business I've ever built.
I'm also interested in...
Making it more affordable and less stressful for small business owners to run their software without feeling like they're cutting corners (or doing less than they should). I want to give people the tools they need and deserve without making them feel like they need $1,000,000 in the bank or feeling like a cheapskate using eh tools.
Delegating! The past few years I was focused on ideas that were difficult to delegate because they were so dependent on me and my knowledge/experience. Delegating has always been a weak-point for me and I want to use Command as an opportunity to practice fixing that.
Focusing on one idea long-term. I don't see the need for managing a SaaS product being an idea that goes poof any time soon. Save for adapting to new platforms or delivery mechanisms, it's safe to say I can focus on this one problem without having to chase technology.
There's also another theme underlying all of this. It's not a secret that I'm a 🐢 and take my time working on things (from start-to-launch, I've invested nearly 18 months into Command).
I do that because I want to build things that are really great and really special. I want to produce a body of work that I can look back on proudly when I'm older.
Way back when I started, I came across this clip of Steve Jobs from 2007:
That idea captivated me. I didn't just want to rush things out and ship junk. I wanted to become a master, a craftsman. I wanted to get insanely great at designing and building software, no matter the cost or time.
Command represents an opportunity to uphold this idea in a way that I haven't been able to since I started down this path.
Will I succeed? Only time will tell.
I'll do everything in my power to make success a reality, but I'm not a fortune teller.
No, all I can go on is the same premise that got me this far.