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, Startup Talent

Diamonds in the Rough

As I’ve written previously, every startup needs game changing players. You can hire them if you have a good interviewing process, know what to look for, and can offer a strong compensation package (cash + equity). Sadly, even if you have all of these, the ridiculously competitive job market (especially in areas such as the Bay Area, New York, and several other tech hot spots) may frustrate your ability to bring on ready-built veterans. In such cases, your only alternative is to hire candidates with raw talent and potential and then grow them in house.

Every owner of a fantasy football team would love to draft the top quarterback, top two running backs, and top three wide receivers in the league. But the realities of most leagues typically limit any one team to maybe two veterans with a proven history of production over several seasons of gameplay. The rest of the team must be built around role players and younger, unproven athletes.

The Veterans

In order to develop unproven players, founders must build an atmosphere and system that cultivates growth. Veterans who are chartered and able to develop the younger staff serve as the anchor of high-growth teams. These veteran leaders need to buy into the fact that a key part of their success depends on their ability to raise up their teammates. Team leads need to balance the efficiency of doing tasks on their own versus delegating, coaching, training and empowering others to take ownership for key parts of the project or team.

The Rookies

Once you have the veterans in place, you need to find the right rookies to add to the team. Take a moment to review my previous post on building a strong interviewing process. As I’ve previously written, success is usually the combination of preparation and opportunity. Younger-in-career candidates haven’t have many opportunities, so your goal in the interview process is to identify candidates that have great potential because they’ve done the necessary preparation. You should focus on:

  1. Strong technical ability. Front-line staff typically need to demonstrate very strong technical capability in the role they are hired to play. Make sure your interview process goes the extra mile to identify raw technical talent with real-world “show me” demonstrations and tests rather than “tell me” stories.
  2. Executive abilities. Don’t ignore analytical abilities, methodical / structured problem solving, organization skills, communication skills, and attention to detail. These are common requirements on a resume, but rarely assessed in an interview.
  3. Emotional intelligence. Daniel Goleman published a landmark work where he asserted that a person’s Emotional Intelligence can matter more their Intelligence Quotient. Because of the demands of a high-growth team environment, candidates need to have some basic emotional intelligence in order to thrive. Goleman identifies five key components of emotional intelligence: self-awareness, self-regulation, internal motivation, empathy, and social skills. Make sure your interview team evaluates these aspects of every candidate.
  4. Humility. Finally, each member of a fast-paced, growing team needs to be willing to learn from others and not be afraid of owning up to any mistakes. Humility is essential, as individuals with a modest view of their own importance tend to be better learners and less defensive when mistakes are made.

The Farm System

Once you have the veterans and the rookies lined up, you need to create a system that provides a safe environment to grow. Give people challenges that stretch their abilities. Capable, well-prepared team members really need just one successful project to go from a novice to a strong apprentice. Two successful projects will often be enough to forge a journeyman from a strong apprentice.

When you task a team with multiple stretch goals, regular check-ins become very important. Create daily and weekly processes that have your veterans providing regular inspection, direction and coaching of younger team members. Agile development processes are very well-suited to rapidly develop younger team members.

Keep in mind that, as you challenge teams with stretch goals, failure is not just possible, but likely. Mistakes will be made. Bugs will always plague software development. But failure shouldn’t be fatal. When honest mistakes happen, make sure the team knows where they went wrong and are diligent about recovering from the error. Hopefully, your regular check-ins will uncover the mistake before the freight train flies off the rails or the project goes completely sideways. Plan for problems because, with fast moving young teams, mistakes will happen.

On the flip side, when a young team or team member executes the stretch assignment well, be quick to recognize and reward the achievement. Correct mistakes privately, but praise successes publicly. If the young team member strings together a couple of wins in a row over two to three months, find a way to recognize that with a small bonus. If the team member continues the winning streak over two to three quarters, step up the recognition with either a larger bonus or a small bump in compensation (cash or equity). If the team member demonstrates consistent growth for about a year, recognize it with either a job title progression (e.g., Associate 3 to Associate 4), or a promotion (e.g., Associate 4 to Senior Associate 1).

Creating Brilliance

Building a strong team from a pool of raw talent is very difficult. Few people do it well — even fewer can do it at startup speed. But most startups need to learn how to do this as it’s not likely they will be able to always fill their roles with seasoned veterans. You basically need to find diamonds in the rough, then cut and polish the raw stones to brilliance. With a few strong veterans, a pool of promising rookies, and the right farm system, success with younger teams becomes not just possible, but likely.