How do you know when to pivot or kill a product or feature?

"Get paid vs Not getting paid" As a product manager, you don't build features to get paid every time. While those features add values to your product without generating revenue E.g - For LinkedIn Like/comment/share post feature will not get paid While Sponsored posts gets paid - For Amazon Standard delivery will not get paid While Prime delivery gets paid PM needs to be thorough while coming up with a product roadmap. However, the roadmap needs to be dynamic which should be looked into once/ twice in a month One of the practices that I follow is to include Key metrics in PRD document for any feature. This helps the stakeholders to identify which areas will be measured after the feature is released PM needs to identify such scenarios

My experience for defining goals and metrics are in sectors that don't lend themselves well to metrics. For example high Annual Recurring Revenue per customer in B2B, or even pre-launch in B2C in some scenarios. In these situations you are unlikely to be at volumes of data that will gain you a sensible overview - they will be too sensitive to general "noise" or fluctuations. You will likely need to instead define goals using qualitative information, and that can be as simple as "3 customers mentioned X topic in interviews in the past month". Don't let the goals and metrics framework get in the way of its aim - to allow you to define what the product does, is going to do and why, and make sensible roadmap decisions based on that.

Knowing what you need to accomplish in addition to the desired goals and measures should be done before launching the product. And without this knowledge, it is like traveling without knowing where one wants to go, even if the road is beautiful, it never ends.

Setting clear goals/KPIs is necessary - but the wrong ones are likely to be counter productive. - Before committing to your goals/KPI make sure to squeeze those critical thinking skills of yours. "Is that really what we want to achieve?", "Is that really what our customer want?", "What is really the evidence behind it?". - Beware of the bag of biases: Confirmation bias, Overconfidence, Selection bias, and so much more. Be humble and honest. - Bullets vs Cannon balls: try small, low cost things before committing to a big hairy goal. There's more, of course.. but it is important to acknowledge that this is not just an analytical exercise - it is also a behavioral one. It is about focus, followup, persistence, adjustments.

Typically, any vision is complex and cannot be achieved in a single step, thus along with a clear vision, you also need a clear plan for fulfilling it. You can regard that as a list of mini-visions, each with their own KPIs, but you should focus on the current mini-vision and way to achieve that. This way you don't lose sight of the bigger goal while having tangible milestones towards it. Once a mini-vision is fulfilled, you can make a plan to the next one, with the relevant KPIs.

In many situations, we can ignore the honest feedback we get from the market. We get so blind by the vision we had and the feedback we expected. No one will be more honest than the market itself. Not your mom, not your best friend, not even your haters. The market as a mass is the best evaluator to what you’re offering. Gather data on scale, look at your analytics and understand the different steps of your product offering to understand what and where is the failure. Use that feedback as your engine to move forward.

It is important to listen to customers, but at the same time it also important to understand what is the true source of the pain points. Asking customer's journey is very important, as it helps to know how they are using the product. This is critical since the user journey that we might have hoped for is not the one that is being followed in real life.

Simple. Listen to your end user. Ask precise questions. Gather feedback. And consider the answers as your Holy Grail. The people using your products will give you such valuable insights that sometimes even the product team may not be able to think of.

Metrics help, but nothing beats talking to as many customers as I can. There are some cases where I have seen the metrics were low. Digging into it, it turned out to be enablement issues, additional work was needed, or the feature was no longer needed as the product evolved and was eclipsed by other features.

I've been in a few situations without a user analytics tool to assess if a feature is being used. If you do not have usage analytics to hand, ie there is not a user analytics tool installed, there might be proxy data available in the product's data or logs that you can use instead.

Ignore sunk costs. If a product isn’t delivering it doesn’t matter how much you’ve already put into it. Sunk costs can cloud judgement.

Having an expectation that aligns with the market behaviour of the product, for example, you cannot expect a fintech business to acquire transacting users within a month because there is trust at play which in turn will require some time. The key here is to define "some". How long does it usually take for competition? Another key point to consider is if that timeline is befitting in my business context.

Every feature you build has an impact, even if it’s minute. The way to measure if what you’re building is making a great impact is by comparing it to a similar product’s impact or to your own previous features. It won’t be clear what impact you’re responsible for if there is no other product or service you’re comparing it to to understand how much time, money or effort you need to invest more in it. If the comparison shows low impact, or impact that doesn’t grow, it’s time to move on. Sunk costs are snuck costs, this is business. You’ve got to move on.

Easier said than done. You don’t want to make engaged customers who are using the feature unhappy (and end up losing them) but you see that only a few perceive value and you need to focus your efforts. The key here for me would be to analyze who is interacting with the feature and what makes these customers different from the others (or why are most or target customers not using it). If you can answer this, deprecating or pivoting could become a bit less difficult.

One of the reasons organizations miss when it's time to kill a feature is because clear goals and metrics were not defined before feature release. After a feature is released, if you don't have relevant metrics to evaluate the success of the feature, it can result in wasted expenditure of company resources to upkeep the feature that isn't even valuable to end users. I cannot understate the importance of being able to measure adoption of a feature at regular intervals. Clear metrics should also allow the organization to evaluate if other factors caused a more limited adoption - such as an ineffective marketing campaign - so that early launch issues can be addressed to drive higher adoption.

Few indicators to knowing when to pull the plug : 1. Usage & Metrics : Monitor usage & performance metric closely. 2. Financials : Though this seems to be a no-brainer, sometimes a feature or a product is allowed to run into loses if you have aces up your sleeve in the long run. If you are raking up loses which are beyond your control, it's time. 3. User Feedback : If your users find no value in your offering and your product has no USP. 4. Strategic Alignment : If it no longer aligns with the company's goals and vision. It has no value chain proposition. 6. Competitive Landscape : If your competitors are way ahead of you and your team needs years of hard work just to support the bare minimum offering.

I agree with the others here about sunk cost fallacy. Think about the opportunity cost of carrying on too. What else could you be doing? What is the value in that? Is that more closely aligned with the vision of where you want to go?

Here are a few key considerations I've found helpful when determining to kill a product or feature: Market Feedback: Regularly gather feedback from customers and evaluate whether your product or feature is meeting their needs and expectations. Market assessment: Does the business value still make sense? Do other features have a higher business value? Just because a feature provides some value, it does not mean you should choose it at the expense of a more valuable feature. Long-Term Vision: Does this feature enable key pillars of your strategic plan?

In my experience, the sunk cost fallacy can be a major pitfall in this context. I encountered this firsthand when my team had invested significant resources in a nearly production-ready platform. However, due to internal organizational shifts, it became clear that the ROI for continuing this investment was not justified given other opportunities. We initiated an open dialogue between the product and engineering teams to explicitly address the sunk cost fallacy. This ensured that our decision-making process was unbiased and rational. After weeks of thorough discussion, we made the difficult decision to discontinue the project. I believe it saved both financial and engineering resources for the company and my team.

I used to make Boost, Improve or Kill dashboarding, with my data team. We usually tried to find patterns between feature use, user industries, churn, and some key feature usage. Depending on it we could sometimes deduce a monetary gain from it which helped to assess whether more investment in it could be interesting or if it should be killed.

Remember the intention is not to please everyone. A decision to stop something will make some people unhappy. The key thing is to stick to the message and your rationale and say why it’s good for the customers and the company .

It is important to give clients as much notice as possible. Even though metrics might show very low overall usage, there are always going to be clients that have adopted a certain feature quite intensively.

Making a bad decision is better than making no decision at all, and this is a principle for me. Not only in the course of product development, you need to be able to make a decision, but you also need to be able to communicate this decision well to the team.

It is critical to state what part of the decision is data-driven (hopefully all of it) and relies on assumptions and estimations. Often I see decision that are claimed to be data-driven but are more of a manager's gut feeling

1- Always remind your stakeholders the reason the feature was developed. 2- Explained what may have changed since 3- Give product analytics metrics & meaningful verbatim feedback about it 4- Explain your recommendation 5- Decide and / or clearly explain the company's final decision

Fail fast and Pivot: Identify issues early and minimize wasted resources. The team can refine the approach, learn from failures, and accept failures with a growth mindset. This also builds an innovation culture. Lead by example. Taking the failure of a product or a feature personally will lead to a negative customer experience that WILL tarnish your product’s image. It takes ten times more effort to recover from a bad customer experience. Personal biases or preferences can cloud judgment and lead to decisions that may not be in the best interest of the product or its users.

Usually, it takes several iterations and pivots in order to make a decision to kill a feature - because of all the time and effort investment done previously - loss aversion is a real thing. That is why is it important to conduct detailed and focused user research and discovery up front, in the concept and framing phase, so then the risk of building the wrong feature and wasting so many resources is significantly reduced. User Interviews, Surveys, and Problem and Opportunity-framing Workshops are the most common techniques for validating early-stage ideas and prototypes.

Fail fast and pivot is the game in town. However, as a product manager, you need to understand and try to find an alternative to limit the impact to your clients, especially critical clients. If we challenge ourselves and be creative, we may find a path to satisfy both.

Sometimes you just have to live with your decision. Maybe there was 1 more tweak that would have made that feature work. Maybe it did just needed a little more time or marketing to take off. Maybe it was just in the wrong place in the app. But maybe it was never going to provide the value you thought it would. Sometimes you have to make the hard calls.

Few thoughts.. - I believe we need to stop thinking "Failing fast" and focus on "Failing well". Failing is only good if it is not repetitive, if it provides insights and as cheap as it can get. Failing fast without a strategic learning method - is as bad as it can get. - We have been captured too long in the false narrative that agile is effective. It was - comparing it to the traditional waterfall model. learning cycles of weeks (if not months) is a very wasteful and slow. - Qualitative feedback is king. It is rich and insightful. It is also painfully difficult to process - and it still worth every effort.