Why did you build that feature? 

Imagine the last feature your team developed. What drove its creation? Was it user feedback, competitive pressure, or perhaps an internal hunch? If pinpointing the exact reasons feels challenging, you're in good company. Many product teams face the daunting task of continually innovating, often under tight deadlines and market pressures. Yet, understanding the 'why' behind each feature is not merely an administrative task—it is fundamental to crafting products that resonate deeply with users and endure over time.

How would you uncover the underlying reasons if they were not immediately clear when developing a feature? Which sources would you consult? Whether diving into analytics, reviewing customer service interactions, or conducting targeted user surveys, the goal is to ensure every feature is purpose-built. This approach transforms product development from reactive to strategic, ensuring that each feature meets immediate needs and contributes to the product's long-term vision and success. By refining our approach to feature definition, we set the stage for creating more impactful and successful products.

Four most common reasons

In my experience, there are four primary reasons why product teams decide to create new features. Each of these drivers has its trade-offs, particularly concerning the cost and time involved in generating the necessary evidence to support decision-making. Balancing these factors is crucial. Relying too heavily on one at the expense of the others can skew product development, leading to features that may not align with user needs or market demands. The most successful products result from a harmonious blend of these motivations, ensuring a well-rounded approach to innovation that is both data-informed and intuitively guided. Understanding each team's strengths and limitations can help teams make more informed decisions and build products that resonate with their users.

Primary research

Primary research often represents the gold standard in feature justification. This method, conducted by design and research teams, involves gathering fresh, firsthand data from actual users or customers. With a background in research, I confidently believe that most of the best features I have worked on involve my evidence or that created by my team. Examples of insights from primary research include everything from analyzing interactions between sales teams and customers to more structured user testing sessions where feedback on prototypes and existing products is solicited. While primary research provides invaluable insights directly from the source, it's also the most resource-intensive method, requiring significant investment in time and effort. Nonetheless, the authenticity of the data gathered makes it a powerful tool in the product development arsenal, helping to ensure that new features closely align with user needs and expectations.

Secondary research

Secondary research involves leveraging studies, reports, and analyses done by others—think industry reports from consulting firms or market analysis documents that are publicly available. This type of research is crucial for understanding broader market trends and the competitive landscape. It can inform decisions about which features perform well for competitors, which might suggest similar success if adopted. However, there’s a caveat: the contexts and user demographics for which these studies were conducted may not align perfectly with your target audience. This misalignment can lead to adopting features that don’t resonate with your users, making secondary research a valuable but sometimes tricky path.

When creating a case for a new feature, I commonly conduct a “literature review” or a review of all secondary research I can find. In these, I include all relevant previously conducted primary research and whatever supporting or contrasting information I can see from both the market and academics. Sharing my final recommendations, I have found that some teams successfully grasp the conditional value these reports offer, respecting that they help directionally but not always with precision. There have been times I have also seen certain people latch onto one report or study and use it to justify a complete turn in direction. This has led a team astray as their product proved to be reasonably different from the one introduced in the secondary research. 

Customer requests

Direct customer requests can drive feature development, particularly in enterprise or B2B contexts where client retention and customization can lead to significant sales. While customer-driven features can make products more appealing to specific clients, there's an inherent risk. I remember working with an HRM SaaS provider and a single client requesting that they replace “employee” with “practitioner” in the software, which would have demanded a complete recreation of the foundational aspects of the software.  Additionally, customers often know what they want but may not fully understand what they need, which can lead to features that serve one but not necessarily all users. Balancing these requests with the broader user base’s needs requires a discerning eye and a willingness to probe deeper into the underlying problems these features are meant to solve.

Intuition

There’s something to be said for the gut instincts of experienced product managers and developers who have honed their instincts over many years of product development. Intuition can lead to groundbreaking innovations when the market lacks clear directions. I have seen it, recently working with an authentic product visionary whose repeated success with his ideas was proof of his skill. However, relying solely on gut feelings without backing them up with data or user insights can lead teams down a dangerous route, potentially resulting in features that miss the mark with users. Intuition must be tempered with validation to ensure that even the most innovative ideas have a place in the market. 

Benefits of solid feature definitions

Given the myriad influences that lead to the creation of a feature, it is crucial to establish a solid definition of what each feature is intended to accomplish and the evidence that supports its development. This clarity not only aids in aligning the stakeholders' understanding of the product's evolution but also anchors the feature within the broader product strategy. Having worked at a collection of startups in the past few years, this has become the first question I ask product teams, “how do you define your core features?” I always get an answer, but it rarely is anything structured, nor does it call out why it was created, both in terms of the value and the belief of why it will work. By defining what a feature should do and why it should do it, teams pave the way for three primary benefits that enhance the development process and the product's impact on the market.

The first benefit of a well-defined feature is that it compels teams to scrutinize the assumptions underlying their expectations of what the feature will achieve for users. If robust evidence from primary research supports the feature, the team can be more confident in its potential success. However, assumptions may take the lead without such evidence, which can be risky. A clear definition helps to explicitly mark these assumptions, allowing teams to recognize where gaps in understanding might exist and where further validation might be necessary.

With a comprehensive definition, developing more nuanced metrics that delineate what success looks like for a particular feature becomes feasible. This goes beyond simple usage and user satisfaction measures, enabling teams to define success through specific outcomes and impacts. These tailored metrics are essential for evaluating the feature's effectiveness post-launch and for making iterative improvements based on performance against these defined success criteria. I commonly find teams that desire to increase their product analytics are not stifled by their technical access to raw data but instead lack functional knowledge on metric creation. A solid definition is the first step toward various new metrics.  

Finally, a clear and thorough definition of each feature helps prevent the common pitfall known as the build trap—where teams continuously produce features without a clear connection to a strategic vision or user need. This disciplined approach to definition ensures that every feature serves a purpose, aligning with the product’s overall goals and user expectations. It also aids in prioritizing feature development, ensuring that resources are allocated to the most impactful features first. This strategic alignment streamlines development efforts and maximizes the product’s relevance and value to its users.

Ways to define features

Determining the best approach for defining features is a strategic decision for each company, but two prevalent methods have proven effective in linking feature design directly to user benefits. The first involves understanding User Needs through a Design Thinking approach, emphasizing empathy and iterative learning to ensure features genuinely address user problems. The second method, identifying Jobs to Be Done through an Outcome-Driven Innovation approach, focuses on the specific tasks users are trying to accomplish and the expected outcomes. Both methods are grounded in the philosophy that features should benefit the user, bridging the gap between user desires and product functionality.

A thorough grasp of user needs is crucial, yet it is only part of building a successful business. Addressing these needs must also translate into tangible improvements in business outcomes. Thus, defining these outcomes becomes essential to the feature definition process. Furthermore, when designing a feature to solve a user problem, it is advantageous to identify specific user behaviors that the feature intends to influence. Recognizing and aiming to change these behaviors can provide a clear indication of whether a feature will meet its intended goals, focusing on the practical impact of the feature on everyday user interactions. Most product teams I talk to already think about the actions users will take by designing a feature a certain way but do so without putting any proper definitions around it. 

To encapsulate the behavior and outcome dynamics, I advocate for a framework I call the User Outcome Connection, which integrates three critical variables: specific user behaviors, user outcomes, and business outcomes. This framework is a comprehensive model for defining features, ensuring each element is aligned with and supports the others. By establishing and documenting the relationships between these variables, teams can work to develop evidence that substantiates the existence of these connections with data, validate underlying assumptions, and develop metrics to measure the success of each variable. A structured approach such as this solidifies the rationale behind a feature and enhances the ability to assess its effectiveness post-launch.

During recent consulting engagements, I have helped teams review current features and even kick-start the development of new ones with this framework. Having a straightforward framework that is simple to fill out has encouraged almost everyone to contribute ideas on what behaviors they see changing when thinking through why they are excited to build the new component. It also allows for a vibrant discussion about how realistic a particular behavior is connected to the user outcome. There is an added benefit for the team to have a graphic to review and respond to rather than a sentence or nothing but a discussion. I recommend you take a minute and quickly review one of your features through the lens of the User Outcome Connection!

In conclusion, as industries evolve and customer expectations heighten, teams must reevaluate how they conceive and define new features. Embracing a methodology that rigorously defines what a feature should achieve for customers—connecting user behaviors to outcomes and aligning these with business objectives—can significantly enhance the strategic impact of product development efforts. By adopting such frameworks, teams can ensure that each feature fulfills a specific user need and contributes positively to the broader business goals, paving the way for sustained success and customer satisfaction.

You might also find the following articles interesting: