Ryan Haraki
Note: This blog post is adapted from the original Medium post.
Something I get asked all the time by peers who are just getting into tech or want to start their first company/project is “How do I build something?”. It’s a very simple question, but can warrant a much longer answer, so I thought I would write a piece on my advice on:
If you’re wondering whether you need to learn how to code or not, you can ask yourself these questions (you can skip most of this if you already know how):
Codeacademy: https://www.codecademy.com/
Udemy: https://www.udemy.com/
Free Code Camp: https://www.freecodecamp.org/
The Odin Project: https://www.theodinproject.com/
Why, do you ask? If you can’t code, you won’t be able to ship your product fast enough, you’ll have nothing to do, you’ll lose motivation, then quit. The WORST thing you can do is have a waitlist up for months with nothing real to show and all of your potential users forgetting about you. One of the top reasons startups fail is simply because they don’t ship fast enough.
If you answered “no” to both, then find a way to build your product without coding and as fast as possible. There are plenty of no-code tools out there you can use to build a landing page, forms, and even a full product. My favourite is https://bubble.io/.
Sell, then build. Don’t waste months coding away at something nobody will use. My recommendation is to define your potential users first and be very specific, for example: “College students from Canada struggling in first year math courses”. You can really start to understand what to build when you identify what a potential user and their problems might look like. This is extremely important to do because people just won’t use your product if it doesn’t address a real problem or need that they have. For example, we can ask them some questions like:
Once we ask questions like this, we can begin to make assumptions based on their responses:
Now we can go a layer deeper and ask more questions:
Now we can begin to reach conclusions (notice how they are specific, fact driven and 0 assumptions are made):
Looks like the school is not giving them enough materials to study properly, they learn via video-content, and feel lonely/discouraged to study math.
Awesome, now let’s come up with some solutions based on these conclusions:
We just came up with a solid, specific idea for a startup based on a simple 10–15 minute chat with a college student. Imagine the data you would get from repeating this 50 times! Make sure to note everything down in a Notion doc or something similar.
Once you have this, go on Twitter/LinkedIn/whatever, DM some people that might be potential users, and setup a quick 15 minute chat with them, then repeat as much as possible.
From talking to potential users, you now likely have a bunch of data regarding their problems (in the form of responses to your questions), some assumptions you’ve made (which may have been proven true or false), conclusions, and ideas. Prioritize them based on importance/frequency and begin building.
Your primary cycle while building your product will be the following:
Ship, talk to users, iterate based on feedback, repeat.
If you can minimize the time per step (by maximizing the efficiency of each individual step), then you’ll have an amazing engine going that you can use to keep iterating and build a great product.
You can do this by using a Kanban board to track tasks, a Notion doc to organize your thoughts and strategies, or maybe even a Miro board. Figure out what works for you and keep iterating and coming up with new ideas to make yourself more productive.
Example — Kanban Board in Notion:
Here, we can track our “todos” in a super easy to understand and visual way which makes it easier to prioritize tasks.
The only way you’ll know what to build is by asking your users. Don’t come up with random features and build them because they “might” be valuable, most people do not care about dark mode so don’t waste time on it. You should “Mom test” all of your users to figure out what to build, here’s a link to a free pdf of the book. It covers many of the methods I mentioned above.
Metrics
Make sure to use Google Analytics so you can track basic metrics on how your app is being used so you have something to base assumptions off of.
I recommend tracking metrics on a weekly, monthly and yearly basis..
A few key metrics I like to track and would recommend tracking:
Everything here can easily be inputted into Google Sheets/Excel and plotted on a few graphs so you can visualize your metrics. For example, you can plot your MRR vs MRC (revenue vs expenses) on a time graph to figure out when you will break-even (become profitable).
Example: Breakeven Chat
As mentioned above, we can compare metrics to help us understand our product better. By comparing our MRR (monthly recurring revenue) and our MRC (monthly recurring costs) then we can figure out when and if we are going to break-even and reach profitability.
I’ve jumped into Google Sheets (click here to view the sheet) and thrown together a super simple example with a line chart. Our MRC can include things like payroll, software/hosting expenses, etc. As you can see, MRR > MRC by month 7, so that’s about where we will break-even, which is also shown in the chart. Feel free to copy it and mess around with the data yourself.
KPIs
When it comes to setting KPIs, I recommend setting them depending on your product. A social consumer founder is going to have very different KPIs than a hardtech founder (same with metrics). If you’re building a web3 product then maybe “NFTs minted per user per month” is a good example of a KPI.
Set KPIs as “X per Y” to make it easy to track and more efficient.
A few other examples:
Users interviewed per week Features shipped per week New users acquired per month These are obvious and you should immediately be able to have some understanding of how to achieve them, now you just need to go and do it. If any of your KPIs are inefficient then kill them.
There are a few things not to do that may seem comfortable, but will actually ruin your chances of creating anything valuable:
DON’T:
Analysis paralysis is when you spend so much time thinking about something that you never do it. For example, you may spend too much time thinking about your tech stack, if people may not like your product, etc and just never build it. If you do this, you’ll never even start. I have friends who have been telling me they “want to code and ship a product” for years, and just never start. Don’t be that person. Nobody will respect a “prospective founder” who never even tries or bothers learning the skillset because they’re too busy spending 6 months deciding what YouTube project to clone or what stack to use.
I go from idea to shipped product in about 3 days — 2 weeks. If on the lower end, it’s something I threw together using no-code tools in a couple of hours to test if people want. If it’s on the longer end, I’m shipping a full product. Is it good and polished and amazing? No, but it does what it needs to do, which is all you need on day 1.
When you can move that fast, it’s much easier to increase the efficiency of the product cycle.
Most startups I see on Twitter (especially in crypto) raise $2M, make a waitlist on Typeform, throw a up a shitty website with a blank HTML file and no capitals in their headers or sentences because they’re “cool”, make a raise announcement/thread, gain 10k followers all in 3 days then go silent. I have not ONCE seen this work. Every single company that goes silent and never ships dies, and nobody cares because 1 week after signing up for a waitlist users forget they exist.
You don’t need to ship a perfect product, you just need to ship one. Your earliest users will get it and if they don’t, you probably are not solving a problem that is important to them (this is due to a) lack of user research and/or b) you’re targeting the wrong people for the problem you are trying so solve (bi-product of a). Come up with requirements you can ship in < 2 weeks, then do it.
Overall, building a technology product is really hard and requires a lot of work. There’s more to building one than just coding — you need business skills. If you’re a nervous introverted engineer, you’ll have to figure out how to talk to people.
If you found this useful, feel free to follow me on Twitter and DM me if you want to chat further!