top of page
  • Andy

Working as a Team sucks - if you don't know how to.

Updated: 3 days ago


Building a startup is no easy feature.

In the U.S. alone, around 80'000 new ones incorporate each year, whereas 0.05% raise funds and a further 1% of these will reach unicorn status. (says google)


Those that are successful have several things in common; they understand the market, have a business model that works for that market and a great team to bring the vision to live.

Unsurprisingly, one of the main reasons startups fail is that the team is not suited for the task or has personal discrepancies.


I just left a project I worked on for the past 4 months full time, while freelancing on the weekends to pay the bills.

In a nutshell:

We did not have a collaborative work approach, which I worked towards. The one who brought in the idea also wanted the CEO position and simply called the shots and decided without involving us. It was much more of him presenting his ideas and analysis to us and telling us the way forward. That did not work out, because we others worked towards the things we decided as a group, which then was outdated all the time.


What we should have done, would have been taking a step back, and explaining the things we do to each other, why and how we come to our conclusions. In this regard, we all failed.


Here are a few takeaways from the past months of building a B2B SaaS platform and failing.





Understanding the Market


When having an idea, the team has to understand the potential of the market and who the customers are. And I mean, numbers and definition. If you compare building a product that serves a particular niche locally, a SaaS that aims to get revenue in the hundreds of millions within a few years needs a different approach. To have such growth, there needs to be a large market where you can find that many customers and these customers need to be willing to pay.

If you talk to people, you find out their hard problems that you can solve. Yet, hard problems often don't scale well. Hard problems are also mostly unattractive, boring to look at, and boring to pitch to an investor group. Which is precisely what you need to research. If you find these problems and then back it up with numbers whether there are many people with this problem, you now have a market that really wants your product.

Our failure:

In our case, once we verified the initial product idea, our CEO decided that we needed to enlarge the scope with another additional feature to be more niche. I started to push back and challenge his approach more and more. I wanted to solve their hard problems together with initial customers. But this was received as not sharing the same vision. If I asked him about the market potential I saw with this, he would argue that his gut says my numbers are off and that I don't understand the market.



Product Vision and Product Development


Now for that market that you define, what exactly do you need to build?

There are many ways to find out. On the one hand, you can build a finished product and then find out if someone wants it. This approach works if you have money and a good research team. They look at a market and then design something for it and see if it takes off immediately. If it does, the product will be pretty successful fast, but 9/10 it will not make it out of beta. This is ok because the 1/10 successful one pays off other fails by far.

On the other hand, customer-centric development means building the product iteratively. You create each step together with customers that actually use the product. You find out what they need with prototypes and discovery; you build the core functions piece by piece, receiving constant feedback from your customers.

I would say, 90% of startup development blogs, VCs, entrepreneur courses and accelerator programs teach this approach.

Why? Because of the feedback. You know you are on track, and if someone wants to invest in you, they see the numbers and early traction. I am not talking about biotech products that need 500k to simply get the raw materials to tinker around with. I talk about easy to build software startups here. If you can't prototype it within two weeks and have people play around with it, you are doing something wrong.

If you want to learn how I do it, feel free to reach out. I'll give you a crash course.



Business Model Vision


When you understand the market and have a vision for a product, you need to think of bringing it to the customers. Estimate how much it costs to develop. How many customers do you need if you charge X amount of money for your product to break even?

These numbers change all the time, but there is a massive difference between making money in B2B versus B2C or B2B2C.

Our failure was that we wanted a different model.

I wanted a fast scaling one, a user centric model that works as foundation for later expansion - he wanted a large customer-centric one, having a big client that finances development.

I would say both can work; however, the timeline is different. As is the potential of pitching to investors.

Collaboration


Whether one person pushes all the ideas and calls the shots or the team works together collaboratively, our failure was that we did not talk about it openly enough.

Working with a micromanager with no room for collaboration does not work for me in an early-stage startup. It works very well in a theatre, a dance company or a musical hall, fashion shows, etc., where every line needs to be on point according to a script.

As a startup still in discovery, you should probably invite clients to a workshop to understand their pain. Then you build key features that solve this. Initially, there are no right or wrong opinions in these collaborative works; that is why design sprints are famous. But it helps you to understand how the other teammates approach the same problem and how this fits your vision. Which is crucial for long term work relationships.


At some point, we all need to focus on your individual skills, and we will stop working together so tightly. Each one will have their respective field they push forward. For this to work one person either controls what everyone does or, you have a team that speaks the same vision and works together as a group in a flat hierarchy.



Character


Character means the people you work with have the same understanding of where to draw the line. They agree on when to put the pedal to the metal and when to hit the brakes.


For instance, I pushed hard to incorporate early on. I proposed using a low-money LLC incorporation (20k in Switzerland) so that we could get clients right away. They could then pay for our service - even if it is just to cover our costs.

Legally, this is important because I want to raise funds later on. And when entering the process of due diligence, for one, having had paying customers without an official contract will beg the question: Who owns the product?

My cofounder brushed it off and said he wanted to use things like consulting contracts or other solutions. We would drag out incorporation as much as possible and immediately incorporate a shareholder corporation once we had an investor.

I suppose I opposed vehemently because then the customer would pay for a service, and we build software for them, software they then use. In other words, the customer would own the product they paid for. Same with a consulting agreement, the client owns the intellectual property of what has been built, not the consultant. As startup, you could loose the rights to your own product because of one single early customer you did not create a proper contract with. That is not optimal, to say the least.



Now with all these differences, we had a deadlock in the team. I am convinced that using whatever means to cut corners will ultimately bite you. Investors will find out during due diligence and then you have different problems. At least, that is my opinion.



 



My takeaway

If startups were a movie, we would open the scene with a "getting a team together" montage. Imagine the Blues Brothers or Oceans Eleven get together the sequence. The entrepreneur recruits people they know and people they trust to be the best for the job.

You need people you trust to do the job and people you can work with towards the same goal. Preferably, people you know have the skillset to go where the project needs.

Yet, most of us are founders who do not have such a set of people and no wealthy parents giving us money to hire people from the get-go. I basically have to tinder-date people I build a long-lasting business relationship with - and find out if they are suited along the way. And I will, but I have to talk to them about things that are not specifically work itself.


Thus, a take away for me is that I should have insisted on continuing our founders' talks and asking for reasoning behind ideas way earlier, communicating general things more often. Not focusing on what we do but why.

Instead of being excited about having a team, I should have asked how they understood terms and definitions. For instance, which businesses are you targeting with your vision and why? How do you define them exactly for yourself? Are we at the point where we want to put ourselves out on the market, or should we be stealthy a bit longer?


Looking at the failure rates of successful entrepreneurs, they all have some things in common: They grind out ideas and projects for a long time. Most fail many ideas until that one million dollar project, vision, and the team comes together.


Thus, no hard feelings, and off to the next one.


Thanks for your time, this one was personal.

cheers, Andreas

bottom of page