How to Build Technology Products
How to Build Technology Products
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:
- Building technology products
- Creating and validating your MVP
- Tracking KPIs and keeping yourself on-track
- What NOT to do as a new builder
1 — Building Technology Products
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):
- Is my product really that technical or can this be done with no-code?
- Do I need to hire technical people?
If you answer “yes” to either, learn to code. Here are some resources:
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/.
2 — Creating and validating your MVP
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:
- What exactly are you struggling with?
- What might the root causes of your problems in math be?
- How does this compare to your other classes?
- What do you think of your math professor?
- How did you study for your last exam? Walk me through your process and how you did on the exam.
Once we ask questions like this, we can begin to make assumptions based on their responses:
- Maybe they don’t have enough support?
- Maybe the school is not giving them the attention/resources they need to learn effectively
- Maybe they don’t have enough incentive to spend time studying math?
Now we can go a layer deeper and ask more questions:
- How does your math studying process compare to your other classes?
- What resources are you currently using to study?
- What do you think of the resources given to you by the school? Does it help you learn effectively?
- Do you like studying? Why?
Now we can begin to reach conclusions (notice how they are specific, fact driven and 0 assumptions are made):
- The school is only providing them with lecture recordings and a confusing textbook full of equations which make it hard to understand
- They are using YouTube videos — specifically Khan Academy and Organic Chemistry Tutor
- They study alone, and find it hard to study math with a good payoff relative to their other courses, so they are discouraged.
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:
- A website full of easily digestible video content, example problems, problem sets to help students with first-year university mathematics courses. Users will also be able to join a Discord community where other students can study together and get help on their homework via tutors.
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.
Now What?
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.
The Building Cycle
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.
3 — Tracking KPIs/Metrics and keeping yourself on-track
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:
- MAU and WAU (monthly, weekly active users)
- MRR (if you’re going for profitability, also measure that. If you are negative profit measure time to break-even — shown below)
- Burn Rate (how much you spend per month, also known as MRC or “monthly recurring costs”)
- Churn (weekly and monthly)
- Burn Rate
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.
4 — What NOT to do as a new builder
There are a few things not to do that may seem comfortable, but will actually ruin your chances of creating anything valuable:
DON’T:
- Get stuck in analysis paralysis
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.
- Never ship
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.
5 — Conclusion
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!
