What is a feature release?

Whereas a product release is focused on the introduction of an entirely new offering to the market, the term feature release refers to the rollout of new or updated functionalities within an existing product. The possible goals of a feature release may include any one or more of the following:

• Improving the overall user experience
• Solving a new problem faced by users
• Staying ahead of or catching up to the competition
• Increasing user retention
• Delivering user delight
• Capture new customers
• Upsell existing customers
• Re-capturing dissatisfied users
• Demonstrating attentiveness to customer feedback

When viewed from a process perspective, the actual release of a new feature is only one step in a feature launch. For the purpose of this glossary entry, the terms feature release and feature launch are considered to be synonymous. So much of what can go wrong with a feature release is related to poor execution of the broader feature launch process. Separating the two doesn’t make much sense.

The importance of feature releases to product management

There’s an adage understood by the best software product companies and forward-thinking IT organizations working to optimize operations with custom software: “software is never done.” Product teams find a never-ending opportunity to improve on what came before. However, the exception occurs at the end of the lifecycle when the team sunsets the product. Organizations that are considering custom-developed solutions would be wise to consider that fact when making buy vs. build decisions. Software is not a set-it-and-forget-it proposition.

With this truism in mind, it is the responsibility of the product management team to be in a state of constant discovery of opportunities for user problem-solving, market expansion, and/or competitive differentiation. Once a product has achieved product-market fit, high-quality feature releases become the engine of growth for the product and the company. Working in close collaboration with engineers and designers, it is the responsibility of the product manager to fuel that engine with new features that are valuable, viable, feasible, and desirable.

Stages of a feature release

Generally speaking, a feature release consists of three phases: Pre-release, Release, and Post-release. The Pre-release phase represents the lion’s share of the effort and risk. Messing up or short-changing the Pre-release phase is a recipe for a failed feature release.

Feature release phase 1: Pre-release

This critical stage of the process includes several steps that may appear to be linear but in reality, are often non-linear and iterative. This stage is where the heavy lifting occurs in a feature release.

Discovery

This product discovery step involves development of a deep understanding of the opportunity a new feature may address. Is there a problem faced by users that is adjacent to one the product already solves? Does there happen to be a point of friction in the user flow that needs to be addressed? Is there competitive pressure that needs a response in order to protect market share? Could a new feature solve the pain points of an untapped market?

Tactics for discovery are too numerous to address here in any great detail, but they include activities like user research and observation, market and competitive analysis, and product and customer support data analysis. The key to successful product discovery is to remain focused on problems that need to be solved. Even if a goal for a new feature is to address a competitive threat, copycat, me-too features are not a source of differentiation. Discovery is all about understanding problems; solution definition is the subject of the next step: design.

One of the biggest mistakes product teams can make is to skip the discovery step. Too often organizations fall into the trap of creating feature-based roadmaps oriented around solutions delivered by HiPPOs (highest-paid person’s opinion). When that solution fails, product teams risk falling into the feature factory trap.

Design

When the product team discovers a problem opportunity, they can take the opportunity to identify a solution. When approached holistically, design is a cross-functional activity that involves engineering, product management, and UX and visual designers working together.

• Engineering is responsible for a technical design that is feasible to implement given available budget and skills within the organization
• Product is responsible for making sure the solution is valuable to the market and viable for the organization to support
• Designers are responsible for creating a solution that is desirable by product users

A successful feature release depends on all of these facets of the solution coming together. Product teams that ignore any one of these design considerations or at risk of releasing a feature that doesn’t work, that no one will pay for, that the company can’t fully deliver, or that users won’t use.

Getting design right can take time and may involve multiple rounds of (ideally, rapid) prototyping and testing, which may yield insights that require revisiting the discovery step. Some organizations make the mistake of confusing the need to move quickly with inadequate attention to the design step. Finding ways to rapidly iterate at a low cost through multiple rounds of design before committing resources to what is typically the most expensive pre-release step, development, can make all the difference between a successful and failed feature release.

Implementation

Assuming that careful attention has been paid to the technical element of the design step, the implementation step, including both development and testing, may in one sense be considered the least risky of the pre-release stage. If the engineering team was omitted from design discussions, the entire process could come to a screeching halt. Don’t make that mistake; loop in the engineers early to make sure the selected solution is feasible to implement within a timeframe and budget appropriate to the opportunity.

An additional area of potential risk in this step relates to the subject of opportunity cost, the value of the other thing or things the team could be building while they are working on this thing instead. The risk here is that insufficient attention has been paid to how the organization is prioritizing what to work on. It’s a rare team that doesn’t have a list of things they could do that is longer than what they can actually do in any given quarter. Prioritization is one of those activities that occurs somewhat continuously across every step of a feature release. It’s during development and testing when poor prioritization typically has the most impact because of the impact on opportunity costs.

One the subject of testing, during this step we are specifically referring to technical, functional, and acceptance testing aimed at making sure the feature works as intended. User testing is assumed to be part of the earlier design step and possibly the later Market release phase.

Organizational and user readiness

This step encompasses all of the planning and execution of work with other departments – marketing, sales, finance, customer support, etc. – that is required to fully deliver the new feature. Value statements have to be defined, articulated, and built into collateral. Communication plans have to be created and often initiated well in advance of the new feature being available to users. Pricing strategies may need to be created with order entry systems updated accordingly. Documentation may need to be updated, customer support personnel may need to be trained, and user education strategies and materials may need to be created.

Releasing a new feature to the market can have major impacts across the company and user base. The risk associated with this step is in not considering these ripple effects. A well-designed expertly implemented new feature that solves an important problem could experience an unsuccessful release if the organization and users aren’t properly prepared.

Feature release phase 2: Market release

This brief phase typically gets all the glory. The market release phase occurs when the team releases the feature to the market. In a world of continuous delivery where releases can happen as often as multiple times per day, such fanfare is less common. There are also cases where this phase can be extended based on the roll-out strategy.

Big bang release vs. incremental roll-out

Product teams, need to make key decisions when deciding user readiness during the pre-release phase. Moreover, they consider how they will present the new feature to their user base. One option is to release it to everyone at once, the so-called big bang approach. Releasing to the entire user base in a single day may be right for new features for which a high degree of confidence in the design, implementation, and general readiness exists. However, teams risk the potential of missing an important consideration. In turn, the miss can create a widespread crisis that your team may need to address.

Incremental roll-outs involve a more measured approach. Product teams should expose the new feature to users incrementally. The subset should gradually increase based on an analysis of user reaction and adoption. This approach mitigates the risk of missing something in the pre-release phase. However, this comes at the cost of supporting two different versions of the product.

A note on market release timing

The larger the feature release, the more time product teams should consider when to make the product available to users. Consideration of timing is another decision teams need to make during the organizational and user readiness step of the pre-release phase. Product-led organizations need to consider the timing of a feature release in accordance with other products in the portfolio. Two releases at the same time may distract the market.

From the perspective of a user, there may also be certain timing considerations. For instance, releasing major changes to accounting software at the end of the quarter may cause unappreciated stress for users looking to close their books. The key to success with feature release timing is simply to consider whether there are timing concerns to factor in. Don’t just pull the trigger without thinking.

Feature release phase 3: Post-release

The work doesn’t end after the team releases the feature to the public. In a way, releasing a new feature into the wild re-starts the process.

Performance analysis

Presumably, during the discovery and organizational and user readiness steps of the pre-release phase, product teams drew up expectations to measure the results of the new feature. Once the release is available, it’s important to collect the data necessary to determine how effective the new feature was in achieving those objectives. This step may involve any or all of the data collection methods used during initial discovery.

There are no guarantees regardless of how well executed the discovery, design, implementation, and readiness steps were. When the success of a feature release proves less than desired, product teams need to make decisions on how to adapt. Where post-release performance analysis ends and pre-release discovery begins is a fuzzy line at best.

Final takeaway

If this glossary item has done nothing else, it should at least drive home the point that a feature release is about much more than the deployment of new code. Successful product teams work across the organization to identify, prepare for, execute, and analyze the results of making new features available to users.