You have just invested in a new startup. Like most startups you invest in, they are going to disrupt the industry with their new product. Along with your investment comes a board seat. Initially, one of the important things this company must do is product development – of which you know almost nothing about. Further, the management team has little experience in startup product development.
If your background is general management or management in a large organization, then your traditional management methodologies, which got you to where you are now, are not likely to serve you well in this new role. Indeed, they may even serve to destroy value.
This paper outlines some of the common mistakes made by VCs as they try to guide young startup management teams through the perils of turning a disruptive idea into a product.
The Product Development Process
Like everything in business, product development should follow a process. The general process is:
Step 1: Develop Requirements
Step 2: Conceptual Design
Step 3: Detail Design
Step 4: Design Verification
Within this framework of a processes lies a continuum. Very large companies are going to do things very differently than smaller companies, and startups have their own take on each of these steps as we shall see later in this paper.
Some startups follow no processes. This is a mistake and leads to increased cost and delayed time to market – two things a startup can never have enough of. However, pressuring the team to apply the wrong processes, in the wrong way, can lead to exactly the same result.
One of the defining characteristics of a technology startup is that it is generally initiated by a highly innovative person – an iconoclast. Much research has been done on this personality type. These iconoclasts are a contrast in stunning abilities in certain areas and incompetence in others. These are the wrong people to be talking to about following processes – they will rarely give more than lip service to such traditional matters. If you’re working with a startup, there is likely one or more iconoclast within the organization. It is important you know who they are. Do not waste energy trying to change the iconoclast into a good product developer – it very rarely happens. Note – this does not mean they do not add value – they do, just not when it comes to developing and following business processes.
Engineering is a detailed and focused activity. People good at getting a good product to market are rarely iconoclastic. These individuals excel at accomplishing a given mission in a team environment. It is important you have someone in the organization with this skill set – or outsource these activities to a team with this ability.
A technology startup is very different than a traditional business. A traditional business has a proven business model. The primary focus of all activity in a traditional business is to improve and/or expand this business model.
A startup is very different. It does not have a proven businesses model – just a theoretical (unproven) business model. At the very least, this theory is incomplete – at worst it is wrong. This primary activity of a startup is to prove that the business model works or to pivot to one that does work. Until the businesses model works, there is no reason to scale the business. At this point, the only legitimate activities are activities that test the business model. In all likelihood, most tests will show the need to add/change/pivot from the existing business model. This constant change does not necessarily mean things are wrong – indeed, the presumption of the Lean moment is the idea of a startup that finds a repeatable business model, as contrasted with simply knowing this model ahead of time. In a startup, you should never confuse “change” as a problem to solve – indeed, change is the purpose of a startup – at least until the business model is repeatable and profitable – at which point, by definition, it is no longer a startup.
Startups are not smaller versions of large companies, so, therefore, need a different approach
You do not have to be a social scientist to understand that most people hate change. Most of us are hardwired to seek consistency – excepting our iconoclastic friends we find in early startups. If we accept the idea of Lean, then we accept that a startup will inevitably have a lot of change. If we accept that change will be inevitable, then we must ensure that the culture remains conducive to this change and we must resist our inclination to see change as a problem to eliminate.
In an established business, you add more and more expertise to improve the efficiency of the business to remain competitive.
In a startup, adding anyone to the team who could potentially be resistant to change should be avoided. Technical experts are particularly noteworthy because they have a large investment in the intellectual capital of their expertise, and thus often resist change away from this expertise. This effect is similar to brick and mortar stores being resistant to online strategy. This installed capital, be it real estate or knowledge, cause a bias away from any strategy that no longer requires this capital.
A typical technology startup, particularly at the Series A phase, has to balance between staying nimble enough to change rapidly towards a profitable/repeatable business model, and the discipline of a proven product development methodology. This balance is not easy, and new directors with large stakeholdings can, and often do, tip this scale too far in the discipline direction – all with very well-conceived intentions.
This balancing act between being nimble and being disciplined is not easy. There is no magic formula for getting it right as each situation is different. However, here are some ideas to help guide your decisions:
Committing Too Early: Typically a startup has “sold” the VC on the notion that all they need is money to scale the business. They have developed a prototype and may have even managed to sell a few, or get some customer commitments. Now that the money is available, we just need to grow, grow, grow…. well, be careful.
Filling the warehouse with a product that has not to be through a proper Design Verification Test, or even if it has, may lead to expensive and costly re-work, or worse, scraping the whole lot.
Launching the software with numerous bugs, and an overly complex UI will flood the nonexistent customer support center. The word quickly gets around, and pretty soon they only choice is expensive and costly re-branding effort.
Paying for all that expensive manufacturing tooling only to find out that it all has to be scrapped because we need to change one “little” thing.
Be careful about committing too soon. In a rush to grow fast, you might be causing unnecessary delays. In large established companies, uncertainty is low and rarely do things go too far astray. In startups, uncertainty is everywhere, and problems come out of nowhere. Recognize that no one has a crystal ball. As best described in the book, Good to Great, “shoot bullets before committing the cannons.” Do not be afraid to bring in second opinions for product testing and validation. Have your radar on for any red flag, and don’t ignore them. Over service early customer, even if at a loss, to get an early indication of product performance – or better yet, give some to an OPD and ask them to find the faults.
You are almost certain to find issues – this is not a cause for alarm, and it does not mean your team has failed in some way. When problems are found, do not focus on blame; instead, focus on finding the cause, and implementing and verifying the corrective action.
Always be Validating: You sometimes hear “always be closing” in a larger organization. Sales and more sales – that is how you win the day. As soon as you close one deal, quickly move to get that next customer. What could be more important than finding more customers – right?
In startups, you should replace this mantra with “always be validating.” In large organizations, the value to the customer of certain features, services, channels, etc. is so well known that it is rarely discussed – it’s been part of the industry vernacular for years. In a startup, there is little understanding of these same qualities. Until a startup has a proven, repeatable business model, its primary concern should be learning how the product will stack up against the needs of the customer and the competition – this is more important than getting more customers – unless you need that customer to help validate.
This difference changes the type of salespeople you hire in a startup. The salesperson that has spent years “making her numbers” may not be the ideal candidate for validating markets. This “hunter” personality is likely to believe that their job is done once the beast is dead. Any “objections” the prospect may have are to be overcome with some piece of clever manipulation. In the short term, this approach can even appear correct, as sales quickly raise before they inevitably plateau.
Customer Service people, Field Engineers, Product Managers may be better choices – even though they may have a “farmer” personality type. These people are attentive and good at two-way communication. They feel other people’s pain and have the necessary people skills to help the rest of the organization to understand the customer’s point of view. Although they are rarely the ones to solve the problem, they are often the ones to know a problem exists – and you cannot solve problems you do not know exist.
If you have led an established business in the past, you have learned to hire “hunters” for sales roles – and it likely worked out very well. In a startup, this move may be a mistake. They well certainly generate more sales in the short term, but they will also miss a lot of customer pain points. This lack of knowledge will reduce the probability of being best to market.
Everything is an MVP: Startups use MVPs (Minimally Viable Products) to learn how the product will be received by the market. The idea is to spend little money and time on development to speed up the product development turn over. Each new MVP adds to the knowledge necessary to find the proven, repeatable business model. The faster and cheaper you can progress through these cycles, the better.
However, an MVP is not “the straight line between point A and point B” – as will almost certainly be pointed out by those that operate with established company philosophies. They will advocate the “do it right the first time” mantra. They will point out that it will cost more and take more time. They would be correct except for the assumption that point “B” is knowable. In an established company, customer requirements and how to provide them are knowable. In a startup, less so. Going to point B as fast as possible is the right thing only if you are sure to point B is where you want to go. If you later find out that point C was the correct place to be, then you are now further away.
Water Walker Syndrome: Established companies do product engineering – that is, they improve their products over time by changing the design. These activities are inherently less risky than product development in a startup for a variety of reasons. These companies have clarity in requirements, markets, technology, and people. They have been “incrementalizing” the product for decades. Long ago, they stabilized into a repeatable, predictable process.
In a startup, the world ends about every three days. The startup is creating a new market – there are no people who have worked in this market for decades. No one has the luxury of “history as their teacher” because they have no history. The best they can do is stumble around in the dark. Inevitably they will bump into a lot of things and fall – that is, they will fail a lot.
Too often, boards compare the failure rate of a startup team with that of an established product engineering team – thinking that they both “develop products.” When the inevitable happens, they conclude it is the result of incompetence, and they start looking for a “water walker” to come in a save the day. This new water walker comes in and fails as well – promoting a new search for the next savior. If this pattern is allowed to continue, the result will be a continued “de-risking” of the business as the company “learns” that leadership will not accept failure. With this reduction in risk comes a loss of product differentiation, which leads to loss of outsize growth and profitability potential – that is, it is converted to normal business, not a startup that will disrupt the world.
There are no water walkers. No one has ever done this before – so they are likely going to make a lot of mistakes, and there are going to be a lot of disappointments. The emotional energy necessary to continue in the face of such constant defeat is more than most can handle. Adding additional stress from board members with unrealistic expectations is only going to make things worse, not better.
Accept setbacks. When they happen, focus the team on learning from them, and installing the corrective action.
Best to Market: One of the biggest myths in the startup world is “first to market” is necessary to be successful. There is little empirical evidence to support this rule – Steve Jobs was never first to market. Best to market wins, not first to market. The key is always “what is best.”
Startups often confuse “I made the sale” with market validation. They start focusing on scaling the opportunity and stop asking what “best” is. In all likelihood, the market is changing very rapidly (beginning of the “S” curve). While they are busy driving efficiencies into the product, the market pivots away from their flavor of the solution.
Startups are able to disrupt long established business with giant revenues exactly because they are small – they have almost no mass, so they only need tiny amounts of energy to pivot.
Knowing something will sell is not enough to justify scaling in a startup. You must also know that you are scaling a “best to market” solution. There were plenty of iPod-type devices on the market long before Apple. These devices “sold”, and likely were even profitable for some period of time. They all were displaced when the “best to market” solution was introduced.
About the author: Steve Owens, Founder, and CTO of Finish Line Product Development Services has over 30 years of successful product development experience in many different industries and is a sought-after adviser and speaker on the subject. Steve has founded four successful start-ups and holds over twenty-five patents. Steve has worked for companies such as Halliburton and Baker Hughes. He has experience in the Internet of Things, M2M, Oil and Gas, and Industrial Controls. Steve’s insight into the product development process has generated millions of dollars in revenue for start-ups and small businesses.