This story is a data point that proves that it's possible, not that this gives you a better (or even good) chance at succeeding. Hell, I would wager that greater exposure would have led to much higher sales.
The lack of pressure and the slow cultivation was something that struck me in this article, as opposed to the stereotypical rush of the startup lifecycle.
Sure if you arent sure about your product and havent done any market tests, a minimum viable product is fine.
However, I had/have a service that was already popular and my circle of friends were obsessed with MVP and Lean Startup. They pressured me and when I began mainstream marketing the response was that my service was low quality.
Those people were wrong, but minimal HTML/css bugs was all it took for people to question me.
It's very, very easy to just keep working on things indefinitely, never quite being perfect - a backlog that adds two new items for every one you finish. And the longer you work on something, the more pressure there is for it to be "perfect" at launch. Additionally, if in all this time, you're not getting feedback - you may be developing something that is not quite what people want. Feedback is crucial, and launching your project is a surefire way to get real, useful feedback.
Getting something out there is half the battle for a lot of people. Myself included. It's a very large psychological barrier to launching something. And the more work you put in, the larger that barrier grows - which is paradoxical sounding, but true. With a smaller, proof-of-concept launch, you can change your product direction more easily - if it turns out the feedback isn't great. With a larger more polished product, you have already invested so much into the current direction. There's momentum and emotional attachment (for people like me, that is) which makes it unwise to proceed like that.
But if you don't suffer from these problems of seeking false perfection before launch, and you get feedback throughout development from non-launch sources - you don't need to subscribe to the "lean" mentality.
The lean startup mentality was fundamentally a product of the era of entrepreneurship that birthed it, and the market environment for software.
About 10-15 years ago the web was clearly here to stay and maturing, but literally huge problem spaces had been very lightly explored with software. So it made sense to do something, anything, to solve a problem that software was good at, because the alternative was almost always a legacy approach. Which means even an MVP was likely useful for customers. The only real danger was moving too slow.
It's the equivalent of buying up residential real estate in Brooklyn or San Francisco 20 years ago. Or whatever metaphor you prefer, where a market is growing so quickly that nearly all entrants have the ability to thrive if they are at least somewhat aligned with a consumer problem and willingness to pay.
Thing are different now. There's a software solution for almost everything, maybe not a great one but there's something out there. People are overwhelmed and exhausted by their options, have subscription fatigue, and likely have the experience of adopting a fledgling poorly supported MVP type solution that didn't live very long and regretting it.
People are pretty much the same. But the market environment has shifted.
Nobody gives a fuck about your landing page with two sentences and an email capture box any more. The world has moved on from this model.
Good thing the lean startup was never about this.
The lean startup movement actually grew out of the work by Steve Blank, best summarized in the (unfortunately titled) book 4 Steps to the Epiphany. Eric Ries basically made it more accessible and catchier-sounding, but a LOT of the ideas from that movement are things we take for granted today in the startup world. They didn’t stop working, they just became the default instead of a new way of doing things.
The whole smoke test thing where you setup a shitty landing page and collect emails as validation is more from Tim Ferriss and The 4 Hour Work Week.
Oh, and for the record, it still works. Look at presales, Kickstarter, etc. Same idea: demand validation.
Finally, I reject your idea that everything that people want and need has been built and we’re all just bored and fatigued. Doesn’t match my experience as a business owner, consultant, or consumer. There’s more opportunity for innovation than ever before.
Any pivoting in the business strategy means you don't know your business space. Business opportunities and the required value-add features should be painfully obvious if you have experience and know the industry/niche.
The lean startup approach doesn't advocate spending a lot of marketing dollars showing people your MVP. It advocates being, well, lean, until you have a good reason to believe that you have "product/market fit". It's then that you crank up the marketing/promotion stuff.
After all, wouldn't it be a disaster to spend a lot of expensive marketing dollars showing people a product that they don't want or need?
EDIT: i guess my point is, engineering isn't cheap either. Shouldn't be OK spending that money ahead of product fit either.
The whole point of the lean startup approach is to posit that the "business school approach" is wrong, exactly because you don't know all this stuff ahead of time, and that "business plans" are an outdated idea.
And if what you're doing is a truly novel product, then you almost certainly don't. If you're using the "fast follower" strategy to be the nth company doing a product in a certain space, then sure.
OTOH, even Steve Blank says that there are certain areas where you don't need to do Customer Discovery / Customer Development... like, if you're creating a cure for cancer, it's pretty much all engineering. If you build it (and it works) they will come. But I think that kind of scenario is the exception, not the rule.
A startup is "an organization dedicated to creating something new under conditions of extreme uncertainty" (quoting the insider cover of Eric Reis's The Lean Startup). If there isn't extreme uncertainty, then it isn't a great fit as an overall strategy.
On the other hand, the LS counterpoint would be that you'll miss considerable insights if you rely on existing knowledge/research (Ford's classic "If I asked people what they wanted, they would have asked for a faster horse" quote....)
“The Marimba Phenomenon is very hard to avoid when you spend too much money trying to launch a new product. It’s easy to spend on marketing and PR, since that just takes cash, but it’s hard to spend on software development, because that actually takes time and talent.”
“By contrast, small companies that don’t have great marketing budgets are in a great position to launch early and often.”
Some friends exist just to give us bad advice. There are problems with Lean Startup, but this feels more like "people that don't understand a thing, giving advice about that thing."
Are you saying you should have waited until it had more robust features? Seems like the chances of bugs would go dramatically up.
The point of MVP is to avoid wasting time and resources on ideas that will never get enough traction to be worth it. (Even the best market research can be disastrously wrong.) Lean startups don’t plan to launch a marketing campaign for a half-done product.
Agree on your point about ads though
– Title: “How I’ve Attracted The First 500 Paid Users[...]”.
– “TL;DR” section of the article: “You Don’t Have To Get Covered on Large Blogs” and “Ignore All Competitors” .
Also, it's a 'they' used as a gender-neutral singular.
> "On the private beta launch, I posted a link to Hacker News and it fortunately got covered on the top page and it resulted in over 1,000 beta entries. Beta users gave me lots of suggestions and bug reports and they helped me evolve the app to be ready for the official release."
I enjoyed this article, but this bit I'm not entirely convinced by. The saying does go that competition leads to innovation. Instagram Stories were a great business move, but if they hadn't paid attention to Snapchat, would they have come up with it?
I understand that this article was written about a niche product, but I think it still applies.
On the other hand, I really like the bit about the communication with your customer-base. In game development particular, but also in all sorts of software I use, I see so many developers who don't interact with customers or improve their product based on feedback.
Customer feedback for users that aren't enterprise has to be the ultimate form of support. If I can provide the same service as a competitor to you, but I'll listen to your feedback, respond to it, and potentially act on it, I think I have a big advantage.
There's a big difference between large established players and new startups. Established players can't just grow, they need to protect what they have so that their base doesn't drop out from underneath them. New startups are default-dead and don't have anything to protect yet.
Furthermore: oftentimes, big players offer customers a boatload of features, and most customers don't use nearly all of those features. If you mindlessly copy features, then you aren't paying attention to whether those are the features your small but developing customer base actually wants. The only way to know what features your customers actually care about is to talk to your customers.
The advice to ignore competitors and focus on customer feedback is great when you're small and a solo Dev. As the company grows and you can dedicate other resources, you can start monitoring and selectively copying competitors. I'd still say that internal iteration is a better path though.
Follow them and know what they are doing. But do not adjust your plan easily for just what your competitors are doing.
e.g. A competitor may have launched a bunch of new features that nobody needs or uses. You follow what they do to compete. You then focus on things that don't work when actually, all competitor's customers buy the service for a few core features that they don't shout about, or aren't actually improving (mistakenly).
You can be better at listening to competitors' own customers then they do.
For my app, I have hundreds of feature requests, and for 95% of them all I can say is, that's a nice idea, but I don't have time to do it.
For the remaining 5% it'll take me a year or longer to implement them.
For customers this looks like I'm unresponsive.
When I started out, I often added features in a few days, and customers were thrilled, but that low-hanging fruit is mostly gone now.
I do, however, think you need to balance big featured with quick wins that make a subset of your clients significantly more happy.
If I share a public roadmap, and then I don't deliver, people will be disappointed.
So I've started to only tell people about new features once they are stable enough for testing.
I don't want to build up expectations when I'm not sure when/if I can deliver.
I agree. Your public roadmap should be conservative, or more oriented towards the type of impact you will be making. The intent of a roadmap is to communicate your focus so that folks outside know the general theme. You then have something to reference in conversations later when someone asks for something that doesn't fit with the theme.
Personally I have found any type of feature and expectation discussion easier in person or on a call. I expect feedback over the internet to be poorly phrased or hostile. Expectations break down if you have any type of sales team who are prepared to offer features to close deals.
It looks like you make a database management app for the Mac. If I was creating a theme-based roadmap I might choose a theme like "SQL Console Improvements". You can explain that your focus is on that area of the product, but that your focus may change in the future. When you get close to being certain a feature within the theme will be developed then publish that information. You can operate multiple themes depending on resources.
This approach can also work for feedback. You can let users know that the next theme on deck is "Optimization Tools" ask for feedback on how users want to improve their SQL queries. Then when you start executing on the theme you have collected feedback that can be incorporated. The flow makes users feel involved in the process. Actually summarizing the feedback in public can be a useful community exercise for expectation setting when everyone thinks they have the most important idea.
Google MUST be worried for Apple. Because them are figthing for big amount of users.
But when you are solo, or a small team, and your goal/real chance is have a small number of customers, what other do is close to irrelevant.
You will find a lot of competition and your idea will be already in the open for long time. But that is not important. As long you care for your small(ish) customer base you will be ok.
Is like sell hamburgers in the street. The street seller not need to worry at all with Mc-Donald. IF have a tasty product and can provide a better service, it will be ok
And you can provide that only if you’re focused on present customers.
Took me a very long time to understand this ... PG mentions this as a big failure mode :-/
So my philosophy is to be aware of the competition but listen to my customers and the industry.
Instagram stories - examples like this are where I struggle. At least they copied it fairly well if that's the case :)
What do you do? go after your competitor's 500 customers, many of which are only going to consider switching if their product lets them down or go after the other 10,000 potential customers that don't use either product?
Surely the users of onavo would be self selecting into low economic groups, not indicative of the full population?
Maybe "ignore competitors" is the former.
Example: "carbs are bad" is directionaly true but not universally so (at least I would posit it is directionaly true for the modern American diet)
Spending time on user forums is a poor use of a developer-founder's time. You're better off adding features and focusing on promotion and offloading the rest to a cheap support guy
I completely disagree. You get to know your core userbase and what their pain points are. When you're in charge of development and sales and marketing and everything related to your product, you really need to know what you're doing and why. Being in touch with your users helps with that.
>We would like to provide good, quick and warm user support. If we got a lot of users, we won't be able to support them all.
Frankly admitting that they want to pace user growth for better quality service is both brutally honest, and enticing.
I hope more bootstrapped SaaS companies achieve this equilibrium where pricing is premium, growth is paced, and quality is high.
According to the first graph, it's $30,000 in total sales over the last 2 years which forced him to continue freelancing as his main income. This post is basically announcing ramen profitability. (Of course it's still a great achievement to turn any profit on a side project, let alone supplant his main income)
I have been in the market for a new term, for what to say to people what my goal is with my side projects. Up until now I have been saying, it's not making much, it's all supposed to be for some "beer money"...
Welp. I stopped drinking.
Now I can call it ramen money instead. Cool!
(I do dropshipping of computer hardware, specializing in computerchips). And currently building an OS-disk to the enthusiast-market for Apple G5 workstations (yes, it's a hyper niche, and will only cover my ramens) :)
If you have some basic notion of running a business, you probably won't find much in the way of revelations there. (Some of this is the "Seinfeld is Unfunny" effect, because the better advice you'll find in his blog is now common knowledge, but more is that running a tech business is still running a business.) If you aren't familiar with running a business I can see it being a useful naming-of-parts exercise, though.
1. 100% agree with ignoring competitors unless you’re in a field with heavy network effects. Most niches can have many successful companies, and worrying about your competition will add a lot of stress and encourage you to build things your users don’t care much about. Listen to your customers!
2. Churn is probably low partly because the pricing is low. I charge 10x - 20x this much and my post-trial churn is more like 10% (working on reducing). People are a lot more motivated to cancel if it’s costing them $1000 per year.
3. I should really, really do the support forum thing.
4. Strongly disagree on roadmaps. There are much better ways to make people feel like the service is alive and maintained enough to feel comfortable signing up. I can’t tell you how many times I’ve added unnecessary guilt and stress to my life by promising some future feature to users and then priorities or timing changed. Stupid to put yourself in a box like that for no reason.
I've built more than a couple of product prototypes equivalent to the size of this app and ended up with the questions "what is the USP other than cheaper pricing? what is your marketing budget?" - And was discouraged to a point where I never did launch the product to acquire paid users. And did launch it for free and has decent number of users. But it is not fun working on a product that does not pay.
This is so fresh and encouraging advice here. Even if it was paying me just half of my freelance pay for a decent period - I would call it a success.
And losing all momentum on launch.
People have been spoiled by large companies releasing apps that costs tens of thousands/hundreds of thousands to develop. And have huge server and maintenance costs for free(lets just say you don't pay with money..)
I would put first and foremost how to make a note the very very first thing(and only) thing when I open the app.
I don't want to see ALL the apps features.. I just want to first see how the ONE THING i need this app todo. Make a note :)
Just my 2cents ! Congrats again on having a successful app
Many of the tidbits are the exact opposite of advice for startups that are trying to maximize value.
While these tidbits could minimize startup revenue, they don't minimize "value provided to customers". And it's good advice for anyone who wants to provide a valuable service or technology at a good price.
Some folks want to build a company with the most users. Some folks want to maximize revenue. Some folks want to maximize profit.
An entirely different segment of service providers wants to maximize the value they provide their customers.
It seemed to me that most of the advice is pretty in-line with that given to value-maximizing startups.
If you have the time, would you mind elaborating a bit more on the following? I'm always curious (as an American living in Japan) about small/independent developers who split across two or more cultures.
1. How much of your userbase is Japanese vs English-speaking?
2. Do you find that the goals the users work toward are different based on the language/culture? Are there any things that are language-specific?
3. Do you find that one set of users is stickier than the other?
2. Since my app target is developers, their goals look basically same. But some users are designers, directors, etc. Japanese tend to tweet their thoughts on Twitter and English speakers tend to post their thoughts on our forum or to email me. In a nutshell, Japanese make indirect reactions on social media and English speakers tell me directly.
3. Those who have too many suggestions usually quit using my app soon in my experience because their problems are different from mine. You don't have to please everyone.
> 3. Those who have too many suggestions usually quit using my app soon in my experience because their problems are different from mine. You don't have to please everyone.
I'm sorry, I phrased my question a bit unclearly. "sticky" for me means "easy to retain." So I was wondering, do you have a better retention rate among Japanese users, English users, or is it about the same?
I have been following your development blog for some time (v3), I agree with your priorities in better image support and tables. I made a similar plugin with image resizing support on a different notetaking application, using a jquery slider. I use it everyday. It might be of interest to you. http://vincentmtang.com/2018/06/29/adventures-in-writing-a-t.... The implementation I made is significantly less maintenance too, setting image sizes per image upload is time consuming IMO. It uses a `max-height` and `max-width` property initialization you set, and goes up from there. It is (3) on your blog. It does make it difficult to make responsive image size between devices, but you could always let the user define custom media queries in settings and set a `max-width` or `max-height` property for mobile devices. It really depends on information density of images.
I'm refreshingly surprised that in 2018 it is still possible to make money with a subscription-based Markdown editor. Why would I ever shell out 60 bucks a year if I can pick one of the plethoras of good editors (free or one-time purchase, I use iaWriter for example) and then just sync for free using Dropbox or whatever (and have it encrypted on top of that if I want)? I paid ~30 and I own the editor and have control over my data.
And then there's already established competition, e.g Ulysses.
Kudos on the success, it can only be good news for anyone trying to run a saas.
- It's arguably the only Markdown editor dedicated to note keeping that looks even remotely modern on Ubuntu.
- Its mobile support is decent and gets the job done.
- The developer is very responsive. I can't contribute to the code directly, but my name has appeared on a changelog multiple times because I suggested features / reported problems. Unlike an open source project, this one has a person dedicated to it full time whose goal is to keep me happy as a subscriber. Issues I raise don't tend to be open for months or years with no end, they tend to be fixed within a month or so.
- Its plugins are easy to install. Similarly to Atom, I'm only "ipm install <plugin>" away from having a plugin.
- I find GTD features (notebooks, tags, to-do lists) to be nice to have, even though I don't rely on them extensively.
- I can create a public link for a note and share it with whoever.
- In case shit hits the fan, you can back up the data to a local folder and sync it using whatever.
If I was relying on macOS or Windows, I would have probably found something else.
Standard Notes, as the only decent competitor, is out of the question for me since I would have to use a third-party cloud instead of my own Nextcloud install for the backups.
Main con I could think of: I manually have to download deb packages with every update like I'm some sort of a Windows user.
In fact, here's a note I've created a year ago comparing the various options that were at my disposal a year ago when I was making this decision: https://community.inkdrop.info/note/f607a6970af9e4b40795ec5b...
As an aside, for my dev diary (stored on a cloud file system ) I write markdown in Vim, I used to want to see it rendered and played around with visual editors, but I like vim style editing so I just deal with it in text form with syntax highlighting and that's plenty good enough for me.
> You still have to pay for github if you want it to be private
You can upload to a Gist and set it private
For both of these I like that its just markdown files that I can export if I decide to use something else.
Edit: there is a plugin for vim keybindings, and a solarized light theme. I am sold!
* When the next version will be released (specific date, not just bullshit stuff like "Q1 2019")
* What new features it will have
If I can't find anything like this, I'm less likely to sign up.
1) I don't want to pay in perpetuity for the software you have built. It's unfair. (yes, even if you're a single developer and probably a very nice guy).
2) I'm ok to pay for cloud storage, but I want to be able to opt-in and opt-out whenever I want.
Almost all software is a subscription now, and this is ruining a lot of things IMHO.
I agree with this statement,because as a small developer if you compare you and your product with big companies you will get lost in a short span of time."Good customer support will differentiate you from the big players" is one more great point in your article.
It's the markup format on Github, on Stack Overflow, and for many other sites and tools.
Seriously, part of the cost of running a service is your own income - don’t discount the value of your own labour
It isn't necessarily wrong, just potentially confusing if you read it the wrong way.
I'm sure that one reason why there aren't as many now is that lots of low hanging fruits for niche tech/online/mobile businesses have already been picked, as many people write from time to time, but I also think another reason is that the stories of hypergrowth and unicorns have raised expectations and standards too much. Incredibly high salaries for engineers in SV helped there too (what? 30k? that's nothing...).
But let's not forget that trying to win the big lottery is going to make most people miserable. Creating a sustainable online business - something like what 37signals promotes, or even just a lifestyle one - can be a perfectly legitimate goal, something we should celebrate more IMHO. And the world is still full of niches which can greatly benefit from the thoughtful application of technology and sustain that kind of businesses.
EDIT: clarified language
Yeah, you're in your first year. Of course churn rate is low.