A Practical S-Curve for Software Entrepreneurs

Modeling the Maturation Process of New Software Products

Overview

The notion of the so-called S-curve in the context of technology management has been around since at least the mid-1980s (Christensen, 1992). In general, a technology S-curve plots an outcome variable of interest (e.g., technical performance, profit) over some predictor variable like time or engineering effort. As the name suggests, the slope of the S-curve is initially pretty flat, then rapidly increases and the plateaus off again. As it turns out, S-curves are quite good at modeling phenomena such as product life cycles and the effect of innovation, which can cause a jump from one S-curve to another (Adner and Kapoor, 2016). See Fig. 1 for a simplified illustration.

Fig. 1: S-Curves in Technology Management

In the following, we will look at a very practical kind of S-curve that may be especially relevant to software entrepreneurs. The idea is to use the S-curve to model the maturation process of new software products (and services). In particular, the S-curve can be used to describe and analyze the link between two types of maturity: product maturity (e.g. technical functionality, user experience), and business maturity (e.g. business planning, profit generation).

Fig. 2 shows the S-curve for new software products at a glance. The following sections give a brief overview of the different levels of product and business maturity, as well as the three broad phases of maturity spanning the S-curve.

Fig. 2: Maturity S-Curve for New Software Products

Levels of Product Maturity

As Fig. 2 illustrates, product maturity refers to the software product’s tangible evolution from a mere “gut feeling” to something more full-fledged. You may have come across terms like “prototype” and “MVP” in the past, yet these terms can be confusing, partly because they are used interchangeably when they really shouldn’t be; they all represent a slightly different level of product maturity. So to provide some much needed clarity, here are brief descriptions of the key levels of product maturity shown in Fig.2:

• Gut Feeling: This is the feeling (as yet untested) that may have been sparked by past experience, an interesting technical discovery, an interesting conversation with someone, or even something you happened to see on the news. Your gut feeling indicates that you are “on to something” — that “something” may be problem-driven (a market gap, an unmet need), solution-driven (a new technical discovery or invention), or something in between (an idea of how to connect a known problem to a known solution).
• Sketches and Wireframes: These are static and somewhat abstract representations of the product user interface (UI) and user experience (UX), and are thus typically the domain of designers. Whereas a sketch might only show a single screen, a wireframe (in the form of an “if-this-then-that”, “box and arrow”-style flow diagram) shows how users are able to transition from one screen to the next in the software product. Due to their static and abstract nature, sketches and wireframes are also often referred to as low-definition (or “lo-fi”) artifacts.
• Mockups: These are more detailed representations that give an indication of what the final product might actually look like. For instance, as a software entrepreneur, you might use a mockup of you product (e.g., the home screen of your app or website) to give potential investors a realistic experience of the look-and-feel of the final product. However, mockups are generally not interactive, so they often go hand-in-hand with POCs.
• Proof-of-Concepts (POCs): These are interactive (clickable) representations of the software product, that show off the technical potential of the product. Note that the focus is on technical potential and how certain technical challenges can be overcome in principle, rather than the final technical architecture. For instance, if the software product includes a complex machine learning algorithm, the POC might simplify some aspect of the algorithm’s deployment (e.g., use a small data sample, use default model parameters, etc.), so that you can quickly demo the POC to stakeholders.
• Prototypes: The key purpose of building a prototype is testing, ideally by getting feedback from potential users. You build prototypes because you want to test features, functionality, and UX/UI decisions that end up shaping the software product that is shipped to customers. As such, the prototype is only really doing its job well if it is helping you accept and reject various design choices in the software product based on user feedback. An implication of this is that prototypes should have a clear way of tracking user interactions (e.g., by tracking clickstreams). Due to their interactivity and focus on realism, POCs and prototypes are also also often referred to as high-definition (or “hi-fi”) artifacts.
• Minimum Viable Products (MVPs): This is the most bare-bones version of the final product that can still be released to customers. In a for-profit context, an MVP would be a version of the product that a customer would be willing to pay for. Whereas a prototype might only have features implemented that are being explicitly tested, the MVP has everything implemented (back-end, middleware logic and front-end) to a sufficient enough level that customers can actually use the software product in a meaningful way. An MVP is not perfect, however, and nor is it ever intended to be. Indeed, in early MVPs, the UI may not be very fancy, the UX may feel a bit “clunky” and the technical performance might not be that great. The point is to release the product out into the market as fast as possible, so that valuable user feedback can start being collected; over multiple iterations, short release and feedback cycles can lead to dramatic improvements in the overall product.
• Standardization: Once the product goes through a few MVPs, most of the bugs should be ironed out and you will likely have a fairly good idea of what the customers want. As such, you may want to consolidate the product into a stable release that is rigorously field-tested, highly reliable and would be supported in the long term by your company via periodic updates. A common approach to producing a stable release is to impose a certain degree of standardization on at least the core features of the product. This might involve standardizing the UI and UX to help users become familiar with the ways of interacting with the product (e.g., searching, swiping, clicking, the position and content of menus). You can also standardize aspects not directly visible to users, such as any middleware logic or backend infrastructure, to reduce the risk of bugs creeping in.
• Add-ons: These are additional product features or complementary services that you offer from time to time in order to keep improving the value proposition for your customer base. For example, think about all the add-ons that you can get with web browsers like Firefox and Google Chrome; none of them fundamentally change the product (it is still primarily a web browser), but they do try to improve it in terms of usability, privacy, and personalization. Complementary services (e.g., IT support and consulting) can similarly strive to improve the customer experience.

It is worth emphasizing that, reaching a certain level of product maturity (such as standardization) does not obviate the need for artifacts like sketches and prototypes that correspond to the early levels of maturity. Indeed, as your software product evolves, you would continue to use of the above-mentioned artifacts in the future iterations of the product. Moreover, as implied by Fig. 1 earlier, once your product starts nearing the end of its current S-curve, it is important to identify the innovation that will take the product to its next S-curve.

Levels of Business Maturity

In contrast to product maturity, the business maturity dimension in Fig. 2 is concerned with the entrepreneur’s ability to make money with the software product. If the product is sufficiently novel, there may be no existing, tried-and-tested business model that can be applied directly. In the absence of existing models — or sudden “eureka” moments — the entrepreneur may have to take a more experimental, trial-and-error approach to coming up with a viable, long-term business model. Fig. 2 highlights a few key levels of business maturity, which can be summarized as follows:

• Gut Feeling: As with product maturity, gut feeling here is about being “on to something”, but in a commercial sense. Perhaps the entrepreneur has become aware of a pressing consumer need, or realized the inadequacy of existing products that attempt to satisfy this need. Without necessarily knowing what a better product would look like specifically, instinct might tell the entrepreneur that people would be willing to pay for it (possibly even a lot).
• Back-of-the-Envelope Calculation: This is a rough attempt to quantify the costs and revenue streams associated with actually building and selling the product. Simplifying yet realistic assumptions will be made about cost factors, market size and so on, to reach some round numbers that can be easily interpreted. Although back-of-the-envelope calculations sound easy, many entrepreneurial ideas don’t make it past this stage. Being forced to quantify costs and revenues, the entrepreneur may discover costs that have previously been overlooked or underestimated (e.g., technology licensing fees, rent, salaries, tax), or that the market size is likely too small (even allowing for wildly optimistic assumptions) to generate sufficient revenue.
• Business Plan: This is typically a document that potential investors like business angels, venture capital (VC) firms and banks will want to see before agreeing to fund the development of the product. It is also a document that gives entrepreneurs more confidence over the commercial potential of their idea. The business plan will generally include sections detailing the purpose, team structure, market analysis, product and financial projections (and requests for funding) of the new venture.
• Breakeven: This is when the business is able to generate enough revenue to cover its costs. Technically, the breakeven point in terms of product units sold is computed by dividing the fixed costs by the contribution margin (sales price minus variable costs per unit). Interestingly, the numerator in the breakeven calculation typically does not factor in the opportunity cost of spending effort in developing this particular product (rather than some other, more lucrative one), so the true breakeven in that sense is likely a lot higher (and therefore harder to achieve).
• Profit and Profit Growth: The business achieves a profit when the revenues exceed the costs. There are different types of profit, such as gross, operating and net profit, depending on the kinds of cost items that are subtracted from the revenue. Achieving profitability is especially important to a new software business, since the profits can be reinvested to support various activities (from further product development to marketing and sales). Over time, the entrepreneur may be able to tap into more of the market to boost revenues, and find ways to reduce the cost base; such things can lead to profit growth, measured over different time periods (e.g., monthly, quarterly, yearly). Although software businesses may not be as capital intensive as some others, the entrepreneur and investors will still be keen to see a steep profit growth to justify their bets.
• Mature Business Model: If everything works out well, in time the entrepreneur will have a mature business model that regularly turns a profit and shows a suitable level of growth (which can be in the two digits or even three digits in the world of software). To use a video game analogy, this is the equivalent of unlocking the first few levels of the startup game. The next levels may involve further establishing and building on the mature business model by extending the product functionality, adding complementary products to the company’s portfolio, and expanding the customer base by entering new markets.

Phases of Maturity

Taken together, the levels of business and product maturity yield the S-curve shown in Fig. 2, which can be broken down into three fairly distinct phases of maturity:

1. Incubation: This phase is about taking that initial spark (the “eureka moment”) brought about by your gut feeling and making it tangible. Rather than just blowing it off as a pipe dream, the idea of the software product is incubated and given a chance to take shape. This happens both from the product side (via sketches, mockups and POCs) and the business side (back-of-the-envelope calculations around the potential market, costs and revenue streams). Entrepreneurs in the incubation phase often talk about this as working on a “side project” or “skunkworks project”, being in “stealth mode”, being “early-stage”, and so on. If the software product is incubated successfully, the entrepreneur should hopefully come to the realization that “we have a cool idea”, and that, unlike a dream, “it’s possible to build this”.
2. Acceleration: This is a key phase for software products since it is essentially about putting the entire value proposition — and business model that operationalizes it — to the test. Will people actually buy the product? Will the product achieve breakeven or even a profit? Entrepreneurs typically don’t go the acceleration phase alone, and instead seek out advice and funding from angel investors and VC firms. Especially with software products, access to networks and resources of external stakeholders can be crucial enablers of the rapid growth (both in terms of business and product maturity) that is needed to successfully make it through the acceleration phase. If all goes well, the entrepreneur will go from thinking “we could make some money” and “people are buying are product” to realizing that “we are starting to make a profit” and “we can keep making a profit”.
3. Stability: This is the last phase of the S-curve, in which the product essentially enters a business-as-usual (BAU) state, or “steady state” as it is sometimes called. The stability phase is characterized by a shift in the entrepreneur’s priorities from mainly “conquering” (e.g., growth hacking, breaking into new markets) to also “governing” (e.g., enforcing consistent design and standardization of product behavior, eliminating bugs and improving software security). Ultimately the stability phase is about viewing the product through the lens of a grown up, established business.

Although the above three phases neatly define the different parts of a single S-curve, the story of a software product clearly does not end in Phase 3. Instead, the product can go one of two ways. If sufficient innovation does not take place, or the product simply does not have a long-term value proposition, the product enters a fourth phase of decline and obsolescence. If the necessary innovation does happen (e.g., significant technological improvements, repositioning the product to address a wider market or focusing on a niche), then the product can jump onto the next S-curve, and continue its upward trajectory. Spotting the next viable S-curve and transitioning to it at the right time and with the right momentum are skills that make successful entrepreneurs stand out; this may be especially true in software, where the lack of rapid innovation can quickly lead to products being left behind by newer and better competing offerings.

Finally, in case you have already come across the concept of a product life cycle (PLC), then you may see certain parallels to the discussion of the S-curve above. PLCs typically focus on the growth of commercial metrics such as sales and profit over the product’s life cycle, and span the phases of product development, introduction, growth, maturity and decline (Kotler and Armstrong, 2014, p.295-296). The S-curve concept described above complements the notion of PLCs by considered both business and product maturity in more tangible and practical terms.

The Wrap

This article showed how, by considering the link between business and product maturity, we can derive a maturity S-curve for new software products to model the journey of software products from mere ideas to mature businesses. Entrepreneurs can use such an S-curve to gain a better understanding of the current position of their product on the curve and take steps to move it further along the curve (or jump to the next viable one). Being in the incubation phase versus the acceleration phase, for instance, implies a different sets of priorities and levers for the entrepreneurs, and having awareness of this can be a big help.

Finally, Fig. 2 shows only one, and possibly somewhat stylized trajectory that the S-curve could take. In reality, the three phases (incubation, acceleration, and stability) could be of varying lengths and steepness, depending on the software product (e.g., disruptiveness of the product idea, and the ability to build on top of — or combine — existing technological “building blocks”), as well as other external factors (e.g., access to growth funding, and market readiness).

References

Adner, R. and Kapoor, R., 2016. Innovation ecosystems and the pace of substitution: Re‐examining technology S‐curves. Strategic Management Journal, 37(4), pp.625–648.

Christensen, C.M., 1992. Exploring the limits of the technology S‐curve. Part I: component technologies. Production and Operations Management, 1(4), pp.334–357.

Kotler, P. and Armstrong, G., 2014. Principles of Marketing. Harlow: Pearson.