Coupling & Crosstalk: MVP for Hardware Development?

Coupling & Crosstalk is my column in the MEPTEC Report. This column appears in the Summer 2014 edition on page 8.

Electronic coupling is the transfer of energy from one circuit or medium to another. Sometimes it is intentional and sometimes not (crosstalk). I hope that this column by mixing technology and general observations is thought provoking and “couples” with your thinking. Most of the time I will stick to technology but occasional crosstalk diversions may deliver a message closer to home.

MVP for Hardware Development?

Just like professional sports leagues, lean product management has MVPs! Sports teams try out players, compete, and then end the season with “Most Valuable Players” and champions. Unlike sports, winning product managers start out with Minimum Viable Products (MVPs) early on to
determine which products and features to field in the market.

Lean product developers use MVPs to test core functionality and build relationships with early adopters who hopefully will become product evangelists. Using MVPs, also know as “minimum feature set” products, is a good practice to accelerate time to market by validating the product and adjusting the business model.

With software, it is fairly straightforward to generate a MVP build that has only the most critical functions including those that differentiate the product. Hardware is more challenging, but there are ways of building “sub systems” or “proof of concept” versions that allow customers to validate the features. Customer feedback on functionality and utility can be collected and analyzed while spending the absolute minimum cost and time to build each iteration of the MVP.

The early adopters are game to test the MVP’s functionality since they get early access. They know that the MVP is not a finished product and that their inputs will shape the future direction of the product. Similar to the international confusion over the naming of “football”, which in America isn’t soccer, MVP isn’t a product. The MVP is not intended to be a version of the final product but a “discovery” vehicle. Since the accuracy of customer reports may vary widely, MVPs provide a platform for collecting data about actual usage patterns.

The marketers and/or customers may not fully know what needs to be in the final product or how it might work or be used. This is especially true with disruptive technology or never-before-seen products. Steve Jobs is reported to have not used customer “focus groups” for defining early iPhone product requirements since he claimed customers had no idea what they wanted until they built the first iPhone.

Another source of confusion with MVPs, possibly due to the name again, is the concept of minimalism or minimum product requirements. Sometimes MVPs are confused with the goal that “full-featured” products should only contain the features that customers value and nothing extra. If customers are unwilling to pay for a feature why add it since it will have direct development and support costs along with indirect costs such as inventory and “cost of complexity”? To maximize profits, the marketer needs to clearly identify the minimum set of product requirements and then add features to provide the right amount of “sizzle” to increase sales.

Sometimes the only way to get real data on the value of features is from actual sales and price negotiations. The difficulty in obtaining real data may be compounded by customers not knowing what they value until they have experienced a given feature. Building MVPs or having other “demo” programs can help customers gain greater understanding of what they want. And occasionally customer “wants” that exceed their true “needs” may justify features that can be included at a premium.

Mining this data yields additional sales and profit opportunities that may be non-intuitive. Years ago when shopping for a convertible, I was told they were only available with “optional” heated seats. I laughed hysterically since I thought it was ridiculous to pay for heated seats here in the temperate San Francisco Bay Area. Over time, after grudgingly paying for the heated seats, they became my favorite luxury item in the car. The marketing and sales team at the dealership and the manufacturer profited by knowing the customers’ desires better than the customers.

With software, especially web-based applications that typically have extensive user tracking and analytics, it is easy to measure the features customers use. Historically for “hardware” this is more difficult without direct observation of end-user use cases. Many new hardware products today have sufficient computational power and connectivity that can report detailed usage patterns. For example, most smartphones relay usage statistics back to the manufacturer. And as the surprised reporter from the New York Times learned, the Tesla he was reviewing recorded every driver action. Not just speed and location of the car but small actions such as rolling down the windows and adjusting the cabin temperature.

Lastly, product management teams need to consider the issue of differentiation. How is your product different from existing solutions in the market? Ideally, the differentiation is substantial and sustainable. A “me-too” product with just a slightly lower price may not be enough. The competition could simply lower their price to remove the difference. A new function, for which there is substantial intellectual property protection (patent, etc.), that significantly improves the performance of a product at the same price point as the competition is a significant and sustainable differentiation.

As a company develops new products or enters new markets, product management often doesn’t have a single most valuable player (tool). There are three competing challenges that need to be balanced: minimalism, differentiation, and discovery. Knowing what your customer really values and how your product is different is essential. Minimum Viable Product (MVP) activities, even for hardware, are good vehicles for discovering what your customer really needs while balancing the development risk. The last thing you want to do is to spend months building a product no one wants to buy!

As always, I look forward to hearing your comments directly. Please don’t hesitate to contact me to discuss your thoughts.