Be Wary of Solving a Small, Rare Problem [video]
blog.ycombinator.com
blog.ycombinator.com
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.
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.)
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.
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.
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.
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.
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.
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.
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'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.
- 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.)
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.
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.
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.
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.
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.
Edit: thanks braindead for the transcript !
https://scribie.com/transcript/26bbb21e33ff4989b9494b496cf25...