[erader]

I totally agree with that sentiment, but I find it hard to swallow coming from Intercom.

Even as their customer, I find that they don't like to solve any problem that doesn't fit within their 'philosophy'. I've submitted countless feature requests to no avail, and clearly they've left their customer facing teams high & dry. I feel bad for their support staff and success teams that have been completely disjointed from product teams.

Intercom is my go-to example of a product that tried to re-invent the wheel, but only came up with half of a wheel. They need to finish it. They need to help customers solve the problems they are experiencing, which continue to exist because some missing features don't fit the 'Intercom philosophy'.

Generally speaking for any product team, just make sure you've completed your due diligence of making sure a problem is in fact rare and small. You'll often be surprised at what you uncover.

[tensor]

As an aside, I think companies should take "problem requests" not feature requests. A feature requests implies a solution, and letting your customers be your product designer leads to generally messy and poorly designed products.

So rather than submitting "I'd like the app to do Y", it would be amazing if customers instead submitted "I'm trying to solve problem X and having trouble." Maybe Y is a good solution for X, but maybe Z is too and Z wasn't asked for even though it might be what you need.

[sitkack]

Related, "How to Ask a Question" [0]

Features always need to be put in the context of the problem(s) they are solving. If a product team is implementing customer feature requests in an open-loop they are doing it wrong. The product designer's job is to synthesize multiple requests, find the root causes of the problems and come up with a compact composable design that knocks out multiple FRs at one time. Simply implementing FRs gets one into a wall of buttons.

[0] http://www.catb.org/esr/faqs/smart-questions.html

[erader]

This is exactly how our team likes to operate :)

Taking only 'requests' leads to a whole range of potential problems: - Feature bloat with random one-off buttons and gizmos - Product teams getting in the habit of ignoring requests if they know that most don't quite fit - Really complex products (both for customers and internal teams to understand/troubleshoot) - Unclear roadmaps - Wasted time. For example, I had a request to build a notification-silencer for specific executives at a company. I recommended that the executive set up email filters instead

[mikeleeorg]

Yes!

I once implemented a GetSatisfaction/UserVoice-esque feedback widget. The most useful feedback we received came in when we worded the widget with text like, "What problem would you like us to solve for you?"

It got slightly less responses than a generic, "Feedback form" label, but the quality of responses was much higher.

[hw]

Sometimes a product team think they know what their customers want and are tunnel-visioned with their 'wheel' too much to see the forest through the trees. Also, it's not uncommon that product teams prioritize feature requests from their larger accounts over smaller ones.

Feel free to check out Re:amaze [0] (I'm a co-founder). Our philosophy and product is driven solely by customer requests - not looking at what others do and just trying to fill a competitive feature checklist. If there's something you need that you don't have right now that we can solve, we'd be absolutely happy to discuss. We leave no customer request stone unturned.

We're starting to look at our 2018 roadmap and the first thing we are doing is looking at feature requests by our customers (both big and small, we don't discriminate) and plan around solving our customers' pain points. In fact we do that every week as well, albeit at a smaller scale.

On the issue of disjointed teams, I really do think it's extremely important for the product team, engineering team and everyone in a company to be involved with customer support and actually answer customer support conversations. That's the only way (aside from being a customer directly) that the company as a whole can get behind the customer and understand their pain points. That's in fact how we do things at Re:amaze. While that might be shunned at and not too feasible at larger companies, there's still a ton of room for a sliver of that to happen.

[0] https://www.reamaze.com

[charlesdm]

Totally agree! I work on a completely different product in a different market (Stockfolio, a stock and crypto investment app: https://stockfolioapp.com) but I've found exactly the same thing to apply.

Once you have a working product in a market you know exists, the most important features will frequently pop up; people will reach out to you. You can then use all that feedback to build out a great product.

[newusertoday]

can you share the features that are lacking in intercom? and would you be willing to pay more for them? if yes how much i.e $/month

[erader]

My list is too long to share, but let me give you a very simple example.

On most chat platforms, the widget displays an "mail" button or something similar that allows the visitor to send the transcript to themselves for reference later on.

Intercom does not have this, and agents don't the ability to quickly send transcripts either. Our team literally has to copy/paste the transcript into a new Zendesk ticket to send it.

Intercom's philosophy dictates that a 'conversation' is an ongoing thing that happens anywhere: in-app if the user is in session or via email once the user's browser session your website has stopped.

Their philosophy ignores the very clear pattern of visitors treating the intercom widget like a "normal" chat widget (which many have come to expect).

The 2 ways to perceive this are: - Adding this feature adds value for me and I should pay for it - Adding this feature bring Intercom to parity with customer expectations, and should be included in the price. Not having it is an unnecessary blocker.

I strongly believe in the second one.

[stuaxo]

I get a similar feeling with Docker.

If your not using Docker as a deployment tool and want every deployed instance to be the same then you are SOL. Which is a shame, as there are other uses, but they are hampered by the lack of a couple of features that have had open tickets for a long time.

[Terr_]

I'm afraid I don't understand what deficiency or scenario you're describing here. Does it have something to do with ensuring old containers are stopped?