Product-Delivery Methods

A Typical Software-Development Lifecycle

Now, let’s look specifically at the software-development lifecycle. Consider what software-development model would help you take your idea to market and ensure a fast rollout for your digital product.

The software-development lifecycle refers to development process for a software product—from ideation, requirements definition, and design through development, testing, deployment, and maintenance, as shown in Figure 2.

Image source: ncube

Software-Development Methods and Project Outcomes

The parameters that position your product in the marketplace are your idea, funding, and time to market launch. Figure 3 shows the effect of various software-development methods on these parameters.

Most startups fail because of either the idea itself, a lack of product/market fit, exceeding the project’s budget, excessive time in development, or the timing of the product’s release. Project outcomes depend on different combinations of the following factors:

• a big idea, a good market, time to develop, and the budget to launch
• a good idea, uncertainties about the market, and a good budget
• a good idea, but uncertainties about the market and a low budget
• a big idea and a good market, but no budget and inadequate development time
• the possible combinations go on…

Where does your product fit in the marketplace? As a product owner, how would you want to develop and launch your product?

The Software-Development Process

Let’s consider some different approaches to the software-development process.

Waterfall

The waterfall software-development process that is shown in Figures 4 and 5, which is otherwise know as the linear sequential model or classic lifecycle model, is one of the oldest, most traditional models for software development.

When it’s useful:

• Use this process if your product idea relates to government, medical, or educational domains, which have strict requirements for signoffs, documentation, and compliance approvals.
• You’re unlikely to finish development of the product on time and on budget unless there are no drastic changes in requirements.

When it’s not:

• This process is not suitable for testing product performance or user behavior or for iterative testing that requires flexibility in your approach.
• Changing feature requirements is not an option.

Hybrid Waterfall

This is a modification of the classic waterfall development process and lets you receive feedback at the end of every stage. The hybrid-waterfall approach, shown in Figure 6, helps you determine at each stage whether you are on time and on budget or are in a time crunch. It also lets you choose to explore or defer certain features, then revisit them whenever you are ready. Product owners who ideate and bootstrap their solutions and don’t initially opt to get angel or venture-capital (VC) funding, often prefer this method.

Opportunity—This approach is useful when you need to raise funds for the development of products that have a detailed Business Requirement Document or Product Requirements Document. It helps you envision the capabilities of the product, which, in turn, helps investors visualize the magnitude of the product opportunity, then subsequently take steps toward product development.

Lean Startup Method

The Lean Startup method, shown in Figure 7, has its basis in the Lean manufacturing principles of Toyota’s production system, which focuses on optimizing development time and resources and delivering only what the user needs. The outcome is a minimum viable product (MVP)—a minimal version of the product that you can release to market and learn what users do and don’t want, then implement users’ feedback in the next release.

Image source: Plutora

When it’s useful:

• This development method is useful for product owners and teams making continuous updates to their products.
• Use this approach when exploration and gaining user feedback are important.
• It helps teams understand their product’s market fit and prioritize building the most important features.
• Teams that are extremely tight on time and budget can benefit from this approach.

When it’s not:

• This method is not effective in organizations that are rigidly structured and have strict documentation and approval policies.
• This approach is not suitable when a project’s goals, scope, budget, and timelines are predefined and fixed.
• It is not applicable when you cannot obtain user feedback.

Agile Software Development

Agile is now the most popular software-development process because it is a dynamic, iterative approach. Its goal is to move fast and release often so you can gather customer requirements and feedback.

Instead of implementing the complete requirements for an entire product at once, cross-functional teams work in a series of 2–3 week sprints, as shown in Figure 8. The team plans the scope of each sprint, choosing what requirements, or user stories, to develop during that sprint from a backlog. They plan releases based on their delivery capacity.

Image source: Infinity

As shown in Figure 9, sprints can be like splitting a waterfall development cycle into multiple, smaller waterfalls, breaking down the requirements into smaller features, according to their value and usefulness to the product’s users.

When it’s useful:

• This process is suitable for product owners and teams who are making continuous updates to products.
• It’s also good for launching small releases, gathering user feedback, adding value, and fixing bugs.

When it’s not:

• This process is not good for teams with extremely tight budgets and timelines.
• Agile is a dynamic process, so cross-functional teams can easily exceed their initial budget and timeframe.

SAFe: Scalable Agile Framework

Use SAFe, the Scalable Agile Framework shown in Figure 10, for large, enterprise projects with big teams, big goals, distributed teams that are spread across the globe, and products that have extensive feature-requirements lists. Such projects are usually massive in terms of the product idea, the market, funding, and timeline.

Image source: Scaled Agile, Inc.

A product owner should be cautious about launching such a product-development project. When defining the requirements, you could get excited about creating a million-dollar solution and forget the reality that designing and developing every feature would consume enormous time and money. As your business requirements document grows and you add unlimited opportunities for ROI, be sure to vet each requirement against the value it would provide to both the user and the business.

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.”—Steve Jobs

Integrating Features Through Iterative or Incremental Releases

Iterative and incremental development approaches are similar to the Lean mindset in that you build a feature and see how it adds value for your users, then make continuous improvements based on their feedback, behaviors, and demand.

“Quality planning consists of developing the products and processes required to meet customers’ needs.”—Joseph M. Juran

Teams iteratively design and develop small parts of a product’s feature set over a series of releases, as shown in Figure 11. Relying on the feedback and needs of the users, the team adds features as demand for them arises.

An incremental software-development process, shown in Figure 12, is similar to creating an MVP—initially building a minimal product that supports the user’s most important tasks and goals, then gradually adding more functionality and value to the product over time, as you get customer feedback. For each incremental release, teams build a complete feature.

When it’s useful:

• Teams that have clear requirements, but want more flexibility than the waterfall method provides might choose one of these approaches.
• Both of these approaches add a level of flexibility to the software-development process, without throwing away your overall plan, making them ideal for large projects that have well-defined scopes—or for teams that have less risk tolerance.
• With the incremental approach, you can get early feedback on the product’s core features, which can help you validate your business case right away. In contrast, the iterative approach gives users an early look at what the full product could be, letting you obtain better, more focused feedback.
• In either case, you’re talking to users early on about what they actually want, which can save you lots of time and money and eliminate problems that you would have encountered if you had waited to take the product to users until later in the development cycle.

When it’s not:

• This approach does not work well for teams that don’t have a clear, long-term technology plan.
• Unfortunately, trying to add structure to a flexible approach has its own issues.
• Your company’s goals, procedures, or technologies might change over time, making earlier iterations obsolete or even breaking them.
• Plus, both of these methods—especially the iterative approach—require heavy planning and architecture early on. Thus, they aren’t ideal for smaller projects or teams who are still exploring different use cases and trying to find the right product-market fit.

No-Code and Low-Code Development

A no-code development platform lets users use visual components, dragging and dropping them to create a visual model of an application. Designers who cannot code or have little coding experience can use this method to create applications. No-code and low-code platforms minimize difficult coding by providing plug-and-play components or templates for data management, database linking, unit testing, and other add-on functionality.

Benefits of using low-code and no-code development platforms include the following:

• You can continuously create truly agile releases with the help of prebuilt modules.
• You can considerably reduce the time between releases, if the modules are well thought out.
• These platforms reduce your development costs in comparison to traditional approaches. All you need is the right product road map. Many developers of such platforms provide extensive support and help to their customers.
• You could eliminate a 2–3 week sprint that would be necessary for a product release using a traditional approach.
• Multiple releases of such products for different native and hybrid platforms make developing cross-platform applications easy.
• You can get by with a smaller product team because this approach is very productive and efficient.
• Data security and server management are not such big concerns because they’re managed by a service provider.

When it’s useful:

• If you can afford the platform and have tight timelines, you can check whether your idea works.
• You can quickly test the market before getting into detailed design and implementation.
• This approach is helpful if your timeline doesn’t accommodate using all the traditional methods of detailed research, design, and development.
• It lets you quickly test whether you’ve found the right platform.

When it’s not:

• If you need to own the source code, this approach won’t work for you.
• New ideas that require modules your team hasn’t yet built can slow you down.
• This method requires a mature design process that ensures you can differentiate your product from those of competitors, innovate, and disrupt your marketplace.
• Platform-dependent workflows or switching platforms could add to your current workload and might slow your releases.

Top No-Code and Low-Code Platforms

• The FileMaker Platform
• Kissflow
• OutSystems
• ServiceNow Now Platform
• ProcessMaker
• IAR Embedded Workbench
• Salesforce Lightning Platform
• Pega Platform

How These Platforms Differ

According to Wikipedia, the differences between no-code and low-code platforms are not significant, but include the following:

• application’s creator—Any business user can use a no-code platform, but low-code platforms require professional developers who can work within a platform’s constraints.
• core design—No-code platforms usually take a model-driven, declarative approach, in which the user creates an app’s design through drag-and-drop manipulations or by defining simple expressions. Low-code platforms depend more on creating code to specify an application’s core architecture.
• user interface—No-code platforms usually rely on a predefined user-interface layer, which simplifies and streamlines designing an application. Low-code platforms may provide greater flexibility in user-interface design, but at the cost of their requiring additional coding and defining complex requirements.

Cloning Similar Products

You could look for similar product that are already on the market. Many companies offer clones of existing products, which can very helpful if you need to launch your product quickly to achieve specific business outcomes. You can alter such clones to use your branding. Recently, many products have launched using this technique. But be sure that you can create the brand and product value that you need to provide to your customers.

When it’s useful:

• A product owner who has a clear roadmap could hasten a product’s release if similar products already exist.
• Obtaining such a clone requires a sufficient budget upfront to get the source code and have it customized.
• You can benefit from prior product planning and discovery, ensuring a successful idea with good product/market fit.

When it’s not:

• Extraneous ideas that are part of the available clone could add enormous development time and slow down your release.
• If you don’t have an adequate initial budget or sufficient time to buy and customize the clone, this approach isn’t an option.
• Taking this approach could get tricky in the long term because you are not connected to the source-code provider.

Conclusion

I hope this article has given you a basic understanding of the various methods of software-development and how they impact product value, product/market fit, budgetary requirements, and time to release. Once a product owner has created a product or business requirements document or defined the user stories for a project, knowing the right development method to choose for the project can make your life much easier. You could mix and match these development methods to achieve your desired outcomes.

The information I’ve provided in this article should be especially helpful to people who do not have a technical background and, thus, need to understand how to move a product successfully from ideation, requirements definition, and design through development, testing, and deployment.