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.

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.”

• Keeps liquids pretty hot for a while, almost the same (unscientific) temperature range for 6 hours!
• Tea strainer is handy and removable as you need it.
• Slim profile makes it easy to carry in a bag.
• Single-button sip-from-anywhere top is convenient!

Cons:

• No handle to grasp.
• Carrying tote isn’t conducive towards convenient access to the mug, especially if strapped to a bag.
• Difficult to clean and requires a good scrubbing and soak to prevent stains.

Suggested improvements:

• Since the silicone gaskets need TLC and inspection every so often to ensure a good seal, perhaps offer a set of spares in the package and show some more details about care and longevity.
• Make a better (optional?) carrying tote that has a handle or integrates better with bags.

Buy it here!

One of the first harsh lessons I learned right away is that this type of remote is not forgiving to a novice.  If you don’t know what you’re doing, be prepared to have a lot of patience.  Despite the wizard’s attempt to outline the steps needed to get my equipment working and trying the remote out with a simple “All Off” activity, the wizard tool (Pronto Configurator) kept giving me a “There is an error with the configuration data. No valid configuration can be generated.”  Suffice to say, I wish that it would have specified what exactly the error was, and a great deal of restraint went into:

• reinstalling the software,
• installing ProntoEdit Professional to take a look at the code database (but not necessarily knowing what to look for),
• performing a lot of code “learning” for the code database, and
• being bewildered as at some point, the “My Database” set of codes wouldn’t populate with entries and I could not open alternate databases such as the One1R database.

After spending nearly 12 hours (spanning three days) tweaking and testing and revising, I was finally able to call my little project done!  Based on that experience, here are some lessons learned:

• Where possible, test out and stick with the Factory Database codes.  Only teach the codes that really don’t exist in the database and always duplicate the component before you start adding or changing things around.
• Expect a lot of trial-and-error when looking for a code set from the Factory Database.  Sometimes the codeset ID will map to a device’s model number, and other times, not at all.  I found that relying on the Component Type helped somewhat, but it would be useful for Philips to include information such as “Codeset xyz works with ACME G-500 and likely similar devices.”  That way, a user can at least test out codesets for devices that you might recognize as part of a product family.
• Think long and hard about your “Activities” (which are in essence your use cases).  I ended up making four Activities that involved multiple devices and mapped buttons that coordinated all of the devices in concert, but I also added four Activities to correspond to each piece of equipment.  Those activities’ sole purpose was to mimic all of the commands possible with just the device remote.  Where a hard button would not cover a command in an obvious way, I duplicated it on the list of additional “Screen Functions.”  This goes a long way in keeping me from reaching for the original remote.
• Make sure you download this little piece of software (here) provided by Philips.  It should save your sanity if you get the “There is an error with the configuration…” message.

Two hardware improvements that should be made:

1. The silver scroll wheel is a great idea, and its implementation is most of the way to where I think Philips should be.  Instead, I would suggest that the wheel either take the form of a thumbwheel next to the screen (scroll and click, like a Blackberry), or else to simply lower the profile and introduce raised bumps for the cursor arrows.  I found that pressing the cursor arrows usually shifted the scroll wheel to another Activity that should not be active.
2. Along the same lines for the scroll wheel, introducing a discrete instead of a continuous wheel (with slightly more resistance/friction) to give more feedback on the menu item selected and also let the user know of accidental movement of the scroll wheel.

Recommendation: Change the scroll wheel to be more flush with the remote’s surface and introduce a bit more tactile feedback.

It’s clear that a lot of thought and effort was put into aligning this product with the marketplace offerings and distinguishing it from the rest of the Pronto lineup of products to offer consumers a great choice.  With some touchups on the minor hardware and software issues, this would be a no-brainer choice for a universal remote without a touchscreen.

Scaling the controls to the content is extraordinarily important and the problem here is that for 10 functions, one product uses 5 buttons and the other uses 3. For example, if the door knob of a door is too small, many people can’t grasp it and apply the right amount of torque to open the door. In this case, Apple might have found the ideal physical control system while minimizing physical controls with the 2G. However, they might have mistaken necessity for an opportunity to be too clever since having fewer controls seems to have made some functions more difficult to access. In other words, the density of functionality with one control method should be kept to a minimum.

Recommendation: Merge the audio feedback system in the 3G with the physical controls of the 2G. It keeps the control systems consistent and simple to understand.