For the last two decades, I’ve worked with startups in various ways, as a director/board member, running an incubator, conducting due diligence in M&A teams, and providing advice to associates who are starting up new businesses. There seem to be a few fundamental, recurrent challenges facing tech startups. 

Product strategy challenges

The challenges businesses faced varied. Some had invested too much into products that couldn’t be monetised, while others were trying to build a laundry list of products that they simply didn’t have the resources to build. The root cause generally boiled down to a lack of product strategy, with product teams not tasked with formulating a strategy but rather collating requests and funnelling them into engineering.

Engineering challenges

Engineering teams faced some challenges that were relatively easy to rectify, such as improving automated testing, implementing secure SDLCs, and improving team capabilities.

However, engineering teams faced a more fundamental challenge: organisations often viewed their teams as a cost needing immediate recuperation.

When deciding whether to build or buy, organisations often make rudimentary projections: It will cost $50,000 to build, and if we buy it, it will cost $100,000 over 5 years. Therefore, the correct long-term decision is to build! Everyone was happy; the organisation had completed its due diligence; management was delighted; they had saved money long term.

So, what’s the problem? Was it that they spent money on engineering something up front that might not make any money? Was it that sometimes the engineering team built the product on a faulty premise, and it wasn’t fit for purpose? Sure, sometimes these were issues. However, the main problem was that organisations were looking at the cost of engineering teams rather than the value of the engineering team to the company.

An engineer in a SaaS company isn’t providing a small margin of return; they are providing exponentially higher returns than their salary. So, the slight pause the engineering team takes to work on the project doesn’t cost a few thousand dollars in resources. The cost is engineering output velocity, which could be the difference between launching a novel product into the market versus launching half a year later when 10 competitors have launched their products.

That’s not to say that building is never the correct choice, but it’s probably not the proper choice if the only benefit is an estimated cost saving, which is likely wrong.

The plan

The bottom line for organisations is that tech leadership must have a plan. That plan begins with understanding what kind of value creation you should expect from your engineering/product organisations. This should give you a good measuring stick for whether a product is viable prior to going out and spending millions on developing it.

Having been through this process many times in the last two decades and having witnessed numerous blunders, including my own, I’ve realised that many founders need this kind of advice. A number of them, whom I’ve advised, have been egging me on for years to form a fractional CTO/CISO service so that we can work more closely. In discussions with startup Cx’s in the last year, I’ve received clear signals that teams are getting smaller, more dynamic and that this kind of fractional leadership service is a vital industry need. So, with that, I’m happy to announce the launching of Lunaori Pte Ltd out of Singapore (and in discussions to expand beyond).

PS. You’ll notice that Lunaori offers fractional CISO and fractional CTO services, but I’ve not touched upon cybersecurity in this blog post. I had included a cybersecurity section, but this started to look more like a screed than a blog post. So stay tuned; I will be posting about the state of CISO/Cybersecurity in startups in SEAsia shortly.