Prioritizing work for mature products

There's no golden rule or perfect framework for prioritization. Here are a few things we should keep in mind when building mature products (products with substantial revenue and usage).

• Always prioritize our ICP (Ideal Customer Profile)
• As products mature, we start to get more and more users who are not strictly within our ICP. Building for these users is great - but only if we've satisfied the core needs of our company-wide ICP first.
• Should different products have different ICPs?
• The very first ICP should always be the same. However, some products will fill their needs sooner than others.
• Prevent churn before capturing growth
• Not all churn is preventable - some customers' businesses don't make it. These customers are usually in our smallest revenue bucket and shouldn't really impact prioritization - unless the question is about how to make them more successful (which is a good question for sure, but not always relevant).
• Preventable churn usually comes from:
• Lots of bugs or particularly bad bugs
• Missing features that competitors offer
• Pricing
• Not proving value often enough (eg. lack of use because it doesn't fit into their workflow)
• Churn should be roughy equivalent across products - if yours is high, figure out why and fix it. Growth is less effective when you have a leaky bucket.
• Use metrics as a guide, not the end-all-be-all
• Trust your instincts and your convictions. If you _just know_ that something is the right thing to build, then build it.
• Use metrics to help point you in the direction of what general area to focus on if you don't have conviction elsewhere.
• Reprioritize enterprise feature requests when it makes sense
• Larger enterprises will sometimes make esoteric requests. Other times their requests are totally valid - but we're busy with other things.
• If the following are true, you should prioritize their needs immediately:
• The customer represents a large churn risk
• The feature has been requested by multiple customers and will be widely used
• The lack of the feature prevents them from using the core product
• Don't put off the hard things
• If something seems important but difficult, and another thing seems easy, don't just do the easy things. Teams that do the difficult things will pull ahead. (assuming doing the difficult thing is possible - usually we want to see some evidence that it is)