The Three Stages of a Product's Lifecycle

Originally published in Medium

You are designing a new widget, developing an algorithm or defining a database, spending countless hours of work and sleep thinking about it and racing to a deadline. Or you are looking at a new development project and deciding how you will plan or execute it. When you make these decisions, it is worth it to stop and think about what it is that you are building, as it will determine how you should go about it, what risks you should be taking and which ones you need to avoid.

A first thing to realize is that building a product is more than developing a set of features. Given the high cost of engineering and development that building products entails, products tend to have long lifecycles, with multiple versions of them. There is a growing awareness of the need for building extensibility or modifiability in the design of the product itself. The development team can then be dedicated to add new capabilities, remedy design defects or implement any other changes. A well engineered product will allow these changes without the need to start from scratch. This emerging concept of technology platforms is used in many industries as the underpinnings of multiple products. In Information systems, these underpinnings are given by a combination of technology choices, design patterns and explicit extension points (e.g. API’s, plug-in architectures and scripting languages).

In this evolutionary view of product development, the challenges that the development team faces vary a lot with the stage of the lifecycle of the underlying technology platform and the maturity of the target market and competitors. Most product development methodologies, including iterative and agile ones focus on some variation of the conception-development-verification-release-feedback cycle. This is useful as a general approach but fails to highlight the differences between the stages of a product that can determine the success of the development effort.

Dealing with the lifecycle of the underlying technologies is a world onto itself, which would take too much space here, so we will blissfully ignore the technical risks that technology evolution by itself introduces.

Focusing on the maturity of the market and the competition, including potential products our team could be currently offering or operating, I look at projects in one of three buckets:

1.0 Developments aim to create new entrants in a market, where the development team starts from scratch, or from a very generic set of components and platforms to build on. These projects run the risk of starting too many things from scratch at once, ranging from the team itself, which can be a new organization that does not know how to work together yet , or trying new technologies or platforms. For these projects, it is essential to reduce the scope of the first release as much as possible, and minimize exposure to “non-critical” development risks. Techniques that help with achieving this:

• Define a “walking skeleton” or a thin-thread end-to-end demo to shake out any quirks in the development process, tooling, used components, etc… with the minimum functionality possible, even if it involves defining “fake” functionality. The goal is to test the machinery, not to start the journey.
• Define the MVP profile of the product in a clear and communicable way (a three level feature outline works great for this). Classify each of the features as a “right of entry”, “parity”, “dominant” or “breakthrough”, to indicate what level of functionality and “fit and finish” is targeted in each of the features. No matter how tempting, resist over-producing and gold plating any features that are not in the dominant of breakthrough category. Be ruthless in keeping the resources for “right-of-entry” and “parity” features to the minimum needed to clear that bar.
• Separate “ancillary” functionality like authentication, account management, UI management, help & support links, etc.. and use as much off-the-shelf components and/or outsourcing as possible to keep the core team focused on high-value, domain specific functionality.
• Design your project plan around a set of full end-to-end features that can be shown and tested by the business stakeholders, be them Product Managers, Business Analysis or similar.
• Prioritize your features for development following two criteria: Initially pick some easy, low risk features to make sure that your development process and team is well oiled and running, and to quickly develop a small feature set that can serve as the showcase of the ancillary functionality as it comes online. Once this is done, pick the riskiest, most complicated features to make sure that you move the big boulders well ahead of the inevitable time crunch.
• Pile up as much effort as you can onto a single feature before you open another one, keep your battlefront as narrow as possible at any point in time.

X.Y Development: This is development that adds features to a product in the middle of its lifecycle. At this point the technology risk should be close to zero, the design and implementation patterns well established, and the needs of the customer and market well understood. The challenge here is to keep a fast and continuous feature release cadence to the market.

The emphasis needs to be put into defining features that are as independent of each other as possible so that they can be developed and released independently and picking the most value to deliver with the available team capacity. For this type of development, it is also critical to have a robust and fast triage process for bug or incident resolution as well as small improvements that may be required by special customers. A conventional SCRUM or Kanban development process usually runs well and without problems, provided you have strong product owners with an iron fist to rule over the backlog of the team.

X.0 Development: In many respects this is the hardest type of development to manage and deliver successfully. X.0 releases tend to be defined when an external threat appears (e.g. the arrival of Web based applications for Client-Server systems or the emergence of SaaS products in enterprise software) or when the age of the existing technology stack and product makes it too costly or impossible to maintain. This is the classic innovators dilemma for a company. Assuming that the decision of the business is to invest in the next generation of products, the development team will still face a set of almost impossible challenges:

• New development needs to compete with the current “X-1” product, which: (1) Has a very big feature footprint, result of many years of effort and resources. (2) Is very mature, has few new bugs and runs on a stable and well understood infrastructure and (3) Keeps adding functionality and new features to keep up with the market, making it a moving target for replacement.
• Critical resources with deep knowledge of the domain, features and customers are still heavily invested in the current product generation and the need to remain involved in it for its maintenance and adding incremental improvements.
• Specification and/or requirements for the MVP of X.0 does not exist and the documentation from the X-1 release is either non-existent, obsolete or lost. The best spec is the X-1 product itself, which without the right guidance will result in copying the bad things along with the good ones
• The new X.0 release typically involves a refresh of the technology stack and foundation, which introduces technical risk by itself and is frequently underestimated. Furthermore the new set of technologies is usually new for the team, requiring training and experimentation that is rarely acknowledged in the allocation of resources and schedules.

Faced with these difficulties, plus many of the same ones that afflict 1.0 style development, it is no wonder that these projects are the toughest to pull off. The successive thinning of ERP providers with each wave of technology change (from mainframes to client/server, and then to cloud is a highly visible example of how hard it is to emerge successfully from these changes). There is no silver bullet for these projects, and the approach usually requires the involvement of all the business functions and not only engineering or product teams. The complicity and support of the sales and customer service organizations is essential to give the new product a fighting chance by providing the right environment, incentives and opportunities to learn from real customers feedback.

The highest threat for X.0 projects stems from a combination of boiling the ocean in architecture refactoring, competition for critical resources with other projects with faster payback and the long incubation period they need to stand up to feasibility in the market. When I have seen these projects succeed, they

• Have a champion that can act as a Chief Engineer, with enough pull in the organization to drive the right resources and contend with schedule pressure if necessary.
• Find an “early adopter” customer that is willing to accept the risk of adopting the new product major release and provides a narrow, clear profile of functions to implement in the new product. This is where a close partnership with the sales and business development functions is essential do identify, groom and partner with these “co-innovation” customers
• Create a team with a mix of new staff (not necessarily junior, but new to the project or the industry) with key experienced personnel that avoids repeating mistakes, and making new ones that are already solved in the previous versions of the project. This experienced staff is also the best source of detailed use cases and non-happy-path specifications that are usually ignored in 1.0 type of projects.
• Drive the development through milestones that are validated through the pilot customer. This is harder than it looks because it needs to preserve enough flexibility in the schedule to accommodate unexpected setbacks.
• On the technical side, the chief engineer role is critical to balance the amount or foundational work with the unavoidable technical debt that even a re-architecture project will incur.

Even is you are not starting a new project, you should stop for a minute and do an internal check of what kind of product you are developing. You owe it to yourself, your sponsors, and very critically to your team to be able to set ambitious but achievable goals.

Copyright: ? Salduba Technologies, All rights reserved License: This work is licensed under the Creative Commons License CC BY-NC-SA 4.0