Startup Execution

Getting to Minimum Viable Product

Every venture capitalist, board member and startup advisor counsels the entrepreneur to focus on building their minimum viable product (MVP). Successful startups do a great job of executing on their MVP buildout. Once their MVP is established, adding prioritized functionality transforms the product from acceptable, to good, to great.

Drilling Deeper

Everyone understands the concept behind MVP. But how exactly does a company build out its MVP? What does “viable” look like? Because every company has a different product, it’s impossible to provide specific advice for each situation. However, by drilling down to the next layer of detail, insights become more clear. When discussing MVP, I typically prefer to use the following five terms:

  1. Earliest showable product
  2. Earliest testable product
  3. Earliest usable product
  4. Earliest likable product
  5. Earliest lovable product

The diagram below shows the MVP progression from a user’s current state to an early lovable product.

 

An MVP Example

These abstract concepts frame up the process, but I find it helps to provide a specific example. In this case, let’s assume we’re trying to improve the infrastructure of a package delivery business. Today, the delivery couriers (generically, “users”) have very little infrastructure — packages are hand carried by the users to the destination. Building a delivery truck for the courier may look something like the process below.

 

Showable

Some may ask “what is the benefit of creating something that the user can see, but not use?” This is actually done all the time across many different industries. I’ve often been to trade shows where a vendor has a product in development that isn’t quite ready for anyone to use. In such cases, a very early prototype of the product might be in the vendor’s private “whisper suite” sitting under glass. A few invited visitors that have signed a non-disclosure agreement can look, but can’t touch. If the product is an application, maybe the visitor can watch a recorded demo video, but there’s no ability to deviate from the pre-recorded demo script. There are still many benefits to this as users will start to talk and ask questions. You learn from listening to the questions asked. You get a sense for what users consider important. Often, the user asks some questions that leads to a low-level requirement that wasn’t previously considered.

In this example, the delivery truck is nothing more than a barren truck frame with four wheels. Without an engine, someone has to push the truck frame like an overgrown hand cart. The user might ask how the cart is steered or whether it makes more sense to push or to pull the platform. Regardless of what the question is, you want the user to be engaged.

In the software world, the earliest showable product might be nothing more than a bunch of web pages stitched together to demonstrate the flow of a small application. Each web page has a few constructs on it (text, fields, photos, diagrams, buttons, etc.) but there’s no material code behind anything. Everything is hard-coded with static data. The only thing that works is the navigation between web pages and maybe one or two simple features. You just want to open the eyes of the users to what you have in mind.

Getting early user feedback and discussions certainly helps the development process. However, in my experience, the main benefit of building something showable is to force your engineering team to get started. Too often, the team can get mired asking questions about technical details: Should the front-end framework be built on Angular, React, or Vue? Should the back-end be built in Python/Django, Ruby on Rails, or JavaScript/Express? Should the database be MySQL or NoSQL? The key is to do some quick analysis by seasoned developers, secure buy-in, build out your development environment, and then get started. These tasks themselves can take time, which is why it’s important to push to make some decisions. The team can then focus on familiarizing themselves with the business problem and teasing out specific requirements.

 

Testable

For this evolution of the delivery truck, the earliest testable product adds a folding chair, a steering system and a braking system to the platform. You can invite a small number of users to test the product. Users can actually sit in the cockpit and manipulate some controls. The platform may still be missing some key features. In this example, because the truck lacks an engine, the only way for the user to test some package deliveries with the truck is if the platform is going downhill. Yes, that’s clearly very limiting, but you’ve properly set the users’ expectations by communicating in advance. The point is it’s possible for a few users to put their hands on the product and provide feedback. The initial feedback might be nothing more than: 1) it’s very difficult to turn the steering wheel (because it has a manual steering system) and 2) the folding chair lacks lumbar support and gets pretty uncomfortable when you sit in it all day. Users might not be thrilled, but they are seeing rapid progress and starting to ideate with you.

 

Usable

After receiving the initial user feedback, the engineering team adds a few quick enhancements to the product roadmap. The plan for the earliest usable product already included an engine and a fuel system, but the engineers also replace the folding chair with a traditional automotive bucket seat and install a power steering system. Since the truck platform now has a small engine, it can carry more packages and has a maximum speed of five miles per hour. A limited number of beta users can make deliveries with the truck. Since the platform doesn’t have a body or a roof, it can’t be used in inclement weather, but at least it’s no longer limited to downhill roads only. After using the truck, the users ask for: 1) higher speed (which was completely expected), 2) something to help them lift heavier packages from the ground to the cargo area, and 3) a way to organize the packages in the cargo area. None of the engineers previously realized how back-breaking it can be to lift packages all day. Nor did they understand how it slows down the courier if they have to move other packages out of the way in order to get access to a specific package in the middle of the truck. One user specifically requested the shelving system when they needed to deliver package #2, but had to move packages #1, #4, and #5 first. These last two feedback items would not have been uncovered if the product wasn’t actually being used.

 

Likable

At this point, the product is really starting to take shape. The engineers add a transmission and design a shelving system to organize the packages. The lift gate couldn’t be added yet because the weight that needed to be lifted required a larger battery system, so it’s been deferred to a later release. A larger pool of users signs up to use the product. Adding the transmission increases the truck’s maximum speed, but since the engine is still undersized, the truck tops out at 35 mph. The engineering team also builds a body around the driver cockpit and passenger area, but the packages in the cargo area are still exposed to the elements. With a larger pool of users, product suggestions start to really flow in. To deal with some of the user expectations, you begin sharing a high-level product roadmap.

 

Lovable

Finally, the engineers build the body around the cargo area, resulting in a fully enclosed vehicle. Engineers have been busy, as they’ve also added the lift gate, upgraded the engine (so the vehicle’s max speed is now 65 mph), and added basic wireless / GPS / navigation capabilities. The marketing team begins to salivate as they envision advanced real-time tracking and telemetry, giving package recipients unparalleled ability to track their deliveries. As a bonus, the marketing team also hired a graphic artist to advertise the delivery company’s logo and services on the side of the van.

 

Typical Pathways to MVP

The table below helps illustrate how the product development evolves from showable, testable, usable, likable to lovable.

Each of the five key designated releases (showable, testable, usable, likable, lovable) have specific goals, benefits and limitations. Each release also grows from a very narrow, restricted user base to a very broad community. The table above includes an estimated ideal timeframe to help product teams determine the general rate of progress.

Avoid the temptation to rigidly analyze the specific wording of any given cell in the table above. It is more important to remember that this represents an approach to rapidly evolve the product. Also remember that the earliest usable product will not likely be the most usable product, the earliest likable product will not be the most likable product, etc. This approach emphasizes targeting the earliest release that fits the designated goal.

 

Where’s the MVP?

So, what exactly is the MVP? For a very, very simple solution, it might be the earliest showable product. For typical companies, it’s often the earliest testable product. However, for a very demanding solution involving public safety, human lives, large financial risk, sensitive data, or something similar, it can be the earliest usable product. In many cases, the product team may designate the MVP as one of the Agile sprints one or two releases before or after the earliest testable product. Every startup has to adjust their definition of MVP to align with the nature of their product.

Regardless, the point isn’t to get fixated on a specific definition of MVP, but to focus on the overall process to get to MVP and beyond. The key lessons here are: 1) to iterate quickly, 2) to be very disciplined not to overload features into each release, 3) to engage users on every release after the earliest showable product, and 4) to steadily gather feedback. Entrepreneurs who diligently follow this recipe usually make consistent, predictable progress with their product development, which often leads to great success.

 


Startup Execution

Customer Success – The New Kingmaker

Throughout history, the rule of many monarchs was assured by the work of a key team member. Sir Francis Walsingham served as principal secretary and spymaster to Queen Elizabeth I, expanding her maritime strength, unifying Scotland and England, and disrupting plots against the throne. Cardinal Richelieu served as chief minister to King Louis XIII, consolidating royal power, neutering domestic threats, and brokering political alliances. Even Lando Calrissian, a futuristic ruler, depended on Lobot (the bald guy with the computerized “earmuffs”) to run the mining colony and ultimately, neutralize the Imperial stormtroopers.

Seeds of Success

In the Silicon Valley, teams of capable web or mobile app developers have at times been called today’s kingmakers. Developers are no doubt very important. I myself have been a developer and, as a VP Engineering or CTO, have led teams of developers. However, building your app, product or service is only part of the equation. You don’t have true sales momentum without both a strong sales machine and a strong adoption engine. Without sales momentum, your business plan remains unproven.

Foundations of Momentum

In his book Diffusion of Innovations, Everett Rogers writes about five different types of customers in the technology adoption curve: innovators, early adopters, early majority, late majority, and laggards, as depicted below.

In his book Crossing the Chasm, Geoffrey Moore extends this model in describing a gap or chasm that many companies face in transitioning from innovators and early adopters (“enthusiasts and visionaries”) to early majority customers (“pragmatists”).

When targeting customers, companies should focus on one customer segment at a time. Success with one group serves as the base to market to the next group. Marketing to innovators and early adopters usually relies heavily on selling the vision of the solution. Enthusiasts and visionaries buy when they see the solution’s potential value. However, marketing to pragmatists requires a strong focus on the solution’s realized value. Customer references are key to proving the value of your solution. And the strongest customer references come from those that have deployed and adopted the product. Because it is easy to buy a product, but much harder to adopt it, gaining strong customer references is difficult. This difficulty gives ultimately results in the chasm in the technology adoption life cycle. Given this challenge, it is vital that startups invest in the adoption of their solution among their early customers in order to build the momentum needed to cross the chasm.

Enter the Customer Success Leader

Companies that recognize the importance of customer references create a role solely responsible for customer success. And for many startups, a member of the executive team with a VP title, as a peer to the VP of Sales and the VP of Professional Services, leads the customer success efforts. Because the customer success leader must coordinate between the sales team and the professional services team, it is important for the leader to be at least on equal footing with these other key company roles. In some cases, the VP of Customer Success also leads the professional services team.

Adoption >> Landing

The Technology Services Industry Association (TSIA) defines four phases in the customer adoption process: Land, Adopt, Expand, Renew. Many companies understandably put a strong focus on closing the sale or landing the deal. But strong evidence exists to support the case that adoption is more important than landing the deal. Customers that successfully adopt the solution will usually purchase more licenses (expand) and will almost always renew. With expansion and renewal comes recurring revenue. When managing a growing business, I’d rather have $100 a month for 12 months than a one-time $1,500 purchase today. More importantly, when the time comes to place a valuation on your business, $1,200 of recurring revenue is worth several times more than $1,500 of one-time transactional revenue.

Landing Correctly

TSIA also defines three levels of customer adoption: low, high, and effective. Low adoption occurs when the customer bought the product, but doesn’t use it. Many factors result in low adoption, including the lack of a comprehensive adoption plan, absence of executive commitment, and a resistance to change current processes. Low adoption leads to shelfware. And by definition, shelfware is not expanded or renewed.

High adoption occurs when the customer shows great enthusiasm to implement the solution, often rushing right into an installation project. The software is installed, so the customer can claim it’s adopted. But there is a significant difference between basic installation and effective adoption. Basic installation without a comprehensive multi-phase rollout plan that is tailored to your customer’s use cases and needs gives the initial appearance of victory, but often results in slow and laborious progress after the initial sale. Expansion is rare and renewals are in question. Without investing in a readiness assessment or strategy workshop before launching into a deployment, the initial enthusiasm often leads to a solution that only realizes a portion of its potential. Effective adoption is the goal. You want the customer using the full potential of your solution. When they do, expansion opportunities are plentiful and renewals are practically guaranteed.

Effective adoption occurs when customers have a comprehensive understanding of the people, processes and technology changes required to realize the solution’s full value. With this understanding, customers can build an actionable and detailed solution roadmap with executive and organizational commitment. This roadmap defines the exact problems the customer has and shows how each subsequent phase of the deployment plan solves larger and larger portions of the customer’s needs. This readiness assessment and strategy workshop must be positioned during the initial sales cycle. Positioning it after the initial sale is problematic and painful, as you usually end up having to go through the sales cycle a second time.

Avoid the temptation to rush into a sale without the proper adoption plan. Without this adoption plan, customers will not land correctly. And if customers do not land correctly, the likelihood of adoption, expansion and renewal is slim.

Practicals

The customer success process starts during the sales cycle when a customer’s expectations are set. Customer success is more likely when the sales team sets proper expectations, engages the delivery team as part of the sales cycle, and remains involved through the multiple phases of a customer’s deployment and adoption. In some cases, the need for the sales and delivery teams to work together is so great that it may make sense to have the VP of Customer Success actually manage both the pre-sales engineers and the post-sales consultants.

In addition to creating an organizational structure that leads to successful outcomes, companies need to align compensation with adoption. Compensation plans should be structured to incentivize not just the initial sale, but the successful adoption of the product. Bonuses can be added if the customer agrees to be a public reference. The compensation plan should also make it worth the effort for the sales team to pursue renewals and not just the initial sale.

Customer Success Fuels Momentum

Successful customers serve as a proof point for potential investors, other customers and future employees. Booking one or two dozens deals alone does not define success. Customers shouldn’t just buy your product – they should use it. Your product needs to be adopted and woven into the fabric of the customers’ business processes. In order to drive adoption, you need a customer success team. Momentum grows as you build a strong foundation of successful customers. A strong customer success leader may well be the kingmaker of a startup’s executive team.