There are a few ways these meetings might be organized depending on where we are in the design-development process.
- early concept: help me think about the problem
- late concept: help me choose among these ideas and develop one
- early detail: this is where we are going, what caveats remain?
- late detail: here’s a the detail, what questions do I need to address?
These depend on the thought that there are a few phases/horizons to product design work, namely
- Problem Framing (aka Research or Horizon 3), in which we learn about the challenges and needs of users to understand and select a problem to go after with concepts,
- Concept (or Horizon 2), in which we develop concepts and select among them with the help of users and engineering, and
- Detail (or Horizon 1), in which we develop the selected concept and test the fitness of our more detailed work with users as we go.
It’s a common anti-pattern that engineering gets involved only when we are in detail, but we’d like to pull them into the other phases to be informed about the available problems and to help us develop and select among concepts.
Some Agile purists will decry this phasing as anti-agile, but that requires a blinkered view of what Agile means, which often comes about when one confuses Scrum for Agile. (The dirty little secret of Scrum is that there’s a lot of hand-waving about the large quantity of work that needs to happen outside of sprints to make Scrum possible.)