You may need to try shipping 10 to 30 products for 1 to 3 years before you have anything that works. That's how this approach works. You build stuff and see what sticks.
Startups, and life, are about constantly pivoting when things don't work out. If you don't take action though, you can be sure nothing will ever happen. Stagnancy kills. So ship. Always keep shipping.
The most important thing is to find ideas from solving your own problems. You do that by looking at your own life and observing what your daily challenges are.
You are the greatest expert at your own problems.
Once you have traction and your website, app or startup works, you can learn from user feedback and data you collect then. But that's useful once you're already running. It won't help you find ideas that are suitable for you to execute.
Be more original, and your ideas will be original.
Always start from the problem, not the solution.
To get big, you have to start small.
Niches are a great start because they're usually too small in economic value for big companies to attend to. They're also the perfect size to market a new company towards.
Your idea does not have to be earth-shattering.
You don't know what you're going to end up with. You need constant feedback from your users in the markets to see what people want and what people use and whatnot. You can't just think of that. You can't think big immediately. You have to start small.
Collaborations can be very dangerous. Because if you work with somebody else in a team, there's a big tendency of groupthink, where everyone starts hyping each other on the value of the idea.
Avoid groupthink. You're more rational on your own.
You can't ask "will this idea work". You need to ask the market by building it! Nobody knows until you launch!
Don't be afraid to share your ideas.
"Ideas are worth nothing unless executed. They are just a multiplier." - Derek Sivers
Idea * Execution = Business
The point of sharing your idea is thus not to get people loving it or hating it. The point is that you get your brain working outside of its comfort zone (of talking to itself) and you'll evolve your idea. You'll come up with adaptations of your idea, or entirely new ideas by talking about it.
The faster you get it out, the faster you'll see if people want to use it, how they use it and what other features they want to see you build. Without shipping, it's difficult to get any idea of what they want.
Build fast and minimal.
Users finally accept minimal interfaces and minimal functionality, as long as an app does what it says well.
Your enemy is perfection.
Perfectionism is detrimental because 9 out of 10 times it doesn't make things better but just creates inaction.
Avoiding perfectionism is a skill you have to develop. You need to learn to be fine with everything being not fine.
The core functionality should be operational. Minimum needs to be minimum good.
Making a minimum viable product means it has to be viable, it's not an excuse to be lazy and make something half-assed.
Build yourself or outsource
Doing everything yourself in the longterm probably doesn't work. If you've proven a business model, it's probably smart to keep repeating it (by scaling it up), getting people to work FOR you, with you managing the operations instead of micromanaging and fixing tiny bugs. But that's not what this book is about. We're talking about the beginning. In that case, DIY always tops outsourcing for me.
I'm not great at programming or design. I'm pretty average. But because I can do it all well enough, I have an advantage over many people, teams and companies who are specialized.
Bootstrapping vs. venture capital
Bootstrapping has become an advantage. You keep your costs low, naturally. You get zero of the bullshit attached with VC money. You maintain full ownership over your product and its roadmap (where you want to go with it). You maintain full ownership over the equity so that when you sell it later, you'll get lots of money.
In the early stages of any project that's not funded, keeping your costs down is your biggest priority.
Developers these days are crazy expensive, due to high demand for them.
To build, should you learn to code?
Just know some bits so you can throw stuff together. When I code, every day I have to Google how to do stuff I don't know. Coding is continuous learning.
The core of coding: figuring it out yourself. That's the biggest skill. Fiddling for hours to days to get something working. Not giving up and keep trying. And then suddenly: EUREUKA!
Which tools should you use to build?
A good tip to choose a technology is its age. If a technology has been around for a decade or more, it's probably working well for people.
Just use whatever works for you. I keep it simple. Most companies will eventually built their own framework over time.
People are obsessed with tools because it feels like they're actually doing something productive. They get stuck in this endless research.
All of this stuff simply takes away from your goal, which is shipping a product and selling it to users and getting revenue from it.
Stop asking "what do you use to make that?" or "how did you make that?". It's an inherently stupid question. The question should be "why did you make that?". The philosophy behind something is way more important than how they made it. You can copy their tools, but you'll never be able to copy their WHY (which is what makes people and their products great).
My approach is that I only learn what I directly need now.
This is a much faster and leaner approach which will save you time and make you more productive. And actually ship your product.
Building with constraints
Bootstrapping has become an advantage.
Not having to spend money on office rent is now an advantage.
Not being able to code means you can use off-the-shelf tools to quickly prototype stuff without losing yourself in giant codebases.
If you're "outside" the scene and not famous, it means you can act like an underdog. You'll be more indie than most and, guess what, people LOVE to support independent underdogs.
Most people are overconfident. They think it's easy. It is relatively easy if you have a great product. But even then, a wrong launch can mean failure on day one.
The idea of having a first launch is to make a big splash, get lots of people to use your app, learn from their usage, fixing bugs, developeing new features, and hopefully getting them engaged so they stick around.
Many people have the wrong idea about the term minimum viable product (or MVP). You can't just throw something together and call it an MVP and put it up. It needs to actually work.
The ability to capture the audience that comes to your site on the day of your launch. And then get (some of) them to come back in a few weeks. This is so critical, because most sites see a giant drop of traffic after their launch ends.
The most basic things that you want to see are how many people are using your app during launch (Google shows you that with their real-time tab), where they are coming from (referrers), and their flow inside your app.
Set up a little feedback pop up in the bottom left or bottom right of your app. Especially when your app is very new, it's like a super power to your app's development to get direct user feedback.
Don't stick to one launch, keep launching.
Make every feature a launch opportunity.
Many startups are now simply launching lots of mini apps with distinct functionality that before might have been a feature of their existing app. But by decoupling it from their main app, they can use it as an entire new launch. And that gives them the full benefit of a new product launch.
How to stay motivated working on one product
You shouldn't work on an idea that isn't taking off.
The motivation is intrinsic if people use it or if I make money with it. Then I know it works and I want to keep working on it.
I work on a lot of stuff at the same time because I want to not have all my eggs in one baskets. I think there's a higher chance of success if you try different stuff.
Don't hire growth hackers. 99.99% of them are useless and are trying to sell a mystical art they often didn't even succeed at themselves as something you can just buy as a service.
If anything, growth should have been in your product from the start. The product has to be intrinsically viral nowadays. It needs to be something people really want or need.
Why is organic growth better?
Growth to me should be mostly natural and organic. Especially in the early stages (e.g. after launch) of your product.
When you've got nice traction (depending on your app obviously, but I like 100,000+ MAU as a threshold), you might be able start scaling it up with paid traffic like ads. Why then? Because you've already proven your product works for people.
How to get organic growth?
The best way to get your first users is to launch the first version of your product fast.
Nobody ever said you can't keep launching though. If you add a whole bunch of new features you should tell the world about it. And the best way is to just launch it as a new version of your product.
Spinning off stuff works well because it also gives you an entirely new launch to get traffic from. The product you spin off should be strong enough though to allow it to be its own product.
Every new feature can be a story. Tell about your own journey and maybe struggles before or during the build up to your product.
One way of story telling is building in public.
Why does being transparent work? Because people like to be part of success (or failure) stories.
In that respect, transparency is very meta in its nature. By sharing about the product, it usually makes the product itself do better.
Make people share easily.
A good strategy to grow is to launch an API. This means you make your data (and sometimes features) on your site accessible to other startups.
Making an API means other startups can integrate your app's features and data into their app.
Build with your users. People love doing that because they love co-creating a startup with you. The people that give you those ideas are usually the best users because they're experts at your product. Choosing what to build next, based on what they're saying, is amazing because many times, after you've already solved your own problem, you think that this is it.
Don't be afraid. People are happy to reward you for your work. But those people will only be a small percentage of all the people that are happy to use your product for free.
If you start charging for a product, you'll get hate. Internet hate. A lot of it.
Don't lower your prices. Don't make it free. These people are not your customers. These people will never pay for your app, not even if you lower the price.
Build with monetization in mind early on. Especially if you don't have a lot of cash flow now and actually need a project to give you some revenue (to literally pay your bills).
Monetization is validation.
Limit features to paid users: Figure that out with analytics or talking to users (or just intuition). Pick those features and test if you can make them for paid users only.
Pay-per-feature: You can let customers unlock lots of features at once. You can even let them become paying subscribers. Or you can make each little unlockable feature a single payment.
Ads: Native Ads are ads that don't necessarily come from some big ad network like Google. You write, design and sell them yourself and customize them so they fit with your entire product's look, feel and, most importantly, objectives.
Sponsorships: You make something that many people find very useful and it aligns with a big company's mission. If you get some attention for your project, a company might ask you, or you can ask them, to sponsor you.
Patronage: People these days understand you are a human and need to pay your bills (like them). And many are probably increasingly attracted by an authentic request for money than a big marketing page with flashy buttons to unlock the full version of your app.
Subscription-based memberships: A good middle ground (that I use) is to offer besides subscription, also a one-time-payment lifetime memberships for the predicted lifetime value (LTV) of a customer.
Community model: Subscription payments work especially well with the business model of building a community. People don't like to pay for content anymore, but they do like to pay for connections, e.g. communities.
Job boards: Similar to the community model. You have a free site about a certain niche. Does that niche have its own industry with people working in it? If so, one of your best ways to make money with it is to open a related job board besides it.
Productizing an agency into a SaaS: Many startups started as creative agencies. That means they built a product for a single client, but then transformed that into a standalone product or service.
Learn from your competitors' business models: When you can't figure out any model that will let you make money, it's always a good idea to see how your competitors are making money then.
Keep experimenting with business models.
If you think you've already captured most of the market and it's saturated, see how you can widen the market you sell to. Can you make your product broader and less niche?
How to deal with refunds?
The worst you can do when a customer asks for a refund is to not give it. You now have an angry customer.
When a customer asks for a refund, say sorry that it didn't work out (and mean it!). Then immediately refund them their money. Ask them why your product wasn't what they expected. This might be one of the most useful moments to ask for feedback as you might be able to avoid future refunds to other users.
How to deal with bookkeeping and tax?
I recommend if you're doing over $50,000/year revenue to pay up to $5,000 for a good accountant that understands technology, business and startups. Trust me, they're hard to find. Regardless of country, most accountants are old and behind. My advice is, approach 25 different accountants and make them do a quiz. Ask them what for example Stripe is, how to do sales tax payments in different countries and how they would help manage your thousands of annual transactions.
Where possible, try to automate your side of the bookkeeping before it arrives at your accountant.
Avoid hiring, build robots. Hiring increasing the complexity of your product, business and life. Hiring a person means you need train and manage them and makes you liable for their income and in many countries a lot more than just that (e.g. health insurance). Humans are complex. They're also relatively slow. Robots can be simple. They're also very fast.
A robot for me simply means a task I used to do myself, that I wrote a script for, then scheduled to run every second, minute, hour, day or week.
Automate parts that take quite some time for a human, but don't take too much time to script.
Automate customer support : a user can sign up, cancel their account, get a refund, change their subscription plan, change their credit card etc. all with a self-help dashboard.
Another way is paying a human to be somewhat on standby based on when something happens and they have to deal with it and they log their hours and just invoice you through PayPal.
Make your product into an autonomous organization:
- Automate repetitive work with robot scripts
- Hire a dev ops (or sys admin) person on a contract-basis to manage bots.
- Set up alerts (like with Uptime Robot) so your devs are alerted if your product breaks
- Hire one part-time or full-time contractor who has access to your PayPal or bank and can manage and pay your devs
- Find one or two people that can be somewhat like "the board". They check if the executive runs your company as you would have wished.
- Prepay balance to your hosting company and domain name company