Introduction

Features, Schedule, Quality — Pick any two” – so goes a popular saying among many engineers. And it indeed it does in many ways reflect the trade-offs that often get made. The less time there is to do a task, the more triage needs to be done as to the amount of functionality delivered, and in extreme cases the quality of the system. During the .com boom many companies focused entirely on features and schedule at the expense of quality. My company’s CEO on the other hand likes to rail against the ‘Tyranny of the Or’. What he means by that, is that he doesn’t want to have to choose between features and quality, he wants both! Is he being unreasonable about this ? Hardly. One of the key roles of an Engineering VP is to act as a bridge between the Engineering and the Business sides of the house. Any investment in technology on the part of the company is intended to produce a certain return in a certain span of time. The challenge many organizations face is that the people who understand the business value and opportunity of a technical investment, don’t actually grasp the issues and risks involved in implementing it, and those that understand the technology aren’t always so clear on what the business goal is. This mismatch is a real problem. It tends to lead to over complex designs that in fact fit poorly within the given time and budget parameters. The ongoing challenge for senior technical management is to make sure that the Requirements Management process produces a realistic and sufficiently nuanced account of what is required to succeed, and that at the same time appropriate Development Methodologies are applied. The goal is to understand the business requirements well enough that one can understand a minimal technical design that in fact meets the business goal, and then have a development process flexible enough to achieve this while dealing with whatever surprises arise along the way. This generally implies helping the requirement gatherers fine tune their requirements to reduce them to the minimum required, and carefully matching the technical solution. Maintaining this fine balance is the key to producing products that work well for the users in an acceptable time frame. At the same time, it’s important to monitor the technical risks in a plan, and make sure those risks are properly communicated.

It’s obvious that in addition to the process issues, success in this arena comes from building a successful relationship and communications channel with all the involved parties. It also requires great sensitivity to both the business needs and the limitations and challenges of the technical approach. Particularly in larger organizations, this becomes challenging because it’s harder for the VP to know all the details involved. In this it’s very important to listen closely to what both the business side and the engineers are saying, and learning to recognize when something important is said that absolutely needs to be passed on. Being able to grasp and to communicate both technical limits as well as customer requirements, even when obliquely stated by someone lower down in the organization, is a key talent for a manager.

That said, there are a couple of good approaches to optimizing both feature set and time to market simultaneously, which can be applied either singly or together.

Requirements and Solutions

Having a proper solutions focus is one of the most basic solutions to the puzzle. Mostly customers don’t buy a product because they want the product, they buy because it solves some problem they have. Often times technology companies tend to get so focused on how nifty there products are that they lose focus on what problems are being solved. As a result as a customer one often talks to a sales team and finds one has to stop them from talking about all the cool features to get them to focus on one’s own problem. The consequence is that in many organizations actually devising a solution for the customer is an improvisation done by the field force post-sale. But this setup is intrinsically inefficient. Typically the underlying product is fairly complex, and in many cases only a part of its functionality will be required to solve a given problem. If one can clearly understand the problems to be solved, and tailor a product to exactly solve those problems one can often build a much simpler product than if one tries to solve an entirely general class of problems. By introducing that simplification one can often exactly meet the market need while still being fairly quick about it. The key challenge is that product management, and preferably Engineering management too, have enough accurate customer understanding to be able to correctly define salable solutions. In this case the VPE really needs to help push the Engineering organization to clearly understand the solution space, and be able to make architectural trade-offs to keep the schedule in, while not stymieing future development through an overly narrow implementation. This can be particularly hard in startups whose main asset is some major new core technology. But in those cases it’s particularly important to get a handle on some practical solutions, because those are the ones that will drive sales growth beyond the core of early adopters.

Incremental Requirements Refinement

If the organization is doing incremental development, it’s possible to use incremental requirements refinement to optimize features versus schedule as well. The trick is that almost any high level requirement can actually be divided into a set of parts which vary in importance and difficulty, even if the total requirement itself is of very high importance. Based on that, if you implement only the important parts of the important requirements you can often meet a lot of functional requirements with a fairly modest schedule. Doing this requires a deep grasp of customer needs, a disciplined approach to incremental development, and a willingness to reprioritize on a regular basis. Success here really depends on the company’s ability to prioritize needs. If all requirements are equally high in importance, this won’t work; however, mostly when that happens it’s a sign that the requirements aren’t actually all that well understood. The mark of a correct set of requirements is in fact a detailed notion of what’s important and what’s not.

These two techniques lend themselves to being combined. For example, if a company wants to enter a new market, it can subdivide the space into different solutions, and prioritize those, implementing the most important first. Within each solution, use cases are prioritized, and within those individual little features are also prioritized. Doing this carefully yields an entire roadmap for how an entire feature set is incrementally delivered, producing value at every point on the way.

When there is little cost to releasing a new product, then development schedules can be adjusted for frequent small releases. This is typical in Internet businesses and in software that is hosted rather than deployed at a customer site. In both those cases there is relatively little cost to a release since the environment is controlled, any upgrade is managed internally, there is no cost in supporting the old release, and the upgrade is an easy “push” requiring no consent from customers. The ability to do frequent small releases has a great business benefit since it lets you get features to market as soon as they are ready. The down side is that you get into a cycle of just incremental changes and never undertake large changes that don’t fit into your regular cycle.

In practice, even without doing pure incremental development, there is a common rhythm to the releases of products, typified by an evolution like this:

• 1.0: Ship it
• 2.0: Make it work
• 3.0: Make it work right
• 4.0: Make it work fast
• 5.0: Make it work small
• 6.0: Make it work better than the competition

This obviously is a simplification, but a lot of products follow this pattern, and if executed correctly, it’s just fine. Basically, you need to decide which mixture of features, innovation and quality are required for the target customer mix at every stage of a products maturity curve. Early adopters are more enamored with the concept, and can stand some rougher edges, later as one moves up the adoption curve to more conservative and more demanding customers higher degrees of refinement in both quality and features are required to remain competitive. The main risk is excessive compromise early on. Misjudge the feature set and you either get a toy product or miss the market window; misjudge the quality and get a reputation for flaky 1.0 products. This brings us to the topic of risk management.

Risk Management

Risk Management is something that changes greatly with the size and stage of the company. Startups, with little or no money in the bank, can afford to take enormous risks, since they have so little to lose. As a company gains success, it becomes much harder to balance risk and reward. The company must come to some consensus on a corporate strategy for this. It can be difficult to explain to a business team that if they press extremely aggressive requirements and schedules, they bear joint responsibility with the technical team if the schedules slip or if the quality is bad. However the opposite is also dangerous. Large multi-nationals are sometimes so risk adverse that they barely get anything done. They have the opposite problem that the opportunity cost is harder to measure than the cost of making a mistake. This can mean that your career progresses more by getting less done, so long as you never make a major mistake. As a VP of Engineering it’s important to clarify and test the corporate consensus regarding risk tolerance, especially since the CFO may have a very different opinion than the VP of Sales. Ideally, the CEO has broadly and overtly expressed a position to the entire company regarding feature/timing and quality imperatives. It’s also important to assess the corporate risk tolerance on a regular (quarterly) basis as it changes as the company evolves. There are some general guidelines (subject to specific product or market exceptions) that are typical of early stage companies (expanding on Sam’s evolution below)

• At early stage companies, time to market is critical as cash flow is limited. Thats why it’s important to constrain the initial requirements to fundamental features only and validate them with the prospective user base asap. At a prior company I had joined as a Director of Engineering, my boss, the VP of Engineering told me ‘the quality of a product that doesn’t ship is zero’. That was his way of saying that he (and presumably the rest of the execs) felt that time to market was most critical for that stage of the company ‘life-cycle’.

• As the customer base begins to grow, the company must begin to address any outstanding quality issues, otherwise their ability to gain reference accounts, quotes is impacted and the cost of maintenance begins to eat into product development funding. Also, the best way to kill a young startup is to gain a word-of-mouth reputation for poor quality products.

• Once the basic features and quality are ‘under-control’ (relatively speaking), the focus typically turns to adding new platforms, reducing footprint, performance, scalability (depending on product), usability and human factors

Mis-Management

The techniques described here work well with reasonable people. Unfortunately, many people are promoted into higher managers who don’t have the faintest idea about any of this. Some of them can be educated. See Managing Up and Sideways. If they can’t be educated, it may be best to run, fast. The issues around features versus time to market are a real litmus test for the rationality of one’s superiors. If you find yourself in a situation like this with your immediate boss (CEO) then it’s best to quickly the support of your peers (especially VP of Sales) on your side and have them become advocates on your behalf. I’ve personally found that the CEO values the input from the VP of Sales more highly than other execs, since they have a direct/quantifiable impact on the CEO’s success. I would also contend that a CEO who wants all 3 (features/quality/time-to-market) may not be in touch with the customer needs/priorities. If neither the CEO nor the VP of Marketing can support you in making these trade-off decisions, it’s a REALLY bad sign that the company may not truly understand their prospect/potential customer base.

Note: This is an excerpt from “Leading and Managing in Silicon Valley“, a book co-authored by Sam Hahn and other VPEs.