you run a company. you get lots of customer requests.
while every business is different, these requests can usually be described as deep or wide.
below are some thoughts on approaching each type of customer request, based on your company goals.
customer request: "improve X to also do Y, Z."
- retention. existing customers who depend on this feature will thank you for investing in making it better. vendor lock-in is also a great marketing strategy (see: microsoft).
- activation. free trials who routinely cancel will stick around, since their expectation of feature X will be meet with elation vs frustration.
- reputation. does your company want to be known for doing Y and Z really well?
- focus. is this investment worth shifting priority of other projects on your roadmap?
customer request: "integrate your app with ______."
- acquisition. potential for co-marketing to a highly trusted audience - the other company's customers.
- revenue. your ideal customer persona (ICP) could be waiting for mere compatibility, no extra features required.
- overhead. more to maintain, either in lines of code or support expertise.
- focus. are you ignoring your #1 channels to chase the next best thing?
in my opinion, companies who are first to market should go wide first, deep second.
at fomo, we call this spreading surface area.
beyond the allure of a new audience, increased market visibility also deters would-competitors from starting.
later, as [preferably] high-CLV customers ask for deeper feature sets, you already have their credit card on file.
nothing is worse than building a brand new feature for a prospect, only so they can bounce because they don't like your pricing.
likewise, nothing is better than keeping a customer by delivering something they need to remain successful on your platform.
a product roadmap that doesn't change to meet customers' needs is a product roadmap designed by developers, not entrepreneurs.
likewise, a product roadmap that cowers to every chat request is designed by an insecure marketer, not a visionary.
practice creating a symbiotic relationship between what you want to build, what you actually build, who you build it for, and when you deliver.