Let us consider the automotive industry. It is currently one of the most dynamic in technological advancements and innovations. And, to keep up with these advancements, we are building future-forward solutions which can be stood up or torn down whenever needed instead of having to use the same technology for years.
Developing the next generation of solutions by adopting this generation’s needs early, identifying new approaches of problem-solving and increasing the speed of implementation will ensure continued business success.
In this blog, I shall discuss what it takes to tackle such circumstances that require high flexibility to meet the ever-changing requirements of a dynamic ecosystem.
Short-cycle iterative development to create breakthrough impacts
We engineers at HARMAN Connected Services work in SCRUM. We are agile. One of our main goals is to deliver quick, precise pieces of code that achieve maximum customer needs with minimal effort. It sounds like a simple target to achieve; asking customers what they need and delivering exactly what they want but establishing such a process can be challenging.
So, let me make it as straightforward as possible, here are some of the usual high-level lifecycle of collecting new features:
- Get the customer requirements
- Determine which new capability should be part of our product
- (as opposed to a project, which is separated from the product)
- Add the new feature to existing products
- First, deliver this MVP to the customer
- Continue delivering improved products to the customer with new features
For us at HARMAN, MVP means building a product with robust features,
- something that will not crash our product when used incorrectly,
- something that will look and feel OK,
- something that can be used by our customers,
- maybe even in production but without the full set of features.
While introducing a new product feature, especially a generic feature it must continue to be robust. The feature must support many a sunny day or a rainy day flow. It may need configuration flags and plug-ins. Lest we forget, it should also support backward compatibility among other things.
The customer may only want a new capability, but there is more to it than merely applying just that. Let us think of a shelf full of books and someone tries to push in a new book in the middle of the row. This will affect the whole shelf. Likewise, while implementing a new feature, we must understand that the requested feature must be implemented along with other essential additional capabilities. So, if you must implement more than the core of the feature, why not just implement them on day one? This will only enable you to receive customer feedback as soon as possible.
We always try to get the quickest feedback from our customers for each new feature. This is one of our most important values.
A customer typically focuses only on the core feature and that sometimes becomes the essence of the feature itself. While the customer definitely expects us to consider rainy-day scenarios but does not allocate resources to provide quick feedback. Our approach is to:
- Implement the feature as soon as possible,
- Send the new core feature to the customer for feedback,
- Get the feedback from the customer
- Make the modifications based on the feedback
Is this feature an MVP? No, it is not! We still have to think about exception handling for the product, but at this stage in the product cycle, feedback for exception handling could wait as compared to the feedback for the core feature itself. We could consider this after the first round of feedback. This essentially reduces the quantum of feedback requirement during any iterative step, making it less resource intensive.
While the customer's feedback on the sunny-day usage is more valuable, ensuring that a backup process is in place for rainy-day circumstances will only increase confidence in your product. All other things are secondary and can be delivered later after the first feedback is received from the product, research and development teams. Also, know that the feedback on the new feature's core could potentially change your entire solution.
So, does MVP really exist? Yes, it does. We could consider the core of the feature and the codes surrounding it an MVP but to get to the correct MVP we need to continuously communicate with the customer starting before pre-MVP delivery, get their feedback, and determine if we require any post correction.
I would like to hear your thoughts about building an MVP, please drop me a line here or on LinkedIn/Twitter.
