What you should focus on when starting with your tech startup

Lessons I've learned about what's important when starting-up

Startups are very different from regular companies. Often times our formal education and our careers don’t prepare us adequately for this endeavour. With so many things to learn and try while starting a business, it’s always beneficial to build on top of the advice of others. This is exactly the aim of this article - I’d like to share some lessons that I’ve learned along the way while building my startups and talk about things I would do differently next time, so hopefully you don’t have to learn them the hard way.

So without further ado, and in not particular order…

Me, thinking about all my [dumb] life choices

Culture is important, but progress is more important

When we were building our companies, we put a lot of emphasis on culture, teamwork, values and vision. It came naturally, because we all cared about the company. Intrinsically, for us our work life was important and we wanted to create the best version of it. As most people, we had worked for some bad bosses and in some dysfunctional teams so wanted to avoid that. We wanted to be better than that. And we were.

I don’t regret any of this, and I’m not saying that this is what ultimately made us fail. However, I also believe that we could have used some of this energy in things that would have made a bigger difference. Next time, I’d be more diligent about how much of the work that goes into creating a nice culture is really necessary. In fact, more often than not, the nice environment comes from being around like-minded people, building a business you care about, the energy that comes with the ups and the hope that comes after a down is over. We don’t need fancy offices, designer furniture or moderated off-sites. Leave the 2 day workshop for defining the company value for later, when you have time for it.

Here, there’s a huge asterisk, though. You should still make sure the company culture is not bad. And that you’re building on top of solid ground. If there’s mistrust, burn-out, fights or bad teamwork, fixing it should be still the top priority.

Goals vs. the journey

Startups are not what they used to be. Nowadays, being a startup person is a lifestyle, and a coveted one at that. Everyone wants to be the startup person, the founder, the entrepreneur. Hence, it’s about the journey.

In the past, startup people were scrappy individuals that had a vision and wanted to work on technology. Yes, they very much enjoyed the journey, but they were also all about creating products that people loved. Now, it’s all about maintaining that status of a startup person and having a fancy title.

These are not only my words, it’s what many think. In fact, when asked about the initial success of the Y Combinator, Jessica Livingston - one of the founders of the program mentioned the same thing. As startups became mainstream, so did the people that found them.

In practical terms, this means that you should be asking yourself this - are you and your team in “it“ because you really have something to create and share with the world. Or are you only along for the ride, enjoying that sweet investor money.

There’s nothing wrong with the latter. I’ve been there. But it comes at a price - the incentives are shifted. Often times you are not as committed as you should be. It’s more likely that you’re in a business or domain you don’t necessarily care so much about, and therefore, less likely to know intimately. Put differently - you might not be willing to go the extra mile.

Being lean

The lean methodology and “The lean startup“ by Eric Ries are ever so popular. There’s no shortage of content on that and it seems almost everyone (at least in the startup scene) is familiar with it. I’m not sure how many people actually read the book, but they are surely familiar with the concept.

The reason I want to re-iterate on that is because, nevertheless, a vast amount of founders and startup employees fail to follow through.

I don’t want to turn this into a summary of what the lean startup is. I’ll just say that a central point in the book is the concept of validated learning and building prototypes that are as minimalistic as possible (that still validate a hypothesis). It sounds easy enough in theory. The problem is often times that it takes discipline to not let a prototype grow out of proportion. It’s so easy to add just one feature, or work just a little more on the design.

This is especially true for us, engineers. We are so comfortable on our computers, hacking away. And we are so uncomfortable talking to people or doing marketing, or setting up experiments, that we are the first ones to fall into this trap. We continue writing more and more code until our lean prototype turns into a full on product. The wrong product, often times.

A shortcut to the lean methodology: If you don’t have the time to read “The lean startup“, but you still want to dive deeper into that topic, you can read another amazing write-up on the same topic - “Pretotype it”. It also has a free version that’s more than enough to get a good understanding of the concept. Even though, Eric Ries and Alberto Savoia came up with these theories separately (as far as I know), they are similar enough for the casual reader.

Here, I don’t have a terribly concrete advice other than - keep reminding yourself of the lean startup and always question:

• What are you testing?

• What’s the minimum amount of work I need to do in order to validate this hypothesis

• How do I test this hypothesis

Unfortunately, it doesn’t come easy. There’s always a voice in your mind that tries to get you to do things the old fashioned way.

Only hire if you absolutely need to

Strangely enough, building a startup can also be e lonely endeavour. I remember, when I started out, I found it difficult to be the only technical person on the team. Even though I don’t ask for help very often and prefer to be self sufficient while working, I could always rely on my colleagues when push came to shove. And as soon as there were no “colleagues“ in my team, I felt unusual pressure on my shoulders.

Later on, I had a tech team around me, but I was mostly the only one responsible for our servers, effectively making me always on call. This also ground me down after a while and made me wish I had people around me that could take over a lot of that burden.

To add to that, if I’m perfectly honest with myself, one of my goal in life has always been to be leader and to have people around me that I can develop and work together with. So I was inherently biased towards wanting to expend the team.

I’m writing this to show that there’s a real bias towards wanting to scale up and hire people. It’s also a big measure of success - most people wouldn’t consider a company of one or two people successful, even if it makes a lot of money. As a consequence to that, you will be tempted to start hiring. It always seems like a good thing to do. Often times you tell yourself that hiring takes a while, so you need to start sooner. While this is not untrue, having more people on the payroll puts a lot of burden on a startup’s financials. Especially in tech, payroll is easily the biggest spend.

With additional team members, there’s also additional overhead. You are very nimble when you’re alone or with a couple of people. When you have a full team, bureaucracy comes soon thereafter.

---

Just as I was writing this, a new episode of the Rework podcast came out outlining exactly that. It’s a really interesting conversation (even though it’s more extreme than I’d personally put it). You can check it out here.

Embrace chaos

This one is a bit overdramatic, I must admit.

It’s easy to go to a startup still carrying your big company baggage. For me, this baggage manifested in a mentality of:

• We need structure

• We need processes

• It’s my team versus your team

• Everything needs to be well defined

I almost feel embarrassed looking at that list. It looks like I was being unreasonable, but trust me, it was more subtle than this. It was more the case that my priorities could have been better set. And I should have embraced that every start is chaotic, and that’s ok. Most of us have been thought in university and early on in our career that processes and a well thought out architectures are paramount to success. While that might be the case in big companies and complex projects, this is not usually the case with startups.

It’s nice that nowadays things like Scrum and Agile have become mainstream, but even following them can be too structured for a very small team. Obviously you wouldn’t follow Scrum if you worked alone. Probably also not if you had two people on the team. These methodologies are tools for a job. The question is - do you have that job (a.k.a this problem). My advice is: Think if you have a problem with the team not being in sync, or not knowing what to do. If you don’t, introducing a process around solving that, is redundant. Cross the bridge once you get there.

Stick to domains you know

This one hits close to home because it’s a mistake I’ve made more than once.

Building a company is an endeavour of such immense breadth. There are so many different topics you need to learn and exercise. This is fine - skills can be learned. However, every time you need to first learn and then apply, you lose time. Each time you make a decision regarding something you don’t know, it’s a shot in the dark. Both these combined slow you down and decrease your chance of heading in the right direction. Which are both very effective startup killers.

Sure, I can learn to run a hotel. I can get into the hospitality domain. But how much time would it take me to learn the ropes? How many bad decisions will I make because I don’t understand how things work?

Warren Buffet is famous for saying that he doesn’t invest in business he doesn’t understand. So why should you?

Fight or flight

History is full of people that gave up too soon, people that kept going even after all all signs were telling them to stop. And everything in-between. Each of these people would give you either an advice to run away immediately after you see no traction on a product or to persevere until you find something that works even if the future seems hopeless. Which one would be better - I don’t know. I don’t think any one of them is better than the other. At the end of the day, the only thing that matters in your decision making is probably if you believe in a product or you don’t. If you feel it in your heart that a product will work in one way or another, you will persevere and iterate over and over until it’s at least a tiny bit too late. And if you don’t genuinely believe in a product, you will find an excuse to shut it down as soon as you feel resistance. I guess there’s a first lesson here - only work on products you genuinely believe in.

You will never know for sure if you should fight or flee. However, you can learn to read some signs. I am certainly not the expert here, and I’ve done my share of mistakes in this regards, so I can only give my personal opinion here. Take the following with a pinch of salt. Let’s look at some common warning signs.

Bad numbers

You should have at least some sort of metrics that quantify the success of your company and product. If they are bad, there’s something wrong. Period. The problem here is that there’s always room for doubt, there’s always multiple ways to interpret the data, there’s always an excuse. You always want to look at numbers with happy and optimistic eyes. Don’t - be critical towards your metrics. If you don’t understand what they mean, expand on them until you do. One piece of related advice I heard a long time ago was:

When we don’t know something, our minds tend to fill in the gaps with what we want to hear.

I heard it in the context of sales and storytelling. Funny how it also applies here.

Users don’t care and/or are churning

Churning should be obvious by now.

Quantifying if users don’t care is more complex. Still, I find it very important. I’ve seen many startups struggle with the same - they make changes, experiment, update, change, redo… and nothing happens. Engagement is the same, Active users is the same… almost as if nothing changed. There’s a huge bug… and yet no-one complains, metrics remain unchanged. It could be that the changes made weren’t big enough to warrant a change in people’s behaviour. Or it could be that they are just not engaged.

I metric I would consider using here is the Sean Ellis (the author of Growth Hacking) score for finding product-market fit. It goes:

If you were to wake up tomorrow and your product no longer existed, how would you feel? If at least 40% of your users say they would be very disappointed, then you have a product-market fit.

If you don’t want to read the whole book, but you still want to hear Sean elaborate on that score, Lenny’s Podcast has an amazing interview with him.

And on the topic of Product-Market fit…

Product-Market Fit

I’m not the person to be speaking too much about product-market fit. It’s a very lengthy topic and it’s really difficult to quantify. What’s easy, though, is to know you have it, once you have it.

Since it’s so difficult for the regular person to know where exactly they are on that path, I’d recommend that you consume as much media and literature about it as you can possibly bear. There are multiple schools of thought about it, and different people are saying different things, but from my experience most of it is helpful at least to a degree. And the more perspectives you gain, the more you understand what to look for and you can define your own journey.

Cut the right corners

This is a topic that’s much bigger than a paragraph, or an article, or even a book. So I will not even attempt to write an exhaustive here. It’s a common thing for people to say “If you’re not at least a bit embarrassed to release a product, you released it too late“. The Lean Startup teaches us to do the bare minimum in order to validate a hypothesis and to “fake it till you make it“ in a way. Facebook has the famous slogan to “move fast and break things“.

Cutting corners is a necessity. It’s not the most glamorous thing to say or do, there can be social pressure against it, but it has to be done. That’s what it takes to be successful.

In tech, all we hear from professors, blogs, videos and colleagues is that the code needs to be perfect, specifications need to be perfectly defined and the architecture spotlessly laid out. And yet, every company you go to, there are gaping holes in the system and considerable technical debt. I’m also sure there are many failed companies with the most beautiful code still saved in GitHub. I wonder why… At least with the gained popularity of Scrum and Agile, the popular opinion shifts slowly to accepting the inherent uncertainty in developing products and embracing iterative approaches.

On the other hand, things can quickly get out of hand if you cut too many corners or “embrace chaos” too much.

It’s a balancing act between maintaining momentum and not backing yourself up into a corner. Or doing something immoral or plain illegal. It’s a lot about having a plan and being mindful about what can eventually get you on the straight and narrow.

One famous example here is the way Vanta started out. Their founder, Christina, started out without any product at all. She talked to companies around her and proposed that she’d take care of their compliance and certification for them. Once she saw there was a great need for that, and she discovered, in depth, how this works, she just needed to build a platform around it. This example is a little cheeky because doing what is essentially consulting for a company is hardly cutting corners. More traditional examples include promising features you don’t have yet, doing things manually and so on.

On a more day-to-day level, cutting corners is about not being perfectionist, applying the 80/20 rule of reaching 80% of a goal with 20% effort and not doing unnecessary for the time being work. In essence, it’s about not over engineering, or even plainly under engineering something, often because you’re not sure it would even work, or last.

When I was little, my father liked to tell me an interesting factoid about building tanks during World War II. He was explaining to me how German tanks were built meticulously and how all parts were refined to perfection. Whereas Soviet tanks were constructed so sloppily that often times parts wouldn’t even fit together without modification. However, in the war’s fierce battles the life expectancy of a tank in the field was around a week, so it didn’t really matter how reliable the German tech was or that Soviet tanks were almost trash just coming out of the assembly line All they needed to do was not fail for a week.

As much as I don’t want to have such gruesome comparisons to running a company, it is true that in the early years, it’s about survival. When you’re surviving, you typically need to make some concessions about the long term future. Startups are often times no different.

Embrace cross-functionality

Here, I personally got lucky. I’m a heavily technical professional, but I do have experience with a plethora of technologies. I wrote iOS applications for many years, I then switched to backend development, I ran my own services on production, have experience running teams and I’ve gain a lot of knowledge about building products along the way. Am I the best DevOps engineer? No. Can I impress you with mad Python skills? Unlikely. But when you’re building a company, these skills are rarely very useful in isolation. You need someone that has enough breadth to keep the ball rolling and not get blocked. More importantly, you need someone that has a holistic views on the whole product and knows how to put the puzzle together.

I cannot really tell you it necessarily puts you in the best spot during conventional job interviews (unfortunately). Nevertheless, it puts you in a better position in many other situations in life. The most important thing is to not be afraid to get into a topic and to have enough range to jump right in and be productive.

This advice is probably more relevant to people that are just starting out. If you already have 25 years of experience doing enterprise sales, it’s the wrong time to tell you to learn how to make websites. Related to that, the next section is advice I tend to give to young people aspiring to be entrepreneurs.

Focus on core skills

Everyone in a company is doing important work (I hope). The thing is, however, in a small company, there is work that’s more important than others. Each company has a set of core skills absolutely necessary for success.

For example, I was mentoring a young person who wanted to find work in project management, product management or maybe software development. The long term goal was, however, to become an entrepreneur and run a business. This made it difficult to recommend going full throttle towards project management, even though it was easier in the short term. Project management skills can be very useful in an established company, but if there’s no-one to create the actual business and develop products, there’s no project to manage.

If your ultimate goal is to start a company doing X, you best make sure you, personally, or at least someone on the team can do X.

Working with agency and urgency

I stole this one, I admit it. I first encountered it in an interview about hiring practices in OpenAI. They explained that these two are the most important qualities they look for in new talent.

To expand on these words, they refer to taking ownership, driving topics to completion and doing so promptly and directly. As soon as I heard about this, I immediately thought about how we were often doing things in our companies and also companies I worked for in the past. We were working very well together, we took pride in what we were doing and we were genuinely doing our best to achieve our goals. Unfortunately, we were also spending a lot of time talking about doing things, arguing how to do them and when to do them. Retrospectively, there was an aura of indecisiveness, uncertainty and even fear. Essentially, we were very good at talking about things, whereas we should have focused on actually doing them. This is how I interpret agency and urgency.

Going forward, I want to be the one working according to these quality and I want to be surrounded with others that all show agency and urgency in their work.

Wrapping it all up

Hindsight is 20-20, as they say, and my startup experience is no exception. There’s no point in dwelling on the mistakes of startups past, but we can learn from them. We can try to be better and better each time. There are many more concrete takeaways one gets when reminiscing about the past - specific things that went wrong, improvements that could be made. These are mine - at least the ones that broadly apply to the general public.

For me this article was like a retrospective about the last few years, mostly things I learned the hard way and aspirations how I could do better next time. I wish, I had someone around me in the past, who could share these lessons and make my journey at least a tiny bit easier. So this is my gift to you, to future me and to the internet. I hope it saves you some grief in the future. Thanks for reading my story!

What about you? What were the lessons you have learned working in your companies? What were the funniest mistakes that were made?