#marketing

Always be launching

Wim • @wcools • • Part of Day 62

Every product has a number of major “launch moments”. For example, announcing the availability of a beta version. Or launching the full version to the public. Everyone working on web apps will be familiar with launch days on Product Hunt, Hacker News, and so on. Whatever industry your product is in, there will always be a small number of large publications, events or sites you want to be mentioned on.

While these launches are a great way to make some waves, they’re just one-time events. If they are super relevant for your audience, they might result in some initial customers. That’s a great boost after all the work preparing the product and the launch. The one-time spike in traffic, and even the long tail of traffic that will follow over the course of weeks or even months, is not going to define your success however. [1]

Rather than being a spark of a magical self-sustaining reaction, it might provide some lift and push you in the right direction. To keep going you need to keep “launching”. Don’t just work towards one big launch, but think about how you can get your product in front of some people all the time.

Other than large public launches, which take a lot of preparation and time (after all, your one and only shot needs to “perfect” right?), these “mini launches” don’t need to be a lot of work. A lot of small marketing activities can add up to a lot of impact. Especially when we’re in building mode, it’s easier to carve out just a little bit of time than to have to prepare for a big marketing push.

For example, a large chunk of our current beta waiting list for Thymer came from a few small comments we posted on forums. Taking a few minutes now and then to comment at the right place (where your audience could be) and time (a bit of luck, so looking for these opportunities more often helps) has more impact than a large “marketing project” would have had at this stage.

Example of a short comment we posted while looking for relevant discussions related to the product. Just a few minutes here and there to grow our launch list with a few dozen more people.

Another advantage is that it’s completely fine for these small launches to fail. You won’t really know for sure what works very well anyway, so if it’s small tasks there’s less reason to not try them and find out right away. It’s also a lot more motivating to do many more small launches while working on a product. Working on a new product for a long time without any feedback from users is risky but can also make the eventual launch feel more like a make-or-break event, even though it shouldn’t. In our case we also do lots of “mini-launches” showing the things we’re working on on Twitter. These are really fun to do for us and they result in new people seeing the product at the same time.

Besides, launching early and often also compounds your efforts. Every mini launch builds more audience, who in turn might share things you launch later, resulting in more people seeing what you’re doing. That also increases the chance you’ll be able to pull of the larger public
launches.

Another reason to keep repeating your marketing efforts is because most of the traffic or impact fades after a while. Even other channels like SEO, ads, and content marketing, which often sound like it’s a set-and-forget kind of thing, need some maintenance. Rankings will drop, content gets stale and ad keywords will become irrelevant (e.g. competitors start outbidding you). Again, that doesn’t have to mean a lot of work which will fill up your entire schedule, but it’s most effective and less time consuming to keep doing it consistently.

[1] Conversely, it’s good to remember that many of these launches have elements of a lottery or popularity contest, so not being able to “succeed” in a big public launch right from the start isn’t a reason your product isn’t successful. You’d be surprised how many #1 ProductHunt products no longer exist and how many #10 products do very well in their markets. Not every launch working out right away is another reason to always be launching of course.

Reduce

Wim • @wcools • • Part of Day 43

The number one priority right now is to get the first version of our product out as soon as possible.

One advantage of time or budget constraints is that it forces you to really think about what the focus should be of your product. Spending a bit of extra time at the beginning to think about how you can simplify the product and reduce the scope saves a lot of time in the long run. The “If I had more time, I would have written a shorter letter” quote is applicable to code, UI, product and marketing as well.

The most obvious way to ship faster is to build less.

Every line of code we’re adding to the product is code we might not have needed in the first place. Maybe certain ideas won’t work out and we need to scrap them later. Or maybe nobody cares about the product in the first place. If the product does take off, we need to maintain all of it. It’s much harder to remove features than it is to add them, in terms of keeping users happy.

This is not the time for premature optimization in our code or being architecture astronauts: we need to ship. That said, spending a bit of time sketching out what screens should roughly look like helps us identity places for re-use.

For example, one of the main components for Thymer will be the editor. On top of that, we also want people to be able to schedule their tasks. If we would dive right in without thinking these features through, we might end up building two completely separate controls for them. Looking at it more closely, they can actually be the same component. We simply might have to make some parts read-only, and date headings will be like headings in a doc, but dynamically generated. And instead of spending a lot of time on a preferences panel, we might just reuse the editor again to show a configuration file or sorts.

Simple products are better products.

Reducing the number of “concepts” doesn’t just reduce the number of components to build. It also makes it much easier for users to understand the product. When there are only one or two core concepts, it’s easy to get a good “mental model” of what the app is and how it works.

For example, many text editors in the past had several modes. Different options were available in different modes, like a view mode and an edit mode. Not only would you need to build both as a developer, but users had to understand the two concepts and deal with working with both. Larry Tesler worked on the idea that interfaces should be modeless (and famously drove around with a “NOMODES” license plate).

Both a good and a bad example of reducing UI concepts is Windows. The Start Menu, introduced with Windows 95, is absolutely brilliant in that sense. Even the most technophobic users only had to learn one concept: whenever you want to do something or you get lost, just click “Start”. Simple to build, simple to pitch, simple to understand.

Windows 8, by huge contrast was a complete mess. There’s a bunch of different start menus, with completely different styles. You had to learn all those concepts and they had to explain why it was better. Same for Settings vs Control panel (and there’s probably more). It takes more time to build, and just confuses the user.

The Home screen and Home button on iPhone is similar to the simple concept of the start menu. I notice how explaining how an Android phone works to a family member without too much tech experience is much more difficult than explaining how to navigate an iPhone. With iPhone you just explain they click one button at any time to get back. Onboarding is way faster with products introducing fewer concepts.

Simplifying the USP and marketing

As a bootstrapped startup, you won’t have the resources to be everything to everyone and outbuild your competitors. You also shouldn’t, because it’s easier to pitch a smaller product to a specific niche than selling large integrated solutions to everyone. You need to build more, need to explain more, need to onboard more, and need more buy-in from more decision makers.

Focusing on just a few core concepts is also important when thinking about your USP and describing why your app is better. Competing against another product which does “A, B and C” by building “A, B, C and D” is typically a bad idea, especially when bootstrapped. So rather than a mix of features and concepts, narrow things down to one simple concept you can describe in a sentence. A lot of marketing is about repeating yourself, and if there are dozens of concepts you need to explain, it waters downs the message about what makes your product worth trying.

Viral Loops

Wim • @wcools • • Part of Day 39

Getting new users for any new product is no easy task. There are endless channels to try: paid ads, search engine optimization and content marketing, integrations with other products, cold outreach, social media posts… the list goes on.

Of all those options, the holy grail is word-of-mouth marketing. When running a business, it’s hard to imagine something better than your customers recommending your product to others. You don’t need any pushy sales tactics (not everyone likes those!), users will trust recommendations from other people over your marketing material, and it scales really well!

Simply deciding “word of mouth” is going to be your strategy is a variation of build it and they will come, and is unlikely to work. Unfortunately there is no way of guaranteeing in advance whether people want to tell others about your service. But that doesn’t mean we shouldn’t try to increase the chances of that, especially if it’s relatively easy to do so we don’t need to give up other (marketing) work for it.

The low-hanging fruit when it comes to improving the chances someone will find your product by existing users sharing it, is to think about viral loops in the product. They’re called viral loops because using the product will cause users to share the product with others, which will then drive new users, and so on.

One example you’ll often see is a “Powered by X” link when you’re interacting with a widget on some website. Another classic example is the “Sent from my iPhone” signature under many of the emails you receive. Or even more basic, the email address itself. Back when nobody had heard of GMail, and you received an email from that domain, existing users were spreading the word for them.

And speaking of GMail, another simple tactic is to try to make the service invite-only at the beginning. The “artificial scarcity” of the invites makes it more interesting for people to share them and ask around who wants any, and makes it more interesting for others to ask around for them. As most of this happens online, it will bring in more users who see this, and get codes to share in turn. At the same time it allows you to slowly ramp up the launch, so you can process all the feedback and fix any initial glitches.

As Diederik wrote yesterday, it’s hard to get significant revenue from very small consumer accounts, and it might make more sense to keep it cheap or free for these users. One advantage of being able to have a free offering is that it might be possible to ask some social media exposure in return. For example, we could experiment with something like mentioning us in a tweet to get free access. Large B2B accounts aren’t going to do this, but word-of-mouth to find those in the first place is helpful too.

A specific features might also lend itself to create some sort of viral loop. To stay with the example of a tweet: for a previous product we tried a feature where you could interact with the app over Twitter. People saw those tweets scroll by in their timelines which drove more traffic to the app. Another feature we might consider is being able to make a part of your Thymer document public. That way people can share things like roadmaps or ideas with others, who will then also get to know Thymer that way.

Finally, it can help to add easter eggs or other fun components to your app which people might want to share. As we wrote about before, we think it’s important an MVP sparks joy in that respect.

Like many attempts to market a product, some of these can be very hit-or-miss. There’s no guarantee it will work, but if they’re easy to do and don’t cost much time, these viral loops are a good way to increase our luck surface in getting more traction with word-of-mouth.

Some landing page dos and don’ts

Wim • @wcools • • Part of Day 15

As I’m working on the first landing page version for Thymer, I thought I’d write a bit about some observations about what (not) to include.

The H1

The H1, i.e. the main title, named after the <h1> HTML element for a large title. This is the elevator pitch when you only have one floor to explain. You have 5 seconds to prevent someone from closing the browser tab. What are you doing?

You need to come up with a way to explain your product in just a few words. No need to cram all the details in one sentence, but just say what it is so someone who is in your target audience might care enough about it not to close their browser.

❌ Use fuzzy language, such as “We deliver results and synergize your business”. I have no idea what that even means. Generic things like “Work better together” or “Market faster” sound more specific (oh it’s about productivity or it’s about marketing!), but that still mostly works if you’re a big startup. Actually I’m quite sure it doesn’t work, but at a certain size it just doesn’t really matter any more what your H1 is. Be more specific than that.
✅ Use your own voice. Read the title out loud. If that sounds super awkward and you wouldn’t use that in a conversation to explain it to a friend, try picking something which sounds more… human.

A good call (to action)

The call to action or CTA is the main action you want the visitor of the page to take. Something like “start a trial” or “sign up for the mailing list”.

✅ Make it easy to find, and prevent too many distractions pointing the user somewhere else.
✅ Make it easy to do. If you just want to collect an email address for users who are interested in your product, don’t create a link “sign up” to a new page where users need to fill out a form. Add an input with a button next to it on the page and remove all the friction.
✅ Think about the simplest action you really need. If you want people to sign up for your service, don’t make it “Contact us”, let them try the service!

Answer concerns

Ideally you should answer any concerns a visitor/potential customer might have before they even have time to worry about it.

When you’ve bought something online (either a product or service) from a company you didn’t order with before, you have probably tried to do a bit of research about them. Can I trust them? Will they actually ship the product? Can I trust them with my data?

Don’t make people search for this. They will want to know the answer anyway, and if you don’t provide it, they’ll leave your site and search for it (and might not come back). Especially in a market which is as impersonal as software, it helps to know the faces behind the product.

Depending on the stage of your product, the questions users might have are different. The security features of your data center are not relevant when collecting email addresses for a prototype, but you need to include those details when you’re selling to larger companies. Think about the kind of person your visitor is. What are they thinking, what are their concerns? Answer them before they worry about it.

Bonus don’ts

Ending with a few don’ts which I’m personally not a fan of, so I’m trying to convince people to stop these 🙂

❌ Tracking! Nobody likes to be tracked. And thanks to GDPR and friends, tracking now also has a real cost (next to making your site slow!). You can simply collect some simple anonymized traffic statistics using privacy-first analytics services.
❌ Obsessive A/B testing. Related to the previous point, but if you don’t have large amounts of traffics, it’s just not needed. It won’t be statistically relevant.
❌ Cookie banners. Just make it stop! Luckily, if you don’t track, you don’t need them 🙂

Initial marketing plan

Wim • @wcools • • Part of Day 7

Now that we know what we’re going to build, we need a way to reach our initial target audience and find some first “fans” who are willing to try the product.

First we need to determine the target audience. Our app is going to be a very horizontal product, which can make it easier to grow (lots of potential users) but harder to start (it’s very general and we need to know how to reach the very first people to get started). Step one is to think of people who could be our initial fans.

As we wrote about here, we picked something we would use ourselves on purpose, so we know the problem and we can try to reach people like us. Let’s say we look for “busy people who create todo.txt files”. Makers/creatives/startups would fall in that category and are most like us, so easiest to find. Another niche category we can probably find online is people writing about things like productivity, GTD, journaling and so on.

We’ll start creating a list of places to find the audience. Some places we can look are:

  • Twitter
  • Subreddits
  • Forums
  • Discords
  • YouTube channels
  • ProductHunt

We can use good ol’ Google, Twitter search and tools like https://thehiveindex.com to find relevant pages. Once we know where to look, we can do a few things to get the word out:

  • Be helpful and answer questions people have to get followers. This is easy and fun, but slow.
  • Directly post what we’re working on and ask feedback (on some places this is actively encouraged, others you have to be careful not to come across as spammy).
  • Search for messages where people talk about the problem or related products in the space, and reply to ask a question, or if they would be interested in our idea (examples are Twitter threads, DMs on Reddit/Forums, etc.)

Especially the last two can feel awkward because it’s a cold outreach of sorts, and they have the biggest chance of resulting in negative reactions (rejection!), or no reaction at all. That’s all just part of the journey though, at some point you need to tell people you exist. Just a random example, look at how a tiny app called WhatsApp posted like this in 2009: https://www.flyertalk.com/forum/travel-technology/952359-thoughts-about-my-free-iphone-app-whatsapp.html

And of course in many cases feedback will also be very positive and people actually like to discover new cool things.

While finding all those users, we also need to tell them what we’re building and point somewhere to our product. For this we need to create a proper landing page. To get people excited about the product, we want the landing page to do a few things:

  • Explain what we’re building
  • Show a little demo video or nice screenshot (we’d let people demo the app if possible, but we don’t have an app yet)
  • Offer something like early access, a private beta or even accept pre-sales. Ask for a way to contact them so we can email them when we launch.

Sometimes a landing page can just be some text explaining what you’re doing. In case of our app, which is in a busy space, it’s probably necessary to showcase a bit of the app itself (like a compelling demo, to show how it sets itself apart from all the other products). To do this, we need to do a bit of prototyping over the coming days, and create a pre-MVP. We don’t need something people can use yet, but at least some sort of (design) mockup for a “screenshot” or video, to show the vision behind the idea.

In parallel, we’ll continue building everything in public and share our startup lessons. We would do this anyway of course as that’s the point of the 80daystartup, but there will also be some overlap with the target audience for the app, so this too might result in more users for our launch list.

We’ll then need to keep building to create the first minimum viable version of the product (focusing on the core features), while we keep posting, replying and doing “mini launches” up to the official launch day itself.

All of this is a very manual process at the beginning. The aim is to find ways to grow faster organically once we have some first initial fans.