liveBook · Manning

Continuous discovery

As explained in Architecture Modernization: Socio-technical alignment of software, strategy, and structure

Continuous discovery is an ongoing product-development practice of regularly engaging customers to learn about their needs and evaluate ideas throughout delivery.

Continuous discovery is an ongoing product-development practice of engaging customers regularly, learning about their needs, and evaluating ideas throughout delivery. Frequent contact keeps user needs visible and enables rapid feedback on proposed improvements. section 8.2.6

Use the practice as an empowered, team-level activity:

  • Talk with customers weekly rather than treating research as a one-off project phase. section 8.2.6
  • Adopt co-creation by testing ideas or sketches early, before completed features or mock-ups limit the ability to change direction. section 8.2.6
  • Give the team authority to act on insights, using product, design, and technology representatives for important decisions. section 8.2.6

Modernizing the Energy Performance of Buildings Register

A UK government department replaced an expensive external-supplier arrangement with an in-house, user-centric team. Within two years, the service was live, improving through multiple daily deployments; satisfaction increased and costs halved. User research and feedback supported the evolutionary modernization approach. section 8.2.10

During modernization, combine conversations with real users with evidence from existing features, logs, and metrics. This reveals unnecessary, inefficient, or unusable features and helps establish requirements before technology decisions. section 8.6

How Architecture Modernization: Socio-technical alignment of software, strategy, and structure covers it

How deep it goes
Explains weekly touchpoints, validation versus co-creation, and trio decisions without detailing a full implementation recipe.
Examples
Uses sketches, feature feedback, weekly conversations, and the Energy Performance of Buildings Register modernization.
What it assumes
Assumes a product team can access users and make decisions; begins feedback before mock-ups rather than requiring finished features.
What you can do after
Apply it via weekly user conversations, early idea testing, and empowered product-design-technology decisions.
How it connects
Connects user research, continuous delivery, product teams, EventStorming, Domain Storytelling, and domain modeling.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Architecture Modernization: Socio-technical alignment of software, strategy, and structure. The section links point to the parts of the book it draws on.