Introducing Product Thinking
A client asked me, “what do you mean by product thinking?” It’s a fair question considering the term is pre-mainstream (i.e. doesn’t have its own Wikipedia entry), easy to take for granted when you’ve been in the scene for a while, and implicit to a number of existing approaches to product development.
Using the words in a phrase to define selfsame phrase is a non-answer, unlikely to engender confidence in you as a coach.
Definitions can be tricky, especially when first attempting them. I remember an experience in the 7th grade history class. Our teacher, Professor Einhorn, gave us a homework assignment: define a list of words having to do with the day-to-day life and society of Iroquois Native Americans.
One of the words was “rubber.” I hoped Professor Einhorn wouldn’t call on me. I hadn’t completed the assignment, and this event predates the “Let’s Each Alternate Doing and Copying Bullshit Busywork Accord of 1989." To my relief, he called upon my more studious friend, Ryan Johnson. Ryan answered, “rubber: one who rubs.” Hilarious? Yes. Still cracks me up. The good professor had a different take. He was, putting it mildly, not amused.
Using the words in a phrase to define selfsame phrase is a non-answer, unlikely to engender confidence in you as a coach. For earlier adopters, harvesting a new point of view while doing stuff tends to come before having to describe or teach that new thing. Do it, reflect on the doing of it, learn how to communicate it, maybe someday you’ll master it and write a book. There’s a natural order at work.
Let’s dig a little deeper than “product thinking is thinking centered on products,” looking at some techniques where product thinking is already at work.
The most innovative and appealing part of design thinking is the ethnographic angle. That we might make our product design choices from a position of observation and user engagement, it’s a revolutionary and great idea. Right up there is the team workflow. Diverge on analysis, converge into context, and synthesize a better solution. When it comes to collaborative culture, it’s the way to go.
Great. Good stuff! But it’s a big pill to swallow (force feed?) all at once. It’s a methodology, after all. Methodologies can create a confrontational vibe.
Jobs To Be Done
Products are hired by customers to do a job. Jobs To Be Done is a handy tool for framing product hypotheses and intent, but if you’re trying to open the door to a product thinking conversation, elaborating with “milkshakes are hired by customers to ease long commutes?”
It all just feels a wee bit too esoteric and conceptual for an opener. It’s the 21st century equivalent of “let’s estimate using gummy bears!”
Oh, user stories. What have they done to you? If I had a nickel for every perverted, bastardized, and twisted implementation of user stories — what should be a “placeholder for a conversation” — I’d have enough money to replace all the dry erase markers I’ve spent writing I.N.V.E.S.T. on a whiteboard. (I’ve probably worn a few whiteboards out, come to think of it.) When the incumbent mindset resembles “The Cognitive Style of Borland® Caliber RM™,” guess what you end up with? Requirement specifications.
Another problem with user stories has to do with their size. It’s a good idea to break them down, so they fit in an iteration, but in doing so you lose the story bit. Stories in an iteration often fall under the “cool story, bro” category: too short, lacking context and intent, bullet point facts or anecdotes only. Certainly not a compelling narrative. Features, epics, and stories have a tendency to become a glorified outline, a functional breakdown, when people aren’t thinking in terms of product.
How About “Product as Story”
These days I open with: “Your product is a story under refinement and your users are characters.” That’s it. That’s the elevator pitch. No need to open with the full prospectus.
…when you use a product, you’re living a story.
Everyone involved in a product’s success understands stories. They watch TV or movies or maybe even read books. They tell the story of their day to their families over dinner. Customers, whether they know it or not, experience products in the first person, as a character. Product managers use the story to communicate intent and progress. Engineers tell and consume stories to understand how the specialized work they do fits into and advances the larger plot.
Products are narratives. It’s not an analogy; it’s a straight up metaphor! As you design, develop, and experiment with your products, you are engaging in the process of telling an ongoing story. And when you use a product, you’re living a story.
Optimizing for delivery doesn’t exactly create an enjoyable narrative. We have the tools to tell our product story — Design Thinking, Jobs To Be Done, User Stories, Story Mapping, and many others — the challenge in organizations that haven’t put all this together is in communicating the value of product thinking so we can get to understanding and maybe even embrace.