
Be Wary of Solving a Small, Rare Problem [video] - lainon
http://blog.ycombinator.com/be-wary-of-solving-a-small-rare-problem-des-traynor-of-intercom/
======
jasode
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)

~~~
exelius
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.

~~~
angry_octet
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.

~~~
ohnoesmyscv
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.

~~~
angry_octet
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.)

------
braindead_in
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/26bbb21e33ff4989b9494b496cf258402e83ee96)

------
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](http://www.catb.org/esr/faqs/smart-questions.html)

------
GFischer
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://scribie.com/transcript/26bbb21e33ff4989b9494b496cf258402e83ee96)

[https://news.ycombinator.com/item?id=15914979](https://news.ycombinator.com/item?id=15914979)

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

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

~~~
dairem
I think this is it : [https://smile.amazon.com/Managing-Humans-Humorous-
Software-E...](https://smile.amazon.com/Managing-Humans-Humorous-Software-
Engineering/dp/1484221575/)

