Launch Tomorrow

Landing Pages for your Lean Startup

  • About
  • Members
  • Blog
  • Services

Archives for August 2013

Funding New Product Development

August 12, 2013 by LaunchTomorrow

Two Approaches to New Product Development Funding 

From a financial angle, there are two often encountered scenarios when funding the greenfield development of a new product:

  1. The founder /VC approach, where the founder serves as the first provider of funding
  2. The “new project within a large  company” approach

In a venture capital context, it is clear that a project is a calculated financial bet by the owners, whether the founders or the VC. An investor (such as the entrepreneur) puts some money into a company. The investor thinks the project will be wildly successful, even though at the moment, the company has no profits, revenue, or possibly even product.

From a pure net present value (NPV) point of view, it looks like the VC in particular has lost a few marbles. They’re handing over a large sum of money to a group of people who might earn an unknown sum of money a few years in the future, at an unknowable discount rate. They might change the world, or be bankrupt within a few months.

As a result, in pro-forma financial forecasts of expected returns, VCs use their estimated discount rate is as a “fudge factor”. This fudge factor gives them an additional margin of safety, if they believe the revenue forecasts are unrealistic. Specifically, if they don’t trust the entrepreneur selling them a part of his company, a new financial investor (VCs) increases the discount rate to reflect the higher level of perceived risk. This approach is, however, a bit heavy-handed. Moreover, it is imprecise, because it doesn’t really reflect risks in the venture. It also allows anyone to “game” a valuation, based on their intuitive gut feel about a company. Despite these issues with NPV in the context of startups, it has traditionally been the most widely used.

Your riskiest assumptions are probably related to your prospects and customers. Establish empathy quickly with your target prospect, figure out what's valuable, and get your innovation into the market.

Funding a new product within a larger company is also a bet, but with a different source of capital. Let’s say you are such a product owner or sponsor. You have a pool of money, either as part of an annual budget process, or obtained via an external loan.

Your goal is to earn an excess return over the cost of having that capital. Traditionally, the most cutting-edge tool for detailed analysis like this would have been Microsoft Project. Not only do you draw out your Gantt Charts about the various stages of the project, and base your estimates on what you expect will happen, you can even use Project to calculate project level rates of return using NPV, internal rate of return (IRR), and possibly scenario analysis.

Your cost of capital, typically the weighted average cost of capital (WACC) serves as the benchmark for deciding whether to invest in a project. The WACC is a simple accounting concept, where you take the average interest rate paid on all debt, and estimate the expected return on the equity based on observable comparable companies, and take a weighted average.

The WACC is analogous to the “fudge factor” assigned arbitrarily by an external financial investor in the VC case. Both of them serve a few purposes:

  • They are a “hurdle rate” above which the investment needs to perform
  • They summarize the opportunity cost of investing in that particular project/new product, as the investor or company sponsor could be invested in any other product/project/investment
  • They quantify the “cost of time” which everyone faces, when working on the project.

Unlike the fudge factor, a WACC is based on actual funding the company already has. It’s very real, not an estimate. Arguably, the VC “fudge factor” is just an estimate of an actual mature company WACC, particularly since most of the funding will come from equity investors expecting a high return, so the actual WACC in a VC venture is high. WACC is also based on financial characteristics specific to that company, such as creditworthiness, risk profile, etc. Most importantly, both are fed into an NPV model, which subsequently gives you an invest/no invest criterion.

What are the effects of using this denominator in NPV?

Both of these scenarios focus you on one objective: controlling or minimizing your immediate costs (negative cash flows) until your product launches in the (usually distant) future, according to John Judd, a serial CEO and CFO. This helps to offset the venture liabilities to investors and banks. It also causes more problems than it solves.

In most industries, product lifecycles have shortened dramatically. There is much less certainty than there was in the 1960s and 1970s, when NPV-based waterfall project management styles were the norm, and rightly so. Nowadays, your industry can change completely over the space of a few years. Just ask any music industry executive.

Moreover, this pace of change is accelerating still. Moore’s Law dictates that the number of transistors which can fit on chip doubles roughly every 18 months. This doubles the processing speed available. It does not even take into account improvements in the available software, which obviously affects you if you are competing in the software industry.

Make the Most of Now

Instead of controlling costs, it makes much more sense in a volatile environment to focus on revenue, and how quickly you can generate it. This is because the software industry is still rather young. After spending much of his career promoting project metrics within software engineering, Tom Demarco came to a rather odd conclusion about the role of cost control in IT projects. Demarco notes:

To understand control’s real role, you need to distinguish between two drastically different projects. Project A will cost around $1 mln, and earn $1.1 mln. Project B will cost around $1 mln, and earn around $60 mln. What’s immediately apparent is that while control matters a lot on Project A, but almost not at all for Project B. This leads us to the odd conclusion that control matters a lot on relatively useless projects, and much less on useful projects.

Great software projects generate massive payoffs. You are better off looking at how your project will generate incremental revenue, than pinching pennies, because the software industry is still very young.

Projects like Demarco’s Project A are sometimes necessary, particularly when looking within existing companies. They do work- if you are sure the project will be steady enough to generate stable cash flows. In this case, you are taking a “value investing” Warren Buffet approach, where you want to pay as little as possible for a very stable, slowly increasing, stream of cash flows. Buffet supposedly doesn’t even look at companies that don’t have a 10 year track record of stable and increasing cash flows, and where the current price of the business implies a certain “margin of safety” (hint: it’s really cheap).

SOMETIMES this is relevant for new products in software businesses, or mature businesses using a lot of software. Nonetheless, you are making a rather dangerous set of assumptions about your environment, your competition, and typically a product that doesn’t even exist yet, much less have a track record. Often these assumptions go many years into the future.

What works for investing in Coca-Cola or Heinz (both owned by Buffet’s Berkshire Hathaway), may not apply to an IT initiative. If you are so risk averse, that you only look at actual cash flows from the last ten years, you don’t take into account that most of the big players change every 10 years in IT. You also need to have a really clear business rationale for sticking to 10 year old technology, if you compete with other software companies.

<< Help Yo' Friends

Filed Under: funding Tagged With: agile funding

Managing Risk the Agile Way: Like a Hedge Fund

August 7, 2013 by LaunchTomorrow

Manage risk. Despite having backlogs, Agile doesn’t manage risks–explicitly. In 2007, Paul Kedrosky noticed a rather peculiar ratio. The ratio of software developers to non-developers at a major quant fund versus a major software company:

  • Oracle (56,000 empl.) — 1:8 (one developer for every eight employees)
  • Renaissance Technologies (178 empl.) — 2:3 (two developers for every 3 employees)

It’s not too much of a stretch to say that hedge funds are a new type of Software Company. After all, they have more developers per capita than the latter, and they generate more cash flow per capita, if they are any good. Hedge funds also provide a fantastic template for how software companies and projects could be run. Risk management separates the men from the boys. Well-run hedge funds make financial decisions quickly, consistently with the spirit of the agile manifesto. They cannot afford to let any bureaucracy get in the way of “high gamma” execution.

In fact, a hedge fund is just a company too, with the main difference being that they have a disproportionately large pool of capital to invest in the markets. As a thought experiment, I explore hedge fund approach to investing to new software projects, specifically to compare a waterfall approach to an agile approach. All software investment projects have embedded real options. Many analytical tools exist when investing with options, and many of them are surprisingly relevant in a new product development context.

Every greenfield software development project, from the moment it’s just an idea discussed by the team, is a bet on what clients or prospects want. Even if the project is being custom made-to-order for one client, it’s possible the client’s actual needs will be verbalized differently, once he sees a prototype. In addition to technology unknowns, development projects also face a number of other unknowns, especially in the context of marketing. Who exactly will need it? What problem will it solve for them? How many potential users exist? How do we effectively find and convince the potential users to buy this software once it exists? That’s why it’s reasonably easy to understand new product development as a bet the product team makes.

dice

dice

Your riskiest assumptions are probably related to your prospects and customers. Establish empathy quickly with your target prospect, figure out what's valuable, and get your innovation into the market.

Don’t make detailed assumptions about the distant future.

Like tax returns, project plans in software development are largely intricate works of fiction, i.e. based on a true story. Instead, you can make supremely detailed tactical short-term plans, where:

  1. your context doesn’t have time to change as much
  2. you can integrate your product development as quickly as possible with paying customers
  3. you can prove that a market exists for the new product, and that the concept is even viable

You are trying to discover an unmet need in the market which your prospects will be crazy about. Then, you actually have a chance that your bet will turn into a Demarco Project B. Then you will be thinking like hedge fund, really understanding and calculating the value of your immediate real options.

In this case, you are investing in a real call option. You have a small initial outflow at the beginning of the project, to generate a minimum viable product. Your losses are limited to that outlay. Your net present value (NPV) will be negative. Based on the standard criterion for accepting an investment project, you should reject such a project if the NPV is less than 0. Nevertheless, within a few iterations, you may generate a product that starts generating revenue. This revenue stream may exhibit exponential growth. In financial option terminology, the real call option has high gamma.

What does this mean for you operationally?

If you are using an Agile approach, you already keep track of your call options in a product backlog. A product backlog is an ordered list of potential features, or user stories, for a product. In the context of a new product, the product backlog’s most important function is to help you, as the product/business owner, prioritize this list, primarily based on the expected payoffs of adding a feature. Once you finish enough of a product that you can sell it, you start getting a lot of feedback about everything but the development process, so it would be ideal to have the flexibility to adapt to market conditions.

This list, while it may look rather dull, is potentially revenue-generating magic in the future. In fact, you can view it as a list of real call options, like the exchange traded derivatives variety. A backlog is effectively a portfolio of real options. An option portfolio is more dynamic. Its value depends on your business context. A number of interesting implications come out of this new model.

In fact, this is where Agile and Scrum metaphors around the backlog as a “feature idea inventory” break down for me. Typically, the product backlog is described as an inventory of potential features, where they are hoarded and stored. In my mind, a warehousing metaphor is somewhat lifeless and static. You don’t take into account the potential features’ value, when doing NPV financial analysis.

After getting an understanding of the market where a company operates, VCs just calculate a “fudge factor”, as a proxy for how much they believe the company will actually generate revenue. They use the denominator to override the value of the company’s real options on the product backlog. The value of these options will effectively decide whether the project will be a Demarco Project A or Project B, yet they aren’t taken into account explicitly at all.

In a high-tech environment like IT startups, return on investment (ROI) is more likely to be driven from adding new revenue streams than from controlling costs and budgeting. From an income statement point of view, the top line (revenues) is much more important than the bottom line (net profits), because we work in such a young and rapidly expanding industry. You can use NPV to trace cash flows down to combinations and series of tasks, and to estimate when you might be able to start selling in the future. Alternatively, you can also explicitly value your backlog items as real options. This way, you keep track of one list of fully developed features you need, so that you can prioritize much more dynamically-as you start selling and getting market feedback.

As a result of taking into account these dynamic scenarios, you have a much more accurate project valuation, at any point in time after the first calculation period used for the estimation! Moreover, NPV on its own systematically underestimates the value of most software and internet R&D projects, because it ignores embedded call options in the product backlog, which typically have high values in a volatile industry. If you calculated their value, and added it to the NPV cash flows you estimated, you can then use the NPV criterion of being net position with more precision. You will be taking into account the true value of what you get, when you invest in that project.

This is the key business difference between agile and waterfall. Waterfall handcuffs you into making estimates of a long term NPV, without explicitly allowing for optionality. Thinking about a product backlog as a portfolio of options is a much finer-grained approach to risk management, particularly when combined with software demos at the end of iterations. Then, you can legitimately claim you run your software project portfolio like a hedge fund manager.

Statistician E.P. Box quipped, “All models are wrong, some are useful”. I would add that some models are more useful than others.

<< Help Yo' Friends

Filed Under: manage risks Tagged With: real options

By Role

  • Startup Founder
  • Software Manager
  • Remote Leader
  • Innovation Executive
  • You Like?

    Search

    Key Topics

  • Faster time to market
  • Early-stage Growth and Marketing
  • Product-Message-Market Fit
  • Experiments and Minimum viable products
  • Metrics
  • About Luke

    Luke Szyrmer is an innovation and remote work expert. He’s the bestselling author of #1 bestseller Launch Tomorrow. He mentors early stage tech founders and innovators in established companies. Read More…

    Topics

    • agile
    • alignment
    • assumptions
    • case study
    • communication
    • conversion rate
    • delay
    • Estimation
    • experiments
    • extreme product launch
    • find people
    • funding
    • Growth
    • inner game
    • innovation
    • landing page
    • landing page MVP
    • manage risks
    • marketing
    • metrics
    • minimum viable product
    • modelling
    • modularity
    • personal
    • Pitch
    • podcasts
    • priorities
    • proof
    • release planning
    • Risk
    • software
    • startup
    • stories
    • time management
    • tools for founders
    • uncategorized
    • unknown unknowns
    • velocity
    • vizualization

    Tags

    agile funding automated testing bottleneck case study conway's law covid customer development digital taylorism existential risk extreme product launch faster time to market growth headlines identifying needs landing page mvp launch lean lean startup managing priorities market risk minimum viable product modularity numbers options output paypal planning principles prioritization problem to solve process risk product market fit real options split testing startup story systemic test driven development testing time management tool underlier value hypothesis value proposition work time

    Copyright © 2022 · Log in · Privacy policy · Cookie policy · Terms & conditions