Build it into the Design Process
- Understand: A survey of the problem you’re trying to solve from the user’s point of view.
- Define: Using insights developed in #1, defining the exact problem your product sets to solve.
- Ideate: Generate competing solution ideas to solve the problem identified in #2.
- Prototype: A mock-up of your product which you can share with others.
- Test: Validating your solution with real users.
Competitive research is most effective during the Understand Phase, but it may occur throughout the entirety of the design process. This is especially true on projects that take years to develop, as competitive offerings may change several times during this period. If we look at the most frequent UX research methods during the Understand Phase, they typically center on user-focused methods such as: task analysis, journey mapping, and persona building. Yet, on numerous occasions working with UX professionals, I have noticed a glaring omission from their research: they tend to dislike including real-world examples because they believe it sullies the integrity of the research. In other words, UX seems to be concerned about building a “net new” product from two sources: how users feel + the design process. The reality of developing a product introduces many more constraints than that.
Don't Reinvent the Wheel
I think the problem here is that many UX professionals shy away from industry-specific domain knowledge in favor of the UX process in-and-of-itself. They tend to pursue the more idealistic path of starting de novo with each problem by going straight to users. Since this is an article about product management, we will add our own twist to that paradigm: as product managers, we are practitioners (not theoreticians).
On a recent project, we needed to build a balance history graph on an account dashboard that showed the user’s account balance over a set period of time. Graphs such as these are so ubiquitous in web design that we seldom pause to think about how complex they are. The graph that we needed to build was the first of its kind on our new web experience, and there was no precedent for how to build one anywhere at our company, including in our proprietary design system. This posed a challenge for us because we faced competing elements in building our solution: the user need, the business need, and the realities of the marketplace.
In the beginning, we sat through dozens of meetings debating how the graph should be drawn. How many developer hours did we burn? I am embarrassed to tell you the answer. In our meetings, the following questions surfaced: How many intervals will the X-axis contain? What data will display in the intervals? How will the graph data be padded on the top and bottom margins? Should we use a floating or fixed percentage for our margins? How will the graph look different in desktop, tablet, and mobile views? What color should the graph be? As it turns out, there’s a lot more going on here than you think. Sitting there flummoxed after hours of debate on how the graph should work, I asked a very simple question to our UX team. “What are our competitors doing?”
[cue crickets]
Sometimes, I think UX designers are uncomfortable making pragmatic decisions that may jeopardize the purity of their research. In a ten-minute web search, I pulled three examples of what I thought were effective graphs that our competitors were using. And before you get on your high horse about plagiarism, let me welcome you to the real world where every human innovation stands on the precedent of ones before it. Inspiration, not copying, is the key to success.
I forwarded the designs to our team. We picked them apart, asking why certain design elements were chosen. “That’s ugly,” one of the designers said. We spent a half hour discussing why. One of the other useful products of this exercise was determining what we did not want our balance history graph to look like. “This reminds me of Microsoft Excel,” I said, as I evaluated one of the designs. “And that’s not a compliment.” Ouch! We were on the right track here in getting closer to our ultimate product through the professional critique of competing products.
Distill it Down (and Up)
One of the most effective pieces of research I’ve ever written as a product manager was an exercise in concision. My company has a subscription to Corporate Insight, which is a competitive intelligence firm best known for its massive inbox-crashing research decks for a variety of industries, including financial services. When we began the participant experience project, one of my tasks was surveying the market by noting what digital experiences our competitors were offering. While the Corporate Insight summaries are very detailed, and very well done, they are extremely long and often do not inspire team conversation. The process goes like this: (1) boss forwards PDF to our team with no explanation, just telling us to “check it out” and probably hasn’t read it, (2) we receive the PDF and open it, read it for 10 seconds until we see the page count of 100, (3) close it, (4) let it sit in our inboxes for a month, and (5) delete it.
I got tired of this paradigm, so I decided to distill down this information into a series of bite-sized slides. One of the most important things a product manager can learn to do is communicate effectively. Not only does that include hosting effective presentations, advocating for your product vision, and writing effective emails, but it also includes learning how to facilitate the communication between tree-people and forest-people. Allow me to explain:
Some people see the forest and other people see the trees, right? Think of a business as a group of people slashing their way through a forest. At the top of any organization, you have forest people. Forest people are executives. Visionaries. Big picture thinkers. Their job is to tell the rest of us whether we’re on the right path. They are strategic individuals who are focused on grand trends. At the bottom of any organization, you have tree people. I don’t mean to denigrate these positions–when I say “bottom,” I mean detail-oriented specialists. These folks are the technicians whose job it is to carve a path through the forest, one tree at a time. The relationship between these two roles is symbiotic, and as old as time itself.
Each group uses their own language, and has trouble communicating with the other group. Yet each group needs the other to be successful. Guess where product managers fit in?
That’s right: the middle!
All product managers must be bilingual. You must be able to speak the language of the trees and filter it up to the forest (and vice versa). “We are on track to miss our deadline because of unforeseen data instability in our lower environments. Here are 3 things we’re doing to solve the problem.” Bam! The executives will love you! Conversely, you need to filter the language of the forest and bring it down to the trees. “Hey guys, we have to make this deadline because we have an SLA tied to one of our clients. Let’s try our best!”
What does this have to do with competitive research? One way you can help the forest people is by taking large quantities of data harvested by the tree people and putting it in language that the forest people will understand. When I compiled the Corporate Insight summary of the competitive landscape, I distilled it down into a simple one-slide summary that I passed out to everyone I could find. Within a few weeks, my slides made an appearance in our product VP’s slide deck, because nobody had thought to do this work before. It helped clarify our research in a way that was practical, engaging, and provided examples. It was the ultimate distillation.
