If Samsung is not willing to extend the life of its hardware for its customers, won’t those customers be less willing to buy Samsung again? Won’t those customers just be dissatisfied with Samsung? I’ve used customer satisfaction metrics in the past to qualify areas of improvement in live products, and with Samsung’s situation, I would do exactly the same thing. Based on this J.D. Power and Associates report issued only recently, performance and ease of operation were identified as two top customer satisfaction factors. And certainly, both can be addressed by both hardware and software changes.

Samsung probably weighed the ROI of developing new hardware as opposed to the ROI of developing a version of TouchWiz on top of Ice Cream Sandwich. Given that Samsung is supposed to have a competitive advantage in terms of hardware development, I can imagine that they concluded that making a new phone is simply more profitable than investing resources into extending the life of the Galaxy S. To me, that’s a shame since it leaves current customers in the cold.

Although the smartphone industry is still maturing, this move could be interpreted as the inflection point where commodification of Android hardware is simply standard operating procedure, in contrast to the typical Apple iOS hardware lifecycle. Considering that it’s easier and cheaper for consumers to realize value in new software on their existing phones as opposed to setting their apps, preferences, and data on a new phone, I wonder if this will be a hard lesson for Samsung to learn in short order.

When it comes to product development, a customer on your books is worth more than two who are just browsing around. And I’d bet that customer on your books will be more likely to buy from you again, as long as you don’t treat them like dirt.

As a product guy, minimum viable product is one important method with which to organize product development efforts, and to maximize the amount of benefit derived from scarce engineering, development, and management resources. In agile development circles, Product Owners work with the team to consciously choose to release “MVPs” frequently, or release a bunch of them together in an integrated package or manner. My take is that “minimum viable product” is the set of features that satisfy the core needs of your target champion audience and provides the team with the greatest return in both actionable feedback and revenue/revenue potential. More than one can go live at a time!

To work backwards a little, agile development and Scrum in particular derive big benefits from thinking in this manner. The reason being that minimum viable product first forces you to think about a set of features, functionality, and fixes that make sense together, and offer your users the greatest benefit. Then, once you arrange things into a bundle, you look for areas where it’s possible to make them bite-sized for the team to work with and to execute on. Let’s say that you end up with 3 minimal viable “products”; that may simply correlate to three distinct milestone dates throughout a calendar year. But not all of them have to go to market immediately, not all of them have to be released as soon as they’re individually done!

Oftentimes, the driving force for product people to tie one minimum viable product to a release is the urge to get something to market ASAP. I say that you ought to resist that urge with all your might! It’s not about the “smallest kernel of your core idea” but rather, how you help your team build a great product iteration that goes to market successfully. It is up to the product folks to exercise some discipline and patience about what exactly constitutes minimum viable product. Anticipating how your users will be delighted by a single button versus a single experience makes all the difference in the world.

In conclusion, for all you product folks out there: Minimum viable product is the set of features that satisfy the core needs of your target champion audience and provides the team with the greatest return in both actionable feedback and revenue/revenue potential. Bundle multiple MVPs if you think the whole is greater than the sum of its parts.

I especially liked two points of his that related to build/iterate/innovate, which were:

• creating space vs. churning features, and
• iterative process – customer feedback

The first, “creating space vs. churning features,” is so relevant to today’s software products that need to scale. Build a simple product first, then layer on convenience and complexity as needed. In contrast, so many organizations end up trying to build in everything, and end up with products like Microsoft Word where so much was invested in every detail, with only a fraction of its capabilities being used.

The second, “iterative process – customer feedback” is so important to maintaining great products. Ultimately, any product that gets launched will inevitably get feedback. Two lessons that I’ve learned the hard way: first, set yourself up to measure everything about your users. And second, always leave room to reinvent the product. It’ll never be perfect the first time around, and frankly, using a combination of KPIs/quantitative data as well as observations in the field will be a huge source of innovation. There’s no such thing as “build it right the first time;” it’s really more like “build it good enough the first time, and be prepared to change.”

Over the last few months, there’s been so much turmoil in the touchscreen tablet space! Consider:

1. HP’s newest foray into tablet computing, not with a Windows OS but instead with WebOS, subsequently gets beheaded in under 2 months after the TouchPad’s launch.
2. Android’s Honeycomb and Gingerbread tablets are growing in number, but not so much in market share.
3. RIM’s launch of the Playbook is widely acknowledged as a flop.
4. Apple’s iPad 2 launch in March is one of the most successful product launches in recent history.
5. And last but not least (by a slim margin), Microsoft continues to plug away with its Windows 7 stopgap strategy while working on Windows 8.

As a product person who’s been working on a HTML5-based offline web application, it’s been an exciting ride! So far, the recent events underscore several key ideas that product folks should take into account: platform flexibility, platform longevity, and control over the platform.Developing platform-specific applications will give you the broadest access to that platform’s advantages and features, but ties you into an ecosystem. Developing platform-neutral applications will give you the broadest access to a user base, but ties you into a variation of whack-a-mole. Given that a platform is composed of both hardware and software, product people have a set of issues to face which will shape your strategy. Hardware ends up being a snapshot in time, an end result of the evolutionary lessons and manufacturing capabilities up to a certain point. Unless a company directly controls their own hardware, it’s unable to fully understand and leverage all the nuances and potential of a device quickly. It takes time and exposure in a marketplace for both developers and consumers to achieve that knowledge. And in the case of hardware manufacturers themselves, failure is not so kind to a company and the ecosystem. In contrast, software is more malleable and can be adapted more easily. Your ability to deliver frequent iterations have less limitations to delivery.

The interesting development lately has to do with HTML5 apps versus native apps. While I’m a bit biased to one camp, I can say this: longevity aside, I’m interested in hitting the widest user base possible, and I’m willing to compromise slightly on performance and hardware features to gain an edge in control and reduce the friction it takes to get the user up and running. Not every company can say that, but every company needs to weigh those factors. And here’s the kicker: HTML5 is still an evolving spec. It is expected to get better over time, and build its API inventory up and continue cutting into the advantages that native apps have. As a wise man once said: “Choose wisely.”

Here’s why I’d predict this sort of product from Apple: the current field is ripe for two things, simplification and opportunity. PayPal touts that their NFC solution only needs a few taps of the phone; Apple will figure out a shorter series of steps. The world’s largest App Store still needs a credit card; Apple will make purchasing digital goods even more seamless and accessible than before. And with its current hardware profile that includes a camera, I’m sure an app will appear faster than George Costanza can say “Important things go in a case”, which would likely scan old-fashioned paper receipts on the spot for tagging and uploading into iCloud. Apple will ask you to say goodbye to back pain, cash, credit cards, and receipts. And consumers will love it.

In contrast, Visa and Square jointly took the high road and continued to build their positive brand image while pushing innovation in the payments space. While Square seems to have capitulated to Verifone’s claims, it is far more likely that implementing encryption was a part of Visa’s terms to publicly back Square. The monetary contribution certainly seems to be far less significant than the potential reduction of Square’s barrier to entry to the payments market. After these events, Verifone may have been better off just ignoring Square!

Conclusion: Innovate with newcomers in your space, and you’re bound to get some halo effect and drive benefits to both companies!

The idea is to eliminate the two line navigation layout which currently has tabs on top and the navigation buttons, menu and URL bar below. The compact navigation model would only have one line and place the navigation buttons, a search button, tabs and menus next to each other. The URL bar is gone and the URL of each tab is not visible at all times, but only displayed when a page is loading and when a tab is selected.

Go Google go!

This sort of innovation and change is on the level of Apple’s (in?)famous decision to start shipping computers without a floppy drive. With the advent of URL shortening services and the proliferation of odd company names, I believe top-level URLs are little more than keyboard shortcuts to our destinations, and longer URLs are only useful to machine interfaces. We users are actively being encouraged to think of browsers and Web services as the equivalent of applications on your desktop! And why not? Simple is great for users, and this is progress that’s simple! More room for content, for rich applications, for interaction: I love it!

In the spirit of the holiday season here in the US, this article from the Wall Street Journal seems particularly appropriate:

In many cases, rewards enticed people whose cards were dormant to start spending…[and] even small rewards can prompt people to spend more.

This useful study backs up the old management consulting adage of “you get what you measure.” In this case, financial services companies measure a customer’s spending and show a clear link to a nominal reward. And voilà, we shouldn’t be surprised that customers then immediately think about what they can get, as opposed to saving the money in the first place. Rewards programs are an ingenious way to acquire customers and encourage spending, but this can be to the detriment of the customers themselves.

My point is that customers need to really question their spending habits in the first place, as opposed to jumping at offers no matter how lucrative they may seem. There are plenty of savvy product managers out there, and their sole job in cases like these are to get you to spend money. Instead of watching your checking account go down for “rewards,” how about watching your savings account go up for a change?