Launch Tomorrow

Landing Pages for your Lean Startup

  • Free Tools
  • About
  • Members
  • Corporate Innovation
  • Blog

Why building for the entire market bloats timeframes, and what to do instead

September 25, 2019 by LaunchTomorrow Leave a Comment

In High Output Management by Andy Grove, Intel’s founding CEO, Grove suggests that Intel operated in an environment where they needed to manufacture units to a market forecast. From the beginning in the 1960s, they didn’t have the luxury of selling up front and building exactly what was sold. Nowadays, this is pretty much the defacto environment for product development. Even in the case of software, where there is no manufacturing or reproduction cost, timing the scope to match demand is a core component of a software company’s success.

In order to plan the release of a product, you need a clear scope of what product development needs to happen first. This includes breaking down tasks, estimating them, and then mapping the specific features to expected customer value. This way you come up with a set of features that need to be created, in order to release the product (or release it again).

How this typically plays out in practice

In practice once this is agreed, new ideas come up. New stakeholders propose specific changes or additions to that original scope. You might even want to try reaching more prospects in a related segment.

1. Add a bit more scope: The natural impulse-in this environment- is for product development teams to simply add scope to the list of stories or tasks which were already agreed.

Vicious feedback loop for scope

2. Push the release back a bit: As soon as they add another feature, this effectively means more work needs to be done. So the effective date when everything will be done is pushed back. Usually this means the estimated completion date needs to be adjusted, even if this isn’t explicitly acknowledged by the team.

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.

3. Delay market feedback a bit: If the release date is moved back, the team delays getting market feedback. Depending on the size of the feature, it might be a few days in a software context. Or a few weeks.

4. Reduce probability sales: of If the feedback is delayed, you reduce the team’s confidence that the product will sell. The less feedback you have, the lower the probability of hitting your sales forecast when you ultimately do release. So your probability-weighted revenue goes down, the later you release. In a sales context, “money follows speed” is common knowledge. Being able to close a deal quickly is really important, because if you don’t, it’s likely the customer will change their mind. And finally, if you are less certain about your sales forecast, this typically influences your overall confidence level in the product. And one of the most natural things done in this case is too…add a bit more scope.

Deja vu. The cycle repeats.

Paradoxically, the more scope you add, the lower the chances of market success of the release. Because you’re innovating in a vacuum/ivory tower/echo chamber/<insert favorite metaphor here>. Even though you think you are improving your product’s chances. Having too many features is overwhelming for prospects and difficult to communicate for you. The paradox of choice kicks in.

Also, if you delay the release date, you are likely to struggle to make sales until that date. There are “forward contracts” or “letters of intent”, however customers will only go for something like this if they are highly motivated to get your solution. It also adds a layer of complexity and obviously a delay, thus making it harder to sell the product.

Implementation notes for startups

In the startup case, you need to get enough scope to attract early adopters in Moore’s technology adoption curve. This will typically be one or a handful of related features which address a core need of theirs and which they can’t address anywhere else.

Source: Harvard Innovation Lab

The idea is that you need enough scope to go after a narrow group of people, just to get started and out the door. Trying to build enough scope for the entire market will mean you’ll never actually move ahead with your business. Because you need to launch it first. The sooner you get it out there, the better for you.

Once you have nailed that first segment, you expand to adjacent segments. You modify the product to appeal to the adjacent segments. And then go sell to them. Do this incrementally, so that you have the benefit of revenues from the first customers. And confidence from initial market success.

Implementation notes for established companies

The above is true for larger companies; however, they have internal operational challenges to overcome also. In particular each of the 4 parts of the circle are often represented by different department heads. Each has his or her own agenda to push.

And while each incremental change might seem to make sense in the short term, the overall effect is the delay of a release. And no one is individually responsible for it.

Launch Tomorrow

Landing Pages for your Lean Startup

  • Free Tools
  • About
  • Members
  • Corporate Innovation
  • Blog

Why building for the entire market bloats timeframes, and what to do instead

September 25, 2019 by LaunchTomorrow Leave a Comment

In High Output Management by Andy Grove, Intel’s founding CEO, Grove suggests that Intel operated in an environment where they needed to manufacture units to a market forecast. From the beginning in the 1960s, they didn’t have the luxury of selling up front and building exactly what was sold. Nowadays, this is pretty much the defacto environment for product development. Even in the case of software, where there is no manufacturing or reproduction cost, timing the scope to match demand is a core component of a software company’s success.

In order to plan the release of a product, you need a clear scope of what product development needs to happen first. This includes breaking down tasks, estimating them, and then mapping the specific features to expected customer value. This way you come up with a set of features that need to be created, in order to release the product (or release it again).

How this typically plays out in practice

In practice once this is agreed, new ideas come up. New stakeholders propose specific changes or additions to that original scope. You might even want to try reaching more prospects in a related segment.

1. Add a bit more scope: The natural impulse-in this environment- is for product development teams to simply add scope to the list of stories or tasks which were already agreed.

Vicious feedback loop for scope

2. Push the release back a bit: As soon as they add another feature, this effectively means more work needs to be done. So the effective date when everything will be done is pushed back. Usually this means the estimated completion date needs to be adjusted, even if this isn’t explicitly acknowledged by the team.

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.

3. Delay market feedback a bit: If the release date is moved back, the team delays getting market feedback. Depending on the size of the feature, it might be a few days in a software context. Or a few weeks.

4. Reduce probability sales: of If the feedback is delayed, you reduce the team’s confidence that the product will sell. The less feedback you have, the lower the probability of hitting your sales forecast when you ultimately do release. So your probability-weighted revenue goes down, the later you release. In a sales context, “money follows speed” is common knowledge. Being able to close a deal quickly is really important, because if you don’t, it’s likely the customer will change their mind. And finally, if you are less certain about your sales forecast, this typically influences your overall confidence level in the product. And one of the most natural things done in this case is too…add a bit more scope.

Deja vu. The cycle repeats.

Paradoxically, the more scope you add, the lower the chances of market success of the release. Because you’re innovating in a vacuum/ivory tower/echo chamber/<insert favorite metaphor here>. Even though you think you are improving your product’s chances. Having too many features is overwhelming for prospects and difficult to communicate for you. The paradox of choice kicks in.

Also, if you delay the release date, you are likely to struggle to make sales until that date. There are “forward contracts” or “letters of intent”, however customers will only go for something like this if they are highly motivated to get your solution. It also adds a layer of complexity and obviously a delay, thus making it harder to sell the product.

Implementation notes for startups

In the startup case, you need to get enough scope to attract early adopters in Moore’s technology adoption curve. This will typically be one or a handful of related features which address a core need of theirs and which they can’t address anywhere else.

Source: Harvard Innovation Lab

The idea is that you need enough scope to go after a narrow group of people, just to get started and out the door. Trying to build enough scope for the entire market will mean you’ll never actually move ahead with your business. Because you need to launch it first. The sooner you get it out there, the better for you.

Once you have nailed that first segment, you expand to adjacent segments. You modify the product to appeal to the adjacent segments. And then go sell to them. Do this incrementally, so that you have the benefit of revenues from the first customers. And confidence from initial market success.

Implementation notes for established companies

The above is true for larger companies; however, they have internal operational challenges to overcome also. In particular each of the 4 parts of the circle are often represented by different department heads. Each has his or her own agenda to push.

And while each incremental change might seem to make sense in the short term, the overall effect is the delay of a release. And no one is individually responsible for it.

source: Randy Olson | the operational usefulness of pie charts

Moreover, in a large company environment, go-to-market decisions are often made based on overall market size. While this is useful to think through e.g. positioning of a new product, thinking in terms of top-down market pie charts doesn’t translate into a plan to enter the market. Different slices of the pie will want different features, with some overlap across the market.

It’s ok to plan to enter the entire market eventually, but it’s smarter to prove the approach works on a small corner of the market–before you expand outwards.

Acknowledge it’s uncomfortable, and just do it anyway

I get it. It feels unnatural to be selling something that isn’t perfect. It’s easy to succumb to a fear of rejection, and just put off the prospect of releasing the product for as long as you can. I’ve done it in the past on my own dime. I hear the mechanism at play when mentoring founders. I see the dynamics play out in larger companies every day. Every product team with an ounce of humanity is susceptible to this.

Focus on a small subset of customers with a similar set of needs, and only build the scope that they need. Keep it laser focussed. And get it out there, even if it’s not perfect. Especially in a business context, if your product addresses the core need they have, they will be happy.

Ultimately, fear of rejection just a bias that prevents you from learning what you need to know to make your new product a success. If necessary, speak to customers about their problems only–and don’t show them your solution right away. Most people are happy to gripe to a friendly ear, especially if it’s about something they care about. Don’t make promises you don’t expect to keep. But start speaking with flesh and blood customers right from the beginning.

<< Help Yo' Friends

Filed Under: velocity Tagged With: faster time to market

« How to resource projects and products–optimizing for elapsed time, motivated teams, and budget
How to simplify a complicated process, so that even a 2.5 year old would understand it »

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

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
    • 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 © 2021 · Log in · Privacy policy · Cookie policy