How would you market a new app that's adaptable, like a web browser is?
Traditional product development says to know your customer, and what their problem is, and then create a product for them that solves that problem. But you don't get products like the web browser through that process, because the web browser isn't designed to solve any one problem. Instead it can help solve many problems.
So how would you market a product that's designed to be adapt to solving many problems?
There's one obvious answer: That when you launch your product, you focus on a single problem, and a single type of user. Which is what I've tried to do. There are some benefits to this approach, and it certainly makes some conversations easier. But it also has a negative effect, in that it ends up making the product seem less magical, and correspondingly it's harder to tap into my own enthusiasm when I'm so focused on one use case.
Is there a better approach to marketing a product that's designed to be adaptable like a web browser than focusing on one use case?
There always needs to be a concise need you are meeting and a narrow segment that will likely be your first adopters. The real secret is that your product call to action SHOULD change over time as you grow and grab more market share.
For your web browser example you could say first Lynx came along with a message something like "the best tool for exploring the HTTP protocol" and it was text-only and targeted hardcore Internet pioneers. Then Mosaic came with something new and a new selling point: Page structure and inline images! Everyone saw the value of seeing images so they jumped ship. Then Netscape advanced Mosaic and brought newer standards, Javascript, etc. Then IE waltzed in and their message was "we are Microsoft, we are already on your computer, we are the standard by default" and they used their market power to scoop up all newcomers who might not even know how to install a program (nice angle if you can work it). But the game wasn't over because Chrome then came out with "way faster page rendering".
It is worth noting at this point in the game Chrome was a big deal and backed by Google, but adoption came first from power users and developers. They were the clear target audience, with a focus on better developer tools and really pushing the speed and lightweight nature of the browser. Normal users wouldn't bother learning about Chrome or switch unless forced to, until they built up market share and undermined IE over time. Even now there are new angles like the Brave browser that focuses on privacy and leans hard against other browsers for being tied to advertising streams.
Now the Brave browser might have lots of neat widgets and features but none of that gets mentioned outside of their One Big Differentiator of privacy. First, you pick your one feature to push and you hold onto it like a pitbull. You have to pick just one and stick with it... until the landscape changes you adapt your message, but there can only ever be one message, as frustrating as that seems. And it is important to focus efforts on advancing that one feature as hard as you can (like Chrome did) because it is the only way to get mindshare and have a clear value proposition.
Never underestimate the power of inertia. You really need to not just be 10 or 20% better than a competing product, you need to be 100% better on one thing and drive a stake in the ground around it. If you can do that, people will be forgiving about the features you don't have yet.
Great answer, thanks for writing this. I'm going to have to think more about this.
If you don't mind bringing specifics in, the product I've made is like a browser but with special features for developers. The way I've chosen to market it so far is "the web browser for developers that always refreshes". Which focuses on one single problem: That developers currently constantly switch back and forth between their text editor and browser to review their changes.
But that's not actually the product I've built, the product is really "an extensible web browser for developers", automatic refreshing is just one use case of the technology.
But there's lots of other problems this can solve, and that's where I get into trouble: How specifically it helps is different for every type of developer. Just like developers are all using different features in their text editors and terminals, e.g., everyone uses different plugins and CLI software based on the type of developer they are. The biggest feature of terminals and text editors is that they're customizable to solve lots of different problems.
So my dilemma is I don't know if I should double down on marketing based on one use case: Always refreshing. Which seems like it fits the traditional approach to marketing better. Or do I market it as "an extensible web browser for developers" and deal with the problem that every kind of developer would use that extensibility to solve different problems? Noting that the second approach is more exciting to me, but I don't mind doing the first if that's more likely to be successful.
I think your post points to continuing to focus on refreshing, and then adapt as time goes on? But I guess I'm not 100% sure, e.g., can extensibility/customizability be a "one thing" in and of itself?
Hey @robenkleene I've been doing a lot of thinking about your value prop and I've decided your current approach is not working 🙂 lemme explain.
So, I had a look around your website and honestly I still don't know what it is you've built, and I'm an engineer obviously. AND I don't think the niche idea of a use case helps, as in, the server plugin for refreshing. You're right, that's not really want you've built, and to be honest the sell for that one feature isn't strong enough.
I was think about what would be anologues to your offering... And the things that came to mind we're GitHub actions and IFTTT.com. think about it, they are tools that allow endless benefits of infinite variation.
Now, you might think, no, actually the anologues products are browsers and code editors. But I disagree because people know exactly what browsers and code editors are, so your job is tougher, because you to sell a new idea.
But going back to ifttt and GitHub actions. I'd start exploring how those products/features position themselves, and in particular, what ULTIMATE problem are they solving? Ifttt isn't diving the problem that is hard to get tweets into your inbox (that's a recipe or whatever). It's solving the problem that non developers can't create complex integrations without developers. And now they can.
So, your repla server isn't the problem you're solving. So what is?
I can have a guess based on your website, but I still don't know. And actually I should know clearly from your value prop. Here are some possibilities:
Repla: a programmable browser for developers
But what's the diff between that and current browsers with dev tools etc?
Or
Repla: editor, terminal, browser in one?
Or
Repla: a terminal but rendered with html
Honestly, I don't know, but, what is the core problem you're solving? Because extensions exist for Chrome right? So, what is it?
That it's hard to write powerful extensions?
That it's hard to extend current browsers?
That... I don't know. What problem is it that I as a developer have right now that repla will solve?
That is the problem, and the niche are a focused niche of programmers that would like that. Maybe developers who love writing extensions. Maybe developers who are unhappy with current editors. Maybe junior Devs, maybe senior Devs etc
Hope that helps!
Wow, @thatandyrose thanks for writing this, this really helpful! There are a couple of takeaways I took from this right away, that I'll start with:
Let see if I can also address the browser extension thing here, since that's a big source of confusion: The difference is that Repla plugins can run processes and access the file system, whereas browser extensions cannot. Browsers are generally design to protect you from the websites your visiting, so accessing the file system and other programs you have installed is a big no-no. Since Repla is designed to access the websites you're developing locally, it doesn't need the same type of security as a traditional web browser, so therefore can use a different extension model. This is why I've taken to calling Repla a "web development browser", for lack of a better term. (UPDATE: I think I should clarify this a bit to note that while Chrome extensions can't access the file system, the Chrome browser itself does have some limited access to the file system, e.g., via
file:URLs and relatively referenced resources, and extensions can piggyback a bit on this, so there is a sliver of shared use cases between Repla/Chrome Extensions.)Great question. I'm in a similar boat... I think the "less magical" bit is really a great way to put it. I'd love to hear if anyone has feedback on this!
Glad I'm not the only one! I'd love to hear what you're building if you have anything to share. This is what I'm working on: https://repla.app/ There's more details about how I'm approaching this particular problem on the blog: https://blog.repla.app/
Hey @robenkleene just replied above about your project 🙂 also read your blog post!
In terms of my project, nothing to share yet, still trying to nail the value prop. It's a chart as a service that automatically creates analytics for timeseries data. The difficulty is it's really useful for non technical people BUT also developers who want to quickly generate dashboard etc to analyse time series data. So that's my sticking point at the moment.... It's that think where the ease of useful for a variety of scenarios.
Not like your product at all but done overlap in the difficulty with presenting the value prop
Sounds awesome. When you have something to share, please feel free to contact me either here or through my website. I'd be delighted to return the favor of giving feedback!