.webp)
In this interview, Priya Sukumar, Product Manager at Intuit, defines a user-centric approach to building integrations and shares processes she has used to implement this mindset in her day to day. She also provides tactical advice for collecting user data, leveraging CS teams for user research, and keeping up to date with changes that can effect integrations.
I have more than 10-plus years of experience in the SaaS world, as well as in the collaboration space. I am very passionate about user experience and I believe in user-centric design and design-thinking. Im looking forward to this session.
I feel that product managers pretty much lead and influence what needs to be built next. I'd say to always start with a purpose in mind as a product manager. Having a purpose in mind helps us to attain which goal we want to achieve through this product. Most successful product teams give importance to clear objectives, and a deep understanding of user needs, which frames why they are prioritizing what to build next.
This way, big decisions are not taken by impulse, or just out of intuition. Key attributes to look for while determining what needs to be built is to understand and deep dive into which segment would benefit from this product. What's the scale of impact? And does it solve a user pain point and bring value to the customers we are offering this product to?
And I have found a really good framework, which is called the RICE framework. RICE stands for Reach, Impact, Confidence and Effort, which has been very useful while I'm prioritizing and figuring out what it means to the audience that I'm building for.
Related Content: Building Product Integrations with the Most Business Impact
Let's first start with what's unique about API integrations, right? Product integration is unique in a sense that, especially for a product manager, you need to be an expert, not just your product that you're building, but also the partner API or the external system that you're building on top of. So that's one of the reasons why it's so important to be more user-centric in terms of designing those product integrations. There's always this misconception that integration just mean a data sync and data mapping. It's way beyond that.
It's about how users can seamlessly get their workflow done. A user-centric approach simply means establishing the user voice, right from the beginning, when you're ideating a product. This simply means listening deeply to user needs, and developing empathy to their pain to help define requirements and design. We need to account for and support some of the users existing beliefs, values, and habits that they have incorporated in the years of experience that the user might have using certain products. I believe in three major principles as we think about user centric approach:
Kelly: Yeah, I think people sometimes forget that a product integration can essentially be its own app, its own system. It doesn't have to be a one-way data flow where you're just sending contacts to a different system; it usually gets much more robust than that. One of the really core challenges of product integrations is you do have this other system, which is unlike a product feature where you own that whole process.
You have your current customer base, but when it comes to working with that other system, and designing that experience, you really have to understand potentially another audience's pain points with another system.
The first thing I would map is the user needs and do this through user discovery activities. That's the beginning stage. It actually comes in handy when we want to empathize more with the user perspective, and understand how they use the two different systems. What I've incorporated into some of our integrations as well, as I'm building and leading the team, is user interviews. Honestly, nothing beats having a user interview and actually talking to those users, especially when building enterprise product integrations.
It's important to keep a note that buyer personas could be different from the actual user persona. You need to account for both because buyers are generally more interested in cost, configuration, and onboarding vs an actual user that may be more interested in ease of use and how they'll get things done. What has benefited me when it comes to gathering data is shadowing users and experiencing a day in the life of a user. We'll look at how they go about performing tasks, the workarounds they perform each day, and what's their emotional state is as they go about doing all this.
What has helped me a lot is mapping the entire user journey right from the start with onboarding. How do they onboard? How do they discover this product integration? How do they engage? How do they plan to use this product? How do they exit? How do they finish their job and move on with their life?
So that has been really important. I feel like as product managers it’s something that we need to do, and continue to do. Make sure that you ask a series of questions to understand their current behavior and possible workarounds. It's definitely worth your time to understand the user persona and limitations.
And sometimes during the sessions, we do get suggestions on what can be improved for a product to be even better than our competitors. So those are a few things I would think about as a product managers. Aim to better understand from the user perspective and not just from the system perspective. Of course, these are two different systems, but it comes back to that whole user centric approach of how the users thinks about these two systems and how it needs to work seamlessly.
Related Content: How to Track the ROI of SaaS Integrations
If the goal is growth and adding or expanding your user segment, then making sure you understand those personas with user interviews. As a product manager, it's impossible to be an expert for all systems.
I wish that was the scenario, but it’s not. Sometimes you have to work in a vertical related domains, like a virtual classroom with an educational domain or something in Telehealth, which is a completely different kind of an integration. As a product manager you gain those insights about user behavior through user interviews and also by understanding the segment you're targeting. During these interviews you get to know what other systems they use. For example, I was working on a Telehealth integration. I had zero clue on what this meant, what the doctors did, what the patients needed, and the role that nurses played in all of this.
It was so insightful to actually shadow some of the nurses and the administrative officers in the clinic to understand how they actually use the healthcare system. They had notes that they took and signed. Then they used Outlook. There were three to four different systems they used and all of them had workarounds that they did to address their needs. That's where, as a product manager, you need to be creative to see how you can simplify their life.
I would go back to that whole user-centric approach in defining if it's growth or if it's retention. Each is a little different. How do you penetrate the current account? How do you retain those customers? How do you keep them engaged in the product? How do you get them to come back? In the first 30 days, 60 days, 90 days, we need to have a plan in place.
The engagement goal is a little different. It's just more about how engaged you can keep the user within the product. The more simple and effective the workflow gets, the more they're going to come and use it. So those are things that we need to consider as we're thinking about our roadmap, as well as, building the products.
As we determine the best user experience the product manager should be considering technical limitations in the very early stages of building the product. It's more about how deep you want to go and how much time do you want to spend on it.
We need to spend enough time that you get a foundational understanding of what's between the two systems and what the limitations and gaps are. Gaps could be from UI design styles. It might be that the API and the mapping are so different that you need to figure out the gap between these two systems.
The two systems could be architecturally so different that it needs more engineering involvement to go even deeper to vet out the details. I feel as a product manager at least a high-level understanding of technical limitations is going to be immensely helpful even while designing the product, which is very early in the process. Sometimes we come to a point where the development starts, we are all excited, and then boom, it doesn't work. Now we have to go back to the drawing table.
There's a lot of chaos and confusion when we start thinking about technical limitations in the late stages. That's one of the reasons why I always recommend product managers start understanding the design limitations, understanding the guidelines, and showcasing the brand limitations as well. Sometimes the UI limitations or third-party platforms might not be very evident, upfront, especially when you're attempting to integrate with really big names, which are more strategic. They have very strict branding and style guidelines. Sometimes we have to accept these limitations.
I have found it super helpful to know these limitations, find workarounds, and move on. There's not a perfect kind of application out there. So we have to be creative and find those alternatives. What has helped me is supplementing with video tutorials, detailed user guides, FAQs to address those limitations and ease some of the user onboarding, and help improve adoption. Those are few of the techniques that I've adopted to mitigate some of these limitations as we move along towards the end of building that product.
Related Content: Product Leaders Share Their Frameworks for Prioritizing SaaS Product Integrations
What is very beneficial about the user interviews I mentioned before is that, as product managers during the process, you can build relationships with customers. That's important for the success of the product. When you build a relationship, that creates partnership - more than just customer and company.
We build a closer relationship, they are invested in the product that we are planning to offer. What I have found really helpful is to start with private betas. This is because given it's such a new kind of integration, putting it out there for general usage might actually bite us in the behind. I've experienced that myself. The support call volumes go up.
The first thing that comes to our product managers is the usage doesn't take off, or the goal doesn't work out. What we forget is the secondary impact or the ripple effect of support cases going up, and the sales and account managers pinging you and trying to resolve these fires. I have always found it very useful to have a more organized way of rolling out releases.
I normally start with private beta, since we have built those relationships through user interviews. Given that we are all in an agile kind of a way, it's such an iterative approach to things. So, during the private beta, we get a lot of input from users.
We then take their feedback, make improvements to the product, and go in for public beta next. That's through signups, and so it is more of a restricted public beta. Then we go full on in terms of GA. That has worked for me. Going for a brand new kind of integration that we think would create an impact, but taking it slow.
Private beta requires more hand holding, staying very close. That also means, as product managers, we’re very invested in the product at that point. But, as you said, as it goes to multiple hands of the users, it's close to impossible to handle every single user. So self-service onboarding is very important. That's very key, but also, I’ve found it very helpful to make sure we have a feedback loop set up. That could be within the product itself. One example would be prompting users to rate the product and give feedback in the app.
Then, as a product manager, look into that feedback and use the right kind of tools. There are some word analytics tools to determine the most common pain points that customers are having. In fact, we use Pendo as one of the tools to get feedback. Those are some of the things that have been immensely helpful to get more qualitative and quantitative data.
What I have found really helpful is implementing monthly sync ups with the support team to understand the volume of support tickets we receive, and categorizing those support tickets to understand where exactly to start focusing on. We also collect support ticket data and translate it in terms of product investment.
Meaning, which areas do we want to invest in to elevate some of the issues and customer pain points. Those are things that we look at as part of defining the roadmap. We also make sure we have constant sync ups with the support lead or the support team to get their input as well.
In the case of a product manager, it's a good practice to make sure you have an ongoing partnership conversation with whoever you're integrating with on a regular basis.
It could be monthly, if you're so invested in that particular integration, or it could be on a quarterly basis just to sync up and discuss where they are heading, where your roadmap is heading, and if there are things that would have an influence on either roadmap.
There are two elements. One element is the people who have influence over a product roadmap, and definitely the partner conversations that we have do have influence over these roadmaps. So making sure we understand those, as we have conversations with them. I also suggest working closely with the engineering team to understand if there are any API changes coming in. Also sign up for newsletters. Many of the developer platforms and developer portals now have updates on what's happening to ensure that you are up to speed on what's going on.
It is true that sometimes you will be caught off guard, because not only do we have integrations that we are working on, we have other work that we do. In this case, it's more about how well you react to these changes, and how, as a team, you can immediately jump in and be flexible.
One of the things we've always done on my product team is to buffer out at least 5% or 10% of our product roadmap for these kinds of updates. It commonly happens that platforms do get updated. By ensuring that we buffer certain engineering bandwidth, we make sure that this is taken care of.
POne thing I want say is that many times organizations are just tasked to build ecosystems and marketplaces. In the earlier days, building those marketplaces was a tricky time. Even though the success of building those ecosystems or building that app is defined by the number of apps in that marketplace, it's important as an organization to stay on high-value and strategic integration.
So bottom line, what I'm recommending is to go deeper in building a best interest integration instead of going broader in terms of number of apps, which might be subpar in terms of the integration quality. Most organizations do not give importance to user research. I feel it's very, very important, especially user research, competitive analysis, and understanding the market segment and which users you actually are targeting. Having that research early in the product life cycle helps make sure we don't waste time, money or resources in the later stages.
Most of the time, I feel that organizations run on assumptions. That's a huge, huge problem. When product managers run on these assumptions, they will get into a place where they're frustrated and wont understand why their product isn't being adopted. Why are the competitors going ahead of us? It's because simply, they need to lay the foundational work of making sure they think about user research and design-thinking. Then, they can build a quality product that addresses the user needs and their pain point.
--
If you enjoyed this interview, check out our podcast, Between Product and Partnerships, for more conversations with experts working on APIs, SaaS platforms, and integrations.
