The life of an early tech startup is filled with challenges and dangers. The team’s job is to navigate their ship towards success while avoiding cliffs and shallow waters. All while still building the actual boat that employees and customers are preparing to board. The oft-quoted scare statistic is that 89% of European-based startups fail. Their failure is based on several factors, but this much is clear: A great idea doesn’t guarantee success.

And while several of these factors of failure are only partially under a startup’s control — such as competition, market timing, traction, acquiring talent, and securing funding — this puts even greater pressure on the founding team’s ability to perfectly execute their plan. Simply put, a startup must deliver a high-quality, scalable product quickly to survive these treacherous waters.

At Slimmer AI, we deal with this daily as we co-build products (and co-found new companies) with founders. In the spirit of sharing, we’d like to tell you a bit about navigating these waters. So, hop on board, and let’s set sail!

Here be dragons

A popular saying in almost any industry is “Fast, Good, Cheap; pick two.” In software, this is no different. However, a fresh startup with limited resources will need to cherry-pick from all three effectively. The budding product must be reliable and scalable. It also needed to hit the market yesterday. And all of this must happen before funding runs out. Keeping with the naval theme, it leaves startups with a narrow canal to navigate:

There must be a constant balance between delivery and scalability. Delivery, in this case, is any effort spent on getting the product shipped faster. Scalability is any effort to make the product reliable, maintainable, and scalable. In the earliest phase, the channel between these two is extremely narrow. As both the product and organisation mature, the existing stability and traction allow for a bit more leeway. But even then, oversteer in one direction and, “there be dragons”. Before getting into approaches to navigate this narrow channel, let’s get to know our dragons a little better.

Over-steering towards scalability

In this case, too much early effort is spent on making the product scalable. The team is focused on crafting the most abstract, cutting-edge, beautiful software ever. The code itself makes the engineering team weep with tears of pride. However beautiful it may be, this steers us towards the waters of over-engineering.

Examples of what you might observe here are:

• Extensive work is done on a service to handle thousands of transactions per second. The business forecasts this amount won’t be reached in the next five years, if ever.
• Spending weeks on developing a custom library while there’s a proven off-the-shelf solution.
• Splitting your application architecture over many micro-services while an elegant decoupled monolith design would have taken half a year off the initial launch date.
• Engineering saying A and silently doing B because “the business and product people don’t really understand tech”.
• Building too many features in parallel. Having ten things in progress and nothing finished.
• Continuously introducing new technology or changing architecture while not releasing anything valuable to end-users. Repeating this pattern over many development cycles.
• Viewing the product as a collection of technologies while forgetting end-users, the outcomes they need, and what they value.

There really is an xkcd for everything (https://xkcd.com/974/)

This is not in any way meant to understate the importance of technical excellence. Solid engineering is crucial. However, there’s a good reason software engineering veterans are fond of saying things like “YAGNI!” (you ain’t gonna need it!) and “premature optimisation is the root of all evil”.

In an early startup’s case specifically:

• Funds are limited, and every minute counts. There is quite literally no time to waste.
• Products that don’t ship (early) don’t receive feedback. This means the product is being built on hopeful assumptions and little on actual data about what real-world end-users value (and will ultimately pay for).
• Thoughtless over-engineering increases complexity, which in turn increases overhead. Time will be spent purely as upkeep for having built an over-complicated system.
• Traction and necessary funding rely on getting something to the market, which is beloved by users. Preferably before the competition does.
• Focus on end-users and what they will pay for is often lost when “technology for technology’s sake” takes too strong a hold.

A pattern of “not shipping yet” is easily established. When that happens, it often starts reinforcing itself in a vicious cycle:

Ultimately, over-engineering will leave a startup out of funds, and saddled with plans for the world’s most advanced cruise ship. It’s forever unfinished, will never leave the harbour, neither having any passengers, nor reaching a destination. But boy, on paper, it would be so awesome!

Over-steering towards quick delivery

Let’s look at the other side of the coin: too much focus on rapid delivery. This involves cutting corners to be faster, creating what’s known as “technical debt”.

These waters are often entered by some combination of the following:

• Starting with a small prototype or MVP to validate the product’s feasibility and market reaction. Once the first prototype is built, the startup quickly moves to adding more features instead of stabilising, refactoring, or rebuilding the MVP. Essentially, they try to scale what was not made to be scaled, and are then disappointed at its poor performance.
• Setting unrealistic arbitrary deadlines based on what business-wise sounds good, without involving engineering in these decisions.
• Engineering is pressured to deliver to said deadlines. Wanting to help, and ultimately subject to business and product decisions, the engineering team says: “we’ll do our absolute best”. The silent part being: “just don’t ask how or what our level of confidence is”.
• Engineers not having the experience or courage to really step on the brakes; unable to explain the impact of trade-offs in a way that’s truly understood by the business and product side.
• Business and product assuming engineers are overreacting and want to “gold-plate” everything. In their eyes, the engineers are in love with tech, make things too complicated, and don’t understand the reality of business.
• All the above leads to an outright disconnect between the startup’s business, product, and engineering side. One venture living in two realities.

Source: Dilbert (https://dilbert.com/strip/2013-06-19)

The term “technical debt” is very fitting because a startup essentially takes out a “loan”, which they invest in being faster; faster to validate, grab market share, attract funding, and so on. The “debt” in this case, consists of abandoning technical good practices, which must be paid back by fixing it later. The interest on this debt, is that new work on the product becomes increasingly complicated. The product becomes unpredictable and unstable due to the shortcuts taken earlier. This is not a disaster, if the startup pays its tech debts back in time. However, if the startup doesn’t course-correct by paying its debts, the following dragons will start to surface:

• Technical debt slows down progress. This paradoxically leads to the creation of even more debt to make up for “time lost”.
• New features take longer and longer to build due to increased complications and time spent firefighting. Engineers must work around the workarounds.
• Customers grow increasingly angry due to the product’s unreliability.
• Additional managers and coordinators are hired to manage the mess in customer support, engineering and other places on fire. These people can’t really extinguish the fires, so they move them around while making noise. The overhead of this coordination increases the rate at which funds are spent. At best, they’re addressing symptoms; more likely, it’s making things worse.
• Tech debt interest multiplies until technical bankruptcy, the proverbial “burning platform”.
• Engineering talent leaves because they do not feel taken seriously, are pressured into shortcuts, and can’t be masters of their craft. Nobody wants to work on a burning platform where putting out one fire creates three new ones.
• New funding can’t be acquired because technical due diligence will reveal the mess. Or, further funding is obtained but can’t be used for scaling the business. Instead, it must be used to put out the existing fires. Success, goals and growth the funding was meant to unlock will not be reached.

In short: another vicious cycle kicks off. Time lost on tech debt and its interest is compounded with new shortcuts. This leads to even more tech debt and a need for even more shortcuts. The shakier the platform gets, the harder it becomes to implement structural improvements. Pretty soon, you’re drowning in debt as your product is tech debt all the way down.

Navigating the narrow channel

We now have a picture of what not to do. Over-engineering ends in never releasing, no traction and running out of funds. Delivering too fast sets you up with a burning platform that will never scale. Both can even happen at the same time. The team starts working on several features in parallel and never finishes them due to the lack of focus and being spread thin. The small number of features that finally do get finished are rushed out the door with substantial technical debt. Few things make it out the door, and when they do, it’s tech-debt-ridden rubbish.

It all sounds rather obvious and straightforward. Don’t spend years building the perfect thing. Also, don’t ship a terrible buggy product. Fixed it! However, as is often the case, simple does not equal easy. It is a deeply tough challenge: especially for startups who are learning on-the-go with no safety nets or second chances.

So, how do we stay within the boundaries? What markers can we put in place to guide us? How do we quickly detect we’ve drifted off and course correct accordingly? What lessons hold true, even when every startup’s context is different?

At Slimmer AI, we find the following patterns to be helpful:

• Make the narrow canal an inclusive question.
• Prioritise transparency and psychological safety.
• Deliver in short cycles with clear goals.
• Build strong product and technical ownership.
• Focus on efforts that accomplish both.

Entire books have been written about every single item on this list. Still, let’s shortly go into each of them. Let’s also dive into why they matter in this context, and what are good starting points for establishing them.

Making the narrow path an inclusive question

The balance between delivery and scalability is often a source of friction between business, product and engineering. “We need to validate feature x asap, but engineering is insisting we need to migrate to cloud servers first.” or “We need automated functional testing asap, but product needs us to deliver v1 of feature x, so we can’t fit testing in.”. It becomes a battle between people with the same goals and seeking the same outcomes. In most modern cross-functional product teams, these people are literally on the same team.

Cheesy as it may sound, a great approach here is replacing “but” with “and”. This creates something known as a wicked question. A statement meant to bridge what appears to be in contradiction or examine why a contradiction exists. Moving forward, what path can we follow to create a win-win situation? “How can we validate feature x while moving to cloud servers?” or “How can we roll out automated functional testing and release the first slice of feature x?” These questions invite collaboration and creativity. They encourage scoping and slicing towards an approach that covers both delivery and scalability.

In practice, this means frequently huddling around these questions with everyone involved. This can happen at any time, but for sure when:

• Planning upcoming work, both on a high-level as well as the details regarding the next development cycles.
• Reviewing results of the previous development cycle and the implications for moving forward.

Have business, product, engineering, marketing, sales, and whomever else is involved in the same room with an equal say. Start asking inclusive ‘wicked’ questions and collaborate on shaping a path together. Get creative and make a game plan. Step away from the results for a moment, and work on how you work together.

Scrum.org, Make the wicked question of your team apparent.

Having an experienced Product Manager / Product Owner is of great help here. They know how to shape this inclusive path. They will include the end-user perspective while bridging business and tech. If there are no funds to get one, at the very least have somebody take on the Product Owner role. For starters: this excellent 15 minute video on Agile Product Ownership by Henrik Kniberg explains the role better than most multi-day courses.

Prioritising transparency and psychological safety

Asking questions is pointless when those who are asked can’t answer truthfully. This could be because they don’t have the necessary context to answer, or because they are afraid to speak the truth, but the results are equally bad. You can’t navigate the narrow canal if you don’t know where you are. It’s therefore paramount to prioritise a culture of transparency and psychological safety.

Extensive research has been done into the role transparency and psychological safety play in team and company success. Project Aristotle was a large Google research project from 2012 to 2014, analysing hundreds of teams and the factors that contributed to their success. The number one uniting factor among successful teams turned out to be: psychological safety. In their words: “Team members feel safe to take risks and feel vulnerable in front of each other.” In other words: if you want to have radically honest conversations that get to the heart and reality of things, people will need to feel safe enough to have those conversations.

Establishing psychological safety is hard work. It’s also extremely fragile. As soon as honesty, courage, or vulnerability is met with negative consequences, it breaks apart. As we are essentially still group animals, we quickly learn that the honest and vulnerable path leads to danger. Defences are quickly raised; people start saying what they assume others want to hear instead of the truth. It’s therefore essential that:

• Being human and bringing your whole self to work is standard practice.
• Honesty and vulnerability are considered normal.
• Those displaying it are in turn met with honesty and support.
• Full transparency is the default mode for everything.
• People in leadership positions wholeheartedly exemplify all of this.

To those interested in a deeper dive into psychological safety, I highly recommend the book ‘The Five Dysfunctions of a Team’ by Patrick Lencioni. It highlights psychological safety’s importance and how it’s the foundation for other key aspects of high-performing teams.

Project Aristotle and Lencioni Diagrams (Source: richardhughesjones.com, Image Remade by: Slimmer AI)

Delivering in short cycles with clear goals

Virtually any startup product team will be working in short cycles. Maybe they work with Scrum or perhaps some Agile-inspired custom workflow. It’s unlikely they work in the classic “waterfall” way; multi-month or year projects with a big-bang release. Still, small cycles can end up being a façade for what’s essentially still a waterfall spread over many steps. This is where over-engineering can easily take hold.

Waterfall façade by Agile terminology hacking (Source: Serious Scrum, Image Remade by: Slimmer AI)

To prevent ending up with a waterfall façade, two principles are crucial:

• Ensure that each cycle has a clear goal for delivering value to end-users.
• Ensure that each cycle delivers a slice of working product for reaching this goal.

The combination of these two principles guarantees we move the ship towards our goal with something valuable to show for it. A working product allows the team and stakeholders to truly inspect what has been built, where that puts them, and what the next cycle can deliver. Feedback and validation are gathered as early as possible. Starting from the first cycle, we’re moving out of the harbour and demonstrably delivering value.

Focus on efforts that do both

Some efforts pack twice the punch. They aid in faster delivery and improve scalability. Classic examples in software are continuous delivery and automated testing. They allow a team to release small slices faster but also be confident about their quality due to test automation. When implemented from day one, the code, tests and infrastructure to support this can grow alongside the product. It becomes part of the narrow canal and allows for crossing it at more incredible speed. A true multiplier.

Unfortunately, infrastructure is often not considered as sexy as new features. It doesn’t get an equal seat at the table when product planning and roadmaps are discussed. It should. Because as said, having good infrastructure and test automation means you can ship with confidence and get initial value to customers much faster. A good setup also allows you to pivot or roll back faster. Foremost: if you can’t ship your product, it has no value.

Proper attention to infrastructure comes back to getting everyone in the team involved. Make “how do we get to x” a question that involves all disciplines. Crucial starting points:

• In general, spend time aligning technical ‘multipliers’ with your product releases. Once again: prioritise inclusive conversations that lead to a holistic game plan.
• Make infrastructure a first-class citizen involved in all levels of product planning.
• Make continuous deployments with automated testing a priority from DAY ONE. This way, it evolves smoothly with the product. Start any later, and it soon becomes a gargantuan task.

Continuous Delivery (Source: DevOps International, Image Remade by: Slimmer AI)

Strong product and technical leadership

Apart from principles and practices, it’s worth looking into who should champion their adoption. Of course, a small startup team must collectively navigate the ship and make it happen. However, in the context of delivery and scalability, it’s worth highlighting two essential roles.

1 Product Ownership: a role that can go by many names but is so crucial we’re pointing it out a second time. In any case, the PO is the central person accountable for the value of the product being developed. Their experienced product management includes asking and answering important questions such as: what is prioritised, what do customers value, what does success look like, what do stakeholders need, what is our strategy, what is unknown and assumed, what requires validation, et cetera. A good PO is also able to include engineering partners in this by:

• Including engineering early; during product ideation, discovery and planning.
• Being able to take engineers along for the ride in the business and customer side of developing a product.
• Showing engineers the impact each of their development cycles is making.

The level of inclusion can, of course, vary from informing to close collaboration, but very few activities should happen in total isolation.

This is a friendly reminder to see the short video on Product Ownership mentioned earlier is a great primer for those wanting to learn more about the role. For those that wish to take a deep dive, we consider Marty Cagan’s Inspired the standard work on modern product management in startup and scale-up environments.

2 Technical Ownership: the principal engineer, lead developer, software architect, and hands-on CTO. Essentially, this person is the go-to lead in all technology choices. Starting with a simple architecture that elegantly scales from a rowboat to cruise ship is hard. It’s not just programming, it’s the whole ecosystem and platform lifecycle. Experience is invaluable. Apart from evident tech seniority, this person also needs to be knowledgeable on the product side. They must be motivated by continuous learning, creating value for end-users and making a real impact. To them, technology is simply the means, not the goal.

Apart from experience and skills, both roles have to ‘bridge the gap’. Product needs to understand and truly feel the importance of solid tech. Tech must understand and truly feel the importance of product management, delivery and end-user value. Both must not be afraid of branching into ‘the other side’. Both must welcome inclusive conversations, putting the success of the product and business ahead of ego.

Involve experienced coaching

Even with the best of intentions on all sides, it’s still not easy to get this 100% right. These lessons were learned by making mistakes, trying again, and making new mistakes. It’s messy, beautiful, fun, and frustrating all at the same time. If there is one bottom-line advice: begin with prioritising transparency, inclusion, honesty, and courage. Getting somewhere starts by knowing where you truly are.

Leveraging an experienced coach will help make this process far easier, and will unlock the potential of your experienced product and engineering leaders. You’ll avoid some of the classic mistakes to make the new ones faster. Team coaching can help build a better environment with a greater chance for success.

At Slimmer AI, we help startup teams working on applied AI products with each of these areas, and have navigated these waters several times over. The nature of our work — as a true tech company that invests and co-builds — puts us in a unique position to help founders understand what it will practically take to build incredible products, high-performing teams, and successful scalable businesses.

If you’d like to learn more about my best practices and my role as Product Delivery Manager at Slimmer AI, please reach out! I love to ‘talk shop’. And if you’re ready to start your own startup journey, please see our Venture Studio page for more information about our founder programs and offerings.

‍