For startups with limited resources and relatively limited revenue to protect, the challenge of making key technology decisions is most often limited by cost. The flexibility and low upfront costs offered by cloud-based services and open-source components are attractive and logical platform choices.

For larger organizations – those with sizable revenue, customer base and brand reputation to protect – the challenge is one of balancing risk, speed, and cost with the re-use of established processes and IT assets. Corporate IT departments must strike a delicate balance between providing secure, scalable, flexible, and cost-effective platform capabilities, while also providing the capability for innovation and app development at speed.

To strike the right balance in the face of marketplace competition and ever-evolving technology developments is a particularly taxing problem. But it is one that can be solved by close attention to the product development lifecycle (PDLC), and deliberate, but different, trade-offs at each stage. This article will help you lay a path that helps you navigate your value proposition through these economic and technical challenges.

Product development life cycle

There are many variants of product development lifecycles that focus on describing phases and practices over a timeline.

Following design thinking, we work from a model that centers on the decisions and actions to create products through methodical reduction of uncertainty to build confidence that the app will be successful¹.

Uncertainty and risks are reduced by acting, learning, and adapting to feedback. Technically, this is straightforward: multiple and frequent releases throughout the PLDC.

Releases

Application releases are where product management and tech platforms become a reality. Semantic versioning is a very useful way to communicate the intent and progress of the app.

Technology platform trade-offs

The ideal technology platform is flexible, resilient, always available, high-performing, super secure, infinitely scalable, and virtually free from maintenance, licenses, and other operational costs. And it also supports the super-speedy development of outstanding user experiences.

Many of these quality attributes are mutually exclusive. For example, extremely secure solutions will not be as flexible and user-friendly as moderately secure solutions.

The challenge of evolutionary architecture is to make the right trade-off decisions at the right time throughout the development of the product. Many platform capabilities are difficult and costly to change. A cloud-native solution is not easily migrated over to a hyperscale infrastructure. Containerization adds flexibility but adds complexity and can degrade performance.

Let’s examine how and when we recommend these trade-offs should be made.

Market-opportunity fit

Unsurprisingly, discovery is all about discovering a problem worth solving. It involves idea generation and executing experiments that dismiss or validate hypotheses about the need for a solution. As we all know, humans tend to make flawed assumptions. Especially when it comes to predicting value and behaviors².

How many of your initiatives failed because they were kicked-off based on assumptions and anecdotes rather than gathered evidence?

Arriving at a market-opportunity fit depends on rapid learning through research, experimentation, prototyping, and proof-of-concepts to remove uncertainty.

Platform trade-offs

Speed

Use tools that are familiar to the team members, and boilerplate environments that ensure minimum security and compliance requirements are met (e.g., GDPR).

DO	DON’T
Collect business metrics and feedback to speed up the learning process. Utilize existing services or service providers for collecting data and building dashboards, analytics, and more.	Underestimate the value of feedback coming from users experiencing your idea under as real conditions as possible. Professional opinions on how stuff should work, or hypothetical “what-if” and “would-you-buy” scenarios are not sufficient.

Cost

Minimize upfront investments with open-source, pay-as-you-go, and hosted services.

DO	DON’T
Utilize SaaS, low-code, and AI tools. There are many good tools for creating prototypes to do rapid prototyping and simple integrations with core solutions.	Invest in engineering and quality assurance practices. It’s OK to treat digital assets as throwaways at this point in the lifecycle.

Mature corporate IT platforms very rarely offer the ease of use and speed needed for efficient experimentation. So, most teams will build discovery versions using SaaS tools for prototyping, integration, and user analytics loosely coupled to core systems.

While broad participation in activities is beneficial for motivation and stakeholder buy-in, you should keep the team small and with just enough technical skill to execute experiments for value discovery.

Problem-solution fit

When a business opportunity is properly identified and validated, the focus shifts toward building product versions that embody the core features of your application. At this time, the product team should focus on problem/solution fit. Now, it’s natural to grow the team to include more technical and design talent. However, the overall team size is still best kept small and manageable through direct communication (typically not more than 12 people).

This is the place where many teams are tempted to move towards scaled, program-managed delivery approaches; however, our experience demonstrates that more extreme programming approaches lead to better outcomes.

The same applies to technical architectures. “Keep it simple, stupid” is the overarching principle here, because the uncertainty about customer experiences and behaviors is bigger than the unknowns around how to build the solution. Customers tend not to care about deliberate backend architectures such as microservices and lambdas, but they do care a lot about the user experience!

Platform trade-offs

Flexibility

Flexibility and speed of feature development take preference over scale, performance, and resilience when validating if the solution can become a successful product. The focus is to enable rapid feature development and accommodate feedback.

DO	DON’T
Concurrent engineering. Having the ability to run concurrent experiments with multiple user groups is important. Do this either through feature flags or clever use of multiple environments.	Optimize prematurely for non-functional requirements if it prevents rapid iteration and frequent releases.

Costs

The product is not expected to be profitable at this stage, so controlling development costs is still in focus. Evaluate and test critical infrastructure choices, such as cloud or on-premises hosting, security standards, and containerization to predict operational costs and efforts.

DO	DON’T
Leverage trusted, existing platforms. Proven blueprints and skills offer the best options for keeping overhead and investments affordable. Proven blueprints, whether SaaS, PaaS, or in-house platforms, should offer building solutions that create minimal overhead and keep costs to a minimum.	Aggressively scale the development team. Expanding the team is merited once problem-solution fit is established through successful alpha releases. Whereas alpha product releases are designated to evidence problem-solution fit, the job of beta releases is to test for product market fit.

Product-market fit

Congratulations! Your product team has been successful in gaining traction with a solution and now needs to discover how to take the product to market. At this stage, you already have a solution from building alphas.

At this point, a product manager’s role typically shifts from working within the team to coordinating other enterprise functions to embed the product and its operations in the wider organization. But the development team needs to keep the focus on making sure the product works at scale for all target customers.

While many key architectural elements are set, the effects of those decisions are still unknown. A lot of work remains to ensure that the solution can be operated and maintained at the scale and cost levels necessary to become a successful product.

Platform trade-offs

At this moment a typical critical trade-off decision is whether to keep infrastructure at PaaS or adopt hybrid approaches. In many cases, the core aspects of a solution will show that moving to IaaS will provide the most advantages, while other areas viewed as enabler capabilities will be maintained as SaaS and PaaS offers. For in-house platforms, this is the critical moment for shifting a solution to stable IT maintenance and ops rhythm.

Risk

Monitoring and analytics are key. Leverage even more data to gather insights and feedback for refinement of the user experience.

DO	DON’T
Take advantage of modern solution patterns for availability and elasticity, such as application distribution, user loads, and data volumes.	Leave security and performance concerns to later. Where possible take advantage of the cloud’s global infrastructure to test the app in various regions.

Revenue

A combination of development testing, user acceptance testing, and production monitoring and triage becomes very important and needs to be set up.

DO	DON’T
Establish efficient engineering standards and practices. Part of product-market fit is to ensure the cost of maintenance and support is managed.	Build new IT operations teams and routines. It is normally far more economical to upskill and potentially expand the existing team.

Business model fit

Getting the product to market can be the end point of some product development lifecycles. But it’s not the end of the product. Quite the opposite, it’s with live releases the product becomes part of the ‘real’ operational business.

Reaching the scale stage signifies readiness for mass market adoption and necessitates a platform capable of supporting both rapid growth and high availability. Cloud services, with their unparalleled scalability, are the default choice for many.

Platform trade-offs

Scale

When scaling our solutions, engineering teams should take the opportunity to ‘clean the house’. It’s time to re-evaluate architecture decision records and streamline overall solutions to reduce complexity and streamline operational activities.

DO	DON’T
Invest in scalability and reliability. Ensure the platform can handle growth spikes without compromising on performance. At the extreme end of things, leveraging caching and content distribution network services to reduce data traffic could be an option.	Allow technical debt to accumulate. A large part of supporting a solution at scale is removing the noise that has been accumulated in the solution, through standardizing, and through removing functionality and approaches that no longer serve a purpose.

Revenue

Continuously collect data and analyze it for insights on both revenue and cost drivers.

DO	DON’T
Continuously monitor and optimize operating costs. The infrastructure costs for solutions with large data volumes can be surprisingly expensive. Hybrid approaches, combining cloud flexibility with on-premises control, might offer the best of both worlds, keeping TCO, total cost of ownership, under control.	Skip the reduction of operational risk. Business continuity and disaster recovery procedures must be tested and baselined. Security is not a task that is one-and-done.

While the concepts of “hardening” and “go-to-production” are crude processes, risk reduction is particularly important for non-functional requirements. And not a one-off event. Only continuous improvement driven by economics can prolong product lifecycles and prevent the platform from becoming legacy.

Conclusion

The journey through the product development life cycle involves important choices regarding business and technology development, all of which influence your product’s success trajectory.

Avoid the temptation to scale development and non-functional attributes of the platform while the uncertainty about market uptake is significant. And equally important, product-market fit also means that the technology platform needs to fit the scale and operational standards of the company.

The optimal choice depends on a complex interplay of factors including security, compliance needs, scalability requirements, and cost considerations. But remember that the effect of most decisions will only be evident in hindsight.

The current best practice for capturing decisions as the architecture evolves is “Architectural Records.” ³

We strongly recommend recording the release type with the associated trade-offs. And of course, we also recommend evaluating historical decision records to learn and improve. After all, successful product development comes back to the adaptive mindset: “act fast, learn fast, improve fast”.

If you found this article insightful and want to dive deeper into our capabilities or learn more about product management and cloud cost optimization, dive into our Insights page for fresh perspectives! We also recommend the now classic book Building Evolutionary Architectures.

Notes and sources

1. David Bland and Alex Osterwalder, 2019. Testing Business Ideas.
2. Daniel Kahneman, 2012. Thinking Fast and Slow.
3. ADR (Architectural Decision Records), https://adr.github.io/