6 ms·

Be Wary of Solving a Small, Rare Problem [video]

69 points by lainon 9y ago

jasode 9y ago
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. [1] https://youtu.be/P6pQyB6ACrk?t=41m55s https://youtu.be/P6pQyB6ACrk?t=41m55s
- Retric 9y ago
  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.
  - jasode 9y ago
    >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.)
    - Retric 9y ago
      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.
      - philipodonnell 9y ago
        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.
        Retric 9y ago
        X ^ 1.01 is still exponential. But, I understand your point.
        matlabradoodle 9y ago
        Super-linear* ;)
        deleted 9y ago
        [deleted]
        philipodonnell 9y ago
        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.
  - rsp1984 9y ago
    This. Things go wrong when you don't know which game you're in.
  - odonnellryan 9y ago
    I've been thinking of taking routes 2 and 3... I wonder what are examples of companies who have done this successfully?
- rsp1984 9y ago
  Thanks for providing the relevant mark. You just saved me 40 minutes!
- exelius 9y ago
  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.
  - jasode 9y ago
    >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 https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
  - angry_octet 9y ago
    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.
    - 9y ago
- the-dude 9y ago
  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.
braindead_in 9y ago
Here's a automated transcript in case you don't want to wait for the edited one. https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf258402e83ee96 https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...
GFischer 9y ago
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/26bbb21e33ff4989b9494b496cf258402e83ee96 https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25... https://news.ycombinator.com/item?id=15914979 https://news.ycombinator.com/item?id=15914979
erader 9y ago
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.
- stuaxo 9y ago
  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_ 9y ago
    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?
- hw 9y ago
  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 https://www.reamaze.com
tr0ut 9y ago
I couldn't find the book Des recommended? Anyone have a link?
- dairem 9y ago
  I think this is it : https://smile.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/1484221575/ https://smile.amazon.com/Managing-Humans-Humorous-Software-E...
andy_ppp 9y ago
The market of people willing to sleep in someones front room on an airbed is ridiculously small...

69 points by lainon 9y ago

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. [1] https://youtu.be/P6pQyB6ACrk?t=41m55s https://youtu.be/P6pQyB6ACrk?t=41m55s

Retric 9y ago
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.
- jasode 9y ago
  >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.)
  - Retric 9y ago
    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.
    - philipodonnell 9y ago
      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.
      - Retric 9y ago
        X ^ 1.01 is still exponential. But, I understand your point.
        matlabradoodle 9y ago
        Super-linear* ;)
        deleted 9y ago
        [deleted]
        philipodonnell 9y ago
        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.
- rsp1984 9y ago
  This. Things go wrong when you don't know which game you're in.
- odonnellryan 9y ago
  I've been thinking of taking routes 2 and 3... I wonder what are examples of companies who have done this successfully?
rsp1984 9y ago
Thanks for providing the relevant mark. You just saved me 40 minutes!
exelius 9y ago
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.
- jasode 9y ago
  >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 https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
- angry_octet 9y ago
  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.
  - 9y ago
the-dude 9y ago
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.

braindead_in 9y ago

Here's a automated transcript in case you don't want to wait for the edited one. https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf258402e83ee96 https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...

GFischer 9y ago

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/26bbb21e33ff4989b9494b496cf258402e83ee96 https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25... https://news.ycombinator.com/item?id=15914979 https://news.ycombinator.com/item?id=15914979

erader 9y ago

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.

stuaxo 9y ago
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_ 9y ago
  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?
hw 9y ago
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 https://www.reamaze.com

tr0ut 9y ago

I couldn't find the book Des recommended? Anyone have a link?

dairem 9y ago
I think this is it : https://smile.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/1484221575/ https://smile.amazon.com/Managing-Humans-Humorous-Software-E...

andy_ppp 9y ago

The market of people willing to sleep in someones front room on an airbed is ridiculously small...