Click here to Skip to main content
14,486,466 members

Why Building for the Entire Market Bloats Timeframes, and What To Do Instead

Rate this:
0.00 (No votes)
Please Sign up or sign in to vote.
0.00 (No votes)
26 Feb 2020CPOL
How product development for the entire market can take a long time and what to do to resolve the problem
In order to plan the release of a product, you need a clear scope of what product development needs to happen first. In practice, once the set of features to be provided is agreed upon, new ideas come up. This article discusses how this typically plays out in practice and then gives implementation notes for both startup and established companies.

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.

Image 1

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.

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

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 to... 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.

Image 2

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.

Image 3

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 focused. 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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Lukasz Szyrmer
Program Manager
United Kingdom United Kingdom
Lukasz Szyrmer used to develop in C++ and C# and now manages development teams. He writes about agile, lasagna, and the cost of delay. If you are hungry for more, check out Debugging Velocity for a free chapter in his upcoming book.

Comments and Discussions

 
-- There are no messages in this forum --
Technical Blog
Posted 26 Feb 2020

Tagged as

Stats

7.5K views