Templates for incorporating Research into Product, Marketing, Sales & CS processes
In my first post about Integrating Research, I gave an overview of the different cycles other disciplines commonly work in (notably: Product, Marketing, Sales, and Customer Success) and discussed how you can adapt your research practice to fit into those existing cycles.
If you want to be seen as a good partner and have your work leveraged by multiple teams, you need to understand how others work and do what you can to support those ways of working.
In this guide, we’ll cover the ways those cycles interact with each other as well as provide templates for what your integration plan may look like. Ultimately, you’ll need to develop something that’s customized to your organization, but hopefully these templates can both give you an idea of what the end goal might look like as well as provide a starting point for you to hit the ground running.
Success will look slightly different depending on who you’re integrating with, but a good sign is that Research is seen as a trusted partner across the domain you’re targeting, and that there are concrete checkpoints along the way with you and your team. A few examples from previous companies I’ve worked with:
As much as possible, you want to minimize Research being seen as a gatekeeper or as a barrier. Instead, work with cross-functional partners so Research is seen both as a value-add and as an accelerant to the work they already plan to do.
More intelligence means fewer mistakes, which can save money and brand equity.
Another thing to consider, especially the more you mature your integration strategy: these cycles, while they typically operate independently, have very clear overlapping points. These are good places to establish contact when integrating with a new team, as you’ll already have an idea of how you can help answer questions at that step of the process. The goal is to reuse most of what you already have, though expect to make small tweaks to support your new audience.
This certainly won’t be an exhaustive list, but here’s an idea of some of the overlapping points:
One mistake we made at Auth0 early on was we tried to be too precise. What I mean by that is we were asked what types of research and what methods should be deployed at any given phase of the PDLC. What we learned after a few iterations is that the specifics will change, and what matters more are the types of questions you should be asking and answering at any given point. What methods you use depends on the size and scope of the project as well as the limitations (time, budget, audience, etc). This is why our templates don't include research methods.
Another thing this doesn’t necessarily include are artifacts. Every company I’ve worked with has their own documentation, so while I can provide a Product Requirements Document here, it’s likely that it won’t line up with what your team is using. Instead we focus mostly on the questions to ask, with some potential data sources and partners to consider to support the answering of those questions.
You can see the full list of questions for each cycle in their respective templates, but what might be helpful here before you dive in is to briefly refresh everyone on the structure of each cycle and to provide a few examples of what proof might look like for some of the stages.
There are generally 7 stages to a Product Development Lifecycle, where some degree of traction is required to move to the next step:
This approach of requiring evidence at each stage before moving forward is a type of phase-gating, a widely known project management technique.
The types of research you do and the data/artifacts you produce will vary wildly based on where you are in this process, and tend to progress from generative to evaluative, from strategic to tactical. There’s no point in trying to improve comprehension or conversion on a high-fidelity prototype if you’re in the validation phase (plus, you get different feedback based on fidelity level). In the end, though, the key question you’re trying to answer is: should we keep investing in this?
From my perspective, the Validation phase is both one of the most important and the most widely misunderstood. No initiative should move past this point unless there’s a strong signal that customers want this solution and are willing to pay money (or your leading indicator KPI equivalent) for it. Measuring this requires a combination of qualitative (“are people interested in a solution?”) as well as some advanced surveying techniques often used in Pricing Research (see: Moving beyond basics).
Get the template: Integrating Research with Product Delivery
Marketing activities are typically considered a funnel. Similar to conversion funnels for different key activities in product, customers tend to drop out of the funnel at each phase:
Given this is a funnel, you can approach this slightly differently than when interacting with Product Development. The key question for any funnel is why customers drop out at any given phase (often referred to as a “leaky funnel”), but how you get to that answer will vary widely. The “why” for Awareness is mostly centered around how people consume information, where they seek out answers, etc. whereas for Conversion, it can be much more practical/tactical (e.g. who ultimately owns the decision, what hesitations need to be overcome).
Awareness is both one of the most difficult and potentially rewarding areas that Research can help. Brand Awareness is an entire business of its own, but instead of spending hundreds of thousands of dollars outsourcing it, your internal Research team can help. The beliefs and assumptions potential customers have about your company and/or solution (if they’re even aware it exists) can heavily impact the rest of the funnel. Brand Awareness research is a mixture of generative (“what do you know about ____?”) and evaluative (“how well does ____ resonate?), however one unique challenge may come in recruiting: you’ll want to specifically target non-users.
Get the template: Integrating Research with Marketing
In Sales, it’s often referred to as a “cycle” (and can be one if you consider upsell/expansion), however it often operates more like a funnel similar to marketing in that prospects will drop out at varying stages. The difference is that, for Sales, losing a portion of the prospects is intentional. In fact, Sales has a step explicitly designed to filter prospects out that aren’t a good fit:
Working to support Sales can be a unique challenge: it’s a very mature and robust practice that is mission-critical to the business, so you may be met with more skepticism than other areas.
What’s important here is to understand the goal of each phase and what insights Sales teammates crave to help progress to the next step.
Unlike the PDLC, where keeping an initiative in a given phase until it passes a certain threshold of proof (or it gets deprioritized), the goal for Sales and Marketing is always to move forward. In both cases, these decisions are owned by individuals (Product Owners or Sales reps), so your goal is to provide them with as much intelligence as you can.
For example, a quick google search yields no shortage of top-X lists of questions to qualify leads. But how do you know which questions are going to be the most effective for your business? You could approach this from an evaluative standpoint (testing a subset of questions) or from a generative standpoint (understanding the top concerns for unqualified leads), but a little research can go a long way to optimizing your team’s sales process.
Get the template: Integrating Research with Sales
The Customer Lifecycle is somewhat unique in that it often starts where Sales or Marketing tends to end: the conversion from a prospect into an actual customer. This is sometimes referred to as an hourglass.
The Customer Lifecycle functions more similarly to the PDLC in that the goal is to move customers along but the timeline and the individual requirements will vary. The questions you’ll be asking and the insights you’ll be providing can be boiled down to: what do customers need to continue to grow and mature in their use of our solution? How do we help them unlock more value?
One key difference between Customer Success and Product is the scope of the solution. Product Managers are interested in solving things at a macro level: a solution that works for everyone (or, at least, 80% of everyone). Customer Success Managers care more about personalized solutions: what does my customer need to unlock more value? Where is my customer struggling?
Research can provide tremendous value to Customer Success, but it’s not practical to spin up a new study for each individual customer. Instead, there are two ways to approach this:
The first approach looks a lot like the research process we know and love: identify objectives, develop research questions, select audience and methodology, etc. The second requires a strong relationship with your CS team for it to work well. The more they’re aware of existing or upcoming research, the easier it will be to add value, and the more value-add your research is providing across the organization, the stronger business case Research has.
Get the template: Integrating Research with Customer Success
Hopefully by now you have a better understanding not only of the ways some of your colleagues operate but also of the ways Research can support those ways of working. Without changing much about the core of our practice, we can have a broader impact across the organizations we work in, providing more value to more people and becoming a better strategic partner.
On top of making your organizations more customer-centric (something many business claim to want), increasing the demand for Research across the board will improve your status and lead to more resources for your service. That's an easy win-win.
Brad (they/them) is a UX Leader, User Researcher, Coach, and Dancer who's been helping companies from early-stage startup to Fortune 500 develop engaging, fulfilling experiences and build top-tier Research & Design practices since 2009. They have helped launch dozens of products, touched hundreds of millions of users, managed budgets ranging from $0 to $10M+, and coached hundreds of Researchers. Born in Buffalo and currently based in Brooklyn, NY, Brad dances with the Sokolow Theatre Dance Ensemble and Kanopy Dance Company, co-organizes the NYC User Research meetup, and served on the Board of ResearchOps from 2018-2021.
