Welcome to a subscriber-only edition of The Overlap! Subscribers get a paid edition of The Overlap, in addition to the free editions. We’re trying this until October 27! More details here.
Thank you for subscribing thus far. I hope you enjoy this one!
I used to facilitate a lot of journey mapping workshops. My first two journey mapping workshops generated lots of great ideas! But I still felt like it wasn’t clear how we would deliver those ideas.
“We’d love to have a ‘contact customer support’ button! Actually wait, we're still hiring a customer support team…”
“We spent a lot of time in our workshop exploring social features! But we learned later on it would take too long to build. I wish we knew that building out social features is time-consuming. That way we could’ve focused our exploration on other ideas.”
“We want our customers to receive a new subscription the moment they run out! But we’re still testing how supply levels can get detected.”
I realized that I over-indexed the workshop on the user experience and under-indexed on the organizational experience. Lots of amazing ideas. But which ones can we feasibly pursue given our current resources? So in my next few journey mapping workshops, I started to hold more space for how we as an org can deliver on those ideas.
A solid backstage is necessary for a great experience
A mentor of mine (Conor!) would encourage me to help teams think through both the front stage and the backstage of their product.
Front stage: all the aspects of your product that a user can see and interact with.
Backstage: all the things the organization does behind the scenes to deliver a great experience.
Teams often think about the front stage, but not the backstage.
Example: Sales promises an enterprise customer a new feature. Product team gets upset because that new feature is hard to build and solves an obscure use case.
Or, they’ll think about the backstage, but not the front stage.
Example: Engineering and product push back on most ideas the new Creative Director shares. “They’re all too complex to execute.” The Creative Director is just trying to do their job: reimagine the product’s brand, but is finding it difficult to win over product and engineering.
I’ve learned that it’s great to help teams think about both.
I don’t think I’m the only one who has this hunch.
Sarah Gibbons says that improving an organization’s employee experience improves the customer’s experience. She calls this service design:
As services grow in sophistication, so does the need to support them. Complex user experiences often break due to an internal organizational shortcoming — a weak link in the ecosystem. For example, when was the last time you called a support hotline, gave your personal information, only to be transferred to another agent asking you to repeat the exact information you had already provided? This pain point stems from an internal process flaw that was produced by a lack of service design.
Similarly, John Cutler says that savvy companies think about how to remove friction for both the customers and the business. When launching a product, you have to consider organizational complexity, but not let the complexity solely dictate what your product should be.
So, build a shared understanding of the frontstage experience. And then build a shared understanding of how the backstage experience helps you put on a great frontstage experience.
Both the frontstage and backstage should inform each other. If the frontstage idea is difficult to pull off, figure out what needs to happen backstage to pull it off. Or reduce the difficulty (while still putting on a great show).
Ok, I get the metaphor. So how do I do this?
There’s a great tool there called service blueprints.
Learn about them here and here.
Then, facilitate a service blueprint workshop with your team. (I like this Figjam template. Simple!)
What I’m Reading
What org design content is out there that isn’t an article?
Content on org design is usually an article (mine included 😅). It’s great but sometimes dry. What org design content is out there that isn’t an article?
Add any here! I’d love to see more!
See you next week,
–tim
Yesterday I shared a brief explanation of what a service blueprint is to an API dev team. They are surrounded by technical architecture schemes that clarify the "how", but we need to map the "what" and the "why" too. The language of on the side of product/business is not aligned to the language of the dev team and this is causing a lack of clarity.
We are in the process of hunting down how many existing, client-facing "productivised" digital services are out there (52, and probably counting...) in order to design the best API architecture, treating the API platform itself as a product (also, we have of course to deal with legacy systems).
We really need something like a service blueprint to get through it.