Playback speed
×
Share post
Share post at current time
0:00
/
0:00
Transcript

Note: if you’re a fan of the practical advice I dispense in this newsletter, read more about how you can work with me as a consultant / coach and let’s collaborate - I’m taking on new clients as a strategy advisor and fractional CPO for companies that are scaling - you can reach out via LinkedIn or just click the message button below


I did a video episode with Jon Harmer from Google recently on critical user journeys (CUJs), and during the conversation we hit on an interesting angle that I wanted to share more around: sacred workflows.

What is a sacred workflow? In your product, it’s THE golden path that you want / need every user to travel - the most critical of all user journeys. It likely is the foundation for all other workflows in your product, the flywheel through which all adjacencies converge, and the core driver of revenue generation. It’s the thing that you have all sorts of reliability / performance / quality monitoring set up around, and the trigger for people getting paged when there’s an issue. In short, it’s a really, really big deal.

But then why don’t all product companies treat it that way? Why are some organizations willing to take the risk of upsetting their core user base by playing with the sanctity of this workflow?

The answer, I believe, has to do with how deeply the tribal knowledge around this workflow is codified and ritualized. When you’ve had to grind to find product-market fit (PMF), that learning needs to be preserved so that you can continue to compound on that initial insight as PMF shifts over time.

In the video example above, I talk about the customer experience bar raiser program at Amazon, which among other things kept an eye on the order pipeline (the sacred workflow of Amazon.com). It was essentially a committee made up of the folks who had worked on all major iterations of the checkout flow, who were now helping steer newbies like me who wanted to introduce changes. From the outside, it may sound like an onerous process and gatekeeping, but as someone new to Amazon, it was a crash course in the key learnings that had helped grow the site into the leading e-commerce platform. At some point, someone at Amazon had the foresight to realize that it would be a waste of time for the company and friction for users if new product development didn’t take advantage of best practices learned over the years.

Since that instance ~ 15 years ago, I’ve always been observant when I join new companies around how they preserve canonical product insights and educate new employees on the sacred workflow. For example, having worked at Twitter (I refuse to call it “X”), I noticed early that there was no alignment around what the heart of the service was (this is a longer, future post); some people thought it was creator broadcasting, others saw it as user consumption, and even more focused on advertising as the actual revenue driver. But the fact that there was no company-wide alignment or education around the sacred workflow meant that changes were ideated on and introduced to users that ultimately were wasted product calories. Further, for a company trying to scale revenue and establish itself as a public business, it was very difficult to reason about business continuity, test coverage, service monitoring, latency improvements, and capacity planning when “all features matter”.

Over the last several years, operating as a product executive, I’ve come to the realization that it’s now my job to introduce rituals and best practices around the sacred worfklows of the products in my portfolio. When I joined Amplitude, partly out of necessity as someone onboarding remotely during the pandemic, I picked the brains of early employees to understand which customer conversations had led to the building of the core, differentiated feature set (the most used and demoed ones). I was pleasantly surprised to learn that a lot of these insights had been recorded either verbatim in notes or research calls. I was able to actually collate them together into a reading / play list which new PMs could then consume as they onboarded; in just a couple of hours, you could watch the greatest hits (in terms of customer insights) that had taken a decade to play out in real time. As you accumulate knowledge bills in a product organization, the most potent ones should be around the sacred workflow.

One angle I’m still exploring is how to create an Amazon-style culture around the sacred workflow. That to me is a final and necessary step to ensure that the sacred workflow is maintained by future employees once the old guard is gone The original product team being around to caution and direct new builders isn’t sustainable or scalable; Amazon was an anomaly in that way. I’m a big fan of the brain trust concept that Pixar apparently employs to ensure solid storytelling, and I think techniques like that down to “pass down” tribal knowledge are how you ensure future PMs don’t repeat the mistakes of the past.

If you enjoyed this post, please consider subscribing (and if you’re already a free subscriber than consider upgrading to a paid plan to get access to exclusive content and community).

As always, I’d love to hear from readers about their experiences with sacred workflows - please chime in via comments👇 or join the chat via the Substack app.


further reading / references


childish drawing / interpretation


Note: if you’re a fan of the practical advice I dispense in this newsletter, read more about how you can work with me as a consultant / coach and let’s collaborate - I’m taking on new clients as a strategy advisor and fractional CPO for companies that are scaling - you can reach out via LinkedIn or just click the message button below

Discussion about this podcast

Run the Business
Run the Business
Build. Ship! Repeat?
Listen on
Substack App
RSS Feed
Appears in episode
Ibrahim Bashir