Brian Fugere is CPO at CentralSquare Technologies. He began a career in marketing at AOL before becoming Director of Research & Product Development at Stryker Imaging. From there, Brian served in marketing leadership roles at Belo Corporation and RemitData. Before his current position at CentralSquare Technologies, he worked as VP of Global Marketing at GE, Chief Marketing Officer at Virence Health, and, most recently, Chief Product Officer at symplr, a healthcare operations software company.
In our conversation, Brian talks about the importance of having marketing, product, and UX constantly aligned early for a successful launch of any product. He also shares an example of implementing and standardizing a feedback loop to improve the overall customer experience.
I view marketing and product as two sides of the same coin — you’re delivering an experience to customers. Marketing is more about storytelling, while product is about the physical manifestation of the story and the experience that you’re delivering. A lot of times, my marketing side helps guide my product side from a storytelling perspective. What is that experience going to be, and how do we want the customers or the users to go through that? This eventually translates into UX, but a gap in experience or expectations forms from teams not collaborating.
One of the things that I learned early in my tenure at symplr was that marketing and product need to coordinate and work jointly on any kind of release or new product launch. Each one owns a portion of the process. While product is ultimately responsible for it, marketing has a key role to play, and at symplr, the two teams worked on it together very well.
At symplr, we acquired over 10 companies. Everybody ran things differently within those 10, so one of the ways to combat this difference was by establishing a product operations group. Product ops was responsible for our release process — they built out a comprehensive release process in conjunction with product marketing. The goal was for product marketing to be part of the process from a positioning perspective and also serve as the conduit from product to the rest of the organization.
Let’s say we were launching a new product related to scheduling nurses or physicians. The product marketing team would work with product managers and directors to make sure they understood all the features and functions coming in. They needed to know them well enough to create the positioning documents, marketing collateral, enablement and training resources, and more. Since we had to also enable customers to receive this new functionality, product marketing had to be involved months in advance of anything coming to market.
The first thing we did at symplr was build a framework to collect feedback directly from the customers. It was a multi-layered approach where, at the senior executive level, our executive and C-suite customer council would provide us with strategic direction on where the market was going. The next level down was for product directors. These were our customer advisory boards who could talk about the specific area that the product director was responsible for, where the market was going, their needs, and how things were evolving.
The final tier was our customer collaboration boards at the product manager level. These were users we could ask questions around feature functions, such as, “What color should the button be? Where should the button be?” They’d often vote on prioritization of different features and provide direct feedback on the actual user experience. Those tiers gave us insight into the market and a qualitative view of what was happening.
From a quantitative perspective, we leveraged A/B testing when we launched and used product analytics tools to get true data on how the products were being used. That way, we could react and adjust as necessary. We could also communicate directly with customers through the products to collect feedback or to advise them of new features.
The marketing team was our partner in all of these efforts. They ran the executive customer council while product ran the other two parts of the process. Marketing shared surveys and held focus groups for us to collect feedback from a pure marketing perspective, and the final piece of research came from our UX team. We had dedicated researchers to understand the user perspective on the products themselves, where the future should be, and where the product could go.
It was an in-depth system to get as much feedback as possible. We also had corollaries from internal stakeholders to give their feedback as well.
symplr launched a platform this month that we had been working on for five years. A few years ago, I got direct feedback from a customer who gave me insight as to what users would be looking for. As we got closer to bringing the platform to market, we used that feedback to influence our positioning, as well as the features and functions that needed to be included so that people would want to buy it.
That proved super helpful for me as I shaped the roadmap around what this platform was going to look like. That way, our initial launch capabilities matched directly with the feedback that he gave us.
UX needs to be part of the product organization. Oftentimes, you’ll find UX embedded within engineering, but I believe it should be in product. Product is about defining what it is that you’re going to build, and engineering then defines how you’re going to build it. UX figures out how it’s going to look, behave, and feel from a customer experience perspective.
Then, as you build the product process through roadmapping, feature definition, user stories, etc., the UX team has to be intimately involved in all of these pieces. And if you’re blessed with enough resources to have a UX person assigned to each of your major portfolio areas, there’s an element of continuity that develops over time between the portfolio’s UX leader and product leader. They work hand-in-hand, looking out into the future about where the product is trying to go.
The UX team can help with research into what the feature function should look like, as well as how the rest of the team should think about implementing it. Conversely, the product team needs to be aware of what the UX needs in terms of timing. Can the design the UX team made actually be built by engineers? How much time will they need? You are in it together to make sure that the end design is implemented and matches what you all intended.
The product ops team plays a critical role here. Within the last year, I actually moved our UX organization into product operations to ensure that they were fully baked into our product process. We wanted to have them act as full participants in our product process as we standardized across the entire portfolio.
As I mentioned, symplr went through several acquisitions over four or five years. We grew the portfolio very quickly, with lots of new companies coming in. Each one had its own way of doing things, so establishing product operations made a big difference in terms of how we functioned. We could also ensure that how we functioned as a product team was consistent across the entire portfolio.
We had our roadmapping process feed into requirements, features, and user story development, and then the UX team worked with the architecture team to design the build. That whole effort fed into the scrum process. If we did all of this right and laid it out in advance, everybody had a defined role and time, which granted a higher degree of predictability on what we could deliver.
One of the ways that I work with my product teams is by helping them understand and think as a customer. How do we want our customers to perceive the value that we are delivering intuitively? If we have to spend a lot of time trying to explain what it is that we’re delivering to them, it’s not simple or clear enough. We’ll never be able to realize the ROI that we’re trying to deliver.
The products our teams are building will always be complex, but my team’s ability to boil it down into something simple and communicable is crucial, especially in getting the customers to adopt it and tell others about it. We always want that type of advocacy. From a product perspective and as a product leader, I like to explain that we need our customers and users to explain the value to the financial buyers in the organization. If they can distill down the value proposition, they can convince their organizations to buy our tool, and getting that value proposition down is critical.
We leveraged a quarterly all-hands across product and engineering, as well as a quarterly all-hands just for product and one just for engineering. On top of that, product and UX leaders met weekly to make sure everyone was on the same page. Each release had its own cadence of meetings to make sure that the teams were fully aligned.
When we rolled out new changes to processes, whether it was on the product side, the engineering side, or both, that required its own dedicated change management process. We’d have highly distributed communicative meetings and use our intranet to post and share information. We also monitored and ensured adoption through multiple meetings afterward. There was a lot of work done from a change management perspective.
This comes back to the collaboration I was talking about earlier — by having a partnership between product and UX, UX leaders can look at the roadmap far out enough to ask the right questions. If you can create that partnership between product and UX and get a 12–24-month roadmap, the UX team gets the heads up they need to do the appropriate research to prepare them for introducing something new.
For example, when we added GenAI capabilities into one of our products, we didn’t know what this was going to look like the first time. Everybody had ideas. We looked at other companies and how they had done it, and we took inspiration from that to be consistent across the industry. Ultimately, we wanted to give our UX team and research team enough time to talk to customers and throw various concepts in front of them. That way, we could get feedback to shape how things ultimately would be built and launched.
At the beginning of the year, I send an email out welcoming the new year ahead. In that same email, I recommend a book for people to read. It could be a product book or something else around execution or communication. I remind them that, if they’re a director, they should be seeing a customer physically in their space every quarter, and if they’re a product manager, I want them out in a customer space at least twice a year. That’s just the bare minimum, but the reality is, as product leaders, we can’t do our job sitting behind a desk.
You have to go visit the customers and see their day-to-day interaction with your product. What are the pains that they’re feeling? Where are the opportunities for you to make things different? How do they do what they do daily, and how could you change your product to help take advantage of their inefficiencies? Ultimately, software is just about taking a manual process and making it more efficient.
The future comes from going to conferences, talking to thought leaders, and joining groups to get ideas about what’s coming down in the market. AI is a perfect example. It’s been around for 30–40 years in some capacity, but GenAI popped up just a little while ago. Now, we’re all scrambling to leverage this new emerging technology into our products and experience. You can’t do that in a vacuum, and so you have to be out talking to customers.
After that, you can put something in front of customers, and, most of the time, you’ll be roughly 70 percent right. You can iterate from there to get closer to 100 percent, but you have to be willing to take that risk. The same thing happens with any other emerging technology or process. It requires you to talk to your customers to understand the implications for them, and then you can react and build something that will delight them.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Agentic AI is capable of observing its environment, creating a plan, and executing tasks independently to achieve predefined goals.
Instead of needing to have a different app for each task, a super app lets you accomplish everything in a single place.
Let’s discuss why Skype is being discontinued, what could have been done differently, and a few important lessons for product managers.
Eugene Mandel talks about the importance of “show, don’t tell” with AI products, i.e., why users need visibility into AI applications.
Learn more →
