4 ms·

It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Custome

It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A behaving in one way or another. So which set of customers do you please? How do you ensure that customer requests for behavior changes, or customers being surprised by application behavior doesn't result in a scope creep that expands the requirements of your application to an unsustainable level? How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? There's a lot of jokes about bugs actually being features, but at some point if an application behaves in a certain way long enough and that behavior is relied on elsewhere, changing it is a new feature with all the consequences that come along with that, even if the new behavior is strictly more correct. All of these factors need to be balanced in determining what the best path is to tread in your software. At a certain scale, most of these questions can be addressed organically, maybe by the developers themselves, but at a certain scale it's just not feasible to interface customers directly with developers. You are working on "new features and new products", because customer issues get turned into identification of new markets to solve those issues, which are serviced by new features and new products rather than by "fixing" the old products and features, which would break it for other customers.

stevoski 8y ago
That's a great description of the subtleties of product development, especially within a small team. Many books and articles make it seem like a simple procedure, but actually you often face decisions which will leave some people unhappy, no matter what you decide.
- Novashi 8y ago
  You basically have to get into supporting extensions or custom code and supporting an API if you run into enough of these customers and that’s when you declare that you only have so much responsibility for the customer’s code (and it quickly turns into another support revenue stream).
  - ticmasta 8y ago
    I worked for a company that had product managers that were very talented at turning requests for custom features into solutions that we enabled (and our core was required to implement) but using a third party to implement. Consulting was used to find new core features and keep a finger on the pulse but not as a significant revenue generator. It enabled us to grow a product company to big revenue per headcount metrics, which is hard to do as a service company. The situation described by GP is primarily a expectation and people management problem, not a technical issue.
notyourday 8y ago
> How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? You don't. You remember who pays your salaries ( i.e. it is the customers who pay you buckets of money, not Joe Random User that bitches about paying $5/mo ) and you prioritize the features/requests of the Bucket Of Money customers. If you have a real product, then the requests of Bucket of Money customers would closely match the requests of other customers and your product will grow gangbusters ( see AWS/Salesforce/Dropbox ). If they do not, then it is quite possible that in reality you are nothing else but the custom dev shop for one or two bucket of money customers and you dont have a real product.
- ticmasta 8y ago
  >> you are nothing else but the custom dev shop for one or two bucket of money customers and you dont have a real product. This is my experience building for and selling to enterprise. There are a limited number of 800lb gorillas and but every company thinks they are a special snowflake. This quickly has you building software tightly coupled to workflow which is death for commercial software. It's usually one of the reasons the market exists in the first place; incumbents can't get the required reward to match the effort at their desired scale.
sdegutis 8y ago
> So which set of customers do you please? How do you ensure that customer requests for behavior changes, or customers being surprised by application behavior doesn't result in a scope creep that expands the requirements of your application to an unsustainable level? > How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? Fork the product into two (or more) separate products, each of which are somewhat similar but cater to different audiences with different needs.
- watwut 8y ago
  That strategy would leave you with dozens and later hundreds of forks and variants. You need to make decision here and appoint product owner to make those decisions consistently.
  - sdegutis 8y ago
    Extrapolating from Alan Perlis's quote, I think it's better to have 3 products that each do 1 thing well rather than to have 1 product that does 3 things very poorly.
    - watwut 8y ago
      Practically speaking, you will have multiple products that are crappy, because you will be unable to maintain them all and keep track of what should work how in each version. Moreover, fixes that should go to each will take more time to develop, testing will take more time and there still will be additional bugs due to complexity of it all. Also, organization and management of it all will take more time and effort. You need to reconcile them or make decision.
jlg23 8y ago
The problem is not your alphabet of customers but the insistence on calling it feature "a". If the same feature has mutually exclusive specs, it is not one but two features and it is exactly product development's task to make that distinction.

stevoski 8y ago

That's a great description of the subtleties of product development, especially within a small team. Many books and articles make it seem like a simple procedure, but actually you often face decisions which will leave some people unhappy, no matter what you decide.

Novashi 8y ago
You basically have to get into supporting extensions or custom code and supporting an API if you run into enough of these customers and that’s when you declare that you only have so much responsibility for the customer’s code (and it quickly turns into another support revenue stream).
- ticmasta 8y ago
  I worked for a company that had product managers that were very talented at turning requests for custom features into solutions that we enabled (and our core was required to implement) but using a third party to implement. Consulting was used to find new core features and keep a finger on the pulse but not as a significant revenue generator. It enabled us to grow a product company to big revenue per headcount metrics, which is hard to do as a service company. The situation described by GP is primarily a expectation and people management problem, not a technical issue.

notyourday 8y ago

> How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? You don't. You remember who pays your salaries ( i.e. it is the customers who pay you buckets of money, not Joe Random User that bitches about paying $5/mo ) and you prioritize the features/requests of the Bucket Of Money customers. If you have a real product, then the requests of Bucket of Money customers would closely match the requests of other customers and your product will grow gangbusters ( see AWS/Salesforce/Dropbox ). If they do not, then it is quite possible that in reality you are nothing else but the custom dev shop for one or two bucket of money customers and you dont have a real product.

ticmasta 8y ago
>> you are nothing else but the custom dev shop for one or two bucket of money customers and you dont have a real product. This is my experience building for and selling to enterprise. There are a limited number of 800lb gorillas and but every company thinks they are a special snowflake. This quickly has you building software tightly coupled to workflow which is death for commercial software. It's usually one of the reasons the market exists in the first place; incumbents can't get the required reward to match the effort at their desired scale.

sdegutis 8y ago

> So which set of customers do you please? How do you ensure that customer requests for behavior changes, or customers being surprised by application behavior doesn't result in a scope creep that expands the requirements of your application to an unsustainable level? > How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? Fork the product into two (or more) separate products, each of which are somewhat similar but cater to different audiences with different needs.

watwut 8y ago
That strategy would leave you with dozens and later hundreds of forks and variants. You need to make decision here and appoint product owner to make those decisions consistently.
- sdegutis 8y ago
  Extrapolating from Alan Perlis's quote, I think it's better to have 3 products that each do 1 thing well rather than to have 1 product that does 3 things very poorly.
  - watwut 8y ago
    Practically speaking, you will have multiple products that are crappy, because you will be unable to maintain them all and keep track of what should work how in each version. Moreover, fixes that should go to each will take more time to develop, testing will take more time and there still will be additional bugs due to complexity of it all. Also, organization and management of it all will take more time and effort. You need to reconcile them or make decision.

jlg23 8y ago

The problem is not your alphabet of customers but the insistence on calling it feature "a". If the same feature has mutually exclusive specs, it is not one but two features and it is exactly product development's task to make that distinction.