Several years ago, one or another of my daughters (I have three) said, “Whoa. Dad has an Instagram?”
First of all, my Instagram account is utterly unremarkable. I mostly use it to look at interesting art and photography to soothe my weary soul. My digital media consumption is not the point of this story.
No, what struck me about my daughter’s statement was the relationship it proposed between me and the product: “Dad has the product.” Not “Dad occasionally engages with the features of this product.” Not “Dad maintains an account on an application provided by a company.” In Dad has an Instagram, my daughter proposed a more substantial relationship between the product and its user. The product, in this wise formulation, belongs to its users. My daughter, then a preteen, understood this instinctively.
So often, we product managers, product designers, and product makers think primarily about our own relationship to the product. What should we build next? Can we fit this in the next release? Sales wants a feature: can we promise it? All of those questions put us, the team of people making the product, at the center. But that’s not where we belong. “Dad has an instagram” reminds us that the relationship between a product and its maker is only meaningful if we understand and prioritize the relationship between a product and its user.
The most powerful tool in your toolkit
The product and experience design community has developed many powerful tools and methods to help product managers, designers, and makers. At SDG, our product strategists use the Kano model, relative value, North Star Framework, theme-based roadmaps, and opportunity/solution mapping. We visualize these with grids, Venn diagrams, 4-blocks, 9-blocks, and swim lanes. Our user experience designers and researchers build user personas, craft journey maps, and make mockups, wireframes, and prototypes.
But of all these tools and methods available to product teams, the most powerful is getting to know the people who use your product. The product — as my daughter observed — is theirs, even more than it’s yours. So spend time observing them, talking with them, listening to them. I’d get rid of every chart and model and software tool in my product kit before I’d get rid of time spent with users.
How to get to know your users
Here are some tips to help you get to know your users.
1. Understand your users’ context.
Most software products are made in a similar physical environment, usually an office building with desks and coffee and decent lighting and nice double monitors (or, in these COVID times, in home offices). But much software is not used in such an environment. Users may be outdoors, under pressure, available only in brief bursts. Software used in, say, a pediatric dental office might be used with rubber gloves while a worried child weeps nearby. Software used in an industrial setting may have thunderous machines in the background and only be available between shifts. Pay attention to how they actually use the product, even if it’s not how you think they should be using it. You’ll learn a great deal if you Get Out of the Building into the wild, where your users are. Product folks have even developed an acronym for this behavior: GOOBing.
2. Understand your users’ stories.
Your users are engaging with your product for a reason: to help them with their work, to increase their understanding, to ease transactions, to improve their lives. You’ll make better choices and thus better products if you know their stories. For example, a medtech product might be used by people with a history of health concerns, who are feeling fear, uncertainty, and anxiety. You should respond to them differently than you would on a product used to help an eager bride and groom plan their wedding. Understanding the stories of people — needs and desires, frustrations and fears — will help you with priorities, user flow, layout, interface text, and navigation.
This understanding of users’ stories in order to understand needs and potential responses is where product management and product design converge. A marketer or business manager may get involved in product work to address business and market opportunities. An interaction designer may get involved in product work to tackle human factor and interaction challenges. But both are concerned with the story of the product’s users. This is why we believe that product designers and even playwrights and poets make great product managers, researchers, or analysts. Product work can learn much from disciplines like anthropology or even fine arts: don’t overlook such skills as you build your team.
3. Involve your whole team.
Empowered, cross-functional teams make the greatest products. But many product teams rely on one or two people to understand the users, while the bulk of the team simply takes direction from those emissaries. For example, it’s commonplace for a business to think that the designer on the team should handle user research on her own, and to worry that including developers in these activities is a waste of time and money.
I’ve found that everyone benefits from time spent with users. Engineers who witness the frustrations a user has with the product they’ve made will understand the issue more completely than one who is just responding to JIRA tickets. So include the whole team in the field trip to a user site, or at the very least organize a viewing party where the whole team can watch the recordings of research sessions. Rather than being an inefficient use of expensive developer time, it’s the quickest way to build empathy and understanding. It will pay for itself many times over.
Time well spent
I can honestly say that in my 25 years or so working on digital product, I’ve never had a single conversation with a user that felt like a waste of time. Every conversation, every observation is time well spent. So if you want to supercharge your product mindset, get up from your desk, shut down your laptop, and get out into the wild, where your users roam.
Note: this post originally appeared on the Solution Design Group (SDG) website. SDG is an employee-owned, Minneapolis-based strategy, product, and technology consultancy. In 2020 I joined Solution Design Group, where I half my time consulting with organizations on product, experience, and strategy, and half my time building a product consulting practice for SDG. You can find this and other great posts at www.solutiondesign.com/insights.