An eight-step process that takes a digital product from an idea to a release real users rely on, with the decisions and evidence needed at each step.
In short
A good product development process for digital products moves from understanding the problem, through testing solutions cheaply, to releasing small working increments and measuring their effect. In practice that means discovery, definition, prototyping, an MVP, continuous delivery and follow-up, with a clear decision at each step to continue, change direction or stop.
Most digital products that fail do not fail because the code was bad. They fail because the team built the wrong thing, built too much before learning, or released and never checked whether it worked. A clear product development (produktutveckling) process prevents all three. This guide from Devies, a Gothenburg-based product and engineering consultancy, is for product owners, CTOs and business leaders taking a new app, platform or service from idea to release.
What is a product development process for digital products?
A product development process is the sequence of activities and decisions that turns an idea into a released product and keeps improving it. For digital products it is iterative: each step produces evidence that decides whether, and how, to continue.
Two well-known models shape most modern processes. The Design Council's Double Diamond, codified in 2003, describes four phases: discover, define, develop and deliver, first widening to understand the problem and then narrowing to a solution. The UK government's service manual uses discovery, alpha, beta and live, and is explicit that you should not start building during discovery. The eight steps below combine both with modern software delivery practice.
Eight steps from idea to release
Each step ends with a decision. If the evidence is weak, it is cheaper to change direction now than later.
- Frame the opportunity. Write down the problem, who has it, why it matters to the business and how you will know you succeeded. Keep it to one page. Decision: is this worth a discovery?
- Discover. Talk to users, observe their work, review data and existing systems, and map constraints such as regulation, integrations and security. The service manual suggests discovery often takes four to eight weeks, though purpose should set the length. Decision: is the problem real and worth solving?
- Define. Turn findings into a sharp problem statement, target users, success measures and the riskiest assumptions. Decide what the product will not do.
- Prototype and test. Build cheap prototypes of the riskiest parts and test them with real users. Expect to throw much of this away. Our comparison of prototype, MVP or pilot helps choose the right vehicle. Decision: which solution do we build?
- Plan the architecture and the first release. Choose the technical foundations: platform, integrations, data model, security and hosting. Define the scope of the first release around one core user job.
- Build in small increments. Develop in short cycles with working software at the end of each. Automate tests and deployment from the first week, so releasing is routine rather than an event.
- Release to real users. Start with a limited group, such as a private beta, then widen. Monitor errors, performance and usage from day one.
- Measure and iterate. Compare outcomes with the success measures from step 3. Decide what to improve, extend or remove, and feed it back into the backlog.
Step 1 to step 4 are mostly product design and research work; step 5 to step 8 are mostly engineering. Treating them as one continuous process with the same team, rather than a handover from designers to developers, is what keeps the product coherent.
Who should be on a digital product team?
A digital product team needs a small, stable group that covers product decisions, design and engineering, working together from discovery to release. A typical core team:
Role
Main responsibility
When most active
Product owner
Main responsibility
Owns the problem, priorities and success measures
When most active
Throughout
Product or UX designer
Main responsibility
Research, flows, prototypes, interface design
When most active
Discovery to first release, then ongoing
Tech lead or architect
Main responsibility
Architecture, technical risk, quality standards
When most active
From define onwards
Developers
Main responsibility
Build, test and release the product
When most active
From prototype onwards
Business or domain expert
Main responsibility
Rules, regulation and context of the domain
When most active
Discovery and define, then on call
QA or test specialist
Main responsibility
Test strategy and automation
When most active
From build onwards, often shared
Small teams move faster. Devies built the SEVR Insights accounting platform with three developers and one designer, going from concept to a production-ready platform in four months. The team used an AI-first process with agents for groundwork across design, development and testing, while SEVR contributed accounting expertise and product vision, and daily syncs and weekly planning kept decisions moving.
Where does product design fit in?
Product design is the work of deciding what the product does and how it works for users, and it runs through the whole process rather than sitting in one phase. In discovery it is research; in definition it is framing; in prototyping it is flows and interfaces; after release it is learning from usage.
Three practices keep design and engineering aligned:
- Shared discovery. Developers join user interviews and testing, so technical constraints and opportunities surface early.
- A design system. Reusable components in design and code mean screens are consistent and faster to build.
- Continuous testing with users. Short test rounds every few weeks catch problems before they become expensive.
Our guide to the product design process from problem to shipped feature goes deeper into the design side.
How do you know the process is working?
You know the process works when the team releases often, the releases are stable, and the product's outcome measures improve. Measure both delivery and outcomes.
For delivery, the DORA research programme defines five software delivery performance metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. They show whether the team can ship safely and often. Our guide to DevOps for product teams explains how to start measuring them.
For outcomes, use the success measures defined in step 3: adoption, task completion, time saved, conversion or revenue. A team that ships every week but never moves these numbers has a delivery process, not a product process.
Common warning signs:
- Discovery is skipped "because we already know what users want".
- The first release keeps growing and the date keeps moving.
- Releases are rare, large and stressful.
- Nobody looks at usage data after launch.
- Design and development work in separate phases with a handover document between them.
Keep reading
From our work
Client Case: SEVR InsightsLearn how Devies and SEVR Insights built an AI accounting platform in four months using an AI-first development process that reached 85,000 users.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What are the stages of product development for software?
Most processes for software follow the same arc: framing the opportunity, discovery with users, defining the problem and success measures, prototyping and testing solutions, planning the architecture and first release, building in small increments, releasing to real users and measuring the outcome. Models such as the Double Diamond or the discovery, alpha, beta and live phases describe the same idea with different names.
How long does it take to develop a digital product?
It depends on scope, complexity and the team, but a focused first release of a new digital product often takes from a few weeks to several months. Discovery typically takes four to eight weeks. Teams that keep the first release narrow, automate testing and deployment early and work with a small, stable team usually reach real users much sooner than teams that try to launch everything at once.
What is the difference between product development and product design?
Product development is the whole process of taking a product from idea to release and improving it afterwards, including research, design, engineering, testing and launch. Product design is the part concerned with what the product does and how it works for users: research, flows, prototypes and interfaces. In a good digital product team, design runs throughout development rather than as a separate phase.
Should we use agile or a phased process for product development?
Use both at different levels. A phased frame, such as discovery, prototyping, MVP and release, sets the decision points and the evidence needed to continue. Within each phase, work in short agile cycles with working results at the end of each. Pure phase-by-phase delivery with big handovers learns too slowly; pure iteration without decision points can drift without ever proving value.
