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

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.

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.

How to resource projects and products--optimizing for elapsed time, motivated teams, and budget

In my last post, I explored the implication of a shift in importance and value of resources. Given increasingly shorter time frames for product life cycles, I think time is an increasingly undervalued resource. Zooming in to a sub-micro level, I think we're also looking at a paradigm shift with resource allocation within high technology companies too.

Regardless of technology background, all stakeholders usually negotiate around schedule. Time is the least common denominator, from an accountability perspective.

In a traditional project approach, the team would figure out and agree the scope up front. These requirements would be fixed, once they are translated into cost and time estimates. Dates would also be agreed up front. In this case, there is a lot of analysis and scrambling up front, to try to learn and decide everything before knowing it all. In practice, this front-loaded exploration takes time. Regardless of whether the product delivery team is actually working on the product, this elapsed time on the "fuzzy" front end is added to the final delivery date. It takes a lot of time to define and estimate all of the work needed to deliver the scope. And in practice, this backlog will only help us figure out when the project or product is "done", which in and of itself, has no meaning to clients or salespeople. It is easy to overlook this full-time cost of trying to fix and define all work up front, particularly since the people doing this work can usually get away with not "counting" this time as part of delivery.

standard approach: agile in a waterfall wrapper

And since scope is fixed, and something actually needs to be a pressure release valve, typically one of the bottom three triangles on the left suffer: time, quality, and cost. Then. spending months tracking project progress and with limited client interaction (because it's not "done" yet) is yet another waste of elapsed time.

There is a way to significantly reduce this waste, by bringing in the client early and maximizing learning in a highly disciplined structure. In an Agile approach, the exact opposite approach is taken. We don't try to fix scope up front; we fix the rules of engagement up front to allow both business and technical team members to prioritize scope as they go.

Instead, we strictly define business and technical criteria for a project up front, without fully agreeing what the scope is. So, we agree that we will spend up to $185k, quality is ensured with automated testing, and we have 3 months-to deliver something sellable. We may only deliver 1 feature, but if it's a valuable feature then clients would pay for it. If all of these are unambiguous, then the product team itself can prioritize scope operationally based on what it learns from clients. For all types of products, ultimately the clients and the market will decide to buy whatever is being built.

start work sooner, ship more, and incorporate client feedback sooner

What's fundamentally different here? Scope is defined by a series of operational or tactical decisions by the product team, not strategic ones defined externally to them. Senior business stakeholders shouldn't need to follow and know the technical details of what's in a product and what part of the project is "done". It's getting down into too much detail and communicating a lack of trust in judgement to a highly paid team of technical experts they meticulously recruit and train. It also undermines a sense of outcome ownership by the team. Because everything about their work is defined exogenously and just dropped on them.

What is the total cost of having a waterfall wrapper around agile teams?

Clearly efforts need to be coordinated across an organisation. Trying to use detailed waterfall-style up front planning will cost you elapsed time and may cost you the market opportunity you've identified. It's better to have shared access to backlogs and agile's drive to deliver potentially shippable software on a short cadence. Because you know you can use anything that is done by another team. And you can estimate or prioritize based on an open discussion among teams.

How to optimize for your tech company's scarcest resource

Back in the 13th century, Princess Kinga of Hungary received an engagement ring from Duke Boleslaw of Poland. When discussing her dowry with her father, instead of just offering the usual "gold and money" which was relatively common in those situations, Kinga asked her father to gift a salt mine. Salt was a scarce resource and the only way to conserve food at the time, so it inherently had a lot value.

When gifted the largest mine in the Austro-Hungarian empire ( Maramureș ), she was worried that the whole mine couldn't be moved to Poland and therefore she'd still be under the thumb of her parents. So after significant thought and even prayer, she dropped the engagement ring down the mine's shaft.

Kinga and her ring | Source: Wikipedia

Later, when princess Kinga was in transit to Cracow for her first meeting, she took a handful of Hungarian miners with her. She ordered her party to stop around the Wieliczka area. And asked them to start digging. They hit a rock and said they can't go any further. Kinga asked that the rock be crushed open. It turned out that it was essentially rock salt, and her engagement ring was found inside.

While the truth behind this origin story has been lost in the mists of time, a mineral repository was discovered. What did happen as a result? Huge economic growth in the region. The cities in the country went from being built in wood with wooden forts to brick and mortar and castles. Largely financed by salt mine profits.

Over the longer term, the price of salt fell. With it, the economics importance of the salt mine to the country's treasury. And other resources became important to economic growth. A paradigm shift occurred. And the medieval salt warlords drifted into irrelevance and obscurity.

How is that relevant today?

The closest analogue today is probably the petrochemical industry that fuels the Middle East's economic engine. As long as the price of oil stays high, that whole region has a disproportionate amount of wealth generated. These profits are reinvested in other parts of the economy local and global economy. And the prospect of peak oil would seem to give the sheikhs high hopes for even higher prices of oil and oil-based products over the longer term.

Source: thenational.ae

Yet already there are longer term trends at play which are likely to disrupt this. Looking at companies like Tesla, Elon is betting that the solar energy will replace oil as a source of energy. And the bottleneck will move from generation to storage and possibly transport. At that point, the price of lithium and other minerals needed to build batteries is likely to enter into a longer term bull market.

So, just because oil is valuable now, doesn't mean it will always be valuable. If Elon's strategic hypothesis proves to be right, the oil magnate sheikhs will be out of luck too. Nobody really knows how this will play out. But I'd be willing to bet the oil, gas, and automotive industries will look different in 50 years than they did 50 years ago.

It's easy to overlook one particular resource

Strategic resources or "factors of production" to consider according to classical economics:

• Land
• Labor
• Capital
• Enterprise/Entrepreneurship
• Technology
• Natural resources

Usually the current strategic approach is to think about finding the optimal balance in the resources above for your particular industry. The goal is to maximize wealth in the long run.

Resource levelling | Source: Wikipedia

In the case of software, tech decision-makers usually spend their time focus on labor-sometimes called human capital-as many skills tend be hard to find where it actually matters. Once you recruit and train the right people, then it's a question of making sure they have everything they need to do their jobs. Especially being clear on what needs to be built or modified. But also the other factors in frameworks like Gallup's 12 Questions.

In the executive offices or founder's garages, the discussion extends to capital and entrepreneurship. Knowing where and how to raise budget (capital) and how to allocate it to the biggest opportunities (entrepreneurship) is an ongoing effort.

Over time, a successful company will tend to accumulate technology assets which are unique and which have value. Which make them uniquely capable of executing a business model that beats comparable companies in the same industry.All of these play out over time.

Time is considered an obvious given. Really?

So in addition to the actual resources you need, you need to figure out optimal timing of when to inject in the resources to improve your company's business outcomes. In other words, most companies focus on finding the optimal balance of resources right now-relative to one another. Which is completely reasonable given the current paradigm.

What I'm exploring at the moment...what if time itself is a resource and input? In other words, instead of only thinking about how output changes right now if you add or remove people, what about allowing yourself to think about varying time.

• How would you change your approach if you had year runway to release something?
• How would you change allocations if you had one week before a client wanted to use your product?
• How much are you actually affected by time consuming efforts like training up a new recruit?
• How much time does the team spend on "hardening" and bugfixing before a release in a big batch?
• When will your clients or your actually need to have the product and how does that look in relation to competitor's actions?

These somewhat philosophical questions, if thought through, could have quite significant practical implications on most projects. Because time is money, too. If you have a detailed plan to build a product and prospects who need what you're building, you are effectively paying an economic cost of delay, as per Don Reinertsen's work, for each day the product isn't ready to ship. And if you want to allocate resources rationally, you should be taking into account this cost.

Tech product life cycles are shortening. Company lifetimes are shortening. Industry lifetimes are shortening. At which point does time itself become too valuable of a resource to ignore, when in the throes of pursuing an opportunity?