The time to market vs. quality dilemma

Every day we have less time to ship new features and updates to production. A faster time to market can bring a lot of value to the business — but only if it comes with quality. Takt Time and Time to Market Takt time is a German term that refers to the baton used by conductors to set the pace or rhythm of an orchestra. In Lean Manufacturing, Takt Time represents the time needed to produce a product. In software, we can say that Takt Time is the time it takes for a feature to go live. In other words, it’s the time a team needs to take a feature idea from spec to real usage by users. Time to Market is the time it takes for a product to reach the market. The risk of prioritizing speed (short term) over quality It’s super common for companies, in the rush to beat the competition, to prioritize speed over quality. And yeah, delivering value to customers faster is super important these days. But when we ignore quality just to chase the illusion of speed, that’s when the problems show up. That quick hack or skipping a test might seem to make sense in the moment — but not long after, you’ll see that sacrificing quality didn’t bring anything but a false sense of progress. Maintenance headaches, bugs, performance issues… classic symptoms of tech debt everyone knows. Let’s imagine a software project where, under launch pressure, the team didn’t take the time to build things the right way. A bunch of hacks and low-quality code went live with no thought for the future. Six months later, the project’s grown, several features are already in production, and now you need to ship an update — but here’s the kind of code you’re dealing with: Just imagine how long you’ll spend just trying to figure out what’s going on in this code. Now imagine fixing or adding something. Of course, this is an exaggerated example just to make a point. Below, I mocked up a throughput graph to help us visualize what usually happens in these cases. In the chart above, we’re looking at a (hypothetical but common) scenario where at the start of the project, the team delivered more tasks, but with low quality. Over time, we can see team velocity drops hard — because the code became harder to maintain. How to balance time to market and quality? As we saw, the false sense of speed is a long-term trap. But how can we balance the speed we need to stay competitive and the quality we need to not lose control of the project? Agile methodologies The biggest reason we fall into the speed trap is a misunderstanding of what real speed and continuous value delivery actually mean. What we really need is to let users try new features as fast as possible. That’s where agile methods like SCRUM and KANBAN come in — with incremental processes, we can release new features regularly, without waiting 6 months (or even a year) to find out if users even want them. Continuous delivery To fully benefit from agile, we need to automate our production deploy. That way, we can ship new features almost in real time. For example, Amazon was doing 1 deploy every 11.6 seconds back in 2011 — which let them test way more with real users. According to the article linked above, here are the benefits companies see when they automate their deploys: ~40% reduction in overall development cost ~140% more new programs in development 78% reduction in development cost per program 5x increase in innovation-driving features Unit tests For continuous delivery to work, the system needs to be really well-tested. That’s why unit tests — the simplest and most recommended — are key to making it happen.

Mar 31, 2025 - 20:06

Every day we have less time to ship new features and updates to production. A faster time to market can bring a lot of value to the business — but only if it comes with quality.

Takt Time and Time to Market

Takt time is a German term that refers to the baton used by conductors to set the pace or rhythm of an orchestra.

In Lean Manufacturing, Takt Time represents the time needed to produce a product. In software, we can say that Takt Time is the time it takes for a feature to go live. In other words, it’s the time a team needs to take a feature idea from spec to real usage by users.

Time to Market is the time it takes for a product to reach the market.

The risk of prioritizing speed (short term) over quality

It’s super common for companies, in the rush to beat the competition, to prioritize speed over quality. And yeah, delivering value to customers faster is super important these days.

But when we ignore quality just to chase the illusion of speed, that’s when the problems show up. That quick hack or skipping a test might seem to make sense in the moment — but not long after, you’ll see that sacrificing quality didn’t bring anything but a false sense of progress. Maintenance headaches, bugs, performance issues… classic symptoms of tech debt everyone knows.

Let’s imagine a software project where, under launch pressure, the team didn’t take the time to build things the right way. A bunch of hacks and low-quality code went live with no thought for the future. Six months later, the project’s grown, several features are already in production, and now you need to ship an update — but here’s the kind of code you’re dealing with:

Just imagine how long you’ll spend just trying to figure out what’s going on in this code. Now imagine fixing or adding something. Of course, this is an exaggerated example just to make a point.

Below, I mocked up a throughput graph to help us visualize what usually happens in these cases.

In the chart above, we’re looking at a (hypothetical but common) scenario where at the start of the project, the team delivered more tasks, but with low quality. Over time, we can see team velocity drops hard — because the code became harder to maintain.

How to balance time to market and quality?

As we saw, the false sense of speed is a long-term trap. But how can we balance the speed we need to stay competitive and the quality we need to not lose control of the project?

Agile methodologies

The biggest reason we fall into the speed trap is a misunderstanding of what real speed and continuous value delivery actually mean. What we really need is to let users try new features as fast as possible. That’s where agile methods like SCRUM and KANBAN come in — with incremental processes, we can release new features regularly, without waiting 6 months (or even a year) to find out if users even want them.

Continuous delivery

To fully benefit from agile, we need to automate our production deploy. That way, we can ship new features almost in real time. For example, Amazon was doing 1 deploy every 11.6 seconds back in 2011 — which let them test way more with real users.

According to the article linked above, here are the benefits companies see when they automate their deploys:

~40% reduction in overall development cost
~140% more new programs in development
78% reduction in development cost per program
5x increase in innovation-driving features

Unit tests

For continuous delivery to work, the system needs to be really well-tested. That’s why unit tests — the simplest and most recommended — are key to making it happen.