Four pillars, one bridge.

We didn't invent a methodology: we combine frameworks proven in industry and academia, and adapt them to small teams that build and run what they design. Every phase ends in a decision you make, with evidence in hand.

Where each phase comes from.

Our four phases map onto the frameworks used by the largest consultancies and product teams. This table shows the correspondence.

Binary BridgesDouble Diamond[1]Stage-Gate[2]Delivery and operations[15]
01 UnderstandDiscoverDiscovery and scoping (stages 0 and 1)Hypothesis and baseline
02 DesignDefine and developBusiness case (stage 2)Lean Inception and minimum viable product
03 BuildDeliverDevelopment, testing and validation (stages 3 and 4)Scrum and the build-measure-learn loop
04 OperateOutside the diamond: starts after deliveryLaunch and post-launch review (stage 5)SRE and DORA metrics

What happens in each phase.

  1. Understand

    1 to 2 weeks

    Turn a hunch into a written, measurable problem.

    What we do

    • Interviews with the people running the process, not only the ones approving it
    • A map of the current process and the systems it touches
    • A review of the available data and its quality
    • A baseline: what the problem costs today, in time or money

    What you get

    • A diagnosis with the problem and the measured baseline
    • A map of systems, data and risks
    • An honest recommendation: build, buy, or do nothing
    Your team
    One business owner and access to the people doing the work, about 4 hours a week.
    Decision point
    You decide whether the problem is worth the investment. If it isn't, you keep the diagnosis.

    Frameworks

    • Double Diamond: discover[1]
    • Stage-Gate: discovery and scoping[2]
    • Hypothesis-driven problem solving[5]
    • Design thinking: inspiration[3]

    Templates and artefacts

    • Issue tree[5]
    • Answer-first diagnosis (pyramid principle)[6]
    • Current-state service blueprint[9]
    • Business and data understanding (CRISP-DM), for AI and data projects[14]
  2. Design

    2 to 3 weeks

    Decide what to build, what not to, and how we'll know it worked.

    What we do

    • Solution architecture, with technical decisions written down
    • A clickable prototype tested with real users
    • An incremental delivery plan, most valuable first
    • Cost and time estimates per increment

    What you get

    • Architecture and experience in a single document
    • A validated prototype
    • A delivery plan with scope, cost and success metrics
    Your team
    Weekly review sessions and sign-off on scope.
    Decision point
    You approve architecture, scope and budget before the first line of code.

    Frameworks

    • Double Diamond: define and develop[1]
    • Human-centred design (ISO 9241-210)[4]
    • Lean Inception[8]
    • Stage-Gate: business case[2]

    Templates and artefacts

    • Future-state service blueprint[9]
    • C4 architecture diagrams[11]
    • Architecture decision records (ADR)[10]
    • Minimum viable product canvas[8]
  3. Build

    2-week iterations

    Working software in production from the first iterations.

    What we do

    • Small, tested increments deployed every iteration
    • Automated tests and code review on every change
    • AI evaluated against your data, with quality metrics before release
    • A demo every two weeks of what already works

    What you get

    • Software in production on your infrastructure or the cloud you choose
    • Code in your repository from the first commit
    • Technical and user documentation, current with every release
    Your team
    A product owner who prioritizes and joins the fortnightly demo.
    Decision point
    Every two weeks you see working software and decide what comes next, or whether to stop.

    Frameworks

    • Scrum[13]
    • Build-measure-learn (Lean Startup)[12]
    • Double Diamond: deliver[1]
    • Stage-Gate: development, testing and validation[2]

    Templates and artefacts

    • Definition of done[13]
    • Model evaluation before deployment (CRISP-DM)[14]
    • DORA delivery metrics[15]
    • Living ADRs, updated with every decision[10]
  4. Operate

    Ongoing

    Keep the solution delivering value after we leave.

    What we do

    • Monitoring, alerts and system health dashboards
    • Measurement against the day-one baseline
    • Training and handover to your team
    • Support and evolution under clear service agreements

    What you get

    • A dashboard with the impact measured against the baseline
    • Runbooks for every foreseeable incident
    • Access, accounts and knowledge in your company’s name
    Your team
    The people who will run the solution, during handover.
    Decision point
    You decide whether your team carries on alone or we continue with support.

    Frameworks

    • Site Reliability Engineering (SRE)[16]
    • DORA research program[17]
    • Stage-Gate: post-launch review[2]

    Templates and artefacts

    • Service level objectives (SLO) and error budgets[16]
    • Runbooks[16]
    • Blameless postmortems[16]
    • Delivery metrics dashboard[17]

The same frameworks, without the overhead of a large firm.

These are the practices of global firms we adopt, and where they appear in our method. We have no commercial relationship with these firms: we cite their published frameworks.

Bibliography.

APA format, 7th edition. Links checked in September 2026.

  1. Design Council. (2019). Framework for innovation: Design Council's evolved Double Diamond. https://www.designcouncil.org.uk/our-resources/framework-for-innovation/
  2. Cooper, R. G. (1990). Stage-gate systems: A new tool for managing new products. Business Horizons, 33(3), 44–54. https://doi.org/10.1016/0007-6813(90)90040-I
  3. Brown, T. (2008). Design thinking. Harvard Business Review, 86(6), 84–92. https://hbr.org/2008/06/design-thinking
  4. International Organization for Standardization. (2019). Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems (ISO 9241-210:2019). https://www.iso.org/standard/77520.html
  5. Rasiel, E. M. (1999). The McKinsey way. McGraw-Hill.
  6. Minto, B. (2009). The pyramid principle: Logic in writing and thinking (3rd ed.). Pearson Education.
  7. Sheppard, B., Sarrazin, H., Kouyoumjian, G., & Dore, F. (2018). The business value of design. McKinsey Quarterly. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-business-value-of-design
  8. Caroli, P. (2022, February 22). Lean inception. martinfowler.com. https://martinfowler.com/articles/lean-inception/
  9. Shostack, G. L. (1984). Designing services that deliver. Harvard Business Review, 62(1), 133–139. https://hbr.org/1984/01/designing-services-that-deliver
  10. Nygard, M. (2011, November 15). Documenting architecture decisions. Cognitect. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  11. Brown, S. (n.d.). The C4 model for visualising software architecture. https://c4model.com/
  12. Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Crown Business. https://theleanstartup.com/
  13. Schwaber, K., & Sutherland, J. (2020). The Scrum guide. https://scrumguides.org/scrum-guide.html
  14. Chapman, P., Clinton, J., Kerber, R., Khabaza, T., Reinartz, T., Shearer, C., & Wirth, R. (2000). CRISP-DM 1.0: Step-by-step data mining guide. SPSS.
  15. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps. IT Revolution Press. https://itrevolution.com/product/accelerate/
  16. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2016). Site reliability engineering: How Google runs production systems. O’Reilly Media. https://sre.google/sre-book/table-of-contents/
  17. DORA. (n.d.). DORA research program. Google Cloud. https://dora.dev/

Shall we start by understanding your problem?

The first phase is short and ends with a diagnosis that is useful even if we go no further together.

Book a conversation