Without watching the video, my immediate reaction and counterpoint to the headline is...
1) you often don't get to choose the problems to work on; instead, the problems tend to choose you. (A common sentiment in science and math research in addition to business ventures)
2) the best foundation for starting a company is to "scratch your own itch".
3) having 1000 customers who are rabid fans that pay to create a recurring dependable revenue is better than 100,000 so-called "customers" who sign up for a free trial but churn out.
However, after watching the video (relevant mark is 41m55s to 47m05s [1]), Des Traynor's quote is about prioritizing product features that are applicable to a wider base of customers. He's speaking from a B2B product mindset. If your dev team gets distracted by one-off features, you'll end up doing labor-intensive quasi-consulting work instead of building a broadly useful software product. Software can scale but consulting does not. For enterprise software companies, accidental "consulting work" is an insidious problem because you don't realize you're doing it.
This is exactly why B2B startups should avoid chasing whales. Any customer that makes up more than 10% of your revenue is going to be able to demand things and get them; even if those things are not in the best interest of the product. Your sales people will want to chase whales if revenue is the only metric; so you have to focus them on volume.
It's inevitable at some point; which is why most enterprise software companies end up as consulting companies after a certain scale. Consulting companies are ironically transforming themselves to be software companies as well, so competition is fierce.
Sales people on commissions is a significant driver of this sort of behavior. It isn't neccessarily bad -- they are finding the path in feature space that maximises their revenue. But unfortunately what drives companies to buy isn't the same as what makes end users happy.
I'm reminded that big or fast growing companies often totally ignore their users. (I'm thinking about you, Atlassian, with all your stupid emails about new features, while the bugs pile up, unanswered.)
Even when there are thousands of seats, rarely do vendors actively engage users. Some companies, like MathWorks, do engage well, and I think that is because there are not large corporate buys, but many end users demanding it.
>which is why most enterprise software companies end up as consulting companies after a certain scale.
Also, after growing to a big enough size, the software company can do "consulting" work without it hurting them.
When Microsoft Windows NT first came out, I always thought it was strange that they had POSIX[1] support. There was no I company I knew that actually used POSIX apis. It was only several years later at a Microsoft conference where an employee mentioned that POSIX was there to satisfy some government checkboxes. By adding POSIX, Microsoft was able to sell a ton of Windows licenses to the government. Most other enterprise software companies don't get an obvious ROI like that for customer-specific features.
I dont think it’s impossible to both chase whales as well as satisfying pools of smaller fish. It’s often hard to tell a whale ‘no’ so your team can work on smaller pressing issues for some smaller customers, but there just needs to be a balance and discipline on doing that. How you say no is also extremely important :)
>Consulting can scale [...], sell bodies (Accenture)
That's true but "scale" in the context of HN is often shorthand for "scales exponentially" instead of "scales linearly". The Accenture revenue scales with headcount via labor billable hours. That's not the same magnitude of platform scaling that Paul Graham, Marc Andreessen, and others are talking about. (E.g. WhatsApp platform scales to ~900 million users with just 50 employees.)
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.
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.
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.
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
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.
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.
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.
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.
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.
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?
Readit News
1) you often don't get to choose the problems to work on; instead, the problems tend to choose you. (A common sentiment in science and math research in addition to business ventures)
2) the best foundation for starting a company is to "scratch your own itch".
3) having 1000 customers who are rabid fans that pay to create a recurring dependable revenue is better than 100,000 so-called "customers" who sign up for a free trial but churn out.
However, after watching the video (relevant mark is 41m55s to 47m05s [1]), Des Traynor's quote is about prioritizing product features that are applicable to a wider base of customers. He's speaking from a B2B product mindset. If your dev team gets distracted by one-off features, you'll end up doing labor-intensive quasi-consulting work instead of building a broadly useful software product. Software can scale but consulting does not. For enterprise software companies, accidental "consulting work" is an insidious problem because you don't realize you're doing it.
[1] https://youtu.be/P6pQyB6ACrk?t=41m55s
It's inevitable at some point; which is why most enterprise software companies end up as consulting companies after a certain scale. Consulting companies are ironically transforming themselves to be software companies as well, so competition is fierce.
I'm reminded that big or fast growing companies often totally ignore their users. (I'm thinking about you, Atlassian, with all your stupid emails about new features, while the bugs pile up, unanswered.)
Even when there are thousands of seats, rarely do vendors actively engage users. Some companies, like MathWorks, do engage well, and I think that is because there are not large corporate buys, but many end users demanding it.
Also, after growing to a big enough size, the software company can do "consulting" work without it hurting them.
When Microsoft Windows NT first came out, I always thought it was strange that they had POSIX[1] support. There was no I company I knew that actually used POSIX apis. It was only several years later at a Microsoft conference where an employee mentioned that POSIX was there to satisfy some government checkboxes. By adding POSIX, Microsoft was able to sell a ton of Windows licenses to the government. Most other enterprise software companies don't get an obvious ROI like that for customer-specific features.
[1] https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
Their are 3 proven models for software companies. Sell boxes (Microsoft), sell bodies (Accenture), or customization & support (IBM).
It critical thing is companies needs to understand the business they are getting into from CEO to Sales to boots on the ground.
That's true but "scale" in the context of HN is often shorthand for "scales exponentially" instead of "scales linearly". The Accenture revenue scales with headcount via labor billable hours. That's not the same magnitude of platform scaling that Paul Graham, Marc Andreessen, and others are talking about. (E.g. WhatsApp platform scales to ~900 million users with just 50 employees.)
Choose.
https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...
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.
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.
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
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
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.
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
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.
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.
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.
Edit: thanks braindead for the transcript !
https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...
https://news.ycombinator.com/item?id=15914979