Hacker News Reader

Comment by ryandrake | Hacker News Reader

Been through this at medium sized companies struggling to sell. This kind of customer is alluring but poisonous. Company: We sell Product X! Toxic Customer: I don't want Product X, I want Product Y. If you're willing to bolt Product Y onto one of your menus I will pay you this stack of money for it! Company: $$$!

Bam! The company just went from being a product company to a custom engineering service. You will have to drag Product Y along with your product forever as a big lump of technical debt. After a few repeat iterations of the above, you will have a franken-product with random features hanging off of all ends, confusing to general users and impossible to maintain.

If you're a Product X company and one customer wants Product Y, stand your ground and tell them to go find Product Y somewhere else. If tons of customers want Product Y, maybe pivot and become a Product Y company and ditch Product X.

View on HN

I think 49.9% of executives agree with that and 90%+ of product people/developers agree with that too. The problem is that it's rarely X and Y. It's almost always justifiable, though. Imagine X=1 and Y=100.

If you sell 1 and a customer asks for 100 it's easy to say no. If they ask for 50 or 25 it's still easy.

The problem is when they ask for 2. Or 1.5, and are willing to pay big bucks to get it. It's hard to know whether your line should be at 2 or 20 or 80, especially when you can make business arguments for all of them and they all come with buckets of money attached.

Oh, yes, it's a difficult call. The customer might even start in with this (stop me if you've heard THIS one before): "Hey, we'll pay all your NRE for you and you get to sell it to everyone else including our competitors as part of your product!!"

Do this, and your product people (if you have any) will all quit, and your engineering talent will start thinking "If we're just another custom engineering consulting company now, why don't I just go over to one of the big consulting firms and make actual money doing the same thing?

But there are cases (my common case) where something the customer wants is really a great idea and many other customers would benefit (and we would have eventually gotten there). So it's not always a bad thing :)

Tangent: who are the "big consulting firms [who pay] actual money"? SAP? IBM? Salesforce?

I'd assume companies like Pivotal, ThoughtWorks, and such.

And hundreds (thousands?) of other ones who don't regularly make the front page of HN.

Well, no. There can't be thousands of "the big consulting firms".

But more than that, I'm pretty sure the point of the question was to get a list of such firms (I'd like one too!), not to be assured "they're out there, even if you'll never know who they are or how to find them".

Agreed. I was bought out by a company who charged high license fees but did not charge for customer development. So every customer wanted all these customisations to the point where most of the development was customer-initiated changes. Worse, is that due to this policy they had no idea whether an individual customer was profitable or not, since they had no idea the time/resources spent on that particular customer.

I advocated reducing the license fees but charging for customisations which would reduce this bespoke development considerably, but to no avail.

The big challenge is that this type of technical debt can be hard to see. But "We promised our VC 50% growth, and we're only at 35%, and this gets us to 60%" is very easy to see.

I think this is the main reason that, pretty much, only technical founders seem to succeed at finding good exits (I know there are exceptions), they're very aware of this issue.

I have worked with non-technical founders who just don't understand that concept of a mythical man-month and technical debt. Unless you've lived through it, it just sounds like engineers whining, not a valid business liability. All the non-technical founders I've worked with fall into the trap of catering to their board at all costs.

I had to do an international marketing plan for a local business in one of my marketing classes in school, and the local startup my group chose did exactly this. Their products were so spread out across so many different industries, there was no telling where their focus was.

They were also into consulting, so whatever product they thought up for one customer, they started advertising on their website as a finished product. The product we were focusing on exporting to another country had 1 customer...the one that commissioned the product. We actually didn't learn that until halfway into the project, but by that point, we were already leaning towards suggesting that they forget about exporting any product overseas and focus on getting more business in our area.

I went through this. It's only possible to stand your ground if you have sufficient capital reserves to wait for other customers. In our case we had burned up most of our funding through several pivots so when a prospective customer agreed to pay for Product Y there was no practical alternative but to say yes.

You literally explained the situation I find myself in with my bootstrapped company. I couldn't have explained it better.

He also literally explained the situation of any IT department in a reasonably large corporation. N departments equals M custom features with M > n.

Yes! So many startups in YC encounter this exact problem in their early days...

Ideally you would avoid this situation, but if you find yourself here: a good mitigation strategy is feature flags. If it's been agreed to build feature Y for one customer, then enable that feature for only that one customer. It's not a panacea, and won't necessarily help with your tech debt, but it will help the product stay focused from a user perspective.

FWIW, every product I've worked on has gone through this.

I worked on a large codebase with this approach of 'feature for x'. It will not scale, IMHO.

Far better to agree with someone wanting feature N is that if you want it and it's a good fit for the majority of users, you pay for it - everyone gets it.

It is a hard problem to tackle, especially given the sums involved in delivering sometimes trivial-effort features.

I understand this for products that have product-market fit. But what about products that aren't generating any revenue yet? Wouldn't the fact that someone is willing to pay to develop it further for them indicate demand for the product? Also couldn't this be viewed as doing things that don't scale by building a product that one company loves? How do you draw the line between this, and creating technical debt?

That’s pretty much the reason most web development firms never manage to get really big. There’s too much ad-hoc work.

But what if selling Product Y allows you to become ramen-profitable?

You can

* decide that you want to be an engineering consulting firm that charges only ramen, which will make your customer very happy

* become ramen-profitable on product Y without it taking all your time, build and market product X, then dump your customer and product Y (make sure you don't sign a contract saying that you have to keep supporting product Y)

* say no and find another way to become ramen-profitable

Then you have to make a decision then. Do you want to make revenue from the product, or make revenue via customisations? Problem with the customisation approach is there is limited leverage.

Reply on news.ycombinator.com