The previous posts developed a conceptual apparatus - state spaces, planning, design, grammars - and established the distinction between constructing a domain and navigating within one. This post uses that apparatus as a lens for examining something more practical: the artefacts that different professional traditions produce when they set about creating services and products for people. Boland and Collopy (2004) argue that "our vocabulary of representations is critical in determining how well or poorly we do"; the representations a field relies upon shape the questions it can ask, the distinctions it can draw, and the gaps it is structurally unable to see. Product management and service design both address the challenge of creating things for people, but they do so through markedly different representational traditions - different artefacts, different structures, different implicit assumptions about what matters - and examining those traditions through the lens of state spaces and planning reveals what each makes explicit, what it leaves implicit, and where the structural gaps lie.
Schön (1983) characterised design as a reflective conversation with the situation, in which the designer's representations serve as the medium through which that conversation takes place; the designer makes a move, the situation "talks back" through the representation, and the designer responds. On this account, the character of the representation is not merely a presentational choice but a constitutive one: the representation determines what the situation can say back. A roadmap speaks in the language of sequence and priority; a journey map speaks in the language of experience and emotion; neither speaks in the language of state transitions or formal promises. The question is what these representational traditions reveal when examined together, and what a more complete vocabulary might look like.
Product Management's Representational Toolkit
Product management has developed a well-established set of representations, each addressing a different aspect of the work. The roadmap shows what will be built over time, typically structured around time horizons - now, next, later, or quarterly and yearly divisions - with features or initiatives plotted against those horizons and sometimes grouped by theme or strategic goal. It makes sequence and priority explicit; it provides a rough sense of scope and timing. But it says little about how features connect to user outcomes, what states users occupy before and after the feature is delivered, or what dependencies and preconditions govern the relationships between items (Cagan, 2008). The roadmap is, in state space terms, a trajectory through feature space with no explicit model of the space itself.
The backlog operates at a more granular level. It is an ordered list of work items, each typically expressed as a user story in the canonical form - "as a [user type], I want [capability], so that [benefit]" - and prioritised so that items at the top are delivered first (Patton, 2014). The format makes the work to be done explicit, establishes relative priority, and preserves a user perspective by specifying who wants the capability and why. But the format leaves the relationships between stories largely unspecified; it does not model the state space of the product, and it says little about what completing a given story actually changes in the system's overall configuration. Each story is a local intervention; the backlog as a whole does not compose into a coherent model of what the product will become.
Acceptance criteria come closest to formal state specification within product management practice. The Given/When/Then structure drawn from behaviour-driven development - "given [context], when [action], then [outcome]" - is essentially a precondition/action/effect triple, and in that sense it specifies local state transitions with some precision. But criteria are written per story, not as a complete state model; there is no guarantee of exhaustiveness, no mechanism for checking whether the set of criteria covers all relevant states, and no way to reason about how criteria from different stories interact. OKRs (Objectives and Key Results) operate at a higher level still, structuring goals as qualitative objectives paired with quantitative measures of success (Doerr, 2018). They are closer to promise thinking than other product management artefacts - they represent commitments to outcomes - but the commitments are internal (team to organisation) rather than user-facing, and the causal model connecting activities to the outcomes they are supposed to produce remains implicit.
Taken together, product management's representations are fundamentally planning-oriented in the sense developed earlier in this series: they assume a defined problem space and concern themselves with what to build and when, not with what the problem is or whether the problem space itself has been adequately understood.
Service Design's Representational Toolkit
Service design's representational traditions are oriented differently. The journey map shows the user's experience over time, typically structured as phases or stages - discover, consider, purchase, use, advocate - with touchpoints, emotional highs and lows, and channels mapped within each phase (Kalbach, 2016). It makes the user's perspective explicit; it foregrounds emotional experience and the multi-channel nature of service encounters. But it leaves the triggers for phase transitions largely unspecified, models user states imprecisely (what exactly constitutes being "in consideration"?), and says nothing about what the service provider does unless combined with a blueprint.
The service blueprint, originally proposed by Shostack (1984) and subsequently developed by Bitner, Ostrom and Morgan (2008), shows the service from both provider and user perspectives, structured in layers separated by lines of visibility and interaction: physical evidence, customer actions, frontstage actions, backstage actions, and support processes. It makes the production structure of the service explicit - what is visible to the user and what is not, and how user-facing activities depend on backstage processes. Blomberg and Darrah (2015), however, observe that one of the persistent challenges for blueprinting is to circumscribe and precisely render the design space while simultaneously acknowledging the open-ended, situated nature of service encounters; the blueprint, by its nature, tends to present services as more orderly and sequential than they are in practice. Blueprints do not model states and transitions formally, do not specify preconditions for actions, and tend to treat error paths and exceptions as secondary concerns if they address them at all.
Personas represent user types through composite characters - demographics, goals, motivations, pain points, behaviours - and serve primarily as empathy-building and communication tools. They make user diversity and motivational context explicit, but they do not model how different personas move through the service, what states each persona can occupy, or how to prioritise when the needs of different personas conflict. Service ecology maps show the actors and relationships in a service ecosystem - stakeholders, flows, value exchanges - making the multi-actor nature of services visible but leaving dynamics over time, system states, and the evolution of relationships largely unaddressed.
Blomkvist (2014) argues that service design representations function as externalisations that support design cognition, but that the character of those externalisations also constrains what designers can think about; representations that foreground experience and emotion tend to background structure and specification, and vice versa. Polaine, Løvlie and Reason (2013) make a similar observation: service design's tools are powerful for understanding and communicating the experiential dimensions of services but are considerably less equipped for specifying the structural and operational dimensions that govern implementation. Service design's artefacts are, in the terms of this series, more design-oriented than product management's - they are inquiry tools for understanding what the problem is before attempting to solve it - but they are also less operational. One cannot execute a journey map; it is a thinking tool, not a specification.
Through the State Space Lens
The apparatus developed in earlier posts provides a sharper way of describing what these representational traditions make visible and what they conceal. With respect to state space explicitness, product management implies state through features - each feature in a backlog implicitly assumes a before-state in which the user lacks a capability and an after-state in which the user possesses it - but the state space itself is never modelled. Features are points, not regions in a defined space; the closest product management comes to explicit state modelling is through feature flags and A/B tests, which are implementation mechanisms rather than design representations. Service design implies state through phases; journey phases like "discover" and "consider" function as states, but they are suggestive rather than precise. What event moves someone from consideration to purchase? How are concurrent processes - the user's emotional journey, the provider's backstage activities, the regulatory context - modelled as interacting state spaces? Service blueprints show concurrent activities but do not model how those activities combine into system states.
With respect to transition specification, neither tradition provides formal mechanisms. There is no standard product management artefact for expressing that when a particular event occurs, the user moves from state A to state B with specified preconditions and effects; user flows and wireframes show sequences but without the formalism that would make transitions verifiable. Journey maps show movement between phases, but the triggers are often implicit or expressed narratively rather than formally; blueprints show process sequences but without state change semantics. Neither tradition has adopted statechart-level rigour, and neither has developed a vocabulary for expressing the concurrent, hierarchical, and conditional nature of service state transitions.
With respect to promise structures, product management is feature-centric rather than promise-centric; the backlog is a list of capabilities to be delivered, not a network of mutual commitments between provider and user. OKRs come closer - they are commitments to outcomes - but the commitments are organisational rather than user-facing. Service design has implicit promise structures embedded in its representations; blueprints show what providers do for users, which implies promises, and the emotional journey mapped alongside implies experience commitments. But the promise structure is never made explicit. There is no equivalent, in either tradition's standard toolkit, to Iqbal's (2018) 16x frame for articulating the four dimensions of service promise - outcomes, experiences, performances, affordances - and their constituent factors.
What the Gaps Reveal
The analysis reveals structural gaps in both traditions that become visible only when the state space apparatus is applied. Product management lacks an explicit state model; features are defined but the state space they inhabit is not, which makes it difficult to reason about what states are possible, whether features conflict, or what happens in the spaces between features. It lacks transition specification; user flows show sequences but without preconditions and effects, one cannot verify whether a transition is always valid, what exceptions require handling, or how concurrent transitions interact. And it lacks promise structure; the relationship between provider and user is implicit, which obscures what the product is actually committing to and what the user must provide in return.
Service design lacks executable models; journey maps and blueprints are thinking tools, not specifications, and this creates translation gaps between what designers envision and what developers implement, verification gaps that make it difficult to assess whether a design is complete or consistent, and testing gaps that prevent simulation of the service before it is built. Overkamp (2019) documents the difficulty of translating service design concepts into implemented services, finding that the gap between design representation and realised service is not merely a communication problem but a structural one - the representations do not carry enough information to constrain implementation in the ways that would be necessary. Service design also lacks formal semantics; phases and touchpoints do not have precise definitions, which permits different interpretations by different stakeholders and creates persistent ambiguity about edge cases. And it lacks compositional grammar; unlike Wilkinson's grammar for graphics or Iqbal's framework for services, there is no generative grammar for journey maps or blueprints that would provide systematic validity checking or compositional rules.
Toward Synthesis
What would it look like to combine the strengths of both traditions while addressing these structural gaps? From product management, one would retain the discipline of prioritisation (the recognition that not everything can be done at once), the Given/When/Then structure that comes closest to formal state specification, and the iterative delivery model that permits learning and adjustment. From service design, one would retain the commitment to user-centred inquiry (understanding before building), the multi-actor perspective that sees the service ecosystem rather than the individual user alone, and the attention to emotional and experiential dimensions that product management's representations tend to flatten.
From the conceptual apparatus developed across this series, one would add explicit state space modelling, transition specification, promise structures, and grammar thinking. The synthesis might produce artefacts that do not yet exist in either tradition's standard toolkit: journey maps enriched with formal state semantics in which each phase is a state, transitions have triggers and guards, and concurrent aspects are modelled as orthogonal regions; backlogs reframed around promises rather than features, specifying what the provider commits to under what conditions and with what expected effect; blueprints that can be simulated so that given a particular customer action, the backstage processes that fire and the state changes that result can be traced; and compositional patterns that can be combined according to explicit rules and validated for completeness.
The gap between designed services and enacted services - which Shostack (1984) identified decades ago and which persists in contemporary practice - exists partly because the representational traditions of both product management and service design do not bridge it. We design in one vocabulary, journeys, experiences, and touchpoints, and build in another, features, stories, and code; the translation between these vocabularies loses structure. A representation that made state spaces explicit, specified transitions formally, and articulated promise structures clearly might help close that gap; it would be harder to use than a journey map, certainly, but it might also be considerably harder to misinterpret.
Next: "The Grammar of Graphics: Wilkinson's Contribution" - how Leland Wilkinson created a generative grammar for statistical graphics, and what it reveals about what grammar-based design enables.
References
Bitner, M.J., Ostrom, A.L. and Morgan, F.N. (2008). Service Blueprinting: A Practical Technique for Service Innovation. California Management Review, 50(3), 66-94.
Blomberg, J. and Darrah, C. (2015). An Anthropology of Services: Toward a Practice Approach to Designing Services. Morgan and Claypool.
Blomkvist, J. (2014). Representing Future Situations of Service: Prototyping in Service Design. PhD thesis, Linköping University.
Boland, R. and Collopy, F. (2004). Managing as Designing. Stanford University Press.
Cagan, M. (2008). Inspired: How to Create Products Customers Love. SVPG Press.
Doerr, J. (2018). Measure What Matters: OKRs. Portfolio/Penguin.
Iqbal, M. (2018). Thinking in Services: Encoding and Expressing Strategy Through Design. BIS Publishers.
Kalbach, J. (2016). Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagrams. O'Reilly Media.
Overkamp, T. (2019). How Service Ideas Are Implemented: Ways of Framing and Addressing Service Transformation. PhD thesis, Linköping University.
Patton, J. (2014). User Story Mapping. O'Reilly Media.
Polaine, A., Løvlie, L. and Reason, B. (2013). Service Design: From Insight to Implementation. Rosenfeld Media.
Schön, D. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books.
Shostack, G.L. (1984). Designing Services That Deliver. Harvard Business Review, 62(1), 133-139.