Time to market: the critical path to shipping products that matter

Every product that matters shipped before it was ready

Every product that matters was shipped before it was ready. Not because the people behind it were lazy, but because they understood something perfectionist engineers and nervous managers struggle to accept: the market does not wait, users do not care about your roadmap, and the only feedback that counts comes from real people using real software in real conditions.

Time to market is not about rushing. It is about focus. It is knowing which corners can be cut and which cannot, which features are on the critical path and which are nice to have, and how to build a process that produces good work under pressure without burning people out or shipping rubbish.

This is the operating manual I wish someone had given me fifteen years ago. Every business and every number in its worked examples is invented.

Lateness costs more than overspending, and being first is not the prize

Two pieces of research frame the whole question, and they pull in different directions on purpose.

The first is about lateness. A McKinsey study, as reported in a 1996 Management Science paper on product development, found that companies on average lost 33% of after tax profit when they shipped products six months late, against losses of 3.5% when they overspent on development by 50%.¹ The original study is old and I could not find it published, so treat the exact figures with care. The shape is the point: a late product usually costs far more than an expensive one.

The second is about being first. Peter Golder and Gerard Tellis traced around 500 brands in 50 product categories back through history. Almost half of the market pioneers failed, and the early market leaders, who usually did much better over the long run, entered on average 13 years after the pioneers.²

Together they say something precise. Being first is not the prize. Being late with something you could have shipped is the expense.

Worked example: what six months of delay costs a Kilkenny shop

A homeware shop in Kilkenny, canalsquarehome.example, plans a new range of made to order furniture. The example assumes the range will earn €8,000 of profit a month once it is live, and that the build is budgeted at €30,000.

Option one: the team keeps polishing and launches six months late. Six months at €8,000 is €48,000 of profit that never arrives, and that money is gone for good, because the months do not come back at the end.

Option two: the team launches on time but overspends the build by 50%. Half of €30,000 is €15,000 of extra cost.

Lateness costs €48,000, overspending €15,000. The delay is more than three times as expensive, before counting what six months of real orders would have taught the shop.

The critical path is everything that blocks launch

The critical path is the longest chain of dependent tasks in a project, and so it sets the shortest possible timeline. The method was formalised by James Kelley and Morgan Walker in 1959 as critical path planning and scheduling.³ If any task on the critical path slips, the launch slips. Tasks off the critical path have float: they can slip a little without moving the launch, as long as they finish before they become critical.

It sounds obvious. In practice, people treat all tasks as equally important, spread effort across everything, and panic near launch because the critical items are not done.

Finding your critical path

The critical path emerges from one honest question: what is the minimum set of things that must be true for us to launch?

For an eCommerce shop, that might be: customers can browse products, add them to a basket, check out and pay, and the order lands in the system. Wishlists, reviews, recommendation engines and elaborate filtering are not on it. You can launch without them. You cannot launch without a working checkout.

For a SaaS product: people can sign up, perform the one core action the product promises, and pay. The onboarding tour, the integrations and the mobile app are not on it.

The discipline is answering honestly. Teams love to smuggle features onto the critical path by calling them essential. "Users expect recommendations." Do they? Have you asked them, or is that what a competitor has?

Worked example: the forward and backward pass for a Waterford relaunch

A gift shop in Waterford, merchantsquaygifts.example, is relaunching its website. Six tasks, in weeks:

Task	Weeks	Needs first
A: design system	4	nothing
B: product catalogue	3	A
C: payment integration	3	nothing
D: checkout	4	A and C
E: order management	2	D
F: launch testing	1	B and E

The forward pass finds the earliest start and finish of each task. A runs from week 0 to week 4. C runs from 0 to 3. B can start when A is done, so it runs from 4 to 7. D needs both A and C, so it starts at the later of the two, week 4, and runs to week 8. E runs from 8 to 10. F needs B (done at 7) and E (done at 10), so it starts at week 10 and finishes at week 11. The launch is in week 11.

The backward pass works from the launch back, to find the latest each task can start without moving week 11. F must start by week 10, so E by 8 and D by 4. B must also finish by 10, so it can start as late as week 7. C must finish when D starts, week 4, so it can start as late as week 1. A must finish by week 4, the earlier of what B and D need, so it starts at week 0.

The float of each task is its latest start minus its earliest start, $LS - ES$, where $LS$ is the latest start from the backward pass and $ES$ is the earliest start from the forward pass. B has $7 - 4 = 3$ weeks of float. C has $1 - 0 = 1$ week. A, D, E and F have none, so they are the critical path: $4 + 4 + 2 + 1 = 11$ weeks.

The horizontal axis lists the six tasks, the vertical axis the weeks each one can slip before the launch moves. Four tasks have no float at all: that is the critical path. The catalogue has three weeks of slack. Payment has only one, which matters more than it looks: if the payment integration slips by two weeks, it finishes at week 5, checkout runs from 5 to 9, orders from 9 to 11, testing from 11 to 12, and the launch slips by a week. A task with little float is critical in waiting.

Protecting the critical path

Once you know the critical path, protect it.

Dedicated people. Whoever works on critical tasks is not pulled onto other work. If one engineer is the only person who can build the payment integration, that engineer does nothing else until payment works.

Scope freezes. The critical scope locks early. No "while you are in there, could you also". Everything else goes to the backlog.

Early integration. Build a vertical slice, a thin but complete path from start to finish, then widen it, rather than building the basket in isolation and discovering later that it does not talk to the checkout.

Risk first. If you are not sure the payment provider's API works as documented, find out in week one, not week eight. In the Waterford example, payment had one week of float, so it is exactly the task to start on day one.

The non critical path is still work

Calling something non critical does not make it unimportant. It gets done after launch, in parallel by people the critical path does not need, or it becomes the critical path of the next release. You are not delivering less. You are sequencing, and delivering sooner.

Worked example: a Cork fashion relaunch

A fashion retailer in Cork is relaunching its shop. The initial scope: new design system, product catalogue, search and filtering, customer accounts, wishlists, checkout, payment integration, order management, a returns portal, a loyalty programme, recommendations, reviews and a mobile app. It is scoped at 12 months. The board wants it in six.

The critical path is the design system (everything depends on it), the catalogue, checkout, payment and order management. Everything else moves to phase two: basic category navigation instead of search, guest checkout instead of accounts, a manual returns process for the first month, the responsive website instead of an app, and wishlists, loyalty, recommendations and reviews after launch.

Phase one launches in month five. It is not the full vision, but customers can browse and buy, and revenue starts. Phase two begins straight away, guided by real behaviour. The full scope ships in month 10, two months ahead of the original 12, because phase one showed that three planned features were unnecessary and two unplanned ones were essential.

The over engineering trap

Over engineering is building more than you need, earlier than you need it, for problems you do not have yet. It is one of the most common ways technical teams sabotage their own timelines, and it nearly always looks like professionalism.

It comes from good instincts in the wrong place: anticipating problems, building for scale and avoiding technical debt are virtues in context, and out of context they stop things shipping.

What over engineering looks like

Building for scale you do not have: an architecture for ten million concurrent connections, for a product with no users.

Abstracting before repetition: a generic framework on day one, which no longer fits when the requirements change three months later. Wait for three concrete cases before you abstract.

Premature optimisation: a week spent speeding up a query that runs once a day and takes two seconds.

Gold plating: the feature works, and then another week goes on configuration options and an admin screen nobody asked for.

Building instead of buying: a month spent building your own version of a service you could have integrated in a day, which you now also have to maintain.

The simplest thing that could possibly work

The antidote is a question: what is the simplest thing that could possibly work?

Simplest does not mean sloppy. It does not mean skipping error handling or writing unreadable code. It means solving exactly the problem in front of you, and making the smallest commitment that lets you change direction when you learn more.

For sign in, that might be email and password, with no social login and no second factor for a first test of whether anyone wants the product. For recommendations, it might be "customers also bought", a simple count of which products appear in the same orders, run nightly. A machine learning model can replace it later, once the simple version has shown that recommendations sell anything at all.

When complexity is justified

Not all complexity is over engineering. Compliance checks in a financial product are on the critical path because the law puts them there. Password hashing, HTTPS and input validation are not gold plating, and skipping them is negligence. And if the whole promise is faster search, work on search speed is the product. The test is whether the complexity serves a validated need or an imagined one. "We might need this" usually is over engineering. "Users are complaining about this" usually is not.

Worked example: the admin panel that sank a Galway startup

A business to business (B2B) startup in Galway builds invoicing software for freelancers. The core works: create invoices, send them, track payments. The founder, an experienced engineer, decides a full admin panel must come first: user management, analytics dashboards, audit logs, role based permissions, feature flags, the ability to log in as a customer.

The panel takes three months. In those three months, two competitors launch. By the time the startup does, the market has moved.

What it needed at launch was a database client and secure access to the server, about an hour of setup. The admin tools could have grown after launch as real needs appeared. The startup eventually closed, and its founder named the admin panel as the critical mistake: not because admin tools are bad, but because they came before the product reached the market.

Users will break it, so build for recovery

Here is the uncomfortable truth every experienced developer knows and every inexperienced manager resists: you cannot test your way to a product without bugs. Users will find paths you never considered and break things in ways that look impossible until you read the error logs.

That is not a failure of quality assurance (QA). Any real system has more possible states than anyone can test. The question is how fast you fix bugs when users find them.

Testing is necessary, and not sufficient

Testing catches the bugs you can anticipate. A solid test suite proves the main path works and old bugs stay fixed, and a product without one is reckless. But nobody can test what nobody imagined: emoji in a field meant for plain letters, a double click on the pay button, a customer who leaves halfway through checkout and returns three hours later, a browser extension that clashes with your script. You test the part you can imagine. Users explore the rest.

Building for recovery instead of prevention

Monitoring and alerts: if the checkout fails at 3am, you want to know at 3.01am, not when you open your email at 9am. Easy rollback: automated deploys, gradual releases to a small share of traffic, and feature flags that switch new code off in minutes. Graceful degradation: if recommendations are down, show none rather than an error page. Honest communication: tell people what broke and what you are doing about it.

Speed and stability go together

The research on software delivery backs this up. DORA, the research programme behind the State of DevOps reports, measures delivery with a small set of metrics: change lead time (from commit to production), deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Its guide states plainly that speed and stability are not tradeoffs: the metrics tend to move together, with the strongest teams doing well on all of them and the weakest doing poorly on all of them.⁴

That leads to a counterintuitive point. The heavier the manual gate before every release, the slower the cycle, and the longer a bug found in production lives, because its fix waits for the next cycle too.

Worked example: counting bug days under two release rhythms

Two teams run comparable shops. The numbers are this example's assumptions, chosen to make the mechanism visible.

Team A releases monthly after two weeks of manual testing. Say four bugs a month still reach customers. A bug found in production waits for the next release and its two weeks of testing, so it lives three to six weeks, four and a half weeks on average, which is about 31.5 days. Four bugs at 31.5 days each is 126 bug days a month.

Team B has automated tests, little manual gating and deploys several times a day. Say six bugs a month reach customers, half as many again as Team A, because less is checked by hand. Each is fixed the same day, call it one day. Six bugs at one day each is six bug days a month.

Team B ships more bugs and still exposes customers to about one twentieth of the trouble: 6 bug days against 126. The goal is not zero bugs shipped. The goal is the least total pain for customers, which is the number of bugs times how long each one lives.

Worked example: the perfect launch that missed Christmas

A Limerick retailer plans a new checkout for the Christmas season. Work starts in June, aiming for 1 November, a month before Black Friday.

The checkout is complete by September. Then testing begins. The testers find bugs, the engineers fix them, the testers find more. The test plan insists on every payment method in every browser in every country. By 1 November it is still in testing. Unwilling to risk Christmas on code that has not passed, the board moves the launch to January.

The shop spends its most valuable season on the old checkout, which converts worse. The January launch goes smoothly, but the four months of testing cost the busiest weeks of the year.

The standard for launch is not "no bugs". It is "better than what we have now, with acceptable risk". The new checkout was better in September. Every day after that was avoidable delay.

Trust the process, especially under pressure

When deadlines loom, people make their worst decisions. Features get cut at random instead of by priority. Code quality drops. Communication breaks down. People work longer and produce worse work.

The antidote is a process you trust, set up before the pressure arrives, so that when everything feels chaotic you have a method to follow instead of improvising in a panic.

What a process you trust contains

Clear rules for cutting scope, agreed in advance: the critical path first, customer value second, internal requests third. A steady rhythm of check ins and planning, so that rising pressure uses the existing structure instead of adding meetings. A clear escalation path, so nobody loses days finding out who can decide. And protected capacity: limits on work in progress and a sustainable pace, with any exception named as one.

Worked example: a bug two days before launch

Two teams face the same crisis: a serious bug found two days before launch.

Team A has no process. Engineers debate whether to delay, managers debate who is to blame, and nobody knows who may decide. Three people investigate the same bug. The fix is rushed and barely reviewed. The bug is fixed and a new one is introduced.

Team B has a process. The engineer on call rates the bug against an agreed scale of severity: it blocks launch, the top level. The runbook says the top level gets two engineers straight away, taken off lower priority work. They debug methodically, the fix goes through normal code review and the normal deployment pipeline, with no skipped steps. The launch goes ahead on schedule.

Team B was not more skilled. It had a playbook to follow instead of decisions to make under stress.

Trust in a process is earned

Follow it when it is inconvenient: if the rule is no deploys on a Friday afternoon, there are no exceptions. Review honestly whether a failure came from the process or from skipping it. Apply it to everyone, because a process a founder can overrule at will is only a suggestion. And change it deliberately: "we are changing the process" is healthy, "just this once" is corrosive.

Worked example: the Waterford agency that stopped panicking

A web agency in Waterford has a reputation for chaos. Every project ends in a crunch, developers work weekends, quality suffers and clients are unhappy despite the overtime.

It changes four things. Scope locks after the discovery phase, and later changes become the next phase, not creep in this one. Every project has weekly deliverables reviewed with the client, so slippage shows at once. Developers work on one project at a time, and an understaffed project is escalated, not rescued with heroics. Every project gets the same testing: automated tests, internal review, and a staging site for the client.

The first projects under the new rules are painful, but the agency holds firm. Six months later, in this example, average delivery time is down 20% and overtime down 60%. Not because the work got easier, but because outcomes became predictable.

Quality under pressure means protecting focus

Time pressure does not have to destroy quality. What destroys it is the behaviour that tends to come with deadlines: more interruptions, more meetings, more switching.

What interruptions cost

Interruptions carry a real cost, though not quite the one usually quoted. Gloria Mark and colleagues observed 24 information workers in detail and found their work highly fragmented: people spent about 11 minutes on a piece of work before switching, 57% of those pieces of work were interrupted, and although most interrupted work was resumed the same day, more than two other activities came in between.⁵ In a later experiment, people who were interrupted actually finished tasks faster with no loss of quality, but paid for it with more stress, frustration, time pressure and effort.⁶

So an interruption rarely costs a neat, fixed number of minutes. It costs fragmentation and strain, and over a hard month strain is what breaks quality. Under pressure the sources multiply: managers checking in, status requests, meetings about a worry, chat messages marked urgent. Each looks reasonable. Together they leave no focused time.

Protecting focus time

Batch communication: email and chat at set times, say 9am, noon, 3pm and 5pm, with notifications off in between. Keep blocks free of meetings, whole mornings or whole days. Report status on a shared page or board instead of in calls. And default to writing: if it does not need an answer now, it is a message, not a meeting.

Saying no protects quality

The deepest cause of quality collapsing under pressure is saying yes to too much. "Not now" is a valid answer: "I can look at this after we ship." Point to the agreement: "We lock scope after kickoff. This is a good idea for phase two." And make the trade explicit: "I can do this, but it moves X by Y days. Is that the trade you want?" Once the cost is visible, the request is often withdrawn.

Worked example: the six week build that shipped on time

A developer builds a minimum viable product (MVP) for a Cork startup: six weeks, fixed budget, fixed scope. The founder is anxious and wants daily updates, frequent calls and instant access by chat.

The developer sets boundaries at the start. A written update every Friday with a recorded video walkthrough. One 30 minute call a week, Tuesdays at 10am, with an agenda sent in advance. Chat for emergencies only, meaning something is on fire and blocking work right now. Everything else by email, answered within 24 hours.

The founder resists: "what if I have questions?" The answer: "Write them down. Most will answer themselves by Friday. We will cover the rest on Tuesday." Six weeks later the product ships on time, and the founder admits that most of the "urgent" questions were not urgent at all.

Customers define requirements, not meeting rooms

The most expensive mistake in product development is building the wrong thing. No amount of process, focus or testing saves a product that solves a problem nobody has.

The natural instinct is to define requirements internally: managers speculate, designers draw personas from assumptions, engineers build what they are told. The product launches, and nobody comes.

Why internal requirements go wrong

Insiders know too much to feel a first visitor's confusion. Their incentives differ from the customer's: the salesperson wants the feature that closes one deal, the executive something impressive for the board. Agreement forms too easily around ideas nobody has tested outside the room. And every change is judged against the current design rather than against what customers need.

Bringing customers into the room

Interview before building, and do not ask "would you use this?", because everyone says yes. Ask "show me how you solve this today." Put a clickable prototype in front of five people before any engineering. Give finished pieces to early users while you build. And release to 10% of users first, watch, fix, then widen.

Test before committing the budget

The same principle applies to marketing and operations. Before spending €100,000 on a campaign, spend €5,000 testing the creative and the targeting, and measure orders, not just clicks. Before building a presence on a new channel, try it for a month with a freelancer rather than a year with a new hire. Before signing a long exclusive partnership, run a pilot and judge it on actual results. Before committing to a price, test the alternatives and see what customers really pay.

Worked example: the feature nobody used

A project management SaaS company decides, from competitor analysis and internal brainstorming, to build a resource planning module: Gantt charts, capacity views, skills matching, cost tracking. Four months of engineering go into it.

At launch, almost nobody uses it. Interviews afterwards explain why. Resource planning belongs to the operations team, but the product's users are individual team members with no view of resourcing and no authority to change it. The feature was built for a user who did not exist in the customer's organisation. It was eventually removed because it cluttered the interface. Three interviews before the build would have caught it.

Profit comes from less waste, not more features

Time to market is a profit lever. The sooner you ship, the sooner you earn and learn. But speed alone is not the goal. The goal is the most value delivered per week and per euro, and that means removing waste, not just working faster.

Five kinds of waste in product work

Features nobody uses. Pendo analysed product usage across 615 of its customers' subscriptions and estimated that 80% of features in the average software product are rarely or never used, while about 12% of features generate 80% of daily usage.⁷ Pendo sells product analytics, so read that as a vendor's measurement of its own customers, but the direction is hard to argue with.

Waiting between stages. Work sitting in a queue for design, review, testing or deployment. Smaller batches and closer collaboration shorten the queues.

Rework. A misunderstanding caught in a prototype costs an afternoon, caught after engineering it costs weeks.

Motion. Searching for information, unnecessary meetings, bureaucracy, switching.

Overproduction. Building features or infrastructure ahead of need. The cost is certain, the payoff is not.

Every feature has a running cost

A feature keeps costing after it ships: bug fixes, dependency updates, documentation and support, more for users to wade through, more surface to secure. So it has to return more than its total cost of ownership, not just its build cost, and many features that look profitable on the build alone are not. A focused product with five excellent features beats a bloated one with fifty mediocre ones.

Worked example: doubling revenue by removing features

A B2B SaaS company has 15 features, accumulated over four years of saying yes to customer requests. Revenue has plateaued. Acquisition is expensive because the product is hard to demonstrate, and churn is high because users feel overwhelmed and never adopt the features that matter.

New leadership looks at the usage data. Seven of the 15 features are used by fewer than 5% of customers. Three more are used, but not in ways linked to retention or revenue. That leaves 15 minus 7 minus 3, which is five. They keep those five and remove the rest.

Over the following year, in this example, demos convert 40% better because the product is easier to understand, onboarding focuses on five features instead of 15 so customers reach value sooner, support volume halves because there is less to go wrong, engineering moves faster with less to maintain, and revenue doubles because the time goes into winning and keeping customers. Removing a feature can be worth as much as adding one.

Ship, learn, improve

Time to market is not about cutting corners. It is about knowing which corners matter. A late product usually costs more than an expensive one, and being first is not the prize. Find the critical path and protect it, build the simplest thing that works, fix fast, trust a process agreed in calm weather, protect focus, let customers set the requirements, and remove what costs more than it returns.

The products that win are rarely the ones that were perfect at launch. They are the ones that launched, learned from their users and improved faster than everyone else. Speed is not the enemy of quality. Speed makes learning possible, and learning is what makes quality.

Ship it. Learn from it. Make it better. Repeat.

I have shipped dozens of products across eCommerce, SaaS and agency work. The patterns here are hard won, from projects that shipped on time and projects that did not, from features users loved and features nobody touched, from teams that thrived under pressure and teams that burned out.

Footnotes

1. Morris A. Cohen and others, New product development: the performance and time to market tradeoff, Management Science 42(2), 173 to 186, 1996 (reporting a McKinsey study), Wharton faculty repository, https://faculty.wharton.upenn.edu/wp-content/uploads/2013/04/New-Product-Development_1.pdf

2. Peter N. Golder and Gerard J. Tellis, Pioneer advantage: marketing logic or marketing legend?, Journal of Marketing Research 30(2), 158 to 170, 1993, doi 10.1177/002224379303000203, record and abstract at Crossref, https://api.crossref.org/works/10.1177/002224379303000203

3. James E. Kelley Jr and Morgan R. Walker, Critical path planning and scheduling, papers presented at the Eastern Joint IRE, AIEE and ACM Computer Conference, December 1959, 160 to 173, doi 10.1145/1460299.1460318, record at Crossref, https://api.crossref.org/works/10.1145/1460299.1460318

4. DORA, DORA's software delivery performance metrics, dora.dev, updated 5 January 2026, https://dora.dev/guides/dora-metrics/

5. Gloria Mark, Victor M. Gonzalez and Justin Harris, No task left behind? Examining the nature of fragmented work, Proceedings of CHI 2005, ACM, 2005, https://ics.uci.edu/~gmark/CHI2005.pdf

6. Gloria Mark, Daniela Gudith and Ulrich Klocke, The cost of interrupted work: more speed and stress, Proceedings of CHI 2008, ACM, 2008, https://ics.uci.edu/~gmark/chi08-mark.pdf

7. Pendo, The 2019 Feature Adoption Report, Pendo.io, 2019, https://go.pendo.io/rs/185-LQW-370/images/2019%20Feature%20Adoption%20Report%20Digital.pdf