Value Proposition and Product Strategy
An end-to-end business product strategy and service analysis.
Project Information
This project was executed over 12 weeks and provided a base for discussions around product strategy within certain market segments. Some hard lessons were learned by leadership and managers on product maturity and internal attitudes towards what constituted a product and overall service delivery as market-ready.
Project Links
⁍ Pain points per market segment
Company
Advanced Human Imaging (now Advanced Health Intelligence)
It’s Not Me, It’s You.
After several early integrations, it became clear that our product was not gaining the expected traction. To address this issue and align departments, I suggested initiating a value proposition project.
Leadership triggered various red flags that I believed needed to be addressed, such as blaming the customer for the product's failure.
These included:
⁍ They did not integrate it properly.
⁍ They charged too much for it.
⁍ They implemented our scan guides incorrectly.
⁍ Their users were not reading the guide properly.
⁍ They didn't spend enough on advertising the benefits of the scans.
Needless to say, these were our failures.
The Elephant in the Room
After speaking to key stakeholders, they all agreed that the product did fall short in various ways, but it was market-ready. I wondered why and how they reached that conclusion. The general response was "I've used it!" and others compared it to a competitor, saying "it's easier than theirs and they went to market" (referring to Amazon Halo, which was eventually closed).
What was also happening was that the CEO at the time had come to that conclusion that we were ready to commercialize based on customer feedback and perhaps board member pressure. From that point on, we were now commercializing and no longer in “startup mode”. Everyone, therefore, adopted that mindset, and any problems we knew were there were deemed non-critical, since in their mind by the time the tech would be integrated, they would be solved.
It reminded me of a quote from the book The Mom Test by Rob Fitzpatrick:
"Compliments are the fool's gold of customer learning: shiny, distracting, and worthless."
When it came to customer meetings, naturally, everyone would say only positive things. The usual questions would have the same answers: Yes, it was easy to use. Can you see the live demo, right? Yes, it's easy to integrate; we have a flexible and modular SDK to embed. Yes, you can create your own guides. Check. Check. Check.
Unfortunately, nobody had done the math.
Documenting the maturity of products from stakeholders.
Making it Happen
The company went through a change in leadership at the time, so I proposed to the new CEO that I should undertake a detailed Value Proposition exercise over the coming months and then provide a summary to report any problems. What was needed was the big picture.
I outlined the goals of the Value Proposition:
- ⁍ This intent is run through a series of exercises to see who we are, where we operate and to whom.
- ⁍ It is partly an audit of the company and the market segments.
- ⁍ We should investigate our current offering and map it in a certain way to expose vulnerabilities and weaknesses.
- ⁍ It is a conversation starter to fixing our objectives, fix strategy, drive projects and product offering to fill in customer needs.
- ⁍ It will identify problems with costs and certain clients, offerings, and integration values in the eyes of the customer.
⁍ Create a Service Blueprint and various other visuals to help widen the view of departmental leads.
Findings
Cost Analysis
One of the most important tasks carried out was working out costs:
⁍ Their Costs: Analyzing the cost a partner will spend when integrating our technology, and
⁍ Our Costs: Incurred customer acquisition costs through to a typical integration
It was predicted that a typical (minimum) integration would take a partner 6 non-consecutive weeks to complete, per platform. So if a partner was integrating our technology on iOS and Android, the total time would be 12 weeks (even though Android builds tend to be more resource intensive and take slightly longer!).
This cost and time sink by a customer is important because:
- ⁍ They will need to adjust their already busy timelines and fit us in.
- ⁍ They will also need to make sure they can maintain the features moving forward.
- ⁍ Ensuring that it's generating enough money or value to pay for itself and generate revenue.
In extremely modest calculations, given offshore geography and the best of circumstances, it was calculated that a partner would spend $150,481 per platform or $300,962 for iOS and Android, just to integrate the technology. We would not see income for at least 6-12 weeks, and for the partner to break even at the base cost, it would take 42,918 scans.
The cost to the company was at least US$20,000. Given that the scans being conducted were quite low, the license fee would pay for the company's time in about 4 months. When you make more money from the license fee than the product you are selling, it would seem obvious there are issues.
The solution was clear: everything should be easy to integrate. The modular SDK model was fine, but it left too much for the partner to integrate from day 1. Source code should be handed over from GitHub, and it should be available in various formats like React and Flutter to cater to popular frameworks.
A customer should be able to get something up and running in a day, and from there, they can spend more time giving vision to their integration and spending more time modifying what we give them to meet their desired outcomes. They will have ownership from the beginning and are more likely to support their own codebase if it is handed to them.
Product Pricing
I established that there were 2 kinds of customers with regards to pricing:
- ❶ Partner company pays for users (includes subsidies)
- ❷ Users pay
Typically, companies like health insurers will cover the costs for their policy holders and companies in direct to consumer markets like fitness would likely pass on the costs. It is also about risks to existing products that generate income.
AHI used the same volume based pricing model for both kinds of customers. Working from the entry-level pricing, the base cost for both scans (body scan and face scan) was US$6.99 per user a month. There is also an additional “license fee” of $5000 a month.
If the end-user is paying for the technology, then the customer will need to build it into their subscription model, or implement additional payment functionality for an “add-on”. I discovered that partners will not include the scans as part of their existing subscription because it would price them out of the market and put their main source of revenue at risk.
Instead, we were being integrated as an add-on (low risk). Those individuals who already spent US$11.99 a month on a subscription, will now be offered to pay another US$9.99 (includes partner markup) just to use a fairly minimal scanning feature that isn’t fully integrated yet. A few customers had already undergone this exact scenario, so I did not need to speculate on the outcomes. Barely any add-ons were purchased (in the low twenties) on this integration.
Given the initial developer cost, this is a terrible investment for the customers. The integration would eventually be removed and the contract would not be renewed.
Pricing vs Growth Strategy
Volume pricing is counterproductive to the mass growth strategy that we had adopted in revenue prediction models. The target customers were big companies and governments in healthcare and insurance with a large volume (over 50 million). These deals can take years to solidify, and the product and services were not mature enough for this kind of integration. In practice, we were actually signing with SMEs with under 250,000 potential users (on paper). They were also more likely to be type 1 customers who let their end users pay.
Volume pricing (even with a free tier) works against the growth models of smaller companies, especially when they are passing the cost onto the end user. They are also hit with a $5000 license fee, which was actually just a commitment payment so we could make a minimum from partners to pay for our invested time on the project should they bail.
Our pricing model and strategy were not suitable for the majority of customers we were actually signing. This cost barrier alone was enough to deter users. If they did manage to get through the paywall, then they were met with further barriers affecting the adoption rate.
A free tier, no license costs, and the same low price for all customers would encourage mass adoption. As our customers grow, we grow. Millions of users at 10c are far more potent as a metric for success than 500 at $6.99. The product infrastructure and supporting systems would mature faster due to the adoption rate. Issues would be escalated quicker and solved faster due to their importance. You would end up with a better product over time and maintain customer retention.
Data Saturation
- To date, there has been little or no conversation or mapping around the benefits we offer to post-launch stage or long-term customers. This is a stage where the biometric data is coming in and reaches a point where reporting or dashboards can be created. Users are grouped based on biometric risks or changes.
- This data goes beyond age and biological sex; it includes obesity risk or cardiovascular risk. It is accurate enough to compare it to population data and measure the performance of the app or changes made by the customer.
- This biometric data is then used to shape the business. Decisions are being made using the data of its users to improve its product and expand offerings. This is exactly where you want to be with a customer. They rely on us at this point and will continue to grow. I named this milestone “Data Saturation” and marked it as a sign of a successful integration.
- If we reach that point with a customer, it means we were are successful. We had no long-term vision for partners regarding the benefits of the scan data in product decision-making. I suggested that we should update marketing collateral to include project timelines for reaching data saturation.
Example: Pain Points by Segment
Wrapping Up…
A partially sanitized document can be viewed here. There was some followup by stakeholders to address the problems and opportunities that I uncovered.
Due to the acquisition of 2 more companies (WellteQ and Vertica Health), the project was put on hold. The company also changed names from Advanced Human Imaging to Advanced Health Intelligence, changed CEO again, and was pivoting into different assessment methods where the main focus would tend be around the Biometric Health Assessment.
I went on to further document the full list of barriers that were affecting the product. This would be separate UX Testing projects to determine friction points and putting an "abrasion" value next to each scan.
There was also a shift in the strategy due to the acquisitions and focus on healthcare and medical drug distribution. A lot of key staff considered us as "measurements as a service" like a plug it in SAAS model. Due to the nature of healthcare, this was not a suitable way of thinking. Although that service model resonates with potential investors and the market while explaining market penetration figures, it does not reflect the difficulty in actually fulfilling that task.
We had to change the way we saw our own product. Modularity and customization are enemies of integrations. Keeping it simple and structured for the new assessment products is paramount. It would reduce the load on resources and allow us to focus directly on a great experience.
The Metric of Success
Discussions around what a successful company looks like becomes to come into questions. A sales team with reward based KPIs pushing an unfinished product gives one part of the company a sense of price and then the other is being let down.
It was time to review this notion of success and have conversations around how we can measure it in terms of successfully using the product (e.g. completing a scan on the first go) instead of from a monetary point of view. This grass roots perspective means you align departments as you are all responsible for helping more people perform successful scans. The sales department would become part of customer success and be a conduit for change.
Summary of outcomes
- ⁍ The suitability of our product firmly lies within mHealth (Telehealth, Medical, Corporate Wellness) and Life & Health Insurance.
- ⁍ Support for international customers is greatly diminished due to time zone differences.
- ⁍ Patent protection is ineffective in stopping infringing companies unless the legal fees can be covered.
- ⁍ Lack of Certification/Marking makes us ineligible with some partners.
- ⁍ Lack of champion integrations and case studies.
- ⁍ FaceScan does not properly show lighting for darker skin.
- ⁍ No confidence scoring exists with any scans, leading to a lack of insights into the submitted image quality.
- ⁍ No solution exists for an 'assessment' BodyScan, which is a major pain point for mHealth and Life & Health Insurers.
- ⁍ Weak messaging on Complete Scan's actual value compared to existing hardware or competitors.
- ⁍ Lack of support, documentation, and marketing materials hinder a partner's success.
- ⁍ BodyScan remains immature as an offering.
- ⁍ The effort and cost of integrating CompleteScan by partners do not yield suitable outcomes for growth.
- ⁍ The effort and cost for AHI remain high for all partners, regardless of volume expectations.
- ⁍ There is no long-term vision for partners regarding the benefits of the scan data in product decision-making.
- ⁍ The price is too high when combined with existing subscriptions or offered as a standalone option while subscribed.
- ⁍ Comparing the pricing to a DEXA machine to justify our pricing is not realistic.
- ⁍ Pricing model alternatives achieve growth in different ways, but in practice, they might not be suitable for the use case.