Time to market – 3 do’s and 2 don’ts

Some companies simply obsess over time to market. And for a good reason, it seems. When it comes to software development, an industry where market changes every day, being first out of the gate seems like a good strategy. There certainly are benefits to having a short time to market (which we’ll discuss), but perhaps not at all cost. When the quality starts to suffer, that’s when you’re treading a thin line between the success of being first to market and the failure of offering a subpar product.

But first, what is time to market?

Common knowledge will tell you that time to market (TTM) is measured as the amount of time that elapses between when a company starts working on a product or a feature and when it releases it to the market. Time to market is sometimes also referred to as “speed to market” and is one of the key performance indicators (KPIs) that are used to measure the effectiveness of the company’s product development process.

However, this is a very flawed definition. Especially when it comes to software development, the terms are very much subject to interpretation for a bunch of reasons.

Where does it begin?

Let’s first disect the “start.” When does the company start working on a product or feature? When someone comes up with the initial idea? When it goes through the entire approval process? When the development team writes the first line of code?

In software development, you can come across the term “fuzzy front end” (or “the front end of innovation,” or “phase 0”). It’s the conceptualization stage that happens before actual product development. While theoretically nothing gets written then, all the conceptual work is necessary for the team to know what it’s supposed to do. And, importantly, it will save them a lot of time later. Which is why some companies include phase 0 in their time to market and put emphasis on going through it efficiently.

And where does it end?

On the other end, there’s the question of when is a product released to the market? When you release it for beta testing, does that mean the product development process is done? Or is a minimum viable product (MVP) an actual product? And if yes, then how will the later development affect your budget and KPIs? There are many stages of development process that a product goes through before we consider it “final.” All of them are important milestones, so some companies consider individual time to market for each of them separately. This helps them see how much they still have to go and where they could optimize in the future.

How do you measure it?

Lastly, there’s the issue of measuring units. When you know what your starting and ending points are, do you measure time to market in days or manhours? For companies that “follow the sun” (i.e. work with globally distributed teams that take over development process in shifts, like in a relay race) manhours don’t differ that much from days. But usually companies work with smaller teams that are not distributed. Then, if you consider 8 hour shifts, weekends, and holidays, the discrepancy becomes much more apparent and you have to factor it into your estimates.

So whenever you talk about “time to market,” especially if you want to make it a measurable KPI, you need to discuss all these aspects. There isn’t really one proper way of defining them – some definitions will work better for your use-case than others. What’s important is to agree on one definition internally and have clarity across the board.

Why is time to market so important?

Now that we (more-or-less) know what time to market is we should perhaps ask ourselves why even talk about it? Time to market is definitely one of those KPIs that companies like to obsess over. And while we’re not fans of going to the extremes, we do agree it is important and should be measured. Here are some reasons why.

Early bird advantage

You are probably familiar with the concept of product adoption curve. It shows how people embrace new products in stages – from innovators to laggards. While it doesn’t always pay off to be the first to the market (trailblazing is an expensive endeavor, after all), it certainly pays off to be there early.

This is because earlier players can count on a competitive advantage in the form of a bigger part of the market share. Those who join the market very late can mostly count on about 16% of the “laggards” to be interested in their product. The rest of the consumers most likely already have their preferences set. Meanwhile, early players can count on 84-97.5% of market share! And that’s with less competition in the initial stages of product adoption where there aren’t so many market demands and consumers have lower expectations of the product.

From that perspective the time it takes to launch a product can literally be the deciding factor in its success. It can also be the only competitive advantage one has.

Time to innovate

We’ve already mentioned that early adopters are more forgiving towards new products. Just think what you expected from your operating system in 1997 versus now and you’ll get the idea. This gives you one more advantage: time to experiment on a living organism.

The earlier your product hits the shelves, the more time you have to test it and iterate. And you’ll be using customer feedback, and not just insights from a narrow pool of enlisted testers. That’s something your competitors who are still in the development phase don’t have. When you release bug fixes, users will be happy to see that progress is being made. When you implement new features that stem from user demand, they will be delighted to see the product offer even more than before.

Contrast this with a product that’s been released later and already has a strong competition that has a good, practical understanding of their market. Here, bugs and missing features can severely affect customer satisfaction and send customers looking elsewhere.

Investment payoff

As we’ve already established, if you’re joining the arms race late, you’ll have to bring in a lot of guns with you. Simply put, you need to develop all the features your direct competitors already have, and then some. This means a lot of upfront investment in time and resources to make up for the lost competitive advantage.

Meanwhile, in the tech and digital space, products sometimes become obsolete in a matter of months, best case scenario – years. Think about the lifespan of the iPod (about a decade) or Vine (remember Vine? It was there for, like, three years).

It can happen that before your product takes off, nobody is going to be interested anymore. The solution will have become obsolete before it even paid off. That’s why it’s so important to not just analyze product-market fit and market opportunities before you start working on your project. It’s also crucial to evaluate if the time to market is going to affect these.

What’s a typical time to market for software?

Whenever we’re asked upfront what’s a typical time to market for software, we always respond with a high degree of confidence: it depends.

There’s a great variety in typical time to market from industry to industry. Think pharma, where it takes decades to develop and test medicine, versus electronics, where it can take less than a year. But there’s also a variety within the software industry.

We’ve had clients where product development process took us three months from concept to launch. But more realistically, it takes up to a year to come up with an initial product release and then just as much time to refine it later.

What affects time to market?

Assuming we’re only talking about software development, there’s a number of factors that affect time to market. Some of them are:

• project complexity – naturally, some applications are more complicated than others. It can be because they are demanding technically, have a large set of features, or complex workflows. All these things simply mean you need more elbow grease to get the app to where it needs to be.
• technology you choose – just like building a landing page in WordPress is easier than writing it from scratch, there are many shortcuts developers can rely on to speed up their work. For example, we like to use libraries.
• available resources – and we don’t just mean “human resources,” though obviously the more people you have working on your project, the faster it will be done. But if you’re waiting on funding …

How to improve time to market?

Ah, the question everyone’s asking! Now that we know time to market is actually crucial, how do we optimize it? Here are three trade offs you can make to improve it, and two you shouldn’t even think of!

Do: allocate more resources

As we’ve already said: resource availability directly affects your time to market. So it goes without saying that the more money you spend and the more people you hire, the faster your time to market will be. And you don’t even need to hire an inside team. You can outsource parts of (or the entire) work to external vendors that specialize in software development, like one of our clients did.

Easier said than done, though, right? If we had unlimited resources, we wouldn’t have a problem, but we usually don’t. So here are some other things to consider.

Do: Work smarter, not harder

If you can’t have more resources, the next best thing is to extract the most from the ones you already have. This can mean:

• optimizing processes (for example, implementing scrum) to make decision-making faster and avoid confusion about the next steps;
• using tools (such as Jira) and techniques (such as concurrent engineering) that will allow you to speed up work or even do several steps at the same time;
• or automating activities (for example, introducing automated testing).

Do: Drop the ballast

If resources are not available and your processes are spotless, it might be time to start thinking about reducing the scope of your project. It’s good to have a prioritized product backlog just for that occasion. What are the must-haves without which your product will be worthless? And what are the nice-to-haves that you can add later?  Consider if your product won’t be better off done and released instead of perfect and still in development.

Don’t: sacrifice quality

At the same time, remember that there’s a difference between giving up quantity (the number of features) and quality (the performance of the features). Many companies fall for the sunken cost fallacy. They feel tempted to publish whatever they have, rather than drop a half-baked feature from the release entirely. This can easily backfire, causing bad user experience and affecting your brand perception. So, if your product has a definitive release date and something needs to give, let that not be the quality.

Don’t: skip steps

Similarly, there’s a difference between overlapping steps and skipping them entirely. Unaddressed issues have a tendency to resurface at the worst time possible. So if you cut corners to meet the deadline – for example, you skip user testing – the best case scenario is that you will have make up for that post-release. Worst case? You’ll have to scrap everything and start over. You’d be much better optimizing processes to go through them faster, than skipping them entirely.

We can help

If all this seems a bit complicated, we have good news for you. Gorrion has over a decade of experience managing and developing software, and all the know-how that you need to speed up your time to market. Some of it we’ve shared in this article, but if you need more, we’d be happy to drop in for a call and discuss your project in more detail. Let’s see how we can help!