Earlier this year, my employer Castlight Health acquired another company called Jiff. I took over the product responsibility for machine learning driven and user input driven personalization for the combined companies. The team that built personalization at Jiff is a capable team with many ideas, some customer implementation under their belt and tens of customers who have bought into those ideas. Looking at the clear need in the market, I decided to focus on executing on those ideas to accelerate delivery of functionality to customers who were paying us millions of dollars every year. Since then the team has delivered their first major functionality release which personalizes Jiff home page and prescribes benefits based on machine learning driven prediction intelligence from Castlight. We are now working towards the next release focusing on user input driven personalization and benefits prescription.
When I did my initial analysis of the team and Jiff personalization product, I noticed that like any young and ambitious team, my colleagues were trying to build too many things too fast. I introduced two principles. The first one is to design and build minimum viable products rather than release too much functionality at one time. The second principle is to deliver value early and often. I will talk about the first principle in this post.
Minimum Viable Product (MVP)
I shared the diagram below with the team and explained how we need to build a minimum viable product. For example, I explained to them that if we are building Survey functionality, we should not release it without building at least a simple reporting functionality. It is not only a product error, but also a business error. If we release a Survey feature without associated reporting, customers will reach out to us for reporting, increasing our cost of customer operations. Since manual reporting will involve data analysts and engineers, we will also lose the opportunity to build new valuable features. All these things will make the customer wait for days and weeks and will most certainly decrease their satisfaction with our product. It will also slow down the delivery of future innovation.
I also asked the team to think like a landlord rather than like an architect. The team responded very well. We started defining our products in a very disciplined manner. We consciously reduced features that were not necessary for the MVP. We started thinking about total cost of operations rather than just the first release of the product. Sometimes, sales teams and even business executives lose track of this fundamental principle. It is the responsibility of the product manager to ensure that this principle is understood and adhered to.
Deliver Value Early and Often
We also followed the principle of delivering value early and often to customers. We have large customers who have hundreds of thousands of users. Such customers go live with our benefits management platform usually once a year. These implementation projects are large, take months to execute and have tens of work streams involving multiple teams. I notice a tendency among implementation teams to not show any product until very late in the process. I am putting down a process in place where we show and even release functionality to customers months ahead of their requested delivery dates. I believe it has several advantages. I will write more about this principle in a future post.
When I did my initial analysis of the team and Jiff personalization product, I noticed that like any young and ambitious team, my colleagues were trying to build too many things too fast. I introduced two principles. The first one is to design and build minimum viable products rather than release too much functionality at one time. The second principle is to deliver value early and often. I will talk about the first principle in this post.
Minimum Viable Product (MVP)
I shared the diagram below with the team and explained how we need to build a minimum viable product. For example, I explained to them that if we are building Survey functionality, we should not release it without building at least a simple reporting functionality. It is not only a product error, but also a business error. If we release a Survey feature without associated reporting, customers will reach out to us for reporting, increasing our cost of customer operations. Since manual reporting will involve data analysts and engineers, we will also lose the opportunity to build new valuable features. All these things will make the customer wait for days and weeks and will most certainly decrease their satisfaction with our product. It will also slow down the delivery of future innovation.
I also asked the team to think like a landlord rather than like an architect. The team responded very well. We started defining our products in a very disciplined manner. We consciously reduced features that were not necessary for the MVP. We started thinking about total cost of operations rather than just the first release of the product. Sometimes, sales teams and even business executives lose track of this fundamental principle. It is the responsibility of the product manager to ensure that this principle is understood and adhered to.
Deliver Value Early and Often
We also followed the principle of delivering value early and often to customers. We have large customers who have hundreds of thousands of users. Such customers go live with our benefits management platform usually once a year. These implementation projects are large, take months to execute and have tens of work streams involving multiple teams. I notice a tendency among implementation teams to not show any product until very late in the process. I am putting down a process in place where we show and even release functionality to customers months ahead of their requested delivery dates. I believe it has several advantages. I will write more about this principle in a future post.
