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

Uncommonly Good Product Management

Finding good product management help is hard. Many people have managed products, but few have actually done it well. Poor execution on a great product idea can severely hinder company growth, so it’s very important to build a strong product management team. To help you with this crucial component of your business, I’ll focus on the various roles played, the perspectives needed, the messaging required, and the desired skills of a great product management team.

Building out the Team

Every basketball fan understands that you don’t just throw five guys together on a court and tell them to play if you want to rise above the pickup games at the neighborhood playground. Each player has a position. Each position emphasizes different skills. Understanding the responsibilities of a frontcourt vs. a backcourt player helps you build your team appropriately.

Similarly, as you build out your product management team, it’s important to understand the responsibilities of each individual position. I tend to use a classic 2×2 matrix as a model to communicate many business concepts. To describe the responsibilities of each player’s role on the product management team, I assign the vertical axis to the individual’s focus, from tactical to strategic. I assign the horizontal axis to the individual’s audience, from internal to external. This results in four specific roles: Mini-CEO, Product Manager, Product Lead and Product Line Manager. Each role has a specific set of responsibilities, as presented in the following matrix:

The table below provides a side-by-side, comparative view of the responsibilities of each role.

The following diagram depicts the typical growth of a startup’s product management team, starting from a small, one-man shop to a large, multi-player team:

 

Both Buyer and Seller Perspectives

The best product managers are able to represent both the buyer and the seller perspectives. Amazingly, the vast majority of product management teams only focus on the perspective of the seller or vendor, which includes: product planning and positioning, product development, and product launch. Equally important is the perspective of the product’s buyer or user: product purchase, product usage, and product maintenance. Though some success can be achieved doing a great job on the plan, build and launch steps, maximum success is only found by also optimizing the buy, use and maintain steps. The diagram below depicts how each perspective makes up a complete product lifecycle.

To illustrate this point, consider the perspectives needed by the product manager for a car:

  1. Plan: Analyze the automotive market and position the product.
  2. Build: Design and manufacture the car.
  3. Launch: Execute the go to market tasks required to effectively introduce the product.
  4. Buy: Understand and support the user’s purchase and deployment process.
  5. Use: Drive the car on a regular basis.
  6. Maintain: Service and repair the car as required.

Few would argue that the best product managers for a car must have purchased a car, know how to drive, and occasionally work under the hood of the car. It amazes me that many companies fail to staff the product management team with players that have deep experience from the user’s perspective. Without such experience, the car buying experience will likely be painful, the controls and user interface counter-intuitive, and routine maintenance such as an oil change will be overly complex.

Too often, companies only consider candidates for product management jobs if they have a certain number of years serving as a product manager. Though this is certainly helpful, one of the most effective product managers I’ve ever worked with never previously played any product management roles. In the mid-1990s, Oracle hired a construction senior project manager away from a design/build engineering customer to serve as the product manager for Oracle Projects. Because he combined very strong leadership, an analytical mindset and great communication abilities with years of experience using large, complex construction project management software, he built one of the best products I’ve ever seen in the enterprise project management market. He was such an effective product manager that I still remember his work over 20 years later, even though I don’t remember his name!

FABulous Messaging

Another aspect that amazes me is how few product managers leverage a structured, logical approach to communicate their product’s features in a logical, hierarchical manner. Most product features are presented in a disorganized heap. The most important features are then highlighted as the product’s core value. This approach usually results in unclear messaging that marginally resonates. Any resulting products sales from this messaging are driven by the magnitude of the need rather than the clarity of the value proposition.

Seasoned product managers should break down their product’s value into three categories: features, advantages and benefits (or “FAB” for short). Features are easy to identify – they are the distinctive attributes of your product. Advantages are the factual results of using the feature. Benefits capture the value of the advantage. I’ve often seen product management presentations that fail to differentiate between features, advantages, and benefits, resulting in a tangled, murky and chaotic value proposition. An effective FAB statement describes the following:

  • Feature: what the product has
  • Advantage: why it’s helpful
  • Benefit: the end result delivered to the user

To illustrate, consider the following examples:

No one buys features. Customers buy benefits. Don’t assume your customer can derive the benefits from a list of your product’s features. Failure to clearly articulate features, advantages and benefits inhibits the sale of your products.

The Fundamental Skills

A lot has been written about skills required for a product manager, so I’ll keep this discussion at a high level. The fundamental skills required for a product manager include the following:

The detailed skills vary depending on the exact product management role played, from Mini-CEO to Product Lead.

Product Management Execution

Every startup begins with a unique idea for a product or a solution. Building your idea into a successful venture requires great product management. If you understand the multi-faceted roles of end-to-end product management, cover the perspectives of both the vendor and the user, clearly articulate the benefits and the value of your product, and hire the right skills, then you’ll have the key ingredients needed for a fertile product management team.