I’ll be honest. I hate data. Parsing it, collecting it, strategizing around it–I just want to build things the way I feel like building things. Instinct has gotten me up to here, hasn’t it? And while I haven’t fully made the switch to a hard-core data kind of mindset, I have realized its importance in some areas, especially if you’re a new company.
One of the most dangerous things you can do starting out on a new app or product is changing it too much, especially when you’re not sure where your product stands. The most creeping temptation will always be “I should change the homepage. Or screenshots, or description, or tags, etc. Essentially, your first instinct will be to think, “this is not going as I expected. Perhaps I should change something about the first thing users see?”
This is a devilish temptation that I’ll address in another post. But assuming you’ve decided to make a drastic change, please take this warning: gather as much data as you possibly can before doing so. You’ll hate yourself if you don’t.
Anyone who’s created an app or project of their own knows the feeling of changing something as one last final act of hope, only for absolutely nothing to happen. In fact, changing something because you’re not sure what else to do is the quickest way to murder your project. Because if you put all your hopes in a homepage redesign, spend a month doing the work, and launch to crickets, you’re going to be left saying, “Well shit. Now what? You’ll be so discouraged that you’ll most likely quit. This was the fate of several of my past projects.
Instinct can help you come up with ideas and goals, but it will leave you stranded when it comes to validating your changes. Ugh that word. Validating. Makes me uncomfortable just thinking about it. But it can be important, especially if you’re long-term serious about your project.
This sort of advice is extremely obvious to anyone that operates a wildly successful company. But if like me you’re just someone who’s passionate about creating useful products, and are still hopelessly optimistic about the “if you build it, they will come mindset, it can be difficult to adopt.
If you’re wanting to change your homepage design, make sure you collect as much data as possible about current homepage metrics. Visits, time on page, drop off points, heat maps, and whatever fancy new landing page analytics exist today. After you make the change, you’re going to want to monitor these metrics as closely as possible to look for any improvements or deteriorations. If you don’t collect these metrics before hand, and launch a redesign based on instinct, your morale will quickly suffer if the changes have no apparent effect. And to be honest, a homepage redesign is hardly ever the real culprit for the problem you’re having. Having data can help you realize this.
Most importantly, give your product some quality alone time without bothering it. If you make a change, let it sit for a couple months before being tempted to change something again.
And in general, don’t change things too often. You’ll confuse yourself and find yourself spinning. It’s very rare that a single change will dramatically alter your results. If you depend on changing surface elements of your product or company to improve your results, you’ll be left completely deprived of will and motivation to try other things. And odds are, the fix to the problem you’re having is somewhere in the pile of “other things which you’ll tragically never get to.
I try to write frequently on the topic of building a business as a developer, and other random musings. You can follow along on Twitter.
Top comments (7)
Is this in response to our home page tweaks or is that a coincidence?
Haha totally a coincidence. Actually I was just admiring your new sidebar. So beautiful!—I just want to keep looking at it.
Also, the title really should be "Stop changing your homepage when you're not sure what else to do," but that's kind of long ;) Improving your homepage, however, is something that should constantly be done.
Hehe 🙌
Definitely feel you on all this. We have a few more design tweaks on the way but we're really trying to approach this from first principles. Superfluous change is not the goal.
I've thoroughly enjoyed the principled growth of dev.to. Horizontal development vs. vertical development. It's not easy to do. There's a time and place for vertical development, where you go all in on one feature. But potentially the best investment is horizontally developing the entire ecosystem.
I always get a kick out of reading about your philosophies on the craft, Mo. Can you expand on what you mean by "Horizontal development vs. vertical development"
Horizontal and vertical are definitely terms I use a lot when waxing philosophical about software and business, but there's a million ways to use these terms, I'd love to know what you mean by this.
I guess by that I mean, vertical development would be, for example, having the greatest iOS app the world has ever seen, but having a poor website, customer support, marketing, and everything else. A lot of people go all in on making 1 thing really really good, but neglect the other aspects. Horizontal development means you'll have a living iOS app that isn't the best in the world, but is constantly being updated while you also build up other aspects of the business.
So, for me, there's a time for vertical development, like where I spent over a month just hardcore focused on the new iOS app. After that, I'll balance out the rest of the platform and focus on other areas.
I like to visualize it as laying out blocks. You can stack one pile really high, but that's not really a foundation. Instead, laying them out horizontally, then building up vertically at a balanced pace, and you'll have yourself a nice building ;)