Having diverse experience as a lead product manager I’ve noticed that exaggerated time-to-market estimates for certain features are becoming the norm. Often, the estimates during planning don’t align with the actual time spent on the project implementation. Meanwhile, reducing the TTM is crucial. Any IT specialist will tell you that we are limited by the time available to identify business growth opportunities. Spending too much time on one hypothesis means putting the stakes too high. We are committing to the idea that the development team will focus solely on this task for an entire quarter, rather than tackling two or three. The sooner you see results, the faster you can make decisions and move forward.

However, this concept should be approached with caution. Some tasks cannot be resolved quickly, but reducing time-to-market allows you to manage better and control your plans and objectives.

The main advice for addressing this issue includes better grooming, more thorough requirement analysis, improved estimation expertise, and better prioritisation. Though these tips are well-known, the problem persists. So in this article, I want to share how our development team managed to reduce time-to-market by optimising the processes around product testing.

Common Pitfalls

As far as I have witnessed, companies have taken various approaches to reducing time to market. The main focus was on identifying bottlenecks:

• Where exactly does a task get stuck? At what stage? 
• Why?

Most solutions revolve around the following:

1. Hiring more people: developers, QA-engineers, analysts, designers, and product managers.

2. Simplifying hypotheses to cheaper solutions for faster development.

However, these approaches have consistently failed to deliver the desired results. Let us try to understand why.

The thing is that increasing resources won’t necessarily reduce time-to-market if the processes remain unchanged. More resources mean more tasks, creating a vicious cycle. To reduce time-to-market, every part of the development chain must be continuously improved.

Otherwise, bottlenecks will inevitably appear. For instance, having many QA-engineers can cause a bottleneck in development as developers won’t be able to keep up with task output and vice versa. If the team constantly expands, regardless of the features, the team costs may turn out to be unrecoverable. There’s a mathematical basis for this, similar to traffic congestion: expanding roads and building more interchanges only leads to more traffic jams. The concept is called induced demand, which means when you increase something it becomes even more desired.

Another method is cost reduction or the Minimum Viable Product approach. As a product manager, I often hear that it’s crucial to test hypotheses cheaply to get to market quickly. But the problem is that the solution is often cut down so much that the original hypothesis can’t be properly tested. Meanwhile the resources are still spent and the hypothesis remains unvalidated. Standard tactics like “let’s just put up a banner and check clicks” or “let’s send out a communication and see the interaction rate” do not effectively test a hypothesis focused on solving a user problem within the context of your product.

In summary, any stage can become a bottleneck. Thus, I suggest paying more attention to the creation of efficient testing processes. Further on I will explain why.

QA-centred Approach

Product managers often consider feature testing as the final step, in some cases they even omit it as an unnecessary waste of time. The common attitude can be formulated as: “Everything is done, now it just needs testing.”

However, this stage ultimately determines the form and timing of the feature’s release. During this phase, features often undergo significant changes, and additional requirements may emerge. Quick, ad-hoc solutions are frequently implemented to expedite task delivery.

Why is this the case?

First of all, testing aims to uncover all potential issues that might not align with expected behaviour, exploring various user scenarios, including those not initially planned.

What is more, testing occurs across the entire product, which is often challenging to do comprehensively during grooming. If these factors lead to problems with a feature during testing, resulting in release delays and rework, it indicates that the quality assurance process as a whole is inadequate.

Case Study

Within my development team, I restructured the process to shift the focus on testing. The QA-engineer is fully involved in the product requirements formalisation process. They review requirements before we start discussing them with the team and comment on the following:

• The complexity of automated tests
• Conflicts with existing product logic
• The volume of tests

The last one is a crucial point as it can indicate which product scenarios need to be covered and which not. If my requirements entail a lengthy and costly list of checks during testing, maybe we are trying to cover unnecessary aspects.

The QA-engineer is also responsible for product documentation. The testing checklist is a product artefact that provides final information about the configuration in which a feature will be deployed to production. It may not align with initial requirements, as the grooming and development processes can significantly alter requirements. Besides, for the initial launch, requirements may intentionally be overlooked. Thus, the testing checklist serves as the master data for the final launch and should be publicly accessible.

Moreover, the QA-engineer is accountable for accepting the feature. They are entitled to explicitly  communicate to the product team whether a feature can be launched, confirming that it meets all agreed-upon checklist criteria.

All of the above significantly reduces the development and testing time, the volume of requirements for implementation, the amount of bugs and revisions during development. This means that shifting the focus on the QA process at the initial stage can reduce TTM as well as the development costs. So maybe it is time to review your testing routines. The first step can be to involve QA engineers early in the requirements gathering process, get their  valuable insights and identify potential issues before development begins.