Iterative Value Creation to Customers
Building software products is a lot more forgiving than hardware products. One could counter that by saying all products have unique challenges and constraints. Let’s evaluate our hypothesis by an example of building an SoC for computing devices. The SoC in question has to work with all kinds of software applications, perform under varying degrees of heat and workload. It could be possible to set expectations for users on performance to watt but it would not be possible to ship it if the SoC does not work for all the apps on an operating system for a vendor. Notably, from the business perspective, there is only one chance to impress the customer, no chance to send updates or upgrades to a hardware product. Imagine a car being sold without air conditioning and later on trying to fit the old cars. However, the software can be sold at the bare minimum, to begin with, and then can be upgraded for the existing users. This is a luxury that needs to be utilised carefully.
A product stands to compete in the market so long as it can add value, possibly by solving problems for its users. However, the value is contextual. Something valuable today may not be valuable tomorrow, depending on the market. For example, having the best supply chain, operating at the lowest cost to produce DVDs was valuable a couple of decades ago but not in 2022! Therefore, it is important to prioritise the right value proposition at the right time. How about defects in a product backlog? Don’t they top the priority list? After all, defects are some things that failed to work as advertised. But all defects can’t be taken as the number one thing to do, at the expense of building iterative features. While critical bugs that affect the primary user journey need to be fixed, the rest can be taken up at appropriate times.
As part of product design, there would be features for not just solving user needs but also for product support teams. When the user interaction is not baked into the day-to-day process for prioritisation, there could be slippage in prioritising value creation to the customers. Even though prioritisation is a balancing act between the current risk posed, the complexity of development and estimated efforts, it is recommended to tilt toward the customer values in the beginning, probably until there is a justifiable user base, and later on, make it robust under the hood. Perfection is an ideal goal but maybe, adequacy is better in most cases.
Why all these iterations are important? Simple answer — resources, we have a finite number of working hands. Waiting for them to perfect the product may end up being too late for the market. Google Maps today is far better than ten years ago but they did not wait till 2020 to release the product. Another point worth mentioning about the resources is the translation of capacity into an outcome. Just because I have 500 engineers that can work for two hours simultaneously, does not guarantee that I will get a job worth 1000 hours in two hours. Even the largest software companies with the most brilliant developers also require their product managers to be good at art prioritisation.
Prioritisation is not just for the development of the features but also for release. Shorter the release cycle, a faster iteration of the value to the users. The shorter release requires a robust process. As a product manager, asking the right questions in this regard along with tangible outcomes would lead to a lesser burden on the team. A product manager needs to know which features are valuable and when to ship them. Frequent value addition to the users can keep them excited about the product. Sometimes, a product manager has to go out of the schedule and release the features at very short notice. If user feedback is heard by way of product outcome too late, users do not feel valued. A user that feels valued will be the product evangelist.
There is always a tomorrow and there is always a new version to release but the art of iteration comes from attention to details of user needs.
“If you are not embarrassed by the first version of your product, you’ve launched too late”
_Reid Hoffman, the founder of LinkedIn
