You’ve heard the old saw: “Fast, good or cheap—pick two.” You can get good-enough quality quickly, but it won’t be cheap. You can get a great price and have it ASAP but the quality will likely be suspect. Or you can have great quality at a great price but expect to wait for it. Developing products is a lot like that. It’s a flurry of constant choices—and compromises—that are about quality, cost and speed. Living within these constraints can be challenging, but living without constraints will almost certainly result in failure. What’s a product manager to do?
Quality, resources and time. The un-holy trinity. In project management, they are collectively called the Project Management Triangle, the Triple Constraint or the Iron Triangle. Essentially, it’s the model that outlines the three main constraints a project manager faces. In product management, it’s pretty much the same thing. Quality, resources, and time will dictate the scope of the product you deliver.
Whether a start-up working on a minimum viable product (MVP) to validate a hypothesis or a large established company releasing the nth upgrade to a very complex solution, hard choices will need to be made throughout the development cycle.
Although we will examine each part of this golden triangle separately, it’s important to keep in mind that everything is interrelated.
Quality is arguably the most important aspect of any product, especially when you craft products with care. While the overarching goal should be that “quality is non-negotiable,” it is also important to realize that (a) quality can be a subjective term, and (b) bug-free products simply do not exist. According to Code Complete: A Practical Handbook of Software Construction, Second Edition, you can “expect 15–50 errors per 1,000 lines of delivered code.”
Quality is subjective because it really depends on the point of view. If you define it through metrics such as the number of known issues in your bug-tracking system, you might miss the elephant in the room. Did you really catch every problem possible, especially considering your product will almost certainly interact with very diverse systems and applications? Taking the known issues as a key metric to measure quality, you need to overlay it with the severity, that is, how often will a user actually encounter the problem and how bad will things be?
Another, and perhaps more important, way to look at quality is from the user’s perspective. Aspects that are often not tracked as bugs will also impact quality. Application launch time, number of steps it takes to do an operation over and over again, visual alignment of UI elements or even personal preference all define the perception users have of overall quality.
But let’s assume for a minute that you are going to set the goal for quality at the perfection level for a given release. That is, you move quality from a variable to a constraint. If the other two variables are only somewhat constrained—that is, you don’t have unlimited funds to hire people and you need to ship at some time in the future—the result of fixing quality is that your scope will quickly shrink as you can always improve things. And every time someone tries to improve the product, something will break and effort will get re-allocated to quality as bug fixes seem to have this nasty tendency of causing regressions where you least expect them.
Measuring quality is a combination of both quantitative and qualitative data
So, while you must strive for high quality, you will likely have to settle for less than perfection. Just measuring the number of issues found and the close-rate won’t put the focus on what matters. As in the aviation industry, put in place the clear measures you want to use to evaluate quality, then rate them using a risk-assessment matrix.
Ranking severity against potential of user occurrence does two things. First, it will help you produce a clear priority list of issues to address before going live. Second, and as importantly, you will be able to make the tough choices of what not to fix.
Now let’s look at resources. Let’s pretend for a moment that we have an unlimited budget tied to our product release. Doesn’t that sound great?
No.
Another law that is right up there with gravity and just as inevitable is the Law of Diminishing Returns. And it is oh, so quick to set in.
When teams working on a specific feature get too large, their effectiveness drops and the effort required to put all the pieces back together again becomes unmanageable, even with an unlimited number of project managers. And, because new features have this tendency to introduce new problems in areas that couldn’t possibly have been foreseen, the quality metrics will suffer. This requires more work and more resources. Can you say “vicious cycle”? No matter how many resources of how much money you throw at the issues, it not only never gets better, it often gets worse.
Back to the real world. Resources are normally defined at the beginning of a release cycle’s fiscal year. When upgrading existing products, resources available often have a direct correlation to the success of the current version in the market. Often, companies set an R&D budget at x% of revenue. For first-version products in both start-ups and established companies, using MVPs and lean methodologies and keeping costs to a minimum until product-market fit has been found is a way of life.
Even the fasted growing or largest companies have resource constraints—and that’s a good thing. It forces the scope to be focused on what matters most to the users given the level of quality that’s been identified as the goal. It also often results in driving innovation, in getting people to think creatively about how to achieve the proposed benefit to the user with the least effort. And when the implementation is kept simple and elegant, it normally results in higher quality at lesser cost.
Yes, mature products with millions of lines of code require a lot more effort to enhance than single-purpose apps, but resources constraints are a reality in both cases that need to be embraced in order to deliver great products to the users.
The final aspect that that can help define the scope of a given product release is time, that is, how much time is a team given to deliver a product with a chosen quality level. Simply “shipping when it’s ready” will result in one, very simple truth: the product will never get released. This approach often results in something that has come to be known as vaporware. It will also be the best thing since sliced bread that will never see the light of the day.
If you never ship, nobody will use your product. If you never ship upgrades, you will become irrelevant.
Release dates for a product are linked to financial requirements because new products or upgrades to existing ones, especially when successful, will result in user adoption and therefore will drive the long term sustainability of the company (and the funds to develop future versions).
Even when the product is free, new versions need to get out of the door on a fairly regular schedule. Otherwise, alternative solutions will take over. To get people using your product, you need to get it out the door. To remain relevant, you need to continually improve the value you provide to your users.
With the increasing adoption of Agile Methodologies or variations thereof, the great news is that you are—in theory, anyway—always just a few weeks away from shipping a product. Because of the short time frame of a sprint, what gets addressed in that period comes down to defining the scope that can be delivered with a given level of resources and a quality target. And don’t be afraid to have a “zero features” sprint where the focus in on polishing and fixing bugs as users do value the perceived quality highly.
I am not advocating that a date can’t be moved or that the highest standards of quality shouldn’t be set for the product. Things are almost never black or white—there are no absolutes in product development. The art and science of releasing products is based on constant choices and trade-offs in order to have the best product possible within the given constraints.
—
Original picture and photographer credits available at unsplash.com.