Whether you are improving an existing system or developing something new, you'll usually begin with an idea, a problem to solve, or an opportunity to pursue. At this point, you rarely have a complete understanding of what people need, what the organization can support, or which risks and constraints may shape the solution. You develop that understanding over time by working with stakeholders and users, investigating problems, testing ideas, building the solution, and learning from how it performs in reality.
This work connects strategy, discovery and development, deployment, and ongoing operations. These activities overlap, and you'll likely revisit decisions in each area as new evidence emerges.
Your research may change how you define the problem. Prototyping may reveal that an idea is difficult to use. Development may expose technical constraints, while deployment and real-world use may surface needs and risks that were not visible at the start.
This chapter introduces the core practices you can use to guide a product or information system from the initial idea through discovery, development, deployment, and ongoing improvement.
Thinking Beyond Technology and Features
Successful products and information systems require you to think beyond the technology and features you might build. Instead, you need to evaluate whether an opportunity is worth pursuing and understand the people, processes, information, technologies, and organizational conditions that will shape whether your solution succeeds.
Evaluating Opportunities
Before you sink significant time and resources into an initiative, it pays to step back and ask whether it is actually worth pursuing in the first place. A helpful framework is to check if the idea is 1) desirable for the people affected, 2) viable for the organization, and 3) feasible to deliver (Brown, 2008). Together, investigating these three areas helps keep you from chasing an idea simply because it sounds cool.
Explores whether the opportunity addresses a real stakeholder, user, or customer need. You should identify people's goals, needs, and current experiences to determine whether the opportunity is worth pursuing and what kind of change may be needed. The aim is to understand the problem before committing to a particular solution.
Assesses whether addressing the opportunity makes sense for the organization and if the idea aligns with organizational strategy, supports its goals, and is likely to deliver enough value to justify the investment. As part of this, consider financial, operational, strategic, social, and mission-related value, and weigh the expected benefits against the costs, risks, and effort required.
Examines whether the organization can realistically design, build, integrate, deploy, and operate the proposed solution, as an opportunity may be desirable and viable yet still be impractical if the organization lacks the capability, capacity, or resources to deliver and support it.
These criteria are a valuable way to assess an opportunity, but they don't capture every consequence of the solution as it may consume disproportionate resources, exclude or disadvantage people, compromise privacy, create safety risks, or produce other unintended harms. For this reason, you should also evaluate your ideas against sustainability and responsibility criteria.
Examines the environmental and resource impacts across the full system lifecycle, from development and infrastructure procurement through operation, maintenance, and retirement. With AI-enabled systems, for example, you should evaluate the computing and energy demands of both initial model training and ongoing daily use. When designing a solution, consider whether a less resource-intensive approach could achieve the same outcome, since computing-intensive approaches can carry substantial financial and environmental costs.
Considers privacy, security, accessibility, equity, transparency, accountability, safety, and other factors that affect stakeholders and the organization. If these concerns are not addressed, then the system you implement may harm individuals, create reputational risk for the organization, or produce other unintended consequences.
Ultimately, these criteria help you evaluate an opportunity and ensure it addresses a real need, delivers value, and is feasible and responsible to run. You can use this assessment to decide whether to move forward, investigate it further, or stop work on it.
Understanding the System
To understand what a product or information system needs to do, you need to examine how people, processes, information, technologies, policies and external conditions interact with each other. This includes considering:
Understand who is involved or affected and what they need from the system. Look at their goals, work, responsibilities, working conditions, and ability to influence decisions. This will help you define stakeholder and user needs later.
Analyze how people currently work, exploring the steps, handoffs, decisions, exceptions, delays, and workarounds that are involved, to determine which parts of the process the system must support, simplify, change, automate, or leave in place.
Understand what information people need to do their work and make decisions, where that information comes from, and how it is created, shared, and managed. This will help you identify important data, reporting, privacy, and information-quality requirements.
Identify the systems, tools, platforms, devices and data stores, and other technology used, assessing their capabilities, dependencies, and constraints to help reveal integration needs, technical constraints, architecture concerns, and areas where legacy technology may limit the available options.
Identify the policies, regulations, organizational structures, and external conditions that impact the organization as these will create requirements your solution has to address, while others may limit the options available to you.
What you learn from exploring these areas helps you ground the product or system vision and goals in the realities of the organization and the people it serves. You can use these findings to define stakeholder and user needs, identify process and information requirements, and identify architecture needs that inform the design of your system.
The Product and Information Systems Development Process
As you guide a product or information system from initial idea to launch, you constantly cycle between learning, delivery, and improvement. You deepen your understanding of what the solution needs through research and collaboration, build and deploy it, and use real-world feedback to drive future decisions.
Although the following sections describe three broad areas of activity, you should expect to revisit earlier decisions as your understanding grows.
At a high level, this work involves three interconnected sets of activities:
- Strategy, where you connect problems and opportunities to organizational goals, decide where investment may be justified, define intended outcomes, and revisit direction and priorities.
- Discovery and development, where teams work to understand stakeholder and user needs, explore solution options, define requirements and develop working increments of the product or system.
- Deployment and operations, where the solution is released, supported and evaluated as it's used, generating useful feedback that informs future improvements.
Throughout this cycle, external factors like changes to policy, market conditions, and stakeholder feedback shape the design of your products and systems, changing which opportunities you pursue, the outcomes that are important to your stakeholders, how resources are allocated, or whether an initiative should continue at all.
| Area of Work | What's explored | Key activities | Typical outputs |
|---|---|---|---|
| Strategy | Is this worth exploring? | Connect opportunities to organizational strategy; examine value, risks, assumptions, constraints, and alternatives; establish intended outcomes; make and revisit investment and priority decisions | Strategic rationale, opportunity framing, intended outcomes and measures, assumptions, strategic risks, and a decision to invest, adapt, defer, explore further, or stop |
| Dual-track discovery and development | What should we build, and how should we build it? | Research, stakeholder engagement, goal definition, requirements work, backlog refinement, iterative development | Goals, user needs, architecture concerns, backlog items, working increments |
| Deployment and operations | Is the solution working in practice? | Release, monitor, support, measure usage, learn from feedback | Operational data, support insights, improvement backlog, product learning |
Phase 1: Strategy and Framing the Opportunity
New products and systems usually begin with an idea, a problem, or a strategic goal. In the early stages, you tie an initiative to broader business goals and use preliminary research to gauge its value and viability.
The output of strategy and opportunity framing
The output of your work is enough evidence to support investment and delivery decisions such as:
- A clear opportunity statement.
- Connection to organizational strategy and priorities.
- The initial problem or need being explored.
- Early assumptions and risks.
- A preliminary view of affected stakeholders and users.
- Major feasibility, sustainability, governance, or compliance concerns.
- Intended outcomes and initial success measures.
- A decision to proceed, do more exploratory work, or stop.
Phase 2: Dual-Track Discovery and Development
Once you decide the opportunity is worth pursuing, you start to define the needs of the solution in greater detail and start to develop and implement the system.
Many teams use a dual-track approach for this, where ongoing discovery happens alongside development. This allows the team to keep learning and refining what is needed while still making progress toward a working solution.
In the discovery track, you investigate and refine your understanding of the opportunity. This includes researching stakeholder and user needs, exploring possible solution designs, and clarifying what the system needs to support.
In the development track, you implement the solution, often through short iterations lasting one to four weeks. Each iteration produces a small increment that can be developed, tested, and released to users, which is often (but not always) working software. Then, once it's in production, you can evaluate how it's being used to help identify new needs, missing features, or changes to existing functionality.
The two tracks stay connected through frequent feedback loops as developers participate in discovery activities such as user testing and prototype reviews, while product and design stay engaged with development through demos, software reviews, and scope adjustments.
Start a provisional backlog as you frame the opportunity, using it to capture assumptions, questions that need investigating, risks, technical work, and emerging stakeholder needs. Then, continue to refine these items as you learn more through ongoing discovery and development.
Phase 3: Deployment and Operations
Deployment involves releasing software, installing hardware, and making other operational changes so people can start using the solution. As users engage with it, you can see how the solution performs under real conditions and use what you learn to decide what to fix, change or build next.
In many traditional delivery models, developers write software and hand it to a separate operations team to deploy and manage. These handoffs can often create communication gaps, slow release cycles, and deployment problems (Díaz et al., 2021).
Reducing these barriers is one of the main reasons organizations adopt practices like DevOps, which aim to better connect software development and operations through shared responsibility, closer collaboration, automation, and continuous feedback. Together, these practices can help teams deliver changes faster and more reliably, reducing deployment problems, and helping them recover more quickly when failures occur.
Deployment
Deployment and implementation make the solution available and prepare the organization to use and support it. Depending on your initiative, this work may include releasing software, configuring platforms, migrating data, installing hardware, changing processes, training users, communicating what is changing, and establishing ongoing support and governance.
How you approach deployment will depend on factors such as the size and risk of the change, how frequently you release, the number of users affected, and how easily you can recover if something goes wrong.
DevOps aims to make deployment faster, more routine, lower-risk, and easier to recover from. Three practices commonly used to support this are:
- Continuous integration brings code changes together frequently and validates the integrated software through automated builds and tests. This helps you and the team keep the codebase working and supports the frequent, reliable delivery of changes.
- Continuous delivery keeps validated software in a releasable state, allowing you to deploy it to production whenever the organization decides a release is appropriate.
- Continuous deployment extends this process by automatically releasing validated changes to production without a separate manual approval step, allowing improvements to reach users soon after they are ready.
Operations
Operations involve the processes and practices of keeping the solution running, available, and secure. What's needed depends on the risks and demands of the system. For example, a government digital service that handles a high volume of sensitive data across the country may require extensive monitoring, access management, recovery, and incident response plans, while a small internal tool may need a simpler level of support.
Important operational practices typically include the following:
- Monitoring and alerting: Tracking system health, uptime, performance, and errors so your team can detect and resolve issues early.
- Incident response: Following structured processes to investigate, communicate, and fix outages or service disruptions quickly.
- Performance management: Tracking how systems behave under real-world conditions and resolving bottlenecks as traffic or usage evolves.
- Security patching: Regularly updating software and infrastructure to minimize vulnerabilities and maintain a secure environment.
- Infrastructure scaling: Dynamically adjusting resources to support user growth and shifting demand.
- Release management: Coordinating production deployments to minimize risk and ensure safe rollbacks if anything goes wrong.
- Backup and recovery: Maintaining reliable data backups to ensure systems can be fully restored after unexpected failures.
- Access and permission management: Controlling user privileges to securely manage who can view, modify, or administer systems and data.
- Observability: Diagnosing complex problems using logs, metrics, and distributed tracing to follow requests as they move across services.
Feedback and learning
Once a solution is deployed and in active use, feedback and operational data help you understand how it performs in practice and what may need to change in future releases. This information can come from a number of sources including:
- Post-implementation reviews compare actual outcomes with the original business case, and interviews, surveys, and feedback sessions can then help you identify usability problems, workflow issues, and requirements you missed.
- Application telemetry can help you see how people use the system, such as their task completion times, navigation paths, and error frequencies.
- System log analysis surfaces performance bottlenecks, failed transactions, and recurring exceptions in server, integration, and error logs.
- Support ticket analysis can reveal training gaps, confusing workflows, and missing functionality, which can inform change-management priorities, and helps you update backlog with new features and other changes.
- Experimentation. Online experiments, such as A/B or multivariate tests, let you compare how different content, features, or workflows impact user behavior.
Increasing opportunities to learn
Deploying more frequently can deliver the results your stakeholders, users, and organization are looking for sooner, and gather feedback to inform future releases. For example, a team that deploys every two weeks has opportunities to learn from real use twice as often as one that deploys monthly.
References
Brown, T. (2008). Design thinking. Harvard Business Review, 86(6), 84–92.
Díaz, J., López-Fernández, D., Pérez, J., & González-Prieto, Á. (2021). Why are many businesses instilling a DevOps culture into their organization? Empirical Software Engineering, 26(2), Article 25.