CHAPTER 9

Navigate Challenging Trade-Offs

Generate value quickly and sustainably by managing the tension between scope, time, quality, and resources.

Managing Trade-Offs Is a Balancing Act

Given a finite amount of resources (in cost and personnel), a product manager must balance three parameters: scope, time, and quality. Relaxing or tightening any one of these parameters necessitates tightening or relaxing, respectively, the constraints on either or both of the other parameters.

Scope includes the features and functionality you will provide your users, and the tools, reporting, and systems required for the business to operate the product. You can capture scope as an organized backlog of the validated features and technology needed for successful product delivery.

Richer functionality is usually considered desirable, so that you delight customers and generate greater business value. Too little scope, and your product might not meet your customers’ expectations, or you may fail to anticipate and handle edge cases, which lead to user confusion. However, including too much scope can delay your delivering anything, increase technical and usability complexity, and de-focus and frustrate your team (especially if scope is added later in the development cycle).

Time is the time-to-market, or the speed at which you deliver a functioning product that will serve the stated goals of the business and your customers. It is measured in elapsed time and not resource allocation (such as person-days).

A faster time-to-market is usually considered desirable because you deliver solutions to customers’ problems more quickly (unlocking direct business value). In turn, this also frees up resources to start working on other projects (avoiding opportunity cost). However, at a certain point, accelerating time-to-market begins to take its toll on the usefulness of the product—compromising functionality, usability, and quality—and team morale.

Quality concerns the health of underlying technology and systems supporting the product (their interoperability, robustness, stability, scalability, recoverability, maintainability, reusability, and learnability). Think of meeting design standards for user experience (usability) as another quality consideration.

Not surprisingly, greater quality is generally considered desirable. You don’t want to give end users new features if they are only going to be frustrated by instability or performance issues. You also do not want your development team wasting inordinate time addressing bugs or refactoring existing code when they could be efficiently creating additional business value. You should not expect perfect quality right from the start either; this leads to overinvestment or “gold-plating.” It may be better to get the product into the hands of your users so that you can learn where the real issues are and improve your product’s quality incrementally over time.

Figure 9.1 is a simple framework to visualize the balance between these three concepts as a triangle, the area of which is equal to the total amount of work you can do given a set of resources. Increase the resources, and (theoretically, at least) the area of the triangle can grow to increase throughput. When the area of the triangle must remain constant given a set amount of resources, however, then any change in scope, quality, or time-to-market will necessitate a resulting constraint on one or both of the other parameters.

Many versions of the framework are used in industry—some using resources/cost as one of the points in the triangle (with quality holding constant) and others using a four-point framework (resources, scope, speed, and quality). These frameworks all have much of the same premise—you cannot optimize for all, or even most, parameters. Trade-offs are inevitable, and it is your responsibility as product manager to preempt possible issues, highlight choices, and respond with solutions when compromises are required.

Although simple in concept, managing trade-offs is one of the most complex responsibilities you will face, as every situation tends to present a unique and nuanced set of constraints and challenges. In this chapter, I will introduce principles and techniques to increase your likelihood of making good decisions while maintaining visibility into possible future issues.

What Is Over-Scoping and How Do You Manage It?

Increasing scope to incorporate more features can reduce your ability to ensure a high-quality deliverable. It can also extend the time until launch. As illustrated in Figure 9.2, while delivering “more” might seem customer-centric, it can backfire—you may frustrate customers if the product becomes harder to use or if you make them wait longer to receive any functionality at all. Focusing on fewer features allows you to execute faster and with higher technical quality and usability.

Specifically, scope creep is a process where scope is added after a project has been defined and kicked off. Not all scope creep is bad. Sometimes you genuinely uncover needs that you did not or could not determine at the start of a project. The key is to minimize the sources for unnecessary or later-stage scope creep while managing an objective and collaborative process for necessary scope inclusion.

Let’s look at how over-scoping happens, and how you can address it:

1. Initially Over-Scoping a Product Initiative, Cutting Later

Many product managers generate a long list of requirements and negotiate for as much as possible to be slotted into the time available. Trying to deliver more features and functionality may seem desirable, but it can be a trap. You’ll end up with a tightly-packed schedule, putting pressure on your team and overpromising on what you can realistically deliver. Invariably, well into development, it becomes apparent that scope must be dramatically reduced to make a deadline.

Is more scope inherently better? No—less is more:

•   User experience complexity—What you leave out, as much as what you put in, is what makes a product elegant and easy to use. Too many secondary features make it harder for users to achieve their primary goals. Extra features become distractions: users take longer to learn to use a product and to discover where the features are, and they may have to take more steps to complete their tasks and make more decisions than necessary. Added to this, when there are too many variables, user validation becomes harder: you wonder, “Is poor usability due to confusion between too many feature options, or is the feature itself the problem?”

•   Greater technical complexity—More scope creates code complexity and a higher likelihood of errors. Bug counts rise, performance lags, cross-functional dependencies occur, and you find it harder to isolate where a problem has occurred. Every piece of functionality you add has to be maintained. That means you will later spend resources supporting features that may not deliver much value—taking you away from other more valuable activities.

•   Longer customer wait times—Delivering something earlier is usually better than delivering everything later. Over-scoped projects tend to delay giving customers some satisfaction, in the hope of making a bigger splash. Most customers prefer that you address their top priorities quickly, even if that means delaying other requests. If you wait too long to deliver something to the customer, pressure mounts for you to move faster. Partially complete or broken features are often dropped at the last minute, disappointing stakeholders and customers regardless.

•   Wasted effort and rework—As well as time spent in scope elaboration and negotiation meetings, it is likely the team has created designs, completed validation, and built technical infrastructure to support features that aren’t really needed or (due to time constraints) won’t be built. Cutting scope later doesn’t mean just dropping features; it often means that the user experience team needs to redesign the user interface and that engineering needs to re-architect, to account for the eliminated features.

•   Opportunity cost—For each piece of scope prioritized in the current project, there is a future project in the queue waiting for resources to be available. You can’t address your future project’s important needs while you add features and functionality of lesser value to your current project. The longer they go unaddressed, the more the urgency increases. In addition, new bugs, issues, and ideas will be added to the queue, and delays will grow longer. And your business will suffer from what is called opportunity cost—the cost of not addressing issues might be lost customers and delayed revenue.

New Stakeholder and Customer Requests that Aren’t Aligned with the Goals

As the product takes shape, customers and stakeholders will provide feedback. Much of this feedback should be incorporated if it improves the agreed-upon outcomes. Sometimes feedback is not aligned with the original project goals but includes new ideas and feature requests. Or perhaps the request is aligned, but it requires more effort and delivers less impact than features the team has already decided to work on. The later this occurs in a project’s delivery schedule, the more disruptive it can be.

Unfortunately, new requests are often easy to justify and to tack onto a project in progress. Senior stakeholders or influential customers may see your project as an opportunity to include something they have long desired. They can be hard to say no to. As such, requests circumvent the same objective, rigorous scrutiny that would have been applied at the beginning of a project.

Instead, new requests should be held to the same standard as anything considered at the start. Know and articulate your goals—where you need to be to win the customer or fulfill the vision. That will make it is easier to say no to incoming requests and your own ideas. Failure to do so may result in the following:

•   A launch delay—Each new item of scope added into the product backlog necessitates that you renegotiate delivery dates. While any new scope item might have minimal impact (adding a few days here and there), many additions can substantially extend a launch date. Sometimes, the impact and the implied trade-off is unclear. When it later becomes clear, stakeholders push to avoid delay and ask the team to figure out how to fit it all in without affecting the schedule.

 

•   Analysis paralysis—Even if faced with pushback when requesting new scope, stakeholders may continue to negotiate for its inclusion by asking the product manager to complete a “small” amount of analysis (such as high-level requirements and potential schedule and resourcing impacts) before finalizing a decision. Sounds perfectly reasonable, right? Well, unfortunately, no. Defining, planning, validating, and estimating are not free services—done correctly, they require resources and take the team away from completing the current priorities. The very act of context-switching means your team loses focus and gets confused as to what the goals are.

•   Lower return-on-investment (ROI)—When giving a project the go-ahead, decision-makers usually consider it a good investment, where the business benefits greatly outweigh the costs to build it. Adding scope after the “green-light” decision circumvents your company’s governance mechanisms, increases project costs, and delays realization of benefits. It weighs down ROI, making the project much less attractive—so much so that it might not have been approved in the first place.

3. New Necessary Scope, Not Evident at the Start, Needs to Be Added during a Project

It is usual, early on in a project, to understand some scope well but to underestimate the extent of the work yet to be identified. Unfortunately, most teams are overly optimistic in assessing how much scope is known and forecasting how quickly they can implement what is known.

Examples of scope commonly discovered later include the following:

•   Refined and new requirements that you can identify only as the product takes shape through customer and stakeholder testing and demos.

•   Significant but less-apparent use-cases, exceptions, error-handling, and edge-cases that manifest themselves as the product is tested internally or through user feedback.

•   New technologies with high uncertainty that require “invention,” with proofs-of-concept, before you can establish scope and effort.

•   Seemingly straightforward requirements where no one fully appreciates the complexity until details are understood.

•   Internal requirements from business and technology support teams, which manifest when demoing the emerging product.

•   Requisite integration with tools and back-end systems (particularly legacy technologies), the complexity of which wasn’t obvious earlier.

•   Unanticipated dependencies on other teams or technologies, which are not readily in the team’s control.

•   Time addressing bugs.

The following problems can result if you don’t carefully manage this type of necessary scope inclusion:

•   Constant schedule slippage—If you’re in a situation where you’ve created and communicated a schedule based on the best-case scenario of knowing all scope up front, then each discovery becomes another slippage announcement.

•   Negative perception of project clarity—It is unreasonable to expect product managers, designers, or engineers to know 100 percent of all scope at the start of a project. It is also unfair to refer to the discovery of new necessary scope as “scope creep,” yet that may be how it is perceived. The implication is that the product manager should have done a better job defining requirements at the outset. This might impact the product manager’s reputation and create dissatisfaction among engineers sensitive to changes midstream.

Note though, failure to follow due process—such as prioritizing ideas rigorously, completing specifications, conducting regular user validation, or building a deep and thorough backlog—is laziness. If you are changing priorities or discovering requirements that could easily have been anticipated earlier, do not blame your team for losing respect for you and becoming frustrated at the addition of new scope.

How to Handle Making Delivery-Timeline Commitments

Companies may set deadlines for good reasons. For example, you may have the following:

•   Customer dependencies that require your project be delivered by a certain date, to manage a complex implementation or roll-out.

•   A cyclical nature in your business, such as for e-commerce services or enterprise businesses where sales tend to peak or ebb in certain months.

•   A marketing event or major conference at which you have a set opportunity to unveil the product for the world to see.

Deadlines can also be helpful and necessary:

•   They allow the organization to plan on other long-lead activities such as launching your product into the market, an advertising program, and communicating with and rolling it out to customers.

•   They increase the predictability of when the engineering and design team can start working on the next priorities.

•   They ensure that new improvements are regularly released.

•   They allow your company to manage dependencies between teams and technologies.

•   They create accountability and a sense of urgency among team members.

However, some product managers and stakeholders set fixed dates that are aggressive and arbitrary, often in the hope of motivating the team to work harder. This behavior is unfortunately endemic in the technology industry. Yet, as illustrated in Figure 9.3, if you set tight and immovable deliverable dates that are incompatible with the expected scope, available resources, or quality requirements, you might inadvertently cause the team to

•   cut too many features, even those critical to users, disappointing customers;

 

•   skip time in validating the product with customers and increase the likelihood of usability issues and incomplete features;

•   under-invest in quality to ensure a bug-free product and lower technical debt; and

•   lose pride in their work, lose motivation, and feel unappreciated—knowing they will have to come back to address issues later.

There needs to be some comfort with ambiguity in your organization and a willingness to focus on value-driven outcomes rather than delivery milestones. While it is reasonable to be expected to make time-based commitments, you must manage why, how, and when you make them.

1. Negotiate to Complete Enough Product Discovery to Increase Confidence When Later Establishing Dates

Early in a project’s life, you will typically uncover things you didn’t think of, and scope (and outstanding questions) will grow in size. There will usually be tension between the business, which desires to set a firm delivery date as early as possible, and a product development team wanting to avoid making commitments until they can be fully confident in their schedule.

The trick is to find a balance. Negotiate for the ability to delay date commitments long enough for sufficient discovery and validation, so you can understand the scope and effort required to deliver a quality product to the market. Sufficient discovery and validation includes

•   doing customer validation (prototypes and testing),

•   creating and elaborating on specifications and requirements,

•   pursuing technical exploration (eliminating key technical risks, planning architecture, and proof-of-concept on new technologies),

•   completing high-level effort estimates for known scope, and

•   developing a resourcing plan to deliver your solution successfully.

Here are some good ways of knowing you have moved from a “discovery” mode into a more predictable “delivery” mode:

1.  The rate at which you identify substantial new scope slows, falling well below the rate at which you are completing work. That is, you are delivering more requirements than you are finding new ones to add.

2.  Your team’s throughput (velocity, if you are using Scrum) has stabilized. You are in a much better position to confidently set dates because you can base your estimates on experience and on remaining scope.

2. Build Conservatism into Your Project Plan to Address Unexpected Issues

Do not expect a development team to be willing to make an aggressive date commitment without “all” the scope clearly articulated. However, you don’t want to be required to create an inflexible, detailed requirements document upfront, negating opportunities to adapt to what you learn from team collaboration and customer validation efforts.

Even after you complete your initial product discovery, you have probably only uncovered roughly 60 to 70 percent of probable scope. Moreover, it is natural to be optimistic about how quickly you will deliver against that.

There are two things to consider when establishing a delivery date for your project: (1) the date (or more correctly, a date range), and (2) your confidence level in hitting that date. When you must discuss timelines with stakeholders, do so in the following way:

•   Include a contingency—Explicitly budget for effort toward unexpected scope and issues that will invariably occur. The best way to get stakeholders to agree to this is to gather data on previous projects—past performance is an excellent predictor of the future. (Keep in mind this might be a sensitive subject if it reflects poorly on previous owners.) By looking at initial planned versus actual delivery dates, you can get an estimation for a percentage-based contingency. If you do not have the data, then allowing for 20 percent extra time over the planned schedule is a good place to start. Be transparent about your contingency budget; don’t just pad your estimates.

•   Provide a date range—Rather than a specific date, provide dates for average, best, and low-end cases. Alternatively, rather than setting a hard date in the middle of the month, you can communicate that delivery will occur anytime over that whole month.

•   Include a confidence level—Anytime you share your timelines or delivery dates, include a confidence level (or set of caveats), which your development team has agreed to. A good rule of thumb is to communicate several dates at a 50 percent-plus and an 80 percent-plus confidence level (but this will depend on your culture and audience). Occasionally, you might hear a stakeholder—in a moment of optimism—mention only your earlier date, omitting the upper range and confidence level entirely. If you do, gently remind them.

At the start of your project, your date ranges are broad and your confidence low, but this will improve as you learn and execute more. As the project progresses, closely monitor how quickly your team is working through the backlog to increase the level of fidelity for date estimates. At some point, you’ll be in the position to be highly confident about a specific date and the business can start coordinating other activities toward it. Make a commitment too early, and the chances of disappointment are high; too late, and the business has no time to plan supporting activities (marketing, customer roll-out, and management of other dependencies).

3. Build a Sense of Urgency through Context Setting, Rather Than Aggressive Deadlines—and Actively Manage Stakeholder Expectations

As a product manager, you are in an unenviable position. You have stakeholder pressure to speed up delivery of your projects while also playing a critical role in protecting the team from distraction and anxiety. In this situation, product managers tend to exhibit one of three behaviors:

•   Product Managers who amplify stakeholder concerns genuinely have considerable ownership and passion for their products and desperately want to please stakeholders and customers. Unfortunately, they also tend to turn even the smallest concern into a crisis for their team. They may set aggressive dates or interim deliverables, perhaps checking in on their team’s task-completion status frequently. No one enjoys working with a taskmaster.

 

•   Some product managers simply act as a conduit to pass-on unfiltered communication to and from their team. While being highly communicative, they do little to shield the team. They add little value to their communication as they do not themselves take on the stakeholder management challenge, leaving their team exposed to too much interference.

•   Some product managers are good at absorbing and positively channeling stakeholder communication. They stoically represent their team’s work to stakeholders and protect their teams from too much direct stakeholder interference. They trust that their teams can rise to the occasion to address challenges provided they get the time and resources they need. They choose carefully what stakeholder concerns to communicate back to their team and how they do so.

Absorbers are the most effective product managers, providing air cover and not being overly date-driven. Most of the time, the team is left to do its best to solve problems and works toward a final deliverable with a sense of urgency (and without burning out).

But should you always be an absorber? In rare situations, you might want to act differently. When all else fails, a small (but not uncontrolled) crisis can jolt people into action. Do not overprotect the team—when a message must be loud and clear, it is okay to pass it along unfiltered.

Usually, however, instead of pushing the team to commit to an aggressive scope or dates, provide frequent business updates that maintain a sense of urgency. Remind them that what they are doing is important and why and reiterate that you’re counting on them.

On the flip side, you must set and reset stakeholder expectations. Provide them with frequent status updates and reaffirm commitments previously made. If anything looks like it might slip, be honest as early as possible, so they can adjust their plans or help you. Come to them with recommendations. Never hide bad news.

The Challenges of Managing Quality and Technical Debt

Quality issues tend to arise in four key areas:

1.  The customer cannot easily use the solution. This may be because you cut too many corners in creating and validating user interactions, trying to make the product quicker to engineer.

2.  The engineers were not given enough time to design and architect their code and thus did not make the software easy to write and maintain or flexible enough to change. This makes future development costlier and more time-consuming than expected.

3.  There was insufficient testing to ensure the software did what it was expected to, leading to excessive unanticipated issues once live.

4.  You did not give due consideration to possible post-launch issues that can happen at scale. These issues might include poor performance or failure to build adequate tracking into the solution (making issue diagnosis difficult).

It’s easy to overlook quality issues because they are tricky to anticipate and tend to manifest later in the product lifecycle, often well after launch. It’s also easy to sacrifice quality as the impact isn’t easy to quantify and far from immediate.

The most significant challenge in balancing scope and time-to-market with the inherent quality of the underlying technology and systems supporting the product is that poor technical quality only really becomes apparent at these times:

•   In the final stages of the development process, during performance and systems-wide testing, which surfaces excessive bugs and extends your planned time for testing (interoperability).

•   Early in a product’s life, when customers discover edge cases and bugs you didn’t anticipate (robustness).

•   In production, either as the product slows or fails unexpectedly or uses excessive system resources after launch (stability) and, notably, at “peak” loads (scalability).

•   After a failure, which tests how quickly you can restore a service (recoverability).

•   When you attempt to build upon the product, such as fixing bugs, you require significant effort (maintainability). Alternatively, building new features upon existing features takes much longer than expected due to refactoring (reusability).

•   When engineers cross-train other engineers unfamiliar with the system, and it takes an excessive amount of time to come up to speed (learnability). Poor quality and lack of documentation are likely culprits when you notice the same senior-level engineers must be involved in almost all projects touching technology areas in which they have deep expertise.

Technical debt is the total accumulation of all the small and large trade-offs and technology choices you have made in the past, all of which impact quality. As the name suggests, when technology matures and you continue to build on the shortcuts, left unaddressed, they accumulate as “debt.”

As illustrated in Figure 9.4, many technology companies pay too little attention to quality, overvaluing new feature development and undervaluing the hidden effects of poor quality. Poor quality, however, doesn’t just impact product performance; it also saps the morale of the team, which is forced to work in a challenging, hard-to-maintain, easy-to-break legacy technology environment. The team feels overworked, and they lack pride in their outcomes. Eventually, team members will start to leave.

To improve your ability to preempt quality issues:

1. Include Time in the Project Plan for Architecture, Design, Code Review, and Thorough Testing

As a rule, engineering owns quality. Product management provides support by informing and respecting necessary quality activities and enabling adequate time and attention so engineering can achieve the following:

•   Architect how the systems will work—considering past, current, and possible future needs.

•   Learn new technologies and understand how legacy systems work—perhaps completing proofs-of-concept to decide the best approach.

•   Design the technology, algorithms, and services (such as APIs).

•   Conduct design and code reviews with one another.

•   Cross-train and collaborate with other teams to share knowledge.

•   Rewrite or extend older core components on which your new features will rely.

•   Extend developer tools and scripts for repeatable code integration, testing, and deployment.

•   Build in logging and automated tests and validate that code passes these tests.

•   Complete performance, dependencies, and security testing.

•   Fix bugs.

Budget for it. As a rough estimate, testing and debugging generally take about 30 to 50 percent of the time it takes to produce product or code in the first place (but your team can help guide you). Encourage the team to add technology tasks to the backlog to provide visibility and an opportunity to explicitly prioritize these needs.

Negotiate an appropriate investment in quality and scale given the lifecycle of your product and customer expectations. In general, engineering teams hate having to come back to re-engineer components, preferring instead to “get it right the first time.” An initial product release ought to meet or exceed quality expectations, particularly if you grow faster than anticipated. In the rush to get to market, you don’t want to make so many technology trade-offs that performance is unstable.

Be careful, however, not to overinvest in a fully-scaled solution too early when launching new or beta products that may not need the level of sophistication of more mature products. You still don’t know if you are building a product of great value or not. As illustrated in Figure 9.5, ensuring the highest possible quality at all times can work against you. Over-emphasizing quality and scale at this point might prove very wasteful (delaying time-to-market and the opportunity to gather necessary customer feedback to guide your product’s future, and consuming valuable resources) especially if the product later fails or evolves in a significantly different direction after the initial launch.

2. Involve Support Teams Early to Define Internal “Non-Functional” Requirements

In addition to involving your development team, involve technical operations, QA, business operations, and customer service teams early on. This will help you to achieve the following:

•   Identify non-customer-facing and performance requirements that might not be immediately obvious.

•   Head off last-minute delays when these teams uncover unanticipated needs in their ability to support your product.

•   Help to “right-size” quality—get everyone on the same page regarding what is the sufficient, but not excessive, scale and support required.

Examples:

•   What level of scale will you need? (Your expected growth in customers, database transactions, complex and hardware-intense functionality, availability.)

•   How will the software be monitored once in production?

•   What tools, metrics tracking and reporting systems are used by internal teams that must either be extended to support your product or tested for dependencies that might render them inoperable?

Too often, these teams are brought in too late without enough visibility to an upcoming product release, support tools, documentation, monitoring, hardware, or test automation.

3. Gradually Eliminate Technical Debt

Too much technical debt will eventually slow the pace of development and make even simple functionality far costlier to build. Unfortunately, debugging, refactoring (making existing code better), documenting, and rewriting (replacing existing code) are essentially engineering tasks that have no immediate, apparent business benefit. As a result, it is easily undervalued, overlooked, and deferred.

Examples of technical debt:

•   Reported bugs left unaddressed.

•   Gaps in automated-test code coverage.

•   Duplicated code (for example, having APIs that do, more or less, similar things, or choosing to write new code rather than reuse existing code).

•   Old, unused code that once served a purpose.

•   Shortcuts to get a product out quicker (if you ask for something to be delivered earlier, you might hear an engineer quip, “Do you want it done fast or right?”).

•   Older code languages and practices from the past that do not reflect modern-day approaches.

•   The natural variance that occurs when many coders are involved, whether junior or advanced (each will have a slightly different approach to solving the problem at hand, and some, perhaps many, may no longer be at your company to provide insight or training).

•   Inefficient database transactions, memory leaks, and CPU usage, all of which hog resources.

•   Inadequate or missing documentation, such as comments in the code, release notes, and deployment/support instructions.

•   Unexpected dependencies between systems or challenges (a lack of modularity and flexibility).

•   Legacy systems, perhaps even those considered best-of-breed in their time, that have now been superseded (possibly among the hardest technical debt issue to address, as replacing deeply integrated legacy systems is akin to performing a heart transplant).

Some level of technical debt is manageable and indeed desirable. Accumulating some debt means you are making decisions to go faster—to get something out to your customers or to try an idea out before deciding to commit to serious investment in it. The problem arises when you don’t give engineering opportunities to “pay off” the debt at a later stage.

Recognize that technical debt is a ticking time bomb. Collaborate with your engineering team to invest sufficiently in its removal. How much time should you budget for this? A good rule of thumb is to expect to invest 20 percent of developer time in the activity—but the time you need will vary with how much debt you have already accumulated and how mature the underlying system is.

Adding Resources May Not Be the Easy Answer

In theory, you can relax a project’s scope, timeline, or quality constraints by increasing the budget for resources, usually by introducing additional developers. As shown in Figure 9.6, imagine extra resources making the scope-time-quality triangle larger and more flexible to meet the needs of each parameter. If a team is in a situation where it is unable to relax any of the first three constraints to deliver a quality product within a set timeframe, then adding resources may achieve this goal.

However, three critical considerations suggest that adding resources is rarely a viable trade-off:

•   Increased direct cost—Adding resources can significantly increase a project’s budget. Adding them late in a project typically comes with even higher direct costs since you need to bring on your most experienced talent or expensive vendors.

•   Opportunity cost—When viewed across an entire organization, increasing resources for one project may starve something of equal importance elsewhere. Resource allocation is a zero-sum game—some project or business unit elsewhere loses the resources redirected to your project. Calculating the impact is complicated: you are either forgoing future growth or delaying resolution of an issue that will need addressing eventually (such as deferred maintenance). Redirecting resources may require re-prioritization of projects all over the company, and very senior people might need to make those decisions.

•   Brook’s law—Also known as the “mythical man-month” (from Fred Brooks’s 1975 book of the same name),¹⁰ Brook’s law encapsulates the idea that bringing resources to a team already busy and behind in implementing a project can cause it to slow even further, well before you receive any benefit. Training, onboarding, context-switching, and increased communication overhead divert the team from working on the project as you bring new people up to speed.

If you must add resources to a project, then, be highly selective and thoughtful in doing so:

•   Focus new resources on targeted and isolated components—For example, get them to work on features not already started, to review and test code completed by others, or to catch up on automated testing that might have fallen behind.

•   Make the changes as early as possible—Adding resources earlier in the project will get a longer payback for your ramp-up cost.

•   Bring on team members of proven caliber—Add people with deep experience in the code base, so that ramp-up is minimal.

•   Consider pair-programming—Get new people to work closely with an existing team member so they can learn as they go and be less likely to slow down their colleagues.

Common Organizational Challenges that Make Managing Trade-Offs Harder

Here are some specific situations you might find yourself in that make driving trade-off discussions even more challenging—with some high-level strategies that may help you to address them. Recognize that, if faced, these situations may be over-constrained and imbedded in the company culture—and you can only do your best.

REACTING TO ONE-OFF CLIENT REQUESTS

When deal- or sales-driven, scope and dates are commonly defined up front (particularly if there is a legal commitment), and they are subject to a client’s demands or schedule. You may face very specific requests and customizations by a top client or prospect, communicated through the sales or business development team, and these may be required to win a deal.

Counter strategy In these instances, always endeavor to get involved early in any discussions that will dictate fixed commitments for your team—if possible, ask to be involved in setting deal terms or contracts. Recommend leaving scope high-level (and not prescriptive) and keeping timelines broad. Ensure stakeholders understand the required resources to support the requirements and the implications for other priorities, before client commitments are finalized.

To ensure long-term maintainability, whenever building any solution for a single client, abstract scope and build it as a core feature of your product, which can serve multiple clients, and not as a “one-off” feature. Customizations are often quickly implemented with low quality, and future development of the platform either breaks what isn’t a core part of your overall market solution or requires constant maintenance.

OPTIMIZING FOR SHORT-TERM GOALS

Businesses that emphasize hitting aggressive quarterly business targets and responding solely to incoming customer requests often do so at the detriment of quality and “bigger bets”—projects that, if successful, can generate break-out, outsized gains. Since longer-term investments do not deliver economic returns immediately, they give priority to projects likely to quickly increase sales and customers, even when these results are not sustainable.

Counter strategy Elevate longer-term, value-driven metrics and ask your engineering team to identify and report on quality parameters as a way to highlight their importance and level the playing field.

SEEKING A BIG-WIN

In startup companies, often before a major financing round, there will be a strong desire to demonstrate a “big win.” This might be landing a new customer or delivering an impressive product capability. Larger companies may face similar challenges when expected to announce significant new products or functionality at conferences or marketing events.

Counter strategy Treat these for what they are—executives need to show potential investors or external stakeholders enough, but they may not need a fully-functioning, immediately saleable product. Discuss with stakeholders the minimum requirements to meet their needs. Perhaps a high-fidelity prototype will do.

WORKING WITH AN INEXPERIENCED OR RISK-ADVERSE TEAM

Less mature teams struggle with the ambiguity inherent in embracing ongoing trade-offs. They may interpret a lack of fully detailed, up-front requirements and timelines as stemming from laziness, a lack of commitment to goals, or excessive ambiguity. They dislike taking quality shortcuts because they see this as wasteful, even when exploring products that are not guaranteed to succeed.

In particular, organizations that fear failure struggle, particularly early during the discovery phase, when experimentation is required to formalize scope and timelines are hazy. Perhaps team members worry about their reputations and the possibility of missing deadlines they cannot guarantee.

Counter-strategy Establish and communicate a set of product principles, emphasizing how you want to work. Include learning and discovery of the “right scope” through hypothesis-generation and experimentation, operating without all scope up front, being flexible on dates, and being willing to take calculated risks in quality (with the commitment to clean up technical debt progressively for successful products).

OPERATING IN A COMMAND-CONTROL ENVIRONMENT

A strong CEO, founder, or other leaders concentrate decision-making at the top, confidently directing the product based on his or her vision and belief. While this person’s instincts may be excellent and help focus the team, communication can break down as organizations grow and become more complex. A single individual cannot possibly understand all the nuances and impacts to make insightful trade-off decisions.

Counter strategy: When faced with this situation, while you should not ignore their guidance, treat their requests like others. Evaluate where they fit in the scope priorities and explain the impact on timeline and quality. If they are prescribing highly specific scope requirements and timelines, employ the five-whys technique (introduced in Chapter 4) to understand the underlying need. Then you can suggest alternative approaches and workarounds that may not be as constraining. Rarely take even a senior leader’s request at face value.

If In Doubt—Ship Early, Ship Often

If you are ever in any of these situations where you feel overly constrained on scope, quality, timelines, or resource trade-offs, then focus on “the number one rule” for product managers: Ship! Deliver working product into the hands of customers and stakeholders—code, features, or functioning “early versions”—even if they are imperfect (but not disastrously so).

Shipping builds momentum and confidence in the team. It keeps stakeholders happier. It provides something to test with customers. It highlights any urgent quality issues you need to address. By shipping small increments of code frequently, you start to figure out what scope is essential and thereby improve your ability to estimate the timeline for the remainder of the project.