Not Reinventing the Wheel to Reduce Costs

Sometimes someone within an organization will task the software development team with developing new software features and prescribe a solution that “does not reinvent the wheel”. Many software consultancy companies create software based on the problem-solution paradigm. There is one major customer that has a specific problem, the consultant analyzes the requirements of this customer and formulates a solution.

With the goal of saving costs the consultancy will try to resell this solution to multiple customers, what the consultancy terms “productizing” the application. I believe it is wrong to classify a consultancy’s output as a resalable product like a cog in a machine. The nature of this customer/consultancy relationship is that the next customer will have requirements that are analyzed and the software will need to be changed, which is at odds with profitability because the goal with the second customer initially was to resell an existing solution. To continue to attempt to save on costs the consultancy that is now analyzing the requirements of the second customer will task the software development team with new requirements, prescribing reusable parts of a prior solution and pushing not to reinvent the wheel. What is meant by this is to leverage existing code. However, the second customer’s problem is different than the first customer’s problem, new requirements have been captured the resulting system that needs to solve the second customer’s problem needs to be examined first as a system and not individual swappable parts. After all, what was initially created for the first customer was a solution to a specific problem inside the context of one customer, not a general-purpose reusable framework. Inevitably the second customer has unique demands that end up contradicting the first customer’s and this makes the system grow more complex.

Another way to approach this is if you want to create a product, then analyze different potential customers at the beginning and synthesize a product that addresses those customer pain points. Generate your own frame of looking at the problem (your way of adding value) and spend energy building the framework you will use to build the product, even though the framework has no individual customer yet. A part of a product’s value is how it frames the problem, not just that you can buy a cog. Analyzing customer requirements individually and transmuting these directly into development tasks will not create a product, even though it might result in a solution for a specific customer. A consultancy is not wrong, but terms and business processes that work in product companies might actually be greedy shortcuts in a consultancy that end up misunderstanding and prioritizing future customers solutions.

I’ll give an example to demonstrate how creating a solution for one specific customer is in conflict with creating a resalable product. If you are creating a solution for a specific customer’s problem then you will continuously be trying to keep that one happy satisfied and solving their problems. No two customers are exactly the same. However, if you are building a product then it is acceptable that some potential customers might not be ready to use your product because they are too small or potential customers have outgrown your offering and are ready to move on to other solutions outside of what you offer. In this case, you might lose a customer through no fault of your own and your product is still a success. In a consultancy you have failed if you lose a customer. In a product company you are trying to create customers that are a fit for your product and you are inviting customers to frame their problem so it fits your product solution.

Another example is a consultancy does not want a customer to solve their own problems. Demand for the consultancy increases when the customer has more problems they want solved. This orients the consultancy around expanding to solve more of fewer customer’s problems because the path of least resistance is to sell more solutions to someone who is already paying you. On the other side, a company selling a product can align with insight selling where customers armed with data from websites and research done by themselves have been heavily influenced in knowing what solutions can be used to solve their problems.

Not reinventing the wheel cannot be prescribed because a consultancy wants to reduce costs. Not reinventing the wheel is a constraint on the input and is decided by how the business operates before it gets to the software development team.


One thought on “Not Reinventing the Wheel to Reduce Costs

  1. I agree with your analysis, I think that most middle sized companies lack foresight to develop a middle sized business into a potentially larger more successful business, they are interested in keeping existing clients and meeting all their demands instead of focusing on developing a “Product” that could make more more money and is useful to variety of end users. If you look at most of the hugely successful software companies (i.e. Microsoft, Adobe, Symantec) they didn’t get there by solving problems of an individual, they create a great product and the masses go to them.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s