Sales success is easy. All you need is a product that looks great and has more features than the competition. Of course, once your competitors see your feature-packed, great looking product, they will want to add some new features to their product, just to stay in the game. But that’s okay. You have some extra features of your own hidden up your sleeve…
This is a natural trap for sales teams, product owners, and developers alike to fall into. It is, after all, the job of product owners to come up with new features, developers to get on a build them and sales folk to sell them. No one wants to lose a sale due to a ‘missing feature’. And there was once a time when a great product fronted by a great sales team was as close as you could get to a guaranteed recipe for success.
But now, in the age of Software as a Service, the sales process is being turned on its head.
Customers are increasingly seeking out products that best solves a single problem for them. Doing one thing well is a strong selling-point in a market where clients know what they want and assume they can get it somewhere: ’There’s an app for that’ sounds better to most contemporary clients than ’There’s a suite that can deliver all those things, plus a few things you don’t think you want now but you might use them later’.
Research shows that a product’s longevity is affected by its ease of use and simplicity of uptake. And even in terms of initial sales, a look at the most successful start-ups of the last ten years reveals a long list of products designed to do one thing well. But one of the imperatives of business is to generate new customers – which means adding new features, right?
Sort of. The cost of adding new features rises with each feature you add, leading to a reduction in the total value received from a customer. The code complexity increases and as a consequence the time taken to add a new feature without causing quality issues increases. But it is true that doing one thing well is not the only solution.
Another solution is to look at new feature development in terms of the way your software is built – Application Architecture. Even large and seemingly monolithic applications can have better market success by treating features as modules that can be developed, installed, and maintained separately.
This calls for something of a revolution in how we approach application development.
If your product has been in development for ten years, it’s unlikely you will be able to just stop your release cycle and turn all its different aspects into stand-alone modules without significant upheaval.
Unless you build the redesign process into your development cycle from the start. This might slow down your feature delivery initially. But over a period of time, as you modularise your application, your rate of software release will go up and the bugs reaching production will go down.
The advantage of this approach is that when a new feature is introduced, or a bug is fixed, the change can be isolated within a subset of the code base – reducing the potential impact on other parts of the application and the quantity of testing required. As the change is isolated to a smaller installable this can be released separately, further reducing the testing impact for your customers.
While this approach is not new in the software industry it has a new name – Microservices. The most difficult question to answer when determining your Microservice strategy is where the boundaries of your new application should be.
If you want to read more about this subject, including more of the technical details, we recommend Martin Fowler, and from Thoughtworks.
Stratigence can help move your products Architecture to one that easily supports the addition (and removal) of features.
Any questions? We’d love to chat.
