Developing software products requires choosing an approach that depends on multiple factors such as the intent behind developing, organizational maturity, the stage of ideation, and team skills. There is no single approach that fits all situations. Sometimes organizations fall into the trap of mimicking practices that may have worked for others without conducting a fitment analysis.
It is also important to understand that all development approaches lie on a continuum. On the one end of the continuum, there is extreme agility and organizational flexibility while on the other end, there is directional certainty coupled with process orientation and predictable risk mitigated deliveries.
In this article, I would like to discuss five common approaches that can be used depending on the maturity and the product development stage within an organization.
Imagine a bunch of college graduates with a bright product idea that they wish to develop rapidly and test in the market. In such cases, there may be little to no funding available to develop their product. The intent of the team must be to remain frugal and economical with all their processes and engineering practices. The focus must be on the core development of the concept, as fast as possible. I call this the ‘War Room’ approach – the words capture the essence of the team’s state of mind and focus.
This approach works well with teams that are small and physically co-located. The process is usually informal and involves the ‘shout and solve’ approach for most questions that may arise. There is minimum to no planning involved in this approach. However, it allows for real-time feedback and frequent pivots in strategy. Several successful start-ups have followed this approach to quickly roll-out products on a shoe-string budget. This strategy works well when the organization is at the beginning of its product development journey and has one product idea that it plans to target.
Imagine a well-established business is looking to venture into product development. They have an awareness of the potential products to build, which may appeal to the target customers in their industry. However, putting in the efforts to develop a product also carries a substantial risk that its intended customers may not be interested in using the product. In such a case, the entire effort would be wasted.
A smarter approach would be to build the product enough to demonstrate its core concept and validate its usefulness with the customers before committing to full-fledged product development. The entire Lean Startup movement is built around creating ‘experiments’ that can provide ‘validated feedback’ and help decide whether to persevere on the identified product or pivot into a new idea.
This is an excellent approach in the initial stages when the organization is learning which product to develop among multiple choices by receiving feedback directly from the customers.
Imagine a business that has directional awareness of the type of product portfolio it wants to build. A couple of ideas may be market validated and there may be a strong buy-in within the organization to target those ideas. However, the team may also want to identify more ideas/features that they could assess before venturing further. (Here, market validated means having at least one willing customer who wants to participate in the co-creation journey and uses the product as it is developed.)
This situation requires a defined agile process that provides enough guardrails to build and roll-out MVPs while also providing flexibility to focus on experimentation. Typically, a combination of the scrum with the Lean Startup practice works best here. The key here is to balance planning with doing.
Imagine a business that has gone through its experimentation phase, has tested out a few product ideas, and zeroed in on one or more products having market validation and a defined roadmap.
The organization has directional certainty and focuses on ensuring predictable deliveries of high quality and good user experience. Most organizations may also have significant geographically distributed teams working on the unified product roadmap.
This situation requires battle tested approaches that not only provide guardrails but are opinionated from the organization’s viewpoint and tailored in detail. The focus here is on processes to drive agile deliveries on the identified roadmap. Depending on the team size and geographical dispersion, a combination of scrum/scaled agile strategies for continuous, predictable deliveries and Kanban for support processes works best. The overall engineering practices must also be matured by treating everything as a code and building pipelines that automate all aspects of development, production rollouts, as well as rollbacks.
Imagine a business that has been on its product journey for a considerable time and has a stable customer base.
Along with sustaining the pace of innovation with predictable deliveries, it also becomes imperative for such an organization to invest in deep risk mitigation practices to sustain its moat. Typically, at this point the organization structure too starts resembling a large enterprise with different teams having different goals. Hence, the approach must also be tailored for the needs of each type of team.
As risk mitigation becomes the primary focus to maintain the quality of service, having strong program management and business continuity practices becomes important to ensure there is no risk to reputation. Along with the approaches mentioned in the ‘mature startup’ approach for predictable deliveries, there needs to be a strong governance team focusing on risk mitigated deliveries with enhanced focus on site reliability engineering practices as a part of unified program management. The key here is to have equal focus on maintaining the quality of service for the products along with continuing the innovation roadmap.
Each of the above approaches assumes an organization archetype and recommends a viable product development strategy to pursue. Every organization will continue to evolve, and the strategy must also be adjusted with the change in operating reality.
Source: https://www.crn.in/columns/outlook-for-2023-on-software-product-development-approaches-2/
