In this episode of Mastering CS: Candid Leader Insights, Irina Cismas sits down with Pietro Restivo, Manager of Customer Success at Mia-Platform, a company that helps enterprises scale their digital platforms across APIs, microservices, and DevOps environments. Pietro shares how his years as a product owner shaped the way he thinks about customer outcomes, and why that background gives him a unique edge in building CS from the ground up.
He explains how Mia-Platform structures its CS teams by industry vertical, why the handoff between sales and CS is a process worth formalizing early, how he balances customer feature requests against product vision, and what anyone moving from product into CS should be prepared for.
What You’ll Learn
- How a product owner background translates into a stronger customer success practice
- Why Mia-Platform organizes CS teams by industry vertical rather than by account
- What a structured sales-to-CS handoff looks like in practice
- How to advocate for customers without overwhelming the product roadmap
- Why internal team education is one of the first processes worth formalizing
- What gets harder as a CS function scales inside a technical organization
Key Insights & Takeaways
Outcome-oriented thinking is the bridge. Understanding not just what customers want, but why they want it and what path gets them there is where product ownership and customer success overlap most meaningfully.
Vertical specialization builds credibility. Organizing CS teams around industries like healthcare or financial services means knowing the regulations, norms, and pressures specific to each customer’s world.
Handoff structure prevents information loss. A standardized request form between sales and CS ensures critical context isn’t left to memory or informal conversation.
Internal education is infrastructure. Building a learning and onboarding process for CS team members is as important as any client-facing workflow, especially in a role that lacks deep training resources.
Collaborate on the why, not just the what. Bringing product teams a customer’s underlying need opens the door to better solutions and more realistic timelines.
Flexibility beats playbooks in CS. Unlike product, where cycles are more structured, customer success demands adapting to each stakeholder’s communication style and organizational context.
Podcast Transcript
Intro
Irina (0:11 – 0:35)
Welcome to Mastering CS Candid Leader Insights, the podcast where we dive into the world of customer success with industry leaders. I’m your host, Irina Cismas, and today I’m joined by Pietro Restivo, Manager of Customer Success at Mia-Platform, a company that helps enterprises scale their digital platforms across APIs, microservices, and DevOps environments. Pietro, I’m really happy to have you here. Thanks for joining.
Pietro (0:36 – 0:44)
Yeah, it’s a pleasure, Irina. Thank you for having me here today. It’s a pleasure to share my experience, my point of view on customer success.
From Product Owner to Customer Success: What Triggered the Shift
Irina (0:45 – 1:04)
Speaking of customer success, you spent several years as a product owner before moving into it. What triggered that shift for you? I often see CS moving to product or any other department, but not product to CS. What convinced you?
Pietro (1:04 – 2:58)
When I first started at Mia-Platform, we were pretty much a startup. The customer success role and department didn’t exist yet. As you can imagine, in the very early stage of a company, we were more focused on creating a solid customer base and product.
So I was a product owner, but I was doing a little bit of everything.
Apart from the traditional product owner tasks, I was also deeply involved with customers, ensuring that the product installation went smoothly, supporting them in understanding how to use the product and how they could leverage it to reach their goals. But then as our company grew and scaled, we realized that we needed a customer success department to take care of our clients.
When the department was created, I started to look back at what I had liked most in my jack-of-all-trades position. What I liked most was understanding the customer’s goals, objectives, and challenges, and thinking about how our product could help them achieve those goals and overcome those challenges. I realized that this outcome-oriented, strategic way of working was what I genuinely enjoyed. So the transition to customer success was almost a no-brainer.
How CS Is Structured at Mia-Platform
Irina (3:00 – 3:08)
How is customer success structured to Mia-Platform? What does your team look like in terms of roles or responsibilities?
Pietro (3:08 – 5:25)
We have different customer success teams, and each is focused on a specific industry or set of industries. We have three main teams. The first one, which I’m part of, is focused on insurance and financial services. The second is focused on healthcare, and the third covers real economy, a mix of customers from transportation, energy, retail, and similar industries.
Each team encompasses two different roles: customer success managers and solution architects. CSMs are the main point of contact for our customers. Our main responsibility is to ensure that customers are happy and extracting maximum value from our product, this includes onboarding, staying aligned with customer goals, and helping them understand how to leverage our product and services to reach their desired outcomes.
On the other side, solution architects are our tech experts. They’re responsible for creating the technical solution to the customer’s problems and for the quality of what’s delivered. It’s a collaborative model: CS handles the customer relationship and business value, while solution architects are the technical enabler.
Irina (5:26 – 5:53)
I love that you team up, because one CSM cannot realistically hold all those skill sets. And it’s not very often that I hear about a CS team structured around verticals and industries. What triggered that decision?
How did you end up deciding to focus on different industries?
Pietro (5:53 – 6:40)
At the very beginning, we were just divided by customer. But then we realized that specific industries like healthcare or financial services require adherence to specific regulations and norms. To provide good customer success in those spaces, you have to know them — you have to understand the peculiarities of each industry. So we decided to split by industry to build vertical specialization in the domain.
What Good Customer Success Actually Means
Irina (6:42 – 7:13)
You mentioned the importance of successful onboarding and the partnership with solution architects. But beyond onboarding and adoption, what else contributes to the definition of success for your CS team?
Pietro (7:14 – 10:40)
Sure, this is a very interesting question. And I will start by thinking in general, what is good customer success? I think that good customer success means helping your customers to achieve their desired outcome through the right experience by leveraging your product and services.
The first step is deeply understanding why your customer bought your product — what’s the business value they’re after? And this is especially true for our company, because as you said before we provide a suite of product to enable companies build their AI power internal developer platform. And that is not a straightforward need.
That’s not a straightforward need. You don’t wake up and say, “I want an AI-powered developer platform” — there’s a business goal behind it. So the first step is really grasping where the company expects to go. But then you also have to understand their adoption path
What journey do they want to take to get to their desired outcome? So let’s make an example for it. Maybe a company, both me and our platform, because they want to have, because they want to do a legacy modernization initiative.
Understand a little bit the why, but then there are different ways in doing that. They might want to modernize their database software, their architecture in the fastest possible ways, regardless of the cost. Or maybe they want to have a slower pace, but following a more cost efficient way.
So you have also to understand that it’s not just the outcome, but how do you get it? So this, yeah, understanding the goal, designing the right path and supporting in this path is crucial. But then I think that the second pillar of good customer success is building trust and becoming a true partner, not just a provider, but a partner.
And I think you can do it by blending like several things. First of all, you have to be competent. So yeah, you have to be competent.
You have to be an expert in your product domain. Then you have to set the right expectation. So be honest about what is possible and when.
You have to keep your promises. So once you, once you commit on something, you have to follow through. And at the end, you have to also to deliver and demonstrate that you are delivering value.
So the customer have to perceive that month after month, time after time, they are getting a return from, from your product and services. So I think that when you blend these outcome oriented vision with partnership approach, you are doing good customer success.
Building the Sales-to-CS Handoff
Irina (10:41 – 11:27)
I’m curious because you mentioned that you need to do a bit of discovery and you need to understand the why. And you need to see, and you mentioned something interesting, which I know it, and I think it comes from your product background. What’s the job that the customer has hired you with?
Because he has several alternative solutions that he can reach out to the same goal. So coming back to the discovery part, is there something that you team up with sales and what’s the, when do you do that? Do you do it in the sales phase?
Do you do it post sales? What’s the process and how do you make sure that you are aligned? And what was discussed with one team passes through the other team?
Pietro (11:27 – 12:07)
Yeah, this is crucial, I think. And if not something like the discovery phase doesn’t finish in a specific part of the customer funnel. So sales are the first point of contact.
Of course, they have to do their discovery phase. Sometimes I help in the pre-sale phase as well with like more strategic customer. I help them when we enter in more like technical discussion and product discussion, but sales, that’s the first point of contact.
Then we have an handoff and I will enter if you want, I can enter in detail about how we do that.
Irina (12:08 – 12:25)
Yes, I’m curious. I’m curious because the handover, I think this is a super crucial step. Alignment and it’s usually a pain that the CS teams in general do have the alignment and making sure that they have a smoothness flow with other teams.
Pietro (12:25 – 14:38)
Yeah. This was an issue for us at the very beginning. And actually when we first created the customer success department, there were not very structured process.
So by analyzing the feedback, talking with our colleagues, like one of the first thing that I understood was that we needed a structured communication process with other areas. And the sales one was the first one that we addressed because they are our key partners. So at the beginning it was a little bit artisanal, I will say.
So more of like when a sales finish their discovery and want to engage with customer success, they set a handoff meeting and talk with the customer, talk with the customer success team. This was a little bit critical because you were risking to miss critical opportunities. So what I did was to create this process where to engage our area, the sales team has to fill a request form.
Let’s say it’s just a template email in which there are many fields with all the information that we usually need to know for a customer. So once they fill this form, they can send it to us requesting our intervention. And in this way, by creating a template for passing information, we ensure that we did not miss any critical information.
Then of course, one feature that helps you is automatic notes by AI when you enter in a meeting because you have the transcript of the meeting, you have the notes. So it’s much easier to know what went wrong, what happened during that meeting. But then there are also like phone calls.
There are many touch points between the sales and the customers. And by filling the template, you ensure that they pass all the necessary information.
Formalizing Internal Processes and Team Education
Irina (14:39 – 14:57)
I’m curious, what other processes did you build at the beginning? So the handover between teams and the communication is one thing that you tackled. But other than that, what other processes did you feel the need to formalize it in order to make sure that the whole team is aligned?
Pietro (14:59 – 16:35)
Okay, one very important process that we established when we created this department was learning and education for this role. Because that is not trivial, I think, because it’s a little bit a new role in the industry. It’s not something that exists since 1960.
It’s something that is quite newer. And also the material that you can find to document and learn how to do this role is scarcer than in other roles. You can find a lot of tutorials for developing code, for developing applications, but a little bit less for becoming a customer success.
In the first place, when I started doing customer success, I didn’t have this super idea of what is customer success, what should I do to be a good customer success. So first hand, I started doing some learning courses that I find online by some certificate organization. I assess what was, to me, the most useful one.
And I created a learning process and onboarding of new members in the area. To ensure that everyone that enter in this area knows what customer success is, what are your objectives, what are your goals, what should you do? And I integrated this automatic learning process with on-the-job training, in-person workshop.
So I created this learning flow. And this was one of the first things that I did when establishing this area.
Irina (16:36 – 17:48)
It’s nice because you also focused, or rather prioritized, internal alignment within the team. And that’s usually, I would say, not something I hear as often as I would have expected. We are usually jumping into solving the processes that are client-facing rather than internal-facing. We forget about our internal kitchen, and that’s something we think we can handle tomorrow. And usually, things start to fall through the cracks because we didn’t figure out our internal stuff first. So kudos for that.
We talked about how you communicate with sales, but now, with the product background that you have, how do you work with the product teams today? And how do you make sure that the feedback you get from your customers translates and ends up on the roadmap, without jeopardizing the product vision? Because I know that this is a super sensitive topic, and usually product guys don’t want to be the catch-all for customer requests.
Working With Product Without Jeopardizing the Roadmap
Pietro (17:49 – 17:55)
Yeah. So just to understand that I got it right, are you asking me how do I collaborate with the product team?
Irina (17:55 – 18:04)
Yes, with the product team, and how do customer requests end up on the product team? What’s the process that you have?
How do you formalize it?
Pietro (18:05 – 22:19)
This is a very sensitive topic for me because I was on both sides, so I know both perspectives. I understand that it can be quite stressful for a product team to receive a dump of customer requests and try to integrate them into the roadmap. So I try to collaborate with them.
But of course, as customer success, we are the strongest advocates of our customers. We are the people closest to them, and we can provide crucial feedback to our product team. We have to ensure that the voice of the customer is heard when the product roadmap is created.
But this doesn’t mean that we can just dump demands and expect everything to be done in the timeline that we set. That’s not feasible. What I try to do, what we try to do, is to collaborate. First of all, we don’t just ask for the what. I want this thing. We talk with our product team about the why. The customer wants this feature because they want to achieve that. So we don’t reason about implementing a specific feature, but about what is the best solution to satisfy the underlying requirement. That is the first step.
But then you also have to avoid being the person who goes to product week after week asking “is this ready?” To avoid that, you have to prepare in advance and agree with product on a strategic and realistic delivery timeline. If product tells you they cannot ship a feature in one month, you cannot just say “do it.” You have to find a compromise that will satisfy the customer and match your deadlines. We should be the first ones to find alternatives, like a step-by-step solution that delivers an initial version of a feature. Because the customer is getting something in one month that covers 50% of their need, and they can wait another month for the full delivery. And when you have a good partnership, customers are reasonable. They can understand that not everything is done in the time they expect.
Let me give a real-world example. A customer came to us requesting a new API management feature, fully integrated into the interface of our console, with a lot of specifications. They wanted it done in one month because they had to start a new activity.
But it was not feasible. The full feature with UI integration would require three months. So we asked ourselves, what can we ship fast? We could ship the feature accessible only via command line, without the UI integration. We talked with the customer and agreed to ship that partial solution first, with the full solution following on a longer timeline. We found a compromise between delivery and meeting the requirements.
The Lesson from Product That Never Leaves
Irina (22:21 – 22:37)
What’s one lesson from the product years that you’ll never drop as a CSM and that definitely helped you in your CS roles?
Pietro (22:37 – 24:39)
My experience as a product owner was incredibly useful for my customer success role. And if I had to think about one specific lesson, it’s the importance of clarity and communication.
As a product owner, I had to define why I needed to build something and then translate that why into clear, user-centric stories. We adopted the Scrum methodology, so we wrote stories. And you have to be very clear about the outcome you want to deliver, because you have to align the internal development team and ensure that everyone knows what goal you’re trying to solve for the user.
This translates very well into customer success, because you have to deeply understand what you need to deliver to your customers. You have to get the why very well. What do they want? What does success look like for them? This is a sort of definition of done, translated into customer success terms.
The second part is effective communication. As I said before, to build trust, you have to set the right expectations and keep your promises. And to set the right expectations, you have to be a clear communicator. You have to be clear about what you can deliver and what you cannot. And then walk the talk.
What Gets Harder as CS Scales
Irina (24:40 – 24:47)
What gets harder as the CS matures inside the technical organization as Mia-Platform?
Pietro (24:48 – 27:01)
The first things that come to my mind are customer obsession and internal communication.
On customer obsession: when you are a smaller startup, it’s very easy because you have a lot of interaction and you can report feedback very fast. But then as your customer base grows, you are tempted to create standardized solutions for the average customer, neglecting the uniqueness of each specific customer. And that is something you must avoid.
Because if you do that, you risk creating standardized processes and a general product that doesn’t delight or retain your most important customers. You have to be aware of the specificity and uniqueness of each customer and work on that. Standardization is important, but it’s not everything. It helps you for your internal processes, but in customer success, you have to think by adopting your customer’s point of view.
The second part is internal communication. When you are a small startup, you just go to your colleague’s desk, talk, and solve problems immediately. But as you can imagine, this doesn’t scale with the organization. If you continue to do that, some people become bottlenecks, and information gets lost across departments. So you have to establish workflows and information flows that work, but without getting lost in bureaucracy. The challenge is to create processes that work without putting too many constraints on the team. You don’t have to become too rigid.
What to Know Before Moving from Product to CS
Irina (27:03 – 27:14)
My last question to you is, if you are mentoring someone moving from product into CS, what would you warn them about?
Pietro (27:14 – 27:17)
Okay. Brace yourself, first of all.
Irina (27:20 – 27:23)
No, but if you start with brace yourself.
Pietro (27:25 – 29:09)
It was a little bit easier for me because I was already used to having a customer-facing part of my job. But the thing you have to be most aware of is the level of chaos compared to product. Product tends to be a little bit more straightforward. You analyze the market, you collect feedback, you create the roadmap, execute, monitor the results, and repeat. It’s a cycle you can repeat.
In customer success, there are frameworks and playbooks, but every customer is very different. And within the same customer, each stakeholder can be very different. One stakeholder can prefer a more hands-on approach, wanting to feel your presence and be aligned weekly on what you’re doing. Others, maybe in the same organization, prefer to only be contacted when really needed or during business reviews. So you cannot just apply a playbook. You have to adapt to the person in front of you, to their organization, and create a tailored, specific approach. You have to let go of the idea of a standard, repeatable playbook and adopt a more flexible mindset, doing personalized relationship management and staying aware of each situation.
Irina (29:12 – 29:36)
Pietro, thank you for the conversation. It was great hearing how your background shapes the way you approach customer success today and how you think about processes, ownership, and outcomes beyond just customer check-ins. To everyone listening, thanks for tuning in.
Until next time, stay curious, keep learning, and mastering customer success.
