Think End to End
Photo by Chris Leipelt on Unsplash
“Don’t ship the org chart” is one of my favorite sayings in product management. I first heard it from Ken Norton and considered its application only in terms of team structure. But I recently heard product designer Kim Goodwin talk, and the phrase took on new meaning. She too was talking about silos, but this time from the customer’s perspective.
“Think about the worst user experiences you’ve ever had. They were probably because you were being passed from somebody’s area of responsibility to someone else’s” - Kim Goodwin
Of course, no organization wants to create bad experiences, so why do they? Well, almost as soon as companies are formed, specialization begins. Artificial boundaries are set up between people and departments in search of higher performance.
Organizations become so compartmentalized that in most companies, no one aside from the CEO owns the overall customer experience. Individuals working inside the machine are just touching a small isolated piece of the puzzle. Disjointed incrementalism becomes the norm as anything else would require a distinct investment in coordination.
"Specialization is for insects." — Robert A. Heinlein
In software development, someone eventually has to put their hands on a keyboard. On most teams, this means shifting from ideas to clearly assigned ownership over specific feature areas. As a team focuses in on one detailed area, they naturally defocus the big picture. Our gaze narrows and we massage each pixel and interaction within our circumscribed scope.
In transitioning our vision from the whiteboard to the factory floor, we gain something tangible (code) but can lose our bearings. We forget why we are building the thing at all! Every feature becomes a part on an assembly line, and the connections between parts are easily missed. Worse, the user’s original intent is lost. We forget that before the spec, there was just someone trying to get something done.
In physical products, the joints and seams always remain top of mind. Each piece must come together or it doesn’t work. If the parts don’t fit and you know it right away! But on a screen, we often don’t notice our cracks and seams until a human gets stuck. The downside of bits and bytes.
Absent a physical reminder, we need to conjure an artifact that reminds us of our Raison d’être - what we are users are here to do. A useful tool for this purpose is a scenario. In Kim Goodwin’s words, scenarios are “stories about the desired user experience from end-to-end.” Scenarios act as our horizon line - a landmark to glance towards to maintain our heading.
These stories of our user’s idealized journey force horizontal thinking, cutting across the surface area of our product. Ideally, these stories are forged in research done by listening to real people. Done well, these flows are a powerful vehicle to keep the main thing the main thing. Both persuasive story and distant signpost, they shift our gaze from product capabilities to desired experiences.
By understanding the buckets of work our customers are trying to get done, we can more easily see what features matter most and critically notice where connections between things should happen.
This longitudinal perspective serves another role - prioritization. In planning our work, we often jump to ranking a list of features. We often begin assigning value and effort to each item, but we do so in isolation. Returning to the job a customer is hiring us to do helps us determine relative priorities between feature A and feature B. But as importantly, it guides how deep we go with each feature! Here’s why that second part is so important.
As a Product Manager, you’re asked for a list of requirements - so you create one. If your feature is search - you’ll have a list of things you’d love to do. The list is longer than you can get to (by design) so you draw an arbitrary line and call it your MVP. But how do you make this decision? Where is the right cut-off? Is it just based on your capacity? How much you can fit in?
Here again, the scenario acts as a guardian against the feature list extending into the distant horizon. Anchoring in our customer journey helps us avoid going too deep where it doesn’t matter, enabling us to re-balance our resources towards creating cohesion. Now we can shore up anemic areas of the customers’ experience while avoiding bloating those that are already sufficient to the demands of the user.
It’s not the features we build, but rather the flow we create. It’s the movement across our capabilities that matters! That’s what makes a product feel elegant, bespoke - instead of off-the-shelf parts cobbled together. Depth matters, but good product teams think end-to-end.
Like articles on building product? Subscribe to receive by email
—
To Learn More:
Kim Goodwin at Mind the Product