The 4P Grounding Framework for Research Leads

Varsha Jagdale at UXDX Community: Building Balanced, Research-Driven Product Teams. Video: https://youtu.be/S1gv4EZnZHs

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The researcher drowning in random projects

[00:00:08] Picture this. There's a sole researcher who's working at an enterprise company. Their stakeholders have never worked with research before, and this researcher is now drowning in random research projects with no intentional thread connecting them. But this researcher wanted something more. They wanted research that drove decisions and not just validated them. They wanted to be a thought partner with their stakeholders and not just a service provider. And they wanted a research practice that felt intentional and not just reactive.

[00:00:47] Does this scenario resonate with you? I'm sure it must be resonating with some of you. Well, what I just presented was my story, in some different aspects, at my experiences at VMware, Google and now at Cisco. Throughout my career I have attempted multiple approaches of creating intentional research practices. Few of the approaches worked and few didn't, and I'm here to share those distilled lessons with you today.

[00:01:18] So, I'm Varsha. I lead a research team at Cisco and I'll be sharing the 4P framework. This framework is meant for anyone who wants to intentionally transition from leading research projects to crafting a research practice. So let's get into it. Before we get started, a quick note. This isn't a playbook to copy answers, but rather it's meant to be an inspiration to carve your own path. So please adapt it as you see fit to your context.

Where the framework comes from

[00:01:54] Most of us might have heard of this framework of people, process and technology. It's a very classic framework, it was derived from Harold's diamond model framework back in the early 1960s. And what this framework mentions is that there are these fundamental aspects of any organization, the people, the process and technology, and all of them have to cohesively work for the organization's success.

[00:02:22] So I derived my 4P framework from this classic framework, but then there are certain adaptations that I have made. The first adaptation is primarily that this framework has been adapted for building an intentional user research practice in a high-tech enterprise context. As you can see, I have added a fourth pillar of practice and I have replaced technology with product. So you have the four Ps there: the product, the people, the process and the practice.

[00:02:54] The second adaptation that we have here is that these four pillars need to be strengthened sequentially. And that is so because of a reason: in the classic framework it's like you focus on all these pillars all at once, but what I realized was it was getting unsustainable for me to focus on it all in one go, and it wasn't even productive. What I realized was it was better to work on them in sequence, and the sequence that you see on the screen right now, and we'll get into it in a bit.

[00:03:29] And the third adaptation I have for this framework is that I'm introducing a concept called currency. And the idea is that you keep building one currency in one pillar and that actually helps you strengthen the next pillar. So for example, when you're focusing on the product pillar, you will work on the unique value that you bring, and that can later help you build trust when you're focusing on the people pillar, and that can facilitate the formation of systems during the process pillar, and eventually all of that will feed into how you're able to scale your practice.

Pillar one: product, and delivering unique value

[00:04:10] So let's get into it and let's start with the first pillar, which is the product pillar. Now in the product pillar the goal is to start delivering some unique value. The emphasis is on the word unique here. What is something that research can bring to the table which other disciplines cannot? And when you look at the problem that way, one way to think about it is the unique value comes when you look at any problem space differently or more deeply.

[00:04:45] But in order to do that, first you need good domain knowledge, and this becomes even more critical in an enterprise context. So you have to start by building broad domain, product, business understanding, but at the same time make sure that you're not boiling the ocean, because it can get too much. And then you have to have that piecemeal approach of start with one project, go deep, build your expert domain expertise in that area and then move on to the next. And because of your depth and the research knowledge that you have, it might culminate in you delivering insights which go beyond the surface level and which bring some unique value and contribution to the team.

[00:05:28] So at this time you just want to focus on those domain insights, the unique value, and not get too much bogged down on explaining how research works to the stakeholders, because stakeholders really care about the outcome and they don't care much about the process, at least at the initial stages.

[00:05:49] And how would you know that you have reached success with this pillar? So ask yourself this. Ask if research was able to shift stakeholders' perspective on the problem any differently. Are they thinking about the problem with more nuance, with more context, and did it also fuel certain correct decisions? So think of whether that is happening, to ensure that you have achieved enough success on the product pillar.

[00:06:19] Just to see it in practice, I'll give you an example of how it might look like. So the example here is, maybe you are working on a code development tool which is used by developers. So the domain knowledge you may want to aim for in this space is like, what are the business KPIs, what tools, what features are we offering, what are the key developer workflows, if it's supported by AI, how does the AI work. The first project you may pick up in this area is perhaps the stakeholders are thinking of enabling the developers to share code. And the approach you might want to adopt in this context is that instead of staying at the surface level, you may want to deep dive into the context of the users and understand perhaps how they collaborate and how do they do pair programming.

[00:07:09] And how it might eventually look like is that if you do this pillar right, you will see the shift in the impact that you bring to the table. The insights might shift from pure discoverability issues, like, oh, the share button was hard to find, to some more complex and deeper insights where you inform your stakeholders that it's actually more effective for the developers to share both code and context, and they might have some different product features now to support that.

Pillar two: people, and building trust

[00:07:44] So once your product pillar is strengthened, you would use that unique value that you have provided for the next pillar, which is the people pillar, and it will actually help you build trust. And let's see how.

[00:08:00] It's commonly known that, especially in a highly enterprise and technical space, that you gain trust by showing your competency. You show your competency through the domain knowledge, the rich user insights that you have. And because you have that under the belt now, it is easier for you to gain trust with the stakeholders.

[00:08:20] At this time it is also important to start having more strategic product conversations. If you were having conversations about features, now you can have conversations about the whole product roadmap. But ensure that you are having that at the right levels, like find people at maybe the leadership level to have those discussions, and you are bringing something to the table because now you have developed that rich domain knowledge and you are equipped with a lot of user insight.

[00:08:50] And in these stakeholder conversations, what you have to look for is what problems do the stakeholders have and how you could mitigate those, and not just what research you can do, because sometimes the contribution of a researcher can go well beyond researching something. And you have to just pick up on opportunities to do more strategic research. And now, because you have delivered value, built those good relationships with stakeholders, it will be easier for you to secure buy-in to do more strategic research.

[00:09:22] And don't limit yourself to the one team that you're working with. Rather, expand your network, showcase the insights to maybe some other teams who might also find it relevant. But just a word of caution as you're doing it: do not spread yourself too thin, because it can happen now that you're friends with everyone in the organization but you haven't delivered value to anyone. And the success check that you would want to do at this stage would be just to see for yourself whether you're getting involved in more key business decisions and strategic projects.

[00:09:59] How might it look like in reality? So maybe continuing with the same example of developer experience, now you get to research more deep questions like, how do developers view getting help from others? How does their organization treat that as a signal of their expertise? Those are some deep questions to get answers to. And then you might also see the shift in the impact that you bring. Like you help the team shift from just building code sharing features to perhaps designing tools that build skills and efficiency of the developers.

[00:10:33] And it might also look like you are able to expand your influence now, like some insights from your study might actually spark interest from some other team in the organization. And it could also look like you have become that dot connector now, linking different stakeholder teams in an organization who might be working on similar problems. That's when you know that you have added value and you have built trust with the people.

Pillar three: process, and repeatable systems

[00:11:03] So once you have done that, you bank on that goodwill created in the first two pillars and use it in your third pillar, which is the process pillar, which focuses on building repeatable systems.

[00:11:21] And what it means is, first of all, now that you have deeper relationships with your product stakeholders specifically, you could actually start aligning your whole research cadence with their product roadmap. Maybe you are doing one-off research in the earlier phases, and now is the time to bring the research process and the core product process closer together.

[00:11:45] At this time you also may want to think about what are a few, and the emphasis is on the word few, you don't want to boil the ocean here, but what are the few high leverage systems that you can invest in right now so that you can have a payoff later in the future. And for example, you might find yourself in a situation where UX has to prove its value, and you might want to build a system which just captures the UX metrics on a quarterly basis. Or you might find that there is a lot of research already and you just need to leverage that research, and for that you may want to just build an insights library which banks upon the existing research, and so on and so forth. But it really depends on context. The key is to just invest in few, not do everything.

[00:12:37] And at the same time, when you're building a new system, like you're building a new way of recruitment, just make sure that it sort of weaves into the existing process, to not have systems that are isolated, because it becomes very difficult to manage them later on. And the last thing would be, just don't create a process or a system just for the process's sake, otherwise it will just slow you down later.

[00:13:05] And how will you know whether you have reached success in this stage? Well, ask yourself this: has the research become faster, predictable, and is it working at scale?

[00:13:18] Just to see an example of how it might look in reality, maybe now you might see that there is more process alignment, like the product leader now shares the quarterly roadmaps who was initially just sharing individual project timelines. See that as a win, and see that now your research cadence is aligned to that big picture of the product and not just individual projects.

[00:13:42] You might find yourself in a position of connecting the dots between the insights. Like you might see that there is a lot of research that's already happened and you might do a meta analysis to connect dots between the different research studies, and you get more value out of the existing work that has already happened. And you might also see that now the decisions have become faster, like past research has become more accessible because it's in an insight library, a research library, and it is sort of accelerating decisions of the stakeholders.

Pillar four: practice, and scaling beyond yourself

[00:14:17] And now the final pillar, that's practice, and that's when you will combine the unique value, trust and systems that you have developed in order for you to scale. And let's see how.

[00:14:31] So scaling, what I mean by that is you leverage the systems that you have created previously to amplify your impact through others. And when I say others, it's a common assumption that in order to scale something, in order to build a practice, you always have to manage researchers. But that's not true. As long as you are creating an influence beyond yourself, that counts. So maybe you can think of scaling through designers and PMs and not just researchers.

[00:15:05] You may want to democratize your approach now. And when you're doing so, make sure that you're sharing your methods, like the templates and things, the playbooks that you have created, also with your why, like why you did a certain thing that way, your thought process. And it would also be an interesting idea to partner with other insight teams within the organization to just broaden your influence across the organization.

[00:15:32] One success question you may want to ask yourself at this stage is, is the research happening and influencing decisions even when you are not involved? I know it can be scary just to think that, oh, things are happening without me, but over time I have learned that's actually a good thing. You don't have to be present at all the places and work is still happening.

[00:15:54] So how might it look like in reality? An example of that could be, now you have democratized research, designers and PMs now conduct lightweight studies. For example, going back to the similar previous example of the code sharing feature, maybe they have built a new version of it and now they are independent enough to just go and evaluate it themselves, taking it off your plate. Or you could see that now there are more cross-team partnerships, like you collaborate with another research team in the organization to find opportunities in a new space, like maybe it's the developer and production engineer collaboration workflows.

[00:16:35] And the biggest thing that you will see is that this research-driven problem solving, that's what you are bringing to the table, will exist beyond yourself. You will see other people do that, which is a good sign.

[00:16:53] So just to do a quick recap, the four pillars are product, people, process, practice. You gain a currency in each pillar which feeds on to the next pillar. Once you bring unique value, it helps you build trust with people. Once you have trust with people, you can effectively create systems. And once you do that, you use the systems to help scale up your practice. Just keep in mind that once you have strengthened all these pillars one by one, you just have to keep building up on them and the impact will compound over time. So that's it from me.

Q&A

[00:17:39] Host: Oh, Varsha, thank you so much for that. That was fantastic. Lots of questions that have come in, so I'm going to start with, let me just get it up. The first one was, can you make it into a playbook please, because I'd like to have a look.

[00:17:58] Varsha: Yeah, sure, I think this is definitely something that I can share. My reason behind not seeing it as a playbook was just, don't copy it as is. All the things that I shared were very unique to the context of working in a high-tech enterprise context. So maybe your things are still the same, for example you still have to provide inherent value, some unique value, even in a B2C space, but you might have to do it differently. So that's what I mean by that.

[00:18:29] Host: No, it's great. And you talk about enterprise. It seems to be a lot of enterprise people it resonated with, because we've got a question on, where do you get started? Struggling to get approval at an enterprise level similar to Cisco and I can't influence change. If you were to pick an area, where would it be?

[00:18:52] Varsha: Like where to get started? I imagine as in how would you even manage change?

[00:19:02] Host: And do you talk to your manager? Do you talk to your team?

[00:19:07] Varsha: Yeah, I think it varies, but I would say it really starts with, what are you offering first? I think that's the fundamental shift I had to make in the way I was approaching things. Initially I was like, I want a seat at the table, and then I had to sort of shift that learning to, I have to earn the seat at the table. And wanting and earning are two different things. So I would say you have to start with what value you're bringing to the table.

[00:19:35] Varsha: And maybe for researchers it's like, how we look at things differently, and if you can showcase that, if you can just have one case study to show that this is the difference, this is how we can do things differently, maybe that becomes your starting point. But if your starting point is, give me a seat at the table and this is how research works, that is not going to resonate. You have to speak their product language. So you could start it yourself, or maybe you can tag team with your manager, it really depends on your situation. But just think about what is the value I'm bringing to the table apart from talking about my research process.

[00:20:17] Host: And so when you talk about value, from you as an individual, what did you think was, what did you write down was the value that you would bring?

[00:20:29] Varsha: So for example, at the start of the project it would be things like, I would understand what is involved in that problem space, I would try to understand it deeply at the get-go. The value I'm bringing to the table is just the good questions I'm asking my stakeholders. I have had stakeholders, I have not even done research, I've not even given them insights, but the first thing they told me was, oh, you ask really good questions, or, oh, I did not think about it that way. So that's the micro value you brought into the conversation. Then you go do your research, you look, you find something which maybe the other people have missed, and that's like that second micro installment of value you bring to the table. But I think the value you bring to the table is the work that you do and not just what you say you can do.

[00:21:23] Host: Bringing the why. But yeah, I love it. And what was your proudest moment for when you got others involved in research?

[00:21:34] Varsha: I think the proudest moment, and this was also my scariest moment I would say. I remember asking one of my mentors this, like, hey, what if we democratize research and other people are doing research without asking me? It's sort of like a thing on your ego, like, oh, now they are so well versed with it that they can do it on their own and no one is coming back to you. So I would say that was a very scary and existential crisis moment for me. I'm like, what am I going to do if things don't go via me? And then actually that itself turned into the proudest moment, which was, it's actually good that things are happening without me now, because it frees up my time and I can go do something else. So I think that was just a shift in the mindset of how I was looking at things.

[00:22:25] Host: Yeah, great. And it leads on nicely to the next question on democratizing research. So how democratized is research at Cisco, and is it where you would have the same opinions, or is it where you would like it to be?

[00:22:39] Varsha: So the thing is, the way it is, it's very different, there are different research teams within Cisco. It's not a centralized piece right now. We had more democratization in VMware, because the ratio was too bad between designers to researchers and we had to do that. In Cisco the reality is different. We have a huge research team which can actually cater to a lot more research questions as compared to what it was at VMware. So I would say the level is low, but we still have basic templates as well as research reports. So we have all those in. So even if it's not a designer, or a new researcher who comes in, they can just ramp up quickly [?] because now they have those systems and templates in place.

[00:23:31] Host: No, fantastic, that was really, really great. Thank you so much for that. That was a fantastic session, I really enjoyed it, and it was really clearly laid out in terms of the flow. So really appreciate the structure to your talk. For those tuning in as well, if you want to revert back to it, obviously you can do it on LinkedIn and on our website now, but we will have it on Varsha's profile on uxdx.com too. Varsha, thank you so much for your time and we'll talk to you soon.