Where do ideas for new features come from? How do you decide which ones to build?

Everywhere! Users themselves, colleagues, market research, competitors, randomly in the shower. Generally, I like to consider each idea seriously and work through a few questions to help decide if they are worth building:

1. What, fundamentally is the problem this idea is meant to solve? How worth it is solving that problem vs. others I know about? Does solving this problem create opportunities or risks in any form that I should think about?
2. Is this a problem I need to solve now, in 6 months, in 2 years, etc.? What's the risk of just putting it off?
3. Has this idea been validated in some form already? What's the "why" behind this being an idea? Is there a good hypothesis around it?
4. If it hasn't been tested yet, is there a low-cost iteration of this idea that my team could build and test quickly? What (rough swag) impact or learnings could a low-cost iteration yield?

This feels like a lot of questions, but I've gotten good at answering them quickly with a few driving assumptions to help keep myself moving. This is really hard early in one's product career, and potentially when you're working in a very new job or problem space - but as you ramp up, you start to be able to answer them faster.

This is a two-part question. Let me first articulate how I like coming up with ideas for new opportunities, followed by how I like to make decisions about what to build. Hopefully, you don’t mind that I’m thinking about “opportunities” because it might not always be a feature that’s the right solution.

I should start by saying that there isn’t one right approach to coming up with ideas. In my experience, I’ve had success ensuring that there are:

1. Insights from the four lenses: Customer, Business, Market, Technology
2. Effective methods to facilitate ideation

At the core, you have to have a deep understanding of the underlying user pain point you’re trying to solve through a thorough investigation of the Customer by talking to customers and product usage. You might actually learn very quickly that the user problem is around discoverability or activation, not necessarily a feature gap. Ideally, the customer impact is so deep that it translates effectively into Business impact. The Market context is critical to help understand how your user will experience the product within the broader competitive landscape and the direction an industry is headed. Finally, the Technology lens offers insight into what capabilities could be used as part of a solution.

Preferably, these four lenses come together through cross-functional ideation that has the right participants (e.g. PM, UX, Eng, and even folks go-to-market teams). In a hybrid world where we’re working across time zones, I’ve enjoyed having the opportunity to ideate together synchronously and asynchronously.

In terms of decision-making, the ideation process should lend itself to initial layers of prioritization. I won’t go into prioritization frameworks here, but there are many out there. They do tend to distill back to impact and effort and sequencing. At HubSpot, depending on the type of decision we are trying to make, we may use a “driver, approver, contributor, informed” DACI model used by other companies we admire like Atlassian.

Ideas can come from many places. They include customer feedback calls, customer troubleshooting sessions, customer submitted ideas (at Splunk, we have an idea submission portal called ideas.splunk.com), conferences (at Splunk, we host .conf where we have the opportunity to meet many customers in person), ideas from your engineering team (they generate some of the best ideas), and ideas you dream up yourself.  

Once there’s a list of ideas, we typically do a full re-prioritization at annual planning. Throughout the year, we also slot in new ideas and do minor re-prioritization as things change. 

New ideas can come from various sources:

• Customer and end User feedback

• Metrics and usage data. Metrics movers: ideas that will make a dent on you metrics

• Market research, competitive analysis and trends:

• Stakeholders such as other teams that are dependent on you

• Engineering efficiency and improvements

  Please see my other response on how to decide what to build.

Broadly speaking the decision for what to build depends upon:

1. User problems that the features will help resolve

2. Impact: what is the end customer or business metrics it will move

3. Long term strategy and roadmap alignment -> continue to build features incrementally for a long term benefit

4. Engineering effort needed to build

Generating ideas for new features is an ongoing process that draws from various sources. These sources include customer feedback, market research, internal brainstorming, competitive analysis, and emerging trends. By tapping into these channels, we cultivate a pool of potential features that could enhance our product.

Deciding which ideas to prioritize involves a thoughtful evaluation process. We consider factors like alignment with our product strategy, the potential value to customers, market demand, differentiation, competitive advantage, and the feasibility of implementation within our resources and timeframe. One approach is the RICE framework - Reach, Impact, Confidence, and Effort - which helps us objectively assess the potential impact of each feature or investment opportunity.

Depending on the investment area, we may also do a build vs buy analysis for ideas that we may not be best positioned to build. 

Ultimately, the selected features should contribute to addressing customer needs, improving user experience, and advancing our overall product goals. It's a balance between innovation, strategic alignment, and the practicalities of implementation that guides our decision-making.

One thing I've never had an issue on is coming up with features for a product. If you're ever bereft of ideas, simply go and speak to a customer and they'll provide a dozen ways your product can be improved. But it's important to structure the ideas so you don't get overwhelmed. Here's how you can go about doing that:

• Brainstorm with your partners: Setup time with your partners to generate and refine ideas. You can use customer feedback as an input

• Vote/prioritize on the top ideas: Give everyone a vote and see which ideas people care about the most

• Refine: Go deep on a handful of ideas and come up with a workable problem or hypothesis statement for that idea

Ideas for new features can come from a multitude of sources, and deciding which ones to build involves a thoughtful process of evaluation and prioritization. Here’s how we approach this at Barracuda:

Sources of Feature Ideas

1. Customer Feedback: Direct input from users is invaluable. This can be gathered through support tickets, customer interviews, usability tests, surveys, and feedback forms. Customers often provide insights into what features they need, what issues they encounter, and how their user experience can be improved.

2. Market Research: Keeping an eye on industry trends, competitor analysis, and market demands helps us identify features that could be necessary to stay competitive and relevant in the market.

3. Internal Teams: Ideas can also come from within the company—from engineers, marketers, salespeople, and support staff. These team members often see different aspects of how the product performs in real-world scenarios and can offer unique perspectives on what features might enhance the product.

4. Regulatory Changes and Compliance Requirements: Sometimes, new features are driven by changes in legal or regulatory standards within an industry, requiring the product to adapt to new laws and guidelines.

5. Technological Advancements: Innovations in technology can open up possibilities for new features. Our development team stays abreast of new tools, frameworks, and platforms that can enhance our product offerings.

Deciding Which Features to Build

1. Alignment with Business Goals: The feature must align with the overall business objectives, such as increasing market share, improving customer satisfaction, or driving revenue growth.

2. Customer Impact: We prioritize features based on the value they deliver to our customers. This involves evaluating how much a feature will improve the user experience and meet customer needs.

3. Feasibility and Cost: The technical feasibility of developing the feature, as well as the cost in terms of time and resources, are crucial considerations. We need to ensure that the benefits outweigh the costs.

4. Market Differentiation: Features that can differentiate our product in the marketplace often receive higher priority. We look for features that can give us a competitive edge.

5. ROI and Prioritization Frameworks: We often use prioritization frameworks like RICE (Reach, Impact, Confidence, and Effort) or the Cost-Adjusted Impact (CAI) model to assess and prioritize feature ideas based on their potential return on investment and impact.

6. Prototype and Validate: Before fully committing to building a feature, we often create a prototype and validate it with a segment of our user base. This testing phase is crucial to gather data on the feature's potential success or failure.

Ideas for new features come from various sources, including customer feedback, market research, internal brainstorming sessions, competitor analysis, and emerging technologies. To decide which ideas to invest in, product teams evaluate them against business goals, user impact, and technical feasibility.

Personally, I find a lot of joy during the ideation phase. The biggest challenge I see teams face is bringing these ideas together into a cohesive narrative that generates virality before the product is even built.

A single customer conversation will enable you to generate a product roadmap for the next 1 year.

While looking at competitors, speaking to thought leaders and industry experts, and prototyping new tech will always have their place, nothing beats speaking to a customer to generate new feature ideas. After all, who better to understand what's missing from your product than the ones who will use it most.

Now, it's critical to understand that you should never just build whatever your customers ask for verbatim. The famous Henry Ford quote comes to mind: "If I had asked people what mode of transport they wanted, they would have said faster horses." You are the expert in your field and know the product and tech the best. You should take your customer's feedback and translate it into a solution that addresses their pain point.

Netflix's biggest competitor is sleep

A surprising take on non-obvious solution is what Reed Hasting (CEO of Netflix) said when asked what their biggest competitor was. It was the usual suspects, Amazon Prime, HBO, Disney+. No, Hastings said that their customer falling asleep was their biggest competitor because streaming wasn't zero sum. So, what's a "non-obvious solution" to sleep? Creating 10+ binge worthy shows and dropping all the episodes on a Saturday.

Strategies to translate customer feedback to product solutions:

• Build for the problem: If you ask your customer for product feedback they will tell you a feature they'd like. For example, at Square some customers requested simpler tools for configuring an online site. Instead of building those tools, our team created an automatic site generation tool that converts existing data into a site, without the customer having to do anything. The problem was the complexity of website development, not the lack of tools.

• Uncover the "Why": Keep asking the customer "why" until you get to the root of their problem. For example, customers kept saying they didn't have enough information about certain hardware devices. Upon probing them "why", we realized that we were showing them too many products and overwhelming them. They didn't want more descriptions, they just wanted to be told what device was more relevant for their business

• Focus on Behaviors: Using qualitative and quantitative insights uncover what common behavior patterns are like. For example, we found that many customers were complete a specific task when setting up a new Square account. The obvious implication was that this task was most important to customers. However, what we learnt was that this was actually the first task we surfaced for customers and so they clicked it first.

Prioritize based on what creates most value:

Once you have a list of features, build based on a prioritization framework. While there are numerous frameworks (RICE, Kano, Value/Effort) and you can use any, it's important to be consistent across all the features. For example, if you use RICE - you would rank the features based on Reach (number of users impacted), Impact (level of user benefit), Confidence (certainty of the outcome), and Effort (development time).

As a PMM lead, I usually get feature ideas as a subproduct of my research & daily work. But if extracted, the best ways to discover what we need to build next come from:

1. Reading user feedback through existing surveys, and social listening.

2. Reviewing usability data (heatmaps, user recordings, website feedback tools).
   

3. Reading sales and CS Slack channels. Feature-related insights often spark there. Checking CS tickets for relevant keywords can help too.

4. Exploring Hubspot deals for customers on specific lifecycle stages.

5. Asking & listening to CS, sales, product, marketing, and data analytics teams. When you have the right questions, they will share magical insights.
   

6. Checking competitors, subsidiaries, or companies who serve the same audience. Competitor Intelligence tools can show you tons of interesting things. 

7. Reading competitor's negative reviews and case studies, yes, I do that :)
   

8. Playing with analytical tools to see if there are sub-segment of my audiences that have untypical conversions & behaviors through the funnel, and have untypical feature usage.

9. If I need deeper insights or validation of my assumptions I set up customer interviews or focus groups for feature discovery. But those need more time for preparation & synthesis.

10. If I need a deeper dive into data, I ask data teams to provide reports on what I'm looking for.
    

11. Asking the key knowledge holders and leadership team what they believe in, what we should build but not dneo yet, or what sparks for them.