MVP: The Most Vital Part

August 23, 2018 by · Comments Off on MVP: The Most Vital Part
Filed under: Business, Technology 

The difference between and idea and a product is execution.  As a Product Owner, your chances of being successful are very low if you don’t have a clear definition of your MVP (Minimum Viable Product). Without the MVP being defined, you will most likely take too long and spend too much money trying to deliver your product.  Why is it so vital?  Simply because Product Realization means execution, and execution is the proper management of trade-offs, time, and budget.  The MVP defines what features and functions are critical for the product to be launched to market. Having a clearly defined MVP crystalizes scope and focuses your team to deliver only prioritized essentials.

At LLAMAX, we have worked with several startups.  All startup Product Owners have a great idea and typically understand their users and market really well.  They are innovators and understand the application of their innovations very well.  They are also very clear on what they can do on their own and where they need help with.  Some have prototypes, some kind of working models or even beta units.  However, we have found that most do not have a clear definition of the minimum set of product features that early adopters need and therefore will want to buy and get lost in a never ending quest to get everything right.

The term MVP is typically used in the software or web development context, however, it is just as critical in hardware or services.   Techopedia defines it as “the most pared down version of a product that can still be released”.  We believe this definition is incomplete since each of the 3 words of the moniker has a specific meaning.  “Most pared down” makes sense, since it is the definition of Minimum, but it needs to provide some value at least to a subset of target users.  For a startup or new entrant in a category the value needs to be unique or differentiated.  Otherwise, users will stick to what’s already in the market.  Notice the use of the word value.  Value implies that the functionality is appreciated by the target users and at a cost they are willing to pay.  That’s what makes it Viable.

A product “that can be released as Techopedia’s definition says is not enough. In order to make it Viable it has to perform flawlessly on all of those pared down features.  Quality is never a tradeoff.  A marketing cliché says that good marketing of a bad product will put you out of business faster.  The credibility of your brand and product relies on quality and quality needs good engineering following good processes. If your differentiated functionality resonates well with users, it has to work well.  Skimping on engineering is a mistake. However, with limited resources – another commonality of startups – it is not possible to deliver all your features with quality on your first release. So a clearly defined MVP is also a resource optimization strategy.

The word Product needs clarification as well.  Product Owners commonly believe that the definition of their Product – the thing, software, or service they are trying to sell – is enough.  Of course it is vital and that is the “P” in MVP, but if you want to be successful, you will need your entire marketing mix – or 4 P’s – defined before you launch.  But that is a topic for another post.

So we will take the liberty to redefine MVP as:  The most pared down version of a product that still provides value and can be delivered with quality.

The obviously critical part of defining the MVP is what not to do.  A common error is to focus on the complexity of the feature, rather than its value.  It is tempting to leave behind a complicated performance attribute, but if it provides value and you can deliver it with quality and at the right cost, it is a unique competitive advantage.

As a Product Owner, you may want to hang on to your favorite feature, the one that gave birth to the idea, but if it is not what your target market considers of most value, you will be wasting valuable resources bringing it to market on the first release.  Leave it in the backlog for a future version.  Take a close look at all your features, performance attributes, and functions, even your packaging, manuals, and accessories if applicable.  A simple table like this one may help:

Feature Value Complexity Competitive Advantage (Value * Complexity)
Feature A 0 – 5 0 – 5 0 – 25


These are of course subjective numbers.  We recommend having many people fill out the table on their own.  Then have an open discussion until you reach consensus on the numbers for value and complexity.  Then decide, as a team, what Competitive Advantage number is the minimum in order to make it to the MVP.  Anything below that number goes to the backlog.  Then, check the budget and estimated delivery time.  If you can afford it, go for it.  If not, raise that Competitive Advantage number until you can.  If you are below budget, keep it there, do not be tempted to add the next feature on the list.  Stick to the minimum.

Taking time defining your MVP will always pay off in the long run.  Talk to your advisers, consultants, investors, target users, developers, etc.  Be critical, be candid, and be realistic. Once you define it, write it down and post it somewhere in sight.  Make sure all members of the team understand it clearly before starting development.  It will save you time, money, and a lot of headaches.   Be minimalistic.  Focus on value and quality and do not give either one of them up.



Smart Technology Series: Episode 2: IoT Protocol Inflation

August 6, 2018 by · Comments Off on Smart Technology Series: Episode 2: IoT Protocol Inflation
Filed under: Business, Finances 

As with every new technology trend, there are always standards that compete with each other trying to solve the new problems encountered by the technology needs.  Back in 2010 when the mobile world was nascent, we had Mobile OS Inflation.  Clever technologies, as we pointed out in Episode 1, are no exception.  In fact one could argue that IoT has broken the record of protocol standards.  As Nordic recently posted on their Get Connected Blog: “from ANT to Zigbee”.

The challenge with “things” is that they have very different needs that will drive different connectivity standards.  Wireless standards are typically designed to optimize battery life while maximizing performance for the specific application they are designed for.  They key performance attributes that IoT devices are typically concerned about are:  range, data rates, frequency of data transfers, latency, security, and reliability.  The “goldilocks” of these requirements are clearly different for different applications.

Let’s look at a few examples:

  • A self-driving car will need long range, high and frequent data rates with low latency but it benefits from large power source. The network needs to be secure and very reliable.
  • A remote thermometer will need long range but low rates and infrequent data transmissions. High latency is acceptable, but battery availability may be limited.
  • A beacon will need to be really small, thus driving a very limited battery capacity, but its data needs are also limited. Depending on the application, the range needs can also be short.
  • A switch needs very low latency, but very infrequent and low data rates, while power is not an issue since they benefit from being hardwired.

These examples make the point that one wireless standard will not be sufficient for optimal operation of all of them.  So the need for various protocols is real.

Ant+, Bluetooth, Zigbee, and Z-wave are very similar in nature but do differ in terms of performance attributes.  Ant+ (owned by Garmin) has been primarily focused on fitness devices like heart rate monitors, cycle computers, etc.  Bluetooth is perhaps the most ubiquitous.  It is present in every smartphone, tablet, and computer originally as a low range low data rate communications protocol. However, recently with the additions of BLE and Bluetooth 3, it is expanding into many more IoT use cases than it was before.  Zigbee is arguably the IIoT (industrial IoT) protocol of choice.  It has been available before IoT was even a thing (no pun intended).  It is a very mature protocol.  Extensions like Zigbee Pro and Zigbee Remote Control give it flexibility with reliability, security, and scalability for very complex systems.  Z-Wave, relatively new to the party, is a very low latency and low data rate protocol that supports meshing, making it ideal for home automation projects that include lights, valves, sensors, and the like, where nearly instantaneous action is expected.

WiFi, of course is everywhere and growing.  Newer variants can support rates up to 1 Gbps.  Chipsets are very power efficient, scalable, and extremely cost effective these days.  It is mostly a communications network protocol, but due to its omnipresence, there are a lot of IoT devices out there based solely on WiFi.

For long range needs there is also a growing collection of protocols for IoT applications like  Thread, Sigfox, Neul, or LoRaWAN.  There is a version of Cellular IoT that 5G technologies promise to make widely available.  It has high data rates and capacity with extremely low latency.

The big question is what technology to use for IoT projects. The truth is that it is not possible to settle on a single one even for a simple smart home project.  We have launched applications that combine several of these in order to have the best possible outcome.

It is unlikely that a single protocol will win the IoT battle.  We can expect extensions to some of the most common ones to make them more suitable for different use cases.  Some protocols may wind up relegated to niches and some may even vanish in the future.  However, we will have to live with protocol inflation given the diverse nature of IoT needs.  Successful installations will focus on the right choice of devices and protocols optimized for each part of the project rather than a choice of standards to make it easier for the installer.  Remember, it is about the best performance of the application, not about technology choices.