Be Wary of Solving a Small, Rare Problem [video](blog.ycombinator.com)
blog.ycombinator.com
Be Wary of Solving a Small, Rare Problem [video]
http://blog.ycombinator.com/be-wary-of-solving-a-small-rare-problem-des-traynor-of-intercom/
40 comments
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.
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.
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.
it’s unacceptable to ignore users. At least respond and provide a timeline or a reasonable acknowledgement. Sure, your company might have big accounts thst need more attention, but if there are bugs piled up and feature requests left rotting on the shelf - HIRE.
I agree. But we pay them money whether they screw us over or not. Maybe companies should explicitly price features and bugs in maintenance quotes?
- Base licence $2000 - Feature X - $100 - Fix bug Y - $200
At least it would be clear who has the money to back up their talk. But then would you expect to get the features and bug fixes you hadn't paid for? (Certainly for MATLAB they know how much money people will pay for each toolbox. But of course Sales then focuses only on the new toolboxes...)
I don't think hiring is Atlassian's problem, they have a huge team. Maybe the problems are sitting in the too hard basket. But I don't think so. I think someone decided features=growth and time spend fixing bugs was wasted time. So they are always about the features for the customer they don't have yet, not the ones they do. (And they continually screw their third party plugin developers by implementing popular features in the core. Admittedly, generally better integrated and with saner pricing, but eating their young nonetheless.) The Wilt Chamberlain school of software product development.
(I'm not talking about bugs only I care about -- some of these have thousands of customers demanding a response.)
- Base licence $2000 - Feature X - $100 - Fix bug Y - $200
At least it would be clear who has the money to back up their talk. But then would you expect to get the features and bug fixes you hadn't paid for? (Certainly for MATLAB they know how much money people will pay for each toolbox. But of course Sales then focuses only on the new toolboxes...)
I don't think hiring is Atlassian's problem, they have a huge team. Maybe the problems are sitting in the too hard basket. But I don't think so. I think someone decided features=growth and time spend fixing bugs was wasted time. So they are always about the features for the customer they don't have yet, not the ones they do. (And they continually screw their third party plugin developers by implementing popular features in the core. Admittedly, generally better integrated and with saner pricing, but eating their young nonetheless.) The Wilt Chamberlain school of software product development.
(I'm not talking about bugs only I care about -- some of these have thousands of customers demanding a response.)
>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.
[1] https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
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
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 as long as you realize that's what you're doing.
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.
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.
>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.)
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.)
Accenture can increase billable hours for it's lower level workers though optimizing the entire process. Executed well they can get 4-5x increase in profit per person which is much better than a linear improvement.
Consider all those people with 7 figure salaries and compare it to a 5 person consulting shop in India where Accenture has 130,000 employees. What makes this less obvious is small consulting shops tend to include the salary of top people as part of their profits, where big companies pay well and still have a lot left over.
Consider all those people with 7 figure salaries and compare it to a 5 person consulting shop in India where Accenture has 130,000 employees. What makes this less obvious is small consulting shops tend to include the salary of top people as part of their profits, where big companies pay well and still have a lot left over.
Accenture isn't evidence of scale.
It has revenue per employee of only $88k, nearly the lowest in the S&P 500, close to Starbucks and McDonald's, but with much higher paid employees. That's a complete clusterfuck of a business, and exactly why you don't want to do consulting.
https://priceonomics.com/which-companies-have-the-highest-re...
Whereas Facebook has $2M of revenue per employee, and nearly $200k in profit per employee, which is more than Accenture's revenue per employee. There's not remotely a comparison.
It has revenue per employee of only $88k, nearly the lowest in the S&P 500, close to Starbucks and McDonald's, but with much higher paid employees. That's a complete clusterfuck of a business, and exactly why you don't want to do consulting.
https://priceonomics.com/which-companies-have-the-highest-re...
Whereas Facebook has $2M of revenue per employee, and nearly $200k in profit per employee, which is more than Accenture's revenue per employee. There's not remotely a comparison.
Facebook can't use 200,000 workers making that a meaningless comparison.
Really, Facebook has more limited growth potential without becoming a different company as they can only make so much money from social media. On the other hand you can have 1,000,000 people working for you if you are simply managing work outsourced by others.
Foxconn has 136.12 billion in revenue and 1.3 million workers. Facebook has 27.64 billion USD Revenue and plenty of profit but fewer ways to grow Revenue.
Really, Facebook has more limited growth potential without becoming a different company as they can only make so much money from social media. On the other hand you can have 1,000,000 people working for you if you are simply managing work outsourced by others.
Foxconn has 136.12 billion in revenue and 1.3 million workers. Facebook has 27.64 billion USD Revenue and plenty of profit but fewer ways to grow Revenue.
[deleted]
You usually want to scale revenue, not costs....
Ideally you scale costs to increase profit. If you could increase retinue from thin air then you're not actually scaling anything. But, in a scalable model you invest more in your leverage be that advertising or whatever and you get more revenue which assuming a good cost structure directly results in profit.
Facebooks problem is they can't scale because they already own the market and there are profitable new customers available. If they spend more on advertising they simply get less profit because their costs go up without increasing revenue.
Facebooks problem is they can't scale because they already own the market and there are profitable new customers available. If they spend more on advertising they simply get less profit because their costs go up without increasing revenue.
That's true, but saying that its "better than linear" is not really the same as "exponential growth" that the poster is talking about that you get from self-reinforcing network effects.
X ^ 1.01 is still exponential. But, I understand your point.
Ha, I was in consulting for a while (not Accenture but close enough) and ran projects where we did this type of project-level profitability analysis.
We wouldn't have called it "exponential", because even though you're right that we made a multiple on a person's salary that's > 1, that multiple is pretty much fixed after a certain point in the size of the company.
3x would be typical for a mid, but if I add one more incremental mid I will still expect to make 3x my total salary, so that is still a linear revenue=3*totalsalary. If that 3x because 3.1x or something as I hired more people, then yes, you get some exponential effect there, but it would only do that in extremely small consulting shops.
We wouldn't have called it "exponential", because even though you're right that we made a multiple on a person's salary that's > 1, that multiple is pretty much fixed after a certain point in the size of the company.
3x would be typical for a mid, but if I add one more incremental mid I will still expect to make 3x my total salary, so that is still a linear revenue=3*totalsalary. If that 3x because 3.1x or something as I hired more people, then yes, you get some exponential effect there, but it would only do that in extremely small consulting shops.
[deleted]
Super-linear* ;)
I've been thinking of taking routes 2 and 3... I wonder what are examples of companies who have done this successfully?
This. Things go wrong when you don't know which game you're in.
Which is a totally not new insight. I have been taught this in the 90ies while in a consulting shop which had a product.
Choose.
Choose.
Thanks for providing the relevant mark. You just saved me 40 minutes!
Here's a automated transcript in case you don't want to wait for the edited one.
https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...
https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...
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.
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.
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.
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
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
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
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
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.
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.
[0] https://www.reamaze.com
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
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.
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.
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
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.
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.
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.
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?
I would be grateful for a transcript. Intercom is usually very insightful and their blog posts are great.
Edit: thanks braindead for the transcript !
https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...
https://news.ycombinator.com/item?id=15914979
Edit: thanks braindead for the transcript !
https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...
https://news.ycombinator.com/item?id=15914979
The market of people willing to sleep in someones front room on an airbed is ridiculously small...
I couldn't find the book Des recommended? Anyone have a link?
I think this is it : https://smile.amazon.com/Managing-Humans-Humorous-Software-E...
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