The top 5 mistakes of non tech co founders

The top 5 mistakes of non tech co founders
Photo by Mika Baumeister on Unsplash

Throughout my career and especially In the last few years I had the opportunity to offer advice to tens of technology startups at different stages of maturity.

After having similar conversations with multiple people on the same topics I have decided to do a write up of the top 5 mistakes every non tech cofounder makes while trying to start a technology company.

If you are thinking about being a founder but are not really technical, this blog post is for you.

I hope this will help you speed up your journey and avoid costly mistakes.

#1 - Not know anything about technology

With the notable exception of Apple, all successful software companies in Silicon Valley were started by people with a tech background.

There are strong reasons for this: you can’t run a tech company without basic knowledge of web and mobile technologies, APIs and integration. Now: I am not advocating for business co founders to get an IT degree but a basic understanding of possibilities and limitations of each technological approach is needed.

The biggest issue with not having enough knowledge of tech is that you can’t excerpt any meaningful supervision around the technical choices made and cannot understand the tradeoffs involved - even at a high level - and how they impact your business.

A typical example is when your tech team decides to experiment with new and shiny technologies without fully understanding that not all tech is ready for prime time.

Skilled engineers instead prefer to stick to boring technology - because they know exactly how it will perform in production and how it will handle scale.

A few years ago there was a lot of experimentation in the database space and new technologies were launched every few months. I still remember seeing companies jumping on the bandwagon before these products had reached a meaningful level of maturity, sometimes with huge impacts in terms of stability and data loss.

Another typical issue with over trusting your tech cofounder is over optimization: software engineers - like all technical people - have the natural tendency to look at ways to achieve better scalability, maintainability and robustness before these requirements are really needed.

When there are too many unknown unknowns - like it’s typical for early stage startups - these early optimisations are really counterproductive because they add unnecessary complexity which leads to slower development cycles.

As portrayed in the movie The Social Network, Facebook in the early days started with the simplest setup (1 database server and 1 web server) and the simplest tech (PHP and Mysql) possible and added complexity only after the user base out-grew the current setup, not before.

The same can be said of Google and there are some interesting talks online about how the system architecture at Google naturally evolved only when it really needed to. Cloud providers also have the tendency to advocate for a lot of best practices which end up increasing hosting costs significantly.

Closer to my personal experience are countless examples of premature optimisation like:

Key takeaways:

  1. Skill yourself around the basics of web and cloud technology.
  2. Don’t be afraid to question every choice your tech cofounder makes.
  3. Suggest simplicity and boring technology and optimise only when you really need it.

#2 - Every feature has a cost

This issue is very dear to me as I’ve seen this in practically every single product I worked on.

It’s very common for successful software products to experience very little traction for quite a while and go through many iterations before getting to market fitness.

As your company builds out their SaaS proposition it’s very tempting to add feature after feature in order to increase the value offered to customers.

This makes sense intuitively as

  1. people from sales, product and support provide feedback and requests changes as they use the product or try to sell it
  2. at least some of your developers are employed permanently.

So if the development spending is ongoing and relatively fixed and you have a constant stream of internal feedback you may want to naturally make the most out of both.

There is however a hidden cost associated with each feature you add: code bases have the tendency to grow complex over time as more and more features are introduced.

The problem with complexity in general is that:

  1. it is the enemy of execution - it slows down the development of features that are really needed when you most need them the most.
  2. it increases your ongoing operational costs - as more developers and devops resources are required just to keep the machine running.
  3. it’s usually an indicator of lack of focus.

Most technical people will nowadays tell you that the solution to complex software is to create a microservice architecture. Unfortunately microservices make complexity more manageable but they don’t take it away and their use comes at a cost compared to having a simpler architecture.

The only effective solution to this problem is to understand and monitor your clients' behaviour and needs and relentlessly work to remove the features that are not used.

It may come across as a counterintuitive yet this approach is relatively common in the industry: Google - for example - is famous for killing products and features that don’t get enough traction.

In order to know what’s being used and what isn’t analytics tools are essential. Without analytics you are flying blind as you don’t know what your customers are doing with your product. Thankfully there are now literally tens of solutions available that do not require any custom development and provide great insights at a very low cost.

Analytical tools help uncover what your customers are doing but you can go a step further. Even more valuable is understanding why they are doing it.

If you have a lot of users you can rely on regular surveys - and once again there are a lot of cheap/free tools available in this space - whereas if you only have only a few important clients don’t be afraid to ask them directly what they love and what they don’t in your product - in a meeting or over the phone.

Once you know what’s important to your customers and why, all you need to do is get the courage to pick up the axe and start removing what’s not needed - in pure Marie Kondo style. It’s the only way to remain nimble and innovate quickly over time.

Key takeaways:

  1. Good software offers a handful of essential features and delivers them well.
  2. Put analytics in your code to determine what’s really important and what’s not
  3. be ruthless in removing what’s not needed nor used

#3 - Not enough research

Building software is an incredibly complex and expensive endeavour, requiring highly specialized expertise across multiple disciplines: software development, product management and user experience.

It’s tempting to think that you can get started with just a single developer and a great idea yet your chances of success in doing so are just very very low.

And there is a reason for this: building software is very expensive so building the wrong product is extremely wasteful.

In 2019 the top 2 reasons startups failed in the US were:

  1. no market need and
  2. ran out of cash.

What makes creating a successful startup more complicated is that worldwide discretionary spending has been on a decreasing trajectory for many years now and that successful products need to be disruptive in nature - which makes them harder to build.

Too many times unfortunately, startup co-founders are animated by a healthy bias to action and just want to start building stuff without knowing enough about their potential customers and markets.

This is a big topic and there are lots of powerful tools and techniques to help planning, ideation, prototyping and testing of new ideas like design sprints, lean canvas, user story maps etc. before carrying out any development work.

The most common objections that I hear to this approach are:

  1. I know what the customer wants. No you don’t. Nobody does and even if you are lucky to be right, the customer needs change over time so you need a system to capture and validate that.
  2. It will look bad if we ask so many questions. On the contrary time spent in the day to day with your potential customers can be a source of invaluable information and will make them feel valued and listened to - something everyone values.
  3. It’s just too late, we have already promised a pony and we just need to deliver a pony. It’s never too late to build the wrong product because the client either will get cold feet at the 11th hour or cancel the contract as soon as it’s financially viable if the product isn’t needed.

All in all building disruptive products is not an exact science and there aren’t turnkey solutions but having done no solid research upfront is a recipe for failure.

Key takeaways:

  1. Be curious and think unknown unknowns
  2. Prototype and validate before you build
  3. Don’t fall into the typical trap of making getting attached to unvalidated ideas about market needs

#4 - Not thinking about data ownership

This is a common issue with B2B products and to a lesser extent with B2C ones.

Consumers on average don’t value their personal data too much - although things are changing - and are usually happy to give that up in exchange for free/semi free access to online products. After all nobody pays to use Google nor Facebook but both Google and Facebook still make huge profits by monetising our personal data and selling the capability to produce targeted ads to other businesses.

If you are a company targeting the enterprise market instead things are significantly more complicated.

Your solution will inevitably require to store some of your customer’s data and it’s very tempting to start looking at that information as something you own and can monetize in one way or another.

The issue with this simplistic approach is that if that’s true that most companies don’t do much with the data they have, still they simply don’t like the idea of sharing it.

Sharing data is seen as a big risk as it may give away precious information to competitors.

And it doesn’t really matter if you promise that you won’t: the sole fact that you have potentially valuable client data within your systems is currently seen as a security risk in itself. Breaches happen all the time and businesses are becoming more and more weary of these events and their PR and monetary consequences.

There are of course industry specific solutions to these problems but in my experience they are never simple nor straightforward.

So always think about who will own and store your customers' data and actively try to understand from day 1 what specific situation you will face from a market and regulatory perspective.

Key takeaways:

  1. Think about data ownership. There is no easy solution.
  2. Don’t predicate your revenues on B2B data sharing as you will find endless hurdles.

#5 - Underestimating the problem of integration

Integrations are what make different softwares talk with each other and the problem of integration is at least as old as computer science itself.

Nowadays most companies use a best-of-breed approach where multiple independent software vendors are chosen to offer specialised vertically integrated solutions that need - at some point - some type of interface.

As an example it’s not unusual to have companies choose GSuite for email, Dropbox for file sharing, Xero for accounting and Salesforce for marketing.

Chances are that you are also building a new vertically integrated solution of some sort so thinking about supporting integration with the other players is key.

All modern software nowadays comes with a full set of APIs - and yours shouldn’t be an exception. If you are unfamiliar with the term, tou can think of an API as a standardized and documented language which is specific to your product and that makes integration possible without batch files and other archaic means.

Having a series of vertically integrated solutions all exposing APIs is a starting point but APIs simply don’t talk to other APIs natively.

Between each set of APIs you need a connector. Once again - if you are not familiar with the term - you can think of a connector as the translation layer between different APIs.

The translation requires knowledge of:

  1. the source system’s data model
  2. the target system’s data model
  3. the client specific deployment configuration

Depending on the fragmentation of the industry you are operating in - the number of connectors to develop and maintain can grow very big over time: in the hospitality industry for example there are hundreds of online travel agencies and hotel systems and any software that operates in that industry needs to handle the integration with most of these systems in one way or another .

The good news is that thanks to modern cloud technologies it’s quite easy to get started building connectors with limited development effort: you can get started literally in hours. There are even companies like Zapier that offer no-code integration-as-a-service solutions for small businesses.

But don’t be fooled: each connector comes with significant and not immediately evident maintenance costs.

Brutally speaking: connectors break all the time.

Your team cannot control the roadmap and configuration of the product you are integrating with and this leads to constant issues like:

This is the crux of the problem: from the business perspective - depending on the level of customization - connectors can create significant stickiness with your clients as they effectively act as the technical glue to support business processes that are very hard to change once in place.

But this stickiness is achieved in exchange for more complexity and significant ongoing maintenance costs that need to be factored into your pricing model.

Key takeaways:

  1. Connectors create significant customer stickiness but they are not free
  2. Each integration is a high maintenance feature - if you have too many to maintain your operational costs will explode and your delivery speed will plummet.

Comments

comments powered by Disqus

Subscribe to my newsletter