In the early days of your startup, you might have heard you should have a hacker, a hustler, and a hipster on the founding team. That makes a lot of sense in the initial stages of your company due to the experimental nature of the business. Remember what Steve Blank says: a startup is not a “real” business but rather “an experiment searching for a business model.”

Once you start to move out of the coffee shop and build your initial team, you’ll have to make some careful hiring decisions. I’ve seen founders hiring for new “formal” positions right out of the gate when all they need are operators to validate the business and find product market fit. Instead of finding your next VP of whatever or Chief whatever Officer, you should have no titles until you have paying customers and a product market fit.

I advise all the founding team to call themselves “product” on slide decks and email signature (if you do that sort of thing). Early stage team members should not be going to conferences and don’t need business cards, so the title doesn’t matter.

Here are a few other ways to manage the early stage hiring processes, and run your startup more effectively.

Maintain Equilibrium

Last year, I wrote a piece called “The Holy Trinity of Product Development.” I argued that it’s important to maintain balance in a company. Often, a startup’s first hires (besides the founders), tend to skew either to the technology side (we need 5 developers!), or the marketing side.

Generally, if the founding team is more marketing-minded, they overhire engineers, and vice-versa. Instead, a company should be customer-centric. To achieve this “holy grail,” the company needs both technology and marketing expertise.

Be Well-Rounded

In another article, “Why CTOs Should Know Accounting,” I suggested that CTOs also need to understand the business side of your company. It’s important for all of the high-level employees in a company to be able to converse with the rest of the employees.

Just like the CEO of a company should be able to at least pronounce the word “kanban,” (con-ban not can-ban) and know the difference between Java and JavaScript, a CTO should be relatively familiar with balance sheets, income and cash flow, annual statements, and budgets.

How to Hire

I’d argue that it’s better not to even bother with interviews. Rather, have coffee first. Discuss why they want to work at such an early stage company and review their skills there.

If that goes well, then have the potential employee give a presentation to the entire team. It can be on any topic (Was “The Force Awakens a remake or not?” is a perfect choice), and it gives the team a feel for the candidate’s analytical skills, seriousness about the position, and ability to do something different, while it also provides a unique experience for the candidate.

If the person is successful on their hiring presentation, I’d suggest the “can we have a beer with them” final check. This one’s really complicated – take them out for a beer with the team (or another social engagement if team members don’t drink). Get to know them on a personal level. When companies scale to be over 25 people, it is much harder to do this with the whole company, but each functional area (marketing/sales, tech, backoffice) can do it with their group and a select few members from other functional groups to join.

Avoid Founder Disputes

Early stage companies sometimes have no cash and bring on someone as a “co-founder” with little to no pay. It’s also crucial that you do your best to avoid founder disputes. I wrote a piece on this called “Dynamic Founder Agreements,” but I’ll give you a short summary. I described this agreement like a typical IF/THEN/ELSE.

IF:

The CTO works full-time and performs all of coding and technical duties of V1, his equity is 50% vested over 4 years, 1 year cliff.

ELSEIF:

The CTO works part time, is disengaged, or we need to hire developers sooner than expected, his vested equity is reduced by half and he forfeits his unvested equity. Loses board seat.

ENDIF:

The CTO has to leave the company because he needs a job or a family emergency: if the CTO built V1 then the buyout is a one time payout of $50,000 USD cash or 2% vested equity, if the CTO did not build V1, the buyout is 0.5% vested equity. Loses board seat.

While you might not avoid all disputes, this agreement will go a long way.

Hiring for Bigger Companies

Once your company grows and matures, deliberately hire slow. “Scale” and “move fast” does not mean “hire crazy fast.” Rather, hire for a role only when it is obvious the company is suffering without it.

There is a Silicon Valley secret that dictates that “you make a decision to join a company ONLY if they are resource-constrained. Once they have enough people, time to move on.” The idea behind this secret is that creativity needs constraints. Translation: if your plan calls for ten people, see what you can do with five.

Use these tips when building out your initial team. Don’t fall into the hiring trap.

No one talks about how important it is for your CTO to learn the business side of things. That needs to change. If you’re a co-founder or senior executive at a startup or growth stage company, you need to be more than just an expert in your area. I know that’s asking a lot. Becoming an expert is a massive task. But it’s not enough. Each senior leader needs to be familiar with engineering, marketing, sales, and accounting if you want to maximize your chance for success.

This concept has been popularized for non-technical founders for some time, through efforts like Mayor Bloomberg’s Learn to Code and Business Week’s magnum opus What is Code. But I’ll wager if you’re a CEO, you suck at social media. You probably don’t understand it, even though it’s the future of customer engagement. That needs to change. And this change needs to extend beyond giving non-technical founders technical skills. We need to help CTOs get business savvy.

Perform a Self Assessment

If you had to take over any of your company’s functional roles (marketing, sales, etc.) for a short period, would you be able to lead effectively? If the answer’s yes, great. Proceed. But if not, you’ve identified a major need.

Things happen, and you need to prepare for contingencies. Not only that, how can you screen and hire the right person if you can’t speak the same language?

Non-technical CEO’s should code so they can:

• Understand how the sausage gets made
• Talk to their team with the right vocabulary (i.e. Agile, Scrum, and Kanban)

If you’re the CTO, don’t you want to be relevant in business meetings? You won’t be as strong in marketing as your CMO, but you can add value and influence decisions.

If you outsource business decisions to your non-technical co-founder, there will be consequences. Best case scenario? You disengage from the business side.

Worst case: your disengagement leaves your CEO to feel lonely and stressed. And then one day, you wake up to a phone call from that person saying, “Hey, we’re out of money.”

Don’t let that happen to you.

Jump into the Business Side

I love founding teams comprised of engineers because:

• Less technical risk
• Solve their own problems
• Shared background with me

I’ve been a CTO many times in my career, and I’ve exited multiple companies. But heading back to grab my MBA still made me a better CTO.

I don’t think all developers should get an MBA even though, unlike many of my peers, I think there’s value in one. Instead, I’d suggest creating your self-study MBA.

Design Your Personal MBA

Here are my suggestions for a practical education that will make you a better leader in every functional area.

Accounting

All techies should read The Essentials of Finance and Accounting for Nonfinancial Managers by Edward Fields (who was my Accounting professor in business school).

It’s not exactly A Song of Ice and Fire, but you shouldn’t want to put this book down. You’ll get familiar with:

• Balance sheets
• Income statements
• Cash flow statements
• Budgets and forecasts
• Annual statements

I know. It’s dry. But the book is so necessary.

If you want to supplement it, take an online accounting and finance crash-course like this one at Udemy.

Marketing

Al Ries and Jack Trout wrote The 22 Immutable Laws of Marketing. The book was published over two decades ago, but it’s still essential. Learn from real world case-studies.

And remember this lesson: if people don’t read your website or emails, they’ll never buy your stuff.

To improve your copywriting, try the great Gary Halbert’s Boron Letters.

Sales

Sales makes the world go round. Here are two great books:

• He may have been a little corny, but Zig Ziglar’s Secrets of Closing the Sale is excellent. He knows objection handling better than most.
• Then there’s The Little Red Book of Sales. It’s short, sweet, and to the point. It’s a great reference book.

And finally, for our non-developer friends who’ve stuck through this:

Engineering

Read the Bloomberg article What Is Code that I mentioned before. It’s an interactive history lesson that walks through everything developer and even delves a little into philosophy.

At the very least, you should get familiar with HTML & CSS so you don’t need to bother your developers on trivial tasks. Brush up over at Codecademy.

You’re never going to be an expert in all of these roles. But at a minimum, you need to be conversational.

Have a bias for action and carve some time out for learning. Let me know how it goes.

* Image by Flickr user foam

Building a startup is intense and going through the many challenges creates scar tissue. This is not physical scar tissue, it is intangible.

Although it may seem like this would be difficult to identify, it is generally quite clear when someone has this kind of scar tissue. One reason that many investors prefer experienced startup founders is because they typically have scar tissue.

When we started PMA in 2002, the macro environment appeared to be terrible. Everyone was pessimistic and building a startup at the time was definitely a contrarian idea. Nevertheless, our first few months went relatively smoothly.

Then SARS hit Hong Kong. There were real heroes working in the hospitals, putting their lives in danger everyday, and many did not survive. In comparison, we were actually in minimal physical danger. Shops and restaurants became deserted, which was especially noticeable given that the population density of the city is among the highest in the world. In addition to the health issues and the economic impact, Hong Kong went through a massive crisis of confidence, and we were certainly affected. I would like to say that we all had enough foresight to be practically optimistic but that was not the case. We were simply hunkering down to make it through the challenge.

Eventually, we emerged from the crisis, and Hong Kong rebounded. There were many more challenges building PMA, but that experience helped us to become more resilient and eventually the company was acquired in 2006 for over US$200 million.

But the intangible scar tissue never went away. Even writing about it now, the impact is still there. More generally, everyone who was connected to SARS and Hong Kong during that time was affected in some way.

While building a startup is difficult, events like SARS remind us that there are bigger challenges to deal with in life. Many first time founders have already experienced challenges far greater than building a startup. They have intangible scar tissue.

“Prediction is very difficult, especially if it’s about the future.” – Niels Bohr

The Decision

Imagine that you are a key decision maker at the dominant communication network in the world, having successfully grown through astute acquisitions and network effects. The company’s market value has increased by more than 100x in a short period of time and you are now clearly the market leader.

Along comes a new startup with a proposal, actually a founder and his angel investors who are short of money and are looking for a face saving exit. They are asking for US$100,000 in exchange for their business. Of course, their business has no revenue and their new technology looks like a toy. Your internal team is far superior and has concluded that there is nothing interesting. The chances of this new toy market taking off are extremely small. Finally, even if you needed to compete with them, you could move quickly. Therefore, you dismiss them.

This is no imaginary case. The dominant communication network is the telegraph, owned and operated by the Telegraphy Company. The investors are Gardiner Hubbard and Thomas Sanders. The founder is Alexander Graham Bell and the toy is the telephone.

Of course, it turned out that the incumbent underestimated the founder and his investors, the toy market was not a toy after all and even when the Telegraph Company entered the telephone market it could not win, finally transforming entirely to become a money transfer business.

Problems and Solutions

Why is story from history particularly relevant today? All around the world, incumbents are vulnerable like the Telegraph Company. A downward spiral can begin anytime as the number of startups continues to grow. What are the key problems and, more importantly, solutions for improving corporate innovation?

Problem #1

The smartest people are always and without exception outside of your company.

Solution #1

Build a diverse network outside of your company. This means more than simply going to conferences and collecting business cards. It means building strategic relationships with key players who have diverse networks themselves. The focus should especially be on people connected with early stage startups because that is the most diverse ecosystem and large companies are poorly equipped to try and engage directly with early stage startups.

Problem #2

The structure of power laws results in impact being more important than probability.

Solution #2

Focus on imagination, not knowledge. Knowledge deals with what has happened in the past. It anchors our reality, which is generally helpful for day to day living, but is relatively poor at dealing with power laws and high impact but low probability events. Imagination empowers us to think about the future without the constraints of knowledge. The best way to start building something like imagination is through habits, starting small at first.

Problem #3

The world is path dependent and small inflection points have significant consequences.

Solution #3

Experiment early despite limited information. It is tempting to rely on being a fast follower but, as the Telegraph Company found out, even reversing a decision quickly may already be too late. Instead, it is more helpful to have a portfolio of experiments. That way, you can be involved in potential breakthroughs before it is too late. In addition, even the unsuccessful experiments will result in some learning, building the foundation for better decision making.

Beyond Predictions

Rather than being discrete problems and solutions, all of these issues are related and can be integrated. The common theme is that large companies should to find ways to engage with the diverse startup ecosystems globally.

Of course, the actual mechanics of engagement are not trivial. Holding contests and events is helpful for marketing but does not really address the issue of deeper engagement. On the other extreme, starting a corporate venture capital fund is not simple. For most companies, the most practical route is to partner with early stage venture funds who can act as a bridge with startups.

Regardless of the implementation, all companies need to find a way to make better decisions about the future and their corporate innovation strategy in order to avoid being replaced by toys which transform into platforms.

Not only is it hard to attract talent to your startup (know any free developers in the Bay Area?), as a founder you also have to set the proper structure. A common saying is that you need a “Hacker, Hustler, and a Hipster” on the founding team. In the earliest days that makes sense, especially when you are MVPing and hustling for your first customers trying to find a product-market fit.

Sometime after you have product-market fit and raise a round of funding, you need to hire outside of the core founding team. A lot of founders struggle with the right roles to hire and what the proper structure should be. Some founders hire too many engineers (typically non-technical founders) and some founders hire too many “business” or “marketing” people (typically technical founders), leading to being lopsided in one area. Founders run the risk of being engineering centric or marketing centric in their product development. In reality they need to be customer centric and embrace the Holy Trinity of Product Development.

The Holy Trinity of Product Development: Dev Lead, PM, PMM

When it comes to product development, you need three distinct roles. Those roles are what I call the Holy Trinity of Product Development: Developer Lead, Program Manager (PM), and Product Marketing Manager (PMM). These three roles work together to represent the customer and build the business, ensuring that you are not too engineering focused or too marketing focused. The role in the middle of that fine line is the Program Manager.

Program Manager (PM)

The program manager, sometimes called product manager, is the most important role in the trinity. The PM manages the product definition by talking with customers and potential customers. A PM owns the UX and functional specs and is the chief customer advocate. A PM not only owns the product definition, but also its strategy, position in the marketplace, and if it is a new product, its go to market strategy. Internally, the PM has to coordinate the teams to get the product out the door. This means working closely with the PMM and business teams on what makes sense for the business. The PM can’t set pricing (that is the PMM’s job) but surely can influence it. At the same time the PM has to work with the engineering team to get the product built on time and on budget. While a PM is not required to have any technical or coding skills, the more technical a PM is, the better. At Facebook for example, all PMs usually can write a little Javascript code. This allows the PM to talk to the engineering team in their own language.

What is amazing about the PM is that they have no power or authority over the PMM or dev lead, all they can do is influence the engeneering and marketing teams. It takes a unique skill set to get this done.

Developer Lead

The dev lead has a difficult role to play insofar as they have to represent the engineering team to the PM and PMM as well as work on all of the “tech stuff.” The tech stuff includes: setting the development architecture, get their DevOps game on by organizing the build (doing things like Continuous Integration and Continuous Deployment), coding, and choosing the right technology for the job (Rails or PhP anyone?) The dev lead also needs to keep the engineering team together and motivated and make sure that the agile process is, well, agile.

The hardest part of the dev lead’s job is interfacing with the PM and PMM. The nature of startups is that they are resource constrained and always in a rush to get something shipped. That means an insane amount of pressure on the engineering team. It is the dev lead’s responsibility to work with the business (PM and PMM) in order to set realistic deadlines and proper expectations, all while not being the guy complaining about lack of resources. Not always an easy task..

Product Marketing Manager

While the dev lead represents the engineers and the PM represents the customer, the PMM represents the business. While the PMM is responsible for what all non-marketing people think of as marketing (ad campaigns, trade show booths, email blasts, product placement, media placement, etc), they are also responsible for the business model of the product and making sure that the product makes money (or reaches its broader goals if it is a loss leader.) This means setting pricing, and if this is a freemium product, that is far more complex than you can ever imagine. The PMM is ultimately accountable for the product making money.

The Right Balance

Some startups and companies are tempted to combine the PM and PMM role. This is bad! What happens when you combine these roles is that the focus usually becomes either too customer centric or too marketing centric; you need two people and two distinct roles to prevent this from happening. The right structure creates the right environment. The right people in the wrong structure is a waste of talent, they will not be able to use all of their talents, they will spend too much time fighting the incorrect structure. No amount of free massages, free lunches, and unlimited cookies will fix an improper structure. (Actually it is Google, Facebook, Linkedin, etc who have pioneered the Holy Trinity in Silicon Valley. They adapted it from the larger tech companies such as Microsoft in the 1990s.)

The right people in the right structure/environment is where the magic happens.

This may sound like a lot of overhead, however, you are probably doing this in some form already. Typically at the early stage, founders take on these roles and hire people to pass them off to. It’s a sign that your startup has matured and left the experimental phase.

Now go and build awesome products!

In my role at Fresco Capital and as an advisor to several startups, I’ve seen it all with founders: disputes over shares, disputes over money, disputes over a new laptop, founders break up, a founder falling ill, founders get married, founders get divorced, founders get into physical arguments. Often this leads to one founder completely disengaged from the business and still holding a significant amount of equity or even a board seat. We’ve seen this at large companies such as Microsoft and more recently at ZipCar. Typically you need this equity to hire executives or attract investors. Worse, if the company is being acquired, you now have one founder who can hold up the deal if they are on the board and disengaged. That of course is a problem, but one that can be solved with a dynamic founder agreement.

Founder Troubles

Most founders settle the division of equity question with a static founders agreement. It usually goes something like this:

Founder 1: 50%, vested over 4 years, 1 year cliff

Founder 2: 50%, vested over 4 years, 1 year cliff

This solves a lot of problems, such as if a founder leaves after two years, they will still have 25% of the company but give up the second half of their equity. What happens if one founder is not “pulling their own weight” or contributing enough to earn the vesting (in the other founder’s eyes) but did not leave the company? What happens if they have to leave due to illness or personal emergency? What happens if there is misaligned expectations as what skills a founder brings and what role a founder will play?

I’ve seen this happen at one of my own startups. One of our founders was a lawyer and at the time we sold the company, he could not represent us due to it being a clear conflict of interest. While the legal fees were not all that bad (maybe $50k), to this day, almost ten years later, my other co-founders are still mad at the lawyer co-founder. This was clearly misaligned expectations.

This is what Norm Wasserman calls the Founder’s Dilemma, or the unexpected consequences of not spelling out the roles and expectations of the founders early on combined with the unintended complications of a founder leaving early or disengaging. He suggests a dynamic founders agreement.

The Dynamic Founders Agreement

The dynamic founders agreement is a way to mitigate the risk of an underperforming founder by changing the equity based on pre-set parameters. For example say I am starting a company with my friend Sam. Sam and I agree to a 50-50 split with Sam being the “business guy” and me being the “tech guy”. The assumption is that I will be the coder of V1 and lead the development team after we get funding. But what if I need to leave the company due to family emergency? What about if I decide that I don’t want to code anymore, before we can afford to hire a developer? What if I only give 30 hours a week and consult on the side?

A dynamic founders agreement is a big IF THEN ELSE statement that spells all of this out. IF Steve works as expected, his equity is 50%, if Steve has to leave the company, if he becomes disengaged, here is the pre-negotiated equity and if we have to buy Steve out, here are the terms. For example:

IF:

Steve works full time as CTO performing all the coding and technical duties of V1, his equity is 50%, vested over 4 years, 1 year cliff.

ELSEIF:

Steve works part time, is disengaged, or we need to hire developers sooner than expected, his vested equity is reduced by half and he forfeits his unvested equity. Loses board seat.

ENDIF:

If Steve has to leave the company because he needs a job or a family emergency: if Steve built V1 then the buyout is a one time payout of $50,000 USD cash or 2% vested equity, if Steve did not build V1, the buyout is 0.5% vested equity. Loses board seat.

Having a dynamic founders agreement won’t solve all of your problems, however, it will make the the process of removing a founder much less stressful. Sure some of the language in the dynamic founders agreement will be subject to interpretation, but the “spirit of the agreement” is much easier to follow or even if you have to litigate, more robust. If you never need to use the dynamic founders agreement, but built one anyway, it will force a frank and open conversation about roles and commitment among the founders. This only strengthens the relationship between founders, increasing the chances of success.

All startup teams need help. The good news is that there is no shortage of “startup mentors” out there. The bad news is that there is no shortage of “startup mentors” out there. How you recruit and work with your advisors is critical as the right advisors managed properly can really have a powerful impact on your business.

Many startups that I work with like to build as impressive a list of advisors as they can. When talking with founders about advisors, I usually focus on two things:

• Making sure the advisors augment the skills lacking in the current team
• Formalize the relationship with the advisor and compensate them according to an objective standard

The Team’s Needs

Look at the needs of your business over the next six months to a year and then look at the skills of your team. You will have a lot of gaps. Start to think how an advisor can fill some of those gaps. Some teams will need help figuring out BizDev or do pricing of their products. Some will need help with higher level technology decisions-or someone to interview a CTO candidate/co-founder. Some teams have all the necessary parts but lack a little “gray hair” or folks with the battle scars of doing business a long time. Some teams lack the network to raise money and some teams lack domain experience. (Which I question why are you in that business in the first place.)

You need to find advisors who can augment your team with skills, experience, and connections. If you are all PhDs in astrophysics and are building a related startup, you don’t need the head of your University’s Physics department or even a Nobel winning Physics on your advisory team. You will need some people with business and fundraising experience. Also, don’t try to go get famous people to be an advisor; I know that Mark Zuckerberg is not meeting with you monthly and won’t add much value except for the coolness factor.

The good news is that there are a ton of people out there willing to give you advice. The challenge is keeping the advisors engaged.

The Dreaded Conversation: How to Formalize and Compensate an Advisor

Your advisors mean well and want to help, but they are busy people. You need to set the expectations up front as to what kind of advice you need and how often you will be asking for it. If you don’t have this conversation with your advisor, you run the risk of some very misaligned expectations, leading to a bad experience for both sides. Typically for companies that I advise, we usually have a call once month or every six weeks. But when something comes up that I am uniquely qualified for, the frequency is higher.

You also need to formalize your relationship with you advisors! This is important for several reasons, but the first is legal liability. If overnight your company is worth billions and your advisors have been informally advising you without a contract, they may think that they are due a large stake in your company and sue. Another reason to formalize your advisor’s relationships is that by formalizing it, they will take the relationship more seriously. So many companies ask me to advise them, but the ones I say yes to and have a formal agreement with, I feel more obligated to make the time for. An easy way to lock down an advisor is to use one of the standard Advisor Contracts. I have used this one several times.

Lastly, you need to compensate the advisors in order to keep them engaged. If your advisors want a huge chunk of your company or a salary or stipend, they are not the advisors for you. Use the following matrix to determine how much to compensate the advisor with. First determine what stage your company is at: idea, startup, or growth. Idea is usually pre-seed, startup is usually Seed stage, and Growth is typically a Series A or later. (I explain the stages of funding here.) This is important due to the amount of risk your advisor is taking. Then determine what kind of advisor you are signing up: Standard, Strategic, or Expert. I know that these are kind of vague, but they usually line up pretty easily. Make a proposal and then use the equity number in the box. This should be a standard and non-negotiable. If the advisor tries to negotiate away from these numbers, don’t have them as an advisor. They should not be in it for the money/equity, the compensation is more of a “nice to have.” They should be advising you because they want to.

Lastly, have a vesting schedule and a way to easily remove the advisor. Typically you have an advisor for a year or two, depending on the need of your team. For example, if you lack a technical team at the idea stage and engage with an advisor who is very technical and expected to help you recruit and hire an CTO within a year, you probably only need to sign that advisor up for a year or two. Then make room for other advisors in other domain areas.

Advisory Board vs Board of Directors

What is the relationship between a Board of Directors (BOD) and your advisors? Nothing. More importantly, your board members are responsible for the governance of the company and legally liable for its execution, while your advisors are responsible for nothing and legally liable for nothing. Your directors have high engagement, often meeting in person several times a year. Your advisors are less engaged and often engaged via email and Skype.

Communication

You should update your advisors (and investors) with a bi-weekly or monthly email: explain the good, the bad, the ugly since the last email communication. At the end of the email put in the ask, or what you want your advirosrs to pay attention to or what you need from them. While your advisors may only skim over the updates as they come in, at your next call, the advisors can review those emails before the call and make the call more efficient. You won’t have to spend the first 10 minutes of the call updating the advisor on what happened over the past month. I love getting these emails, it shows me that the companies that I advise are organized and understand proper time management.

My Experiences Advising

I’ve advised many companies over the years. I’ve been asked by many more than I’ve said yes to, I only say yes to companies that I can add value, are in an exciting space, and the founders are awesome people to work with. (Now that I am an investor, I say no to almost 100% of the asks to prevent a signaling issue. I did, however, recently agree to become an advisor to a company where my skills made me uniquely qualified to help.)

What was my experience like? Some companies rarely contacted me. Some contacted me randomly, usually when they needed some specific advice. Other’s scheduled a regular phone call. I’ve done it all: lots of general strategy, accelerator application advice, fundraising tips, team compensation, interviewing CTO candidates, make introductions, M&A advice, and sitting in-between founder breakups. I’ve even pretend to be Paul Graham and asked them YC interview questions.

Some of my companies have had exits, sometimes the money from my shares was great; one exit was small and paid for an awesome dinner and night out with the team. One company I advise recently shut down and I helped the founder find a new gig. All my experiences were worth the time I put in and lots of fun.

Lastly, I learned a lot advising, as much as I taught the founders!

A lot of people misuse the term “MVP” or Minimum Viable Product. To be clear an MVP is not a beta, not a prototype, but rather an experiment designed to test your value proposition’s assumptions by measuring a behavior and learning from the results.

Back in the day, Dropbox did an MVP as just a video and Buffer was just a landing page. Both were experiments to determine if Dropbox or Buffer should even exist. Instead of guessing and building prototypes, they built the simplest of things in order to measure a user’s behavior. Today startups are building functional prototypes and calling them MVPs. They are better off building something they can learn from. Typically the first MVP doesn’t even have to be anything on a device or computer. For example, I once advised a new travel startup that wanted to give you one click access to a daily itinerary based on a map. They assumed that people wanted a map with pin points on it and times to follow. I told them to go to tourist spots and give people real maps with real pin points circled and an analog itinerary to follow. That was an MVP, it was an experiment (map) that measured (how many as a percent of total) a user behavior (did they use the map or not). Let’s take a look at how to build a better MVP.

Getting Started: Customer Segment and Value Proposition

The whole idea of an MVP is to measure an actual result against your expected result to prove or disprove your assumption. In order to do that you need data. The first place to start is to think about is your customer segment; you have to know who your target customers are going to be. Without knowing your exact segment (22–34 year old professional, urban women, single, living alone, earning over $75k), you won’t be able get the correct pool of users to test on.

After you define your customer segment, you define your value proposition. Too many people think that their value proposition is just the solution to the problem they are solving. That is incorrect: your value proposition is the delta between the current solution or workaround to the problem people are currently using and your solution. You measure your value proposition in terms of how much better your solution is compared to the solutions that exist today.

Let’s say you are solving a problem for buying movie tickets. Several solutions already exist; there are lots of web sites, apps, etc. Maybe your solution involves buying the tickets via SMS. Regardless, you have to think about what the alternatives to your solution are and compare them against that. One is simply buying the ticket at the box office. Here your alternative has value, but not tremendous value. Alternatively, let’s say you are developing a life saving cancer drug. The alternative without your solution could be death. In this case your solution would be incredibly valuable.

The Assumptions That Fuel Your Value Proposition

Underpinning your value proposition are your core assumptions. These are the things that would compel someone to buy your product or service. The job of the MVP is to test those underlying assumptions. The only way to successfully test those assumptions is by making a prediction of the result and comparing the behaviors that you measured up against your predictions. Your predictions should be based in fact, facts that would determine if you have a viable business or not. If you don’t make a prediction, then you will not have a way to determine success or failure of the MVP test.

Let’s say you are building a landing page, Buffer style. Your MVP will be to measure how many people give you their email address after your landing page described your product. You will have to drive traffic to your landing page, most likely by taking out some Facebook or Google AdWords ads. You want to measure the conversion rate of people who clicked on the ad (since you pay for click) to providing their email addresses. For example, if 100 people clicked on the ad and came to your page, but only 4 provided their email address, your conversion rate is 4%. (Not bad actually in e-commerce.)

Should 4% be your target? No. You need to determine your prediction based on facts and your business model. Let’s say you estimate spending $100 on Google AdWords to drive traffic to your MVP. If you have a conversion rate of 4%, it will then cost you $25 to acquire each customer. $25 is your CAC or customer acquisition cost. You need to estimate what your Customer Lifetime Value (CLV), or the amount of profit you expect to get out of each customer over the course of their relationship with you, is. At this stage it will be fairly inaccurate, but you need to ground your assumption in reality. (Future MVPs can test pricing.) Let’s say you make the CLV to be $21, based on a lot of factors in your business model. (I talk more about your CLV and CVC here.)

With a a CLV of $21 and a CAC of $25, you will lose $4 on each new customer you acquire. Or CLV ($21) — CAC ($25) = -$4.

For your MVP test, you will need a higher conversion rate/lower CAC rate in order to make a profit. For the first MVP test make a prediction that the conversion rate will be 5%, bringing your CAC down to $20. Or CLV ($21) — CAC ($20) = $1.

Interpreting The Results

Now with your assumptions based in some business reality, it is time to run the test. Typically the results are one of the three following numbers (remember you are aiming for 5% conversion):

• 0.021%
• 4.28%
• 17%

Let’s take 0.021%. This is an absolute failure, you can safely assume that your assumption is invalidated. Safest thing to do is declare the assumption invalid and go back to your value proposition and rethink it. If you have other assumptions associated with your value proposition, you can do some more MVP tests to determine if the entire value proposition is invalid or not. Chances are you will have to iterate your idea and value proposition some more.

What to do if you are at 4.28%? Technically it is invalid since you need 5% conversion rate in order to make any money. Should you just give up and go home? No. You should try some new UX and new design or different language and run the test again. Don’t run the test without changing anything! If your future tests with minor changes are at or over 5%, then you can declare your assumptions valid and move on to test the next one.

Let’s look at 17%. Woo-hoo, your assumptions are more than valid, you blew away your predictions. Verify that your test was fair and then declare your assumption valid and move on to test the next assumption.

Thats all there is to it! Only by clearly defining what success is and basing those numbers in a business reality is an MVP useful. Anything else is just a beta.

Build an MVP, Not a Beta was originally published in Fusion by Fresco Capital on Medium, where people are continuing the conversation by highlighting and responding to this story.

A lot of people misuse the term “MVP” or Minimum Viable Product. To be clear an MVP is not a beta, not a prototype, but rather an experiment designed to test your value proposition’s assumptions by measuring a behavior and learning from the results.

Back in the day, Dropbox did an MVP as just a video and Buffer was just a landing page. Both were experiments to determine if Dropbox or Buffer should even exist. Instead of guessing and building prototypes, they built the simplest of things in order to measure a user’s behavior. Today startups are building functional prototypes and calling them MVPs. They are better off building something they can learn from. Typically the first MVP doesn’t even have to be anything on a device or computer. For example, I once advised a new travel startup that wanted to give you one click access to a daily itinerary based on a map. They assumed that people wanted a map with pin points on it and times to follow. I told them to go to tourist spots and give people real maps with real pin points circled and an analog itinerary to follow. That was an MVP, it was an experiment (map) that measured (how many as a percent of total) a user behavior (did they use the map or not). Let’s take a look at how to build a better MVP.

Getting Started: Customer Segment and Value Proposition

The whole idea of an MVP is to measure an actual result against your expected result to prove or disprove your assumption. In order to do that you need data. The first place to start is to think about is your customer segment; you have to know who your target customers are going to be. Without knowing your exact segment (22-34 year old professional, urban women, single, living alone, earning over $75k), you won’t be able get the correct pool of users to test on.

After you define your customer segment, you define your value proposition. Too many people think that their value proposition is just the solution to the problem they are solving. That is incorrect: your value proposition is the delta between the current solution or workaround to the problem people are currently using and your solution. You measure your value proposition in terms of how much better your solution is compared to the solutions that exist today.

Let’s say you are solving a problem for buying movie tickets. Several solutions already exist; there are lots of web sites, apps, etc. Maybe your solution involves buying the tickets via SMS. Regardless, you have to think about what the alternatives to your solution are and compare them against that. One is simply buying the ticket at the box office. Here your alternative has value, but not tremendous value. Alternatively, let’s say you are developing a life saving cancer drug. The alternative without your solution could be death. In this case your solution would be incredibly valuable.

The Assumptions That Fuel Your Value Proposition

Underpinning your value proposition are your core assumptions. These are the things that would compel someone to buy your product or service. The job of the MVP is to test those underlying assumptions. The only way to successfully test those assumptions is by making a prediction of the result and comparing the behaviors that you measured up against your predictions. Your predictions should be based in fact, facts that would determine if you have a viable business or not. If you don’t make a prediction, then you will not have a way to determine success or failure of the MVP test.

Let’s say you are building a landing page, Buffer style. Your MVP will be to measure how many people give you their email address after your landing page described your product. You will have to drive traffic to your landing page, most likely by taking out some Facebook or Google AdWords ads. You want to measure the conversion rate of people who clicked on the ad (since you pay for click) to providing their email addresses. For example, if 100 people clicked on the ad and came to your page, but only 4 provided their email address, your conversion rate is 4%. (Not bad actually in e-commerce.)

Should 4% be your target? No. You need to determine your prediction based on facts and your business model. Let’s say you estimate spending $100 on Google AdWords to drive traffic to your MVP. If you have a conversion rate of 4%, it will then cost you $25 to acquire each customer. $25 is your CAC or customer acquisition cost. You need to estimate what your Customer Lifetime Value (CLV), or the amount of profit you expect to get out of each customer over the course of their relationship with you, is. At this stage it will be fairly inaccurate, but you need to ground your assumption in reality. (Future MVPs can test pricing.) Let’s say you make the CLV to be $21, based on a lot of factors in your business model. (I talk more about your CLV and CVC here.)

With a a CLV of $21 and a CAC of $25, you will lose $4 on each new customer you acquire. Or CLV ($21) – CAC ($25) = -$4.

For your MVP test, you will need a higher conversion rate/lower CAC rate in order to make a profit. For the first MVP test make a prediction that the conversion rate will be 5%, bringing your CAC down to $20. Or CLV ($21) – CAC ($20) = $1.

Interpreting The Results

Now with your assumptions based in some business reality, it is time to run the test. Typically the results are one of the three following numbers (remember you are aiming for 5% conversion):

• 0.021%
• 4.28%
• 17%

Let’s take 0.021%. This is an absolute failure, you can safely assume that your assumption is invalidated. Safest thing to do is declare the assumption invalid and go back to your value proposition and rethink it. If you have other assumptions associated with your value proposition, you can do some more MVP tests to determine if the entire value proposition is invalid or not. Chances are you will have to iterate your idea and value proposition some more.

What to do if you are at 4.28%? Technically it is invalid since you need 5% conversion rate in order to make any money. Should you just give up and go home? No. You should try some new UX and new design or different language and run the test again. Don’t run the test without changing anything! If your future tests with minor changes are at or over 5%, then you can declare your assumptions valid and move on to test the next one.

Let’s look at 17%. Woo-hoo, your assumptions are more than valid, you blew away your predictions. Verify that your test was fair and then declare your assumption valid and move on to test the next assumption.

Thats all there is to it! Only by clearly defining what success is and basing those numbers in a business reality is an MVP useful. Anything else is just a beta.