​Applied Product Discovery: How We Build Digital Products

Why agile alone isn't enough, and how the 12-week cycle delivers predictable results.

Building digital products is hard. Not because of the technology, but because of the process. We've seen it countless times: talented teams stuck in endless discovery, engineers waiting for decisions that never come, stakeholders frustrated by a lack of visible progress.

The problem isn't agile. The problem is agile without structure.

That's why we developed Applied Product Discovery (APD): a methodology that combines the best of waterfall planning with agile delivery. Plan in quarters, deliver in sprints.

The problem with pure agile

Agile was designed for continuous improvement of existing products. It works brilliantly when you know what you're building and just need to iterate. But when you're creating something new? Pure agile often leads to chaos.

We've seen engineering teams spend 18 months in discovery without writing a single line of production code. We've seen designers create dozens of prototypes that never get built. We've seen stakeholders lose faith because there's no clear timeline, no defined scope, no moment of delivery.

The issue isn't the people. It's the process. Without clear boundaries, agile becomes an excuse for never finishing.

The 12-week cycle

Applied Product Discovery works in fixed 12-week cycles, divided into three phases:

Discovery (weeks 1-2): Define the problem, validate assumptions, align stakeholders. The output is a clear product direction and scope.

Design (weeks 3-4): Create the solution. UX flows, visual design, technical architecture. The output is a blueprint that engineering can build from.

Development (weeks 5-12): Build and ship. Two-week sprints with clear deliverables. The output is working software.

This means four delivery moments per year. Four times stakeholders see real progress. Four times the team celebrates shipping something meaningful.

The Product Triad

Every product needs three perspectives to succeed:

Viability: Is this worth building? The Product Manager owns business alignment, stakeholder management, and prioritisation.

Desirability: Will people want this? The Strategic Designer owns user research, experience design, and interface quality.

Feasibility: Can we build this? The Solutions Architect owns technical decisions, system design, and engineering quality.

These three work as a unit from day one. No handoffs. No finger-pointing. Shared ownership of the outcome.

This is fundamentally different from the traditional model where companies hire a Deloitte for strategy, a Xebia for engineering consultancy, and an offshore team for development. Three vendors, three agendas, and when things go wrong, everyone points at everyone else.

Why this works

Clarity before commitment. The Discovery and Design phases create alignment before development starts. Everyone knows what we're building and why. Surprises are minimised.

Fixed capacity, flexible scope. The team size and timeline are fixed. What varies is scope. This forces prioritisation and prevents feature creep.

Regular delivery. Every 12 weeks, something ships. This builds trust, creates momentum, and allows for course correction.

Integrated expertise. The Product Triad ensures all three dimensions (viable, desirable, feasible) are considered in every decision.

Ready to talk?

If you're building a digital product and frustrated by endless discovery or unpredictable timelines, we should talk. Not a sales pitch. Just a conversation about what you're trying to achieve and whether Applied Product Discovery might help.

Reach out at info@miyagami.com!