Building my Startup pt.1

Intro

Lately, I've been thinking of building my own startup. I've tried a couple of ideas in the past but never made it to release anything in the market ⎯ actually I didn't even make it to build an MVP. The lack of knowledge, direction and management made me and my friends quit the idea after a couple of months of work, yes you heard me, months of work.

I will write a series of blog posts regarding building my own startup for two reasons:

Share ideas and understanding of building your startup
Structure my knowledge throughout this beautiful journey

There is no agenda for this series; I will write my thoughts and understandings based on what I've learned in the last few months I've been working on. I am always open for discussions, especially in this domain, so please do feel free to ping me if anything.

There is no recipe 📝

The first thing I learned after reading a couple of books, listening to podcasts and watching a few videos is that there is no specific recipe for building your startup. Although there are some standard techniques and ideas across all these resources, there is no 101 guide to building a startup. The most challenging part when going into entrepreneurship is that you don't know what you don't know. Now for me, this is exciting mainly because it makes the game even more challenging, and oh boy, I love challenges.

It makes sense, though, because users, the market, and life are quite unpredictable. Users barely know what they need, and the market changes faster than the weather. Besides, if there were a formula, everyone would be doing their own successful business, yet over 80% of new businesses fail in the first five years, and 96% fail within their first ten years!

Mistakes I've made 🚫

Let's get this out of the way first. I've tried in the past to work on two ideas; the first one was a complete failure where we were trying to come up with a solution to a problem that we didn't even know if it existed. We also didn't fully understand what we wanted to build. It was basically brainstorming for two months, trying desperately to find something to make. A complete disaster and a waste of time.

The second one went a bit better. We had an idea that obviously relied on assumptions ⎯ known as a leap of faith assumptions, and we did manage to break down the problem and start working on it ⎯ like complete rookies, instead of validating the idea first 🤦‍♂️. We analysed for a month to pick the right tool to build the MVP. One month to decide how to build the MVP! Now I am not saying we were working full time for a month since all of us had a full-time job and we were meeting together twice a month for 2 hours each, but still, one month for picking the "right" tool for the MVP, unacceptable unless of course your product is building rockets.

The problem with the second idea is that we kept working for eight months trying to build the MVP. I know, almost pathetic. The idea was just an e-commerce system. We have struggled to develop an e-commerce MVP since we thought the market already has a standard for such a system that would not allow us to build something smaller without checkout, shipping, or payment feature. That was not the only issue, in any case. We didn't have a plan. We didn't make a single commitment to a deadline. Oh, did I mention that we spoke to only two users to verify our idea, wasting eight months of building something that might not be needed? Obviously, we ended up in the rabbit hole.

Verify the idea 💡

So after studying some books, everyone seems to say the same thing. To build your startup, you first need to verify the idea and find a market fit!

So there is a thing defined in the Lean Startup book called Validated Learning.

Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startups presence and future business prospects

Learning is the essential unit of progress for startups, which makes sense because the worst enemy of a startup is uncertainty and a lot of it, especially at the inception phase of the idea. The question should not be "could this product be built" but rather "should we build this product?".

So the first thing you have to do is verify that you are solving an actual problem users have. To do that, you will need to do much experimentation. Every experiment starts with a (a) hypothesis, then the (b) implementation, and then the (c) results are analysed.

You have to do this in the early days of your startup, build-measure-learn ⎯ speaking the truth, this is what you do throughout the whole life span of your business, but it's more critical in the early stages. I had this in mind on my second try, but I failed to minimise that feedback loop of build-measure-learn as we worked on the idea for eight months, not releasing a single thing.

MVP ⌛️

So the second thing you need to do is build your Minimum Viable Product to verify your assumptions.

💡 However, I would encourage you to talk to your potential users before building the MVP. Talking to users is another topic that we will cover in the next section, but I would strongly suggest trying to extract some data from them before even building something.

All right, how do you define what is the correct MVP to build? I don't know! I don't know because there is no formula. I am currently struggling to determine a good MVP that can be made in a matter of weeks and shorten the learning feedback loop. I've heard many stories of incredible MVPs that required no software at all, but I am not quite sure how to define one yet. I think the mistake I make, and many entrepreneurs as well, is that we tend to match the MVP with our vision and get afraid that the first launch will be catastrophic for our startup's life which is simply not true. Launches aren't special at all. Do you remember the day that Google launched? How about Facebook? How about Twitter? Exactly it's not that important; it's just a base to start iterating from.

MVP should enable you to get to the build-measure-loop cycle as quickly as possible. The complexity of the MVP should depend on what assumption you need to test. It could be an ad, a landing page, an sign-up form, or a complex working prototype. Another thing is that you will need to drop your professional standards because they bring no value at the beginning. Remember that your goal is to test your assumptions as quickly as possible to minimise uncertainty.

💡 Hold the problem you're solving tightly, hold the customer tightly, and hold the solution you're building loosely.

Talk to users 💬

As I said previously, talking to your potential users is good before even building an MVP. It would be great if you could gather more information from your target group to whom you will provide a solution as soon as possible. I've only talked to a few users before, but that was before studying about building a startup, so I wish I had known these things before.

Here are some tips on how to talk to users

❌ DON'T talk, LISTEN 👂. User Interviews are not the time to sell the user your product. They are meant to extract data from the user to improve your product.
❌ DON'T talk about hypotheticals — hypothetical products or hypothetical solutions. Again, you are not talking about your product; you are talking about the user's problem.
✅ DO ask the user about the specifics of their problem. Generalities won't guide you to a solution; specifics help you break down the problem into individual pieces.
✅ DO understand the contextual information about the user's life that led them to the problem. What are the motivations that got them into that problem in the first place?

Some specific questions to ask users

❓"What is the hardest part about [Situation that user is having a problem with]"
Example: Dropbox might be in a school computer lab at MIT and ask a student: "What is the hardest part about working on a group project with school computers?"

💡If the user says what the hardest part is, and you are not solving it, solve the hardest part instead!
❓ "What (if anything) have you done to try to solve the problem?"
If someone isn't expending effort to try to solve the problem, it might not be that big of a deal.

💡If people are already trying other solutions, your product will be compared against that solution. Dropbox, for example, was compared against emailing files back and forth.
❓ "How do you currently solve this problem?"
This gives you a really clear understanding of how you can market your solution!

💡Customers don't buy a thing; they buy a solution to a problem. For Dropbox, they are not buying a file-sharing system; they're buying a solution to the problem of sharing files on group projects they had last week.

Commonly, the information you collect from your users will open the option of pivoting and changing your strategy. Pivoting is another topic, and I don't know a lot about it, but a company can do many pivot types.

e.g. Zoom-in pivot ⎯ what previously was considered a single feature in a product becomes the whole product.

Pivoting can happen in many stages in the lifetime of a business; the difficult aspect is realising when and if you have to do it.

User interviews are a vast domain, and there are so many resources around that, but the vital thing to remember is that you have to keep your users as close as possible while building your own startup. The shorten the feedback loop between you and your potential users, the higher the chances you are in the right direction.

Metrics 📊

After launching the MVP, the next step is to measure the progress. The MVP provides the first example of a learning milestone. There are many metrics to consider, like user signed up or daily active users, but it's easy to measure the wrong things and get the wrong path.

The lean startup book suggests that metrics should follow the 3mA's

Actionable
Accessible
Auditable

I don't fully understand those as I haven't gotten to the point of capturing such data, but the main idea I am aware of is that it's essential to track the right metrics instead of following misleading trends. Everything that is not moving you close to your primary KPIs is not important to guide your decisions.

Finding an investor 💸

Another critical aspect of building your startup is finding investors. Typically you prepare a pitch deck where you present it to investors, trying to convince them to invest in your idea. It seems this is not that important for me since I have a full-time job to maintain, and I consider my startup a side project for now. Maybe this will change in the future when I might need more resources to steer the startup, but I am not exposing myself to this area yet. Although I know many people go that path before they even find a market fit.

The rest is history 📜

A business has three phases based on the e-myth book.

Infancy -> Infancy ends when the owner realises that the business cannot continue to operate if you do it all yourself.
Adolescence -> Business adolescence begins when you, the owner, decide to get technical help.
Maturity -> A Mature business knows how it got to be where it is and what it must do to get where it wants to go.

As I said, I haven't built something that passed the Infancy level yet, but the goal is always to move to the next level, and this is my goal for now. When I get to the Adolescence phase, I think that the rest will be history. There are a lot more topics that are not covered here, but the intention was to give you more about my experience and learnings the last year. I will keep creating blogs about building my own company as I learn and experiment more.

Here are the resources I consumed lately that generated all the above thoughts:

📚 Books

🎥 Videos

Startup School

🎙 Podcasts

Did you like this one?

I hope you really did...