Scaling Product Operations Without Breaking Teams: Expert Insights with Long Suciu

Patrycja Radwanska: Welcome to Let’s Talk Operations. My name is Patrycja, and in this series we ask industry experts about their practical workflows and the specific B2B tools that they use. Today we’re receiving Long. Our guest has led transformation across companies like Gartner, Freeletics, and Vistaprint, scaling operations across dozens of teams, implementing systems like Jira, Power BI, and Productboard, and driving real measurable outcomes like reducing lead times by 75% and cutting defects by 80%. This conversation, though, is all about what actually works in practice. Welcome, Long.

Long Suciu: Thank you, Patrycja. Thanks for inviting me for this conversation. I’m super excited to talk about product and operations.

Patrycja Radwanska: We’re super happy to have you here. So just in one sentence, as we can start, tell us what you actually do today.

Long Suciu: Yeah. So I help teams and organizations be the best version of themselves, and that’s by designing, optimizing tools and practices to help good people do great work.

Patrycja Radwanska: That’s amazing. That sounds really good. So maybe let’s start with the scale, because I think everything breaks there. You supported more than 30 products and not only product teams. What is the first thing that breaks when an organization scales?

Long Suciu: Yeah, so one of those first things is trying to do everything all at once. And so what’s important as a leader when you’re trying to do any type of transformational organizational change is focus on the things that are important to get changed immediately, quickly, and do this in an incremental, iterative way that transformation. So regardless of what it is that you do, it’s always gonna be when you try to do everything and wanna do it in a short period of time, everything’s going to break. But if you look separate from the massive checklist of things to do and ask the questions, what’s most important, what’s critical, what’s urgent? Put your focus on there. Because also part of that transformational change is the teams, organizations are the ones on the receiving end of that change. And so how do you start that change from a place of trust rather than a place of compliance?

Patrycja Radwanska: Sure. So trust and prioritization, I think that’s the absolute must-haves.

Long Suciu: For sure.

Patrycja Radwanska: When you first started at a company, what is normally messy or unclear and how do you actually decide to prioritize what’s first? So how do you do this prioritization that you were just mentioning is so important?

Long Suciu: So, I think part of that is what’s often messy from the people doing the work to the leaders of the organization is what is a strategy. And understanding what that is. And then on top of that, what are the channels of communication that occur both from a formal standpoint, like from directs and leaders, to the informal conversations, the peer-to-peer or those that are just my friends over there. And I usually get all of my information from that person. The water cooler talk. Because this is essentially at the end of the day where the information flows. And the flow of information tends to be most often the messy part.

Long Suciu: When you go and you ask, hey, can you give me an organizational map? You’ll be lucky to get an organizational map. Or the version of that map that you have might be four or five orgs ago. So anytime I go into organizations, I wanna understand the organizational landscape, who’s where, where are the teams, who are the leaders and whatnot. And then spending time with the people within the organization to try to understand how information flows. And that tends to be the place where if you invest in the early stages of being introduced to a new organization, that is where you get most of your return. Because it allows you to return for questions, come back and say, hey, I just learned this. And once you start establishing those pathways of communication for yourself, then you start to understand how things flow and then you can put together the challenges and problems people present to you with your understanding of how the system works and start to diagnose what the problems might be.

Long Suciu: Is it because this team is working on these things, but they usually are the bottlenecks for things from this other area and they never prioritize their work? But the reason why is they don’t – one, there may not be a system for how work gets introduced to them to ask them, so they don’t even know they’re being asked. Which is often either there’s no ticketing system, there’s no way – a ticketing system like in Jira where information is shared, or there’s the linkage of information. Or this product area talked to this person, but yet that person may not be the decision maker for what that team does in their backlog. They just know that person, so they’ll go talk to them. But either due to team dynamics, that person may not feel safe or have the space to bring up a need from another team. And so they said that they brought it up, but they couldn’t really do much about it. And then it is just this back and forth. So these are the common things I go to look for in terms of understanding holistically, how well is the system designed, is the flow of communication well, do people feel that they can approach each other for conversations, or is everything transactional – I do it through tickets or I post a Slack message in this channel, and then I expect it to be done.

Long Suciu: So, is the environment more transactional or is it collaborative? But then again, how do you prioritize and understand what’s the business strategy or the organizational goals that need to be accomplished, as well as what are the things that are preventing teams from working well? And you essentially say, okay, what can I do that’s gonna have a disproportional positive impact now? And just try to knock off your list. But you do it in a way that’s deliberate and decisive.

Long Suciu: And for myself as a practitioner, it’s important for me to also do what I say or commit to what I’m being asked. Because I’m starting from a place almost of zero in terms of trust, right? I’m new. People, in good faith, will give me their trust. But you have to early on as best as you can solidify that and then incrementally build on that trust. Because further down the line, might take one year, might take two years, but at some point that trust becomes instant. And then when you reach that place of instant trust, then you’ll also start to find that the things that you want to do, because you see problems that others don’t see, the lead time to take an action on it or presenting it becomes shorter as well. Because you don’t have to go through these additional activities or additional conversations to get to that place of okay, let’s go do it. You significantly shorten the lead time.

Long Suciu: And so as an agile practitioner, I’m always about how do I reduce the lead time? Whether it’s a conversation we’re trying to do, an idea, or how a team is getting their work done, the things that we can do to reduce that allows us to get to starting that thing faster or sooner. And ideally, once we can start it, then we’re actually closer to getting it done.

Patrycja Radwanska: It sounds like a lot of holistic work there, right?

Long Suciu: One hundred percent. You need to understand the system because what happens if I’m gonna eliminate these steps in this process – but if I don’t understand, actually those steps were probably there for some reason, rightfully or wrongfully, what happens if I eliminate them? Does it have any effect on any tangent or ancillary process that might be a part of it? And you want to understand those things. Because then when you talk about, hey, I’d like to do this change, I know it’s going to do this, I know it’s gonna cause a problem over here, but this is what I have in mind to resolve or help make that problem less of an issue than it might be.

Long Suciu: So even if you start to improve processes that might have a negative effect on another, if the person that owns that process hears that you’ve considered their process and you actually thought of a contingency plan for how to handle it, that person as well is going to start to trust you. Yes, Long may have made an incorrect decision on something, but he didn’t do it thoughtlessly. It just turned out not to turn out the way that we were expecting. And so you can start to gain that empathy from others in terms of the things that you’re trying to do. By having them be receptive to things that you’re trying to do with positive intent, even though they may result in something that’s negatively impacting their area.

Long Suciu: And so I can speak to a place where we were trying to integrate – we were having this problem with sales. Bugs being reported by sales, not actually knowing what’s happening with them. The process at the time was sales would submit a bug in their tool, Freshdesk, that was their tool of operations. And then a sales support person would essentially contact somebody in product and say, I have this bug. And then that person would then maybe create a ticket – maybe, like I said, maybe create a ticket. One, you have this problem of a disconnection between the information from sales and the information system, Jira, in this case, where product teams are doing their work.

Long Suciu: So this problem – you have bugs not being reported, bugs being reported but not being moved or not even knowing the status of them. So this is a big problem. But the simplest thing would be, oh, just integrate the tools and the flow of information. It’s not even that simple, because you’re talking about one sales organization to 35 varying product teams. So how do you even get to that place? But we know that the principle is get the information to flow in a seamless way. Have these two tools aligned such that the flow of information is gonna go back and forth and regardless of what system of record you go into, the information’s gonna be consistent.

Long Suciu: So those looking for bugs, they exist, they can go find the stuff. But the person in the middle, the sales support person, is gonna have to do some traffic control. Which means an increase of traffic control versus what they were doing before. Okay. So we know people aren’t gonna like that. They’re gonna need to do more work. But if we’re going to ask them to do more work, then how can we make it as straightforward, as easy to follow, as systemic as possible?

Long Suciu: That was essentially: let’s automate some rules in Jira such that the use of tags can direct the flow. And all we need for the sales support person to be able to do is just ask a standard set of triage questions. One, two, three, four, five. And at some point in that line of questioning, it should allow you to identify what’s the tag you need. And then the tag goes on the Freshdesk ticket that syncs to Jira. And Jira says, oh, okay, I know which Jira backlog to create this ticket in. And it creates a ticket. And then we say, okay, if a ticket goes into Jira that’s coming from sales, product teams, you own it, you have a responsibility to understand that it exists. So there’s a new set of rules that says the expectation is if a bug comes from sales, it has to be looked at, acknowledged within 24 to 48 hours. And if something doesn’t, we’re gonna get an alert.

Long Suciu: We built dashboards to identify those things so that we could find them. So we start from a place where, in order to help the sales teams with getting bugs resolved or acknowledged, we added a process for them. But at the end, it actually significantly improved the visibility and transparency of bugs that were being reported, which was 100% capture of all bugs. And once bugs were getting acknowledged, they were quickly going through disposition. Some bugs were not bugs. They were reported as bugs, but it was like, no, that’s how it works. It’s not the best way for that feature to work, but that’s how it works. So that allowed the salesperson to go back very quickly to the client and be like, it’s not a bug. We do apologize. It’s not the best customer experience. But the feedback has been given to the product team.

Patrycja Radwanska: That’s great. I can totally feel how fixing the process made everything much faster. And especially in the sales environment, when you actually deal with the client, it’s super important that you bring things which are bugs, and then you solve them and you go back with the solutions. So I can feel like this definitely must have improved the overall cycle for sure.

Patrycja Radwanska: And at the same time, we also hear a lot of companies that say, oh, we are very agile. What’s your first reaction or what are the patterns that you keep seeing or keep associating when you hear that kind of a statement?

Long Suciu: Yeah. When I hear that type of statement, my first question is to try to understand why are you doing any of those practices? And can I try to decipher – are you applying the principles on which those practices are based? So what’s often coined as scrum theater. On their schedule, they’re doing retrospectives, and you can see that they’re doing dailies, and you can see that they’re having refinement grooming sessions to put story points on work. So you see all the things happening. You can see them on a schedule. You can see tickets with story points. You have to start to ask third, fourth level questions. Oh, so why are you using story points? What do you do when something is too big? How much time are you spending on story points? Are you re-pointing a ticket after you’ve started it? Or even worse, after you finished it? Okay, we finished this ticket. It’s three story points.

Long Suciu: When having seen hundreds of teams do this, you can very quickly detect these patterns. And so when you see those, I think as a practitioner, you can say, okay, often you can go fix the practice. But what I’ve also included in my toolkit for how to handle these things is, let’s not do the practice. What happens if we don’t do it? And story points is a great example. Let’s not do story points anymore. Let’s just focus on the question of, how would you do this? How would you do this piece of work and how big is it?

Long Suciu: Because story points is probably done by 90% of software development teams, that in of itself – oh, it’s taboo. No, you have to – how are we gonna know velocity? How are we gonna – and that’s where the trust comes in. Often when I get asked a question like, what are you gonna do about velocity? Are you tracking velocity? Yeah, where are you tracking velocity? And they don’t really go anywhere. It’s okay, it doesn’t seem to me like you’re tracking velocity. So I think in my opinion, it probably has the least impact on your velocity at the moment if we don’t do story points.

Long Suciu: And yeah, it’s a fun thing because I always like that as one of the first handful of things to go do, to just give that shock to the system. Hey, if you don’t do this, how are you gonna feel? Because that’s often also always the thing of the most contention. So many people have been doing story points for 10, 15 years. What if we don’t?

Long Suciu: And what I’ve found in finding those places where you can just not do it – you’re able to bring the conversations within the team to the things that actually matter, which is how might we do this? How might we design this feature? How might we develop this feature? And how big do we think it is? And you do that repetitively enough, the quality of the conversation starts to increase, and then the tickets themselves become smaller. Oh, we can do this. We can break this up into these three or four pieces. Great. Those three or four pieces will be tickets for your epic.

Long Suciu: And then now you start getting into having the right size epics with the right amount of stories by just eliminating the waste that can come from using story points when it’s not used well. Some teams are great with story points. Great, then that’s not the problem for you to go solve. Maybe it’s the retrospective because this item on this retrospective for the last seven retrospectives – but no one has taken action or took the ownership to do something about it.

Long Suciu: So you go into your teams, your organization, and ask what are the top things that are preventing them from having work move forward? What’s preventing them from starting stuff? What’s preventing them from finishing? And then examine, okay, what are the practices that might be impacting that? What are the practices that might be lacking that would help? And then what are the practices that aren’t worth improving – by actually tossing out? Because there’s actually something that might have been introduced five managers ago, but no one ever thought, why are we continuing to do this?

Long Suciu: Because teams turn over, new people come in, this is how the team works. Those people that originated it are out the door. They left. And with team mobility, practices just stayed versus being questioned. And I think as a practitioner coming in, try to learn and understand how the team is working, indifferent and unbiased towards whether the reason was right or wrong, but what was the reason? And are those assumptions still valid today? It could have been perfectly valid three years ago. Is it still valid today?

Long Suciu: And what I found recently is the validity of assumptions has an even shorter shelf life than it did just a few years ago. This was okay six months ago, it’s no good anymore. And so that’s the interesting part – as a practitioner, you gotta be on top of the new, modern approaches to product management, on top of the new features coming out of Jira and leveraging of AI, and also the new products that are really focused on specific things. When we talk about how do we manage objectives, there’s all of these products that have come out – objective management platforms, product management platforms like Productboard.

Patrycja Radwanska: Maybe before we go there, if you don’t mind, because one thing that was coming to me is, actually what I really also wanted to unpack with you is about the planning, alignment, and the flows. I think if we think about alignment, many times teams are failing not because of lack of effort, but probably lack of clarity. And all the things that you just mentioned are close to this – the alignment, clarity, where that goes. So could you, from your experience, walk us through what would be the ideal quarterly planning process?

Long Suciu: Absolutely. So I think one of the key components of a good quarterly planning process, or one of the key assumptions, is to throw away the belief that every quarter you’re coming up with objectives from scratch. You’re coming up with everything from scratch. The quarterly planning process should be thought of as a continuous process. You’re just going from one quarter to another quarter. But that quarter to quarter is a continuous flow. And if you think of it in those terms, then the efforts and the practices and the conversations that you’re having are just part of a continuous conversation that you had previously.

Long Suciu: So if you take that quarterly planning process as more of a cadence and a flow, ideally you want to get to: we’re gonna start a new quarter, and this is everyone – this is the focus for the upcoming quarter. So you want to arrive at that place with a roadmap, a set of objectives that you’ve been able to inform the teams of such that they know what’s coming.

Long Suciu: In our case, at Gartner, in the business unit that I was in, we needed to tackle one – that it didn’t seem like an activity of high overhead that’s gonna be tremendously burdensome and then was gonna require people spending all their time planning instead of actually doing work. So one of those key things was, what is a good place to say, let’s start the process of getting people to think about it. One week before the start of the quarter was way too short, but we certainly didn’t want to go to okay, at the beginning of the quarter, start thinking about next quarter.

Long Suciu: So obviously, let’s just start right in the middle – six weeks. And we said, okay, if we thought about the six-week time period for the start of the quarter, then how could we space out those six weeks such that each step along the way felt like it was an incremental build?

Long Suciu: And so what we did was, at the start of six weeks, all we’re gonna say is start thinking about it. Start thinking about what you might want to do next quarter. What might be the objectives? And then for the next two weeks, just think about who you might need help from. You might not know what you need, but you probably know that you’re gonna need help from somebody. So it was like, okay, let’s capture that this product area thinks they’re gonna need analytics, or this product area might need data science, or UX, or DevOps. Just to get that. And the intent of that first two-week period was very much about just getting conversations happening, getting people in the right mindset and framework of okay, we gotta start thinking about what are the things that we wanna do next quarter. Where are the objectives gonna be? And start thinking about who we’ll need.

Long Suciu: And then the next two weeks was around sharing with people what you believe are the things that you want to achieve – around the objectives. And that was not getting people to align on them, but giving everyone else transparency of what you’re thinking of. And so the idea of having a quarterly planning process was around how to solve this problem of: any product director, any stakeholder could come up with an idea, go around just talking to people and selling it, and then just try and get somebody to do it. Alignment just didn’t occur. Things just got done sometimes, or things took so long that the stakeholder that was sponsoring it was gone and it just got dropped. And this caused people on the teams to be frustrated because they’d be spending all this time invested in doing stuff and sometimes it would just get dropped.

Long Suciu: Part of the reason why that wasn’t a problem at the time – it wasn’t a business problem because if you looked at business metrics, revenue was great, profitability was great. So there was no business-objectable reason to say, hey, we’re wasting a lot of time here, it’s impacting our growth. Growth was great. All the business parts were great. It’s just all these operational things were being covered up by great business performance.

Long Suciu: So when the time came that we had to do this, it was very easy to say, we need to at the beginning of the quarter figure out what everyone else wants to do so you could prioritize. And so we turned that into that minus four to minus two week period where you get to tell everyone what you’re doing and start to get further alignment. And then the final two weeks was build your roadmaps. And then at the start of the quarter was when we would share the objectives and roadmaps with leadership and give them the opportunity to say, that’s completely wrong – or, these are things that we want to do. And that is where we started, and every quarter we took the feedback on how that planning process was and tried to improve on it.

Long Suciu: Either changing some of the sequencing – we just started with Excel, Google Sheets, with just capturing the initial transparency. Just trying to get the mechanics of, okay, minus six weeks, I need to start to think about what I’m doing and maybe start to talk to some people. Minus four weeks, I need to start to think about what the roadmap might look like. What might be on it, start to talk to more people about whether or not they could do it. Minus two weeks, start to solidify that roadmap. Start of the quarter, teams have an idea what we’re going to do. Leadership has the opportunity to challenge that. And then teams just work off of this. That was the mindset. And then incrementally, yes, we learned some things to improve upon it, but also we needed to think about how do we start to build these practices into the tools so that the tools start to reinforce the behaviors that we want.

Patrycja Radwanska: That’s great because then you align on timings which are already super nicely defined, and then you also enforce it with the tools that at that time you were using. Right?

Long Suciu: Absolutely. Because what was nice was, you can also think of this as how do you scale team-level agile? Teams are working in sprints every two weeks. Organizationally, we’re gonna work by quarters. And then we know at the top level, the organization is in annual planning. And so it’s great, we can have this cascading alignment way of thinking about our flows – have our annual targets, our annual goals, our annual objectives. Okay, then let’s break down to what are the things that we wanna do each quarter. And then within the quarter, how are we gonna break down to the work that we get done every two weeks?

Long Suciu: And how do we build that kind of flow into the tooling? And then how do we actually also rectify – when we talk about the scale across 35 teams, we have an issue of language. And at Gartner, one of the problems I observed was an objective and initiative were the same thing. An initiative was like this big project, might be a two-year project, and that was the objective. And if we were going to be much more modern in the use of objective – what’s the outcome? OKRs, what’s the outcome we want to achieve?

Long Suciu: And so there was this inconsistency between things and outcomes that people were looking to achieve, if they were even thinking about that. Or what are the big things that they want to get done? And that was a very challenging part. And I think it was a challenging part all throughout – this differentiation between outcome and the things that senior leaders want. I want this thing, I want that thing. That’s just always gonna be a common struggle until you arrive at an organization that’s heavily outcome-focused.

Long Suciu: But that’s important to understand as a practitioner or change manager. If you go into an organization, what is the mindset and belief system of leadership? And then if you want change to happen, how do you adapt to that in order to make progress while also providing a path for how that could be easily introduced or integrated when the opportunity comes up?

Long Suciu: And for when we were doing objectives planning, I would say for the first six to eight quarters, it was very much more of a project alignment, high-level projects type of thing until business results weren’t coming in. And then it was like, now what KPI are we trying to move? That started getting discussed more and more often. And I was like, okay, great. Talk about – there’s probably an easy conversation to hop into around, okay, what’s the outcome? What do you want this KPI to improve?

Long Suciu: And so we had to very deliberately over time try to reinforce the what do you wanna achieve? And put more emphasis on that each time. And less on the what do you wanna get done? Answer what do you wanna get done on the backside of when you hear someone’s trying to improve adoption rate of something. And so that’s the transformation. Transformation never ends. You have to look at your organization, look at the processes you have, and just obsess over how do you continue to make this better.

Patrycja Radwanska: That sounds like a long process, obviously, which I think it’s fair enough. Those things don’t happen from one day to another.

Patrycja Radwanska: But if somebody was here today listening to us and they would ask you like, hey, for my delivery next week, what are the first things that I should really look at? What are the first things I could be changing to achieve better results? Do you have any tactical, practical, fast kind of advice?

Long Suciu: For sure. Absolutely. Tell me what on this backlog you need now. What are you currently working on that has started that you need now? And probably you’re gonna get is I need everything. Great. We’re gonna get everything done, but just put it in order for me. Tell me what’s number one. And just one, two, three, four – just put it in order for me.

Long Suciu: Everything’s always going to be important. And what I learned early is don’t challenge whether or not something is or isn’t important. Demonstrate your trust. Yeah, I believe you. It’s all important. Help me understand, if you had to stack rank them, what would you put on the top and what would you put on the bottom? And then once you’ve done that, let’s work off of the top. Let’s get you the things on the top first, and we’ll go down from there.

Long Suciu: And what I found is with that type of conversation – you’re not challenging and saying, I, Long Suciu, who don’t own any of this stuff, am telling you number six is not important. I believe you, that you believe and understand that it’s all important. And if I had a magic wand, I wish you could get it all done simultaneously. Help me understand what’s at the top. Now let’s just get the stuff at the top done.

Long Suciu: And if you’re saying the stuff at the top is the stuff that you’d like to get done first, if you got it, would you be happy? Great. If you start to do that and do that incrementally – they may not say all the stuff at the top, they may say here’s a stack rank but I’m putting these five things all at number one. Great. You’ve done the activity. Because when I have that conversation with you for the fifth time, it’s probably gonna be closer to a one, two, three than a one-A, one-B, one-C.

Long Suciu: And I think one of those things that’s important is, as you have conversations with people on change management or change of behavior or changing mindset, do you understand those principles and the foundations thoroughly and deeply enough that regardless of the question that you’re posed or scenario you’re in, you are always consistent with how you are responding? Because then that adds validity to the principle. Let’s not work on 15 things at once. Let’s work on three. We get those three things done, we’ll work on the next ones. When we finish, when we start doesn’t necessarily always dictate when we finish. Let’s get these things done. Because then that means we have less to look at to decide what to do next.

Patrycja Radwanska: Yeah. I think this is great and I think very often we need to be reminded how important it is to prioritize and make sure that we have this view of these are all the things I really wanna have done, but what you really have to have done at the very beginning of the journey.

Long Suciu: Absolutely.

Patrycja Radwanska: So I would like us to dive a little bit deeper now into tools because you’ve worked deeply with tools like Jira, Power BI, Productboard. So if we can, let’s go super hands-on there. And I would like to start with a very short question. Do tools shape behavior or should behavior shape tools? What’s your answer to that?

Long Suciu: So you should design your tools to reinforce the behavior that you’re looking for. And when you overlook that, yeah, the tools start to shape your own behavior, which may not be what you’re desiring. So certainly, that’s why for me, it was early on in my career where getting deep into how any tool that a team works on is important. Because it’s important to understand how they’re designed, how they were intended, and whether or not the actions and behaviors that you see within a team and the people using the tools reflect that.

Long Suciu: Now I always say to folks – automating a bad process just makes your bad process more efficient. And so you could be inefficient making garbage or you can be super efficient making garbage. And being efficient making bad things is worse because you’re just gonna make those things at high volume.

Long Suciu: So tools are essentially, just like anywhere else, wherever we work, technology is the thing that helps with the scale. Technology is the tools that we have that help with efficiency and improve quality and things like this. So we have to learn and understand how to use them and how they’re designed and understand their capabilities. And then we take those and configure them and design them in a way that’s going to help drive our processes and drive the behaviors and reinforce the behaviors that we advocate for.

Long Suciu: And so when we look at the system holistically, going back to things that we talked about previously, there was this lack of alignment. Not really doing product management, but just people having projects. And then, how are any of these things connected? Objectives and goals people had before were in slide decks, right? And then we had Jira, which just had epics and stories. But even epics weren’t organized in a way – epics were just buckets. I’m just adding this ticket to that epic. But if we take the principle of an organization has objectives and those get broken down quarterly, and each quarter we have a roadmap, and the roadmap is made up of the things that we’re going to do – then we actually have a nice flow of artifacts that we can go from objectives to a roadmap made of epics to epics made of Jira tickets. And so we’re connecting the top-level stuff of the organization to the work of the team.

Long Suciu: So then, okay, how do we make this live? On the team side, we had to tackle having well-organized epics. That an epic is a package. And if you know that package was done right, then it was done right. The synonymous way is an epic is a feature in this case. And we know that we can only do so many epics in a quarter. So what’s the roadmap going to be of the things that we wanna do and get accomplished in this quarter? And then do those things on the roadmap support any of those objectives?

Long Suciu: Now, it could be wrong, could be right, but let’s just make that traceability – that I can go from a single Jira ticket to an epic, to it’s on a roadmap, to it’s an objective. We started this in a very heavy way by just capturing objectives in an Excel sheet and then trying to say it’s these epics. But I saw myself piling it in and was like, this isn’t gonna work. No one’s going to go through this exercise when we’re talking about 70 product managers.

Long Suciu: I decided I needed to go do some discovery work and see what are the tools out there that might help solve this problem. Because certainly we have Jira, and we could just clean up, improve and clean up the execution. Very straightforward, easy to do – just took a lot of time. But we had to go find applications and platforms that did the roadmaps and objectives.

Long Suciu: At that time, we brought on board Quantive for our objective management platform. And we brought on Productboard for our roadmap but also product management platform, which housed both roadmaps and our ideas – the things that we could do but we’re not going to do. And so part of that was also where do we want people to work? The teams executing – Jira is a fantastic tool for execution. But we had product managers that were getting into the weeds on Jira tickets and spending all their time in Jira. And it was taking them away from building roadmaps and actually coming up with ideas. The idea was just a Jira ticket and then these things would just get lost.

Long Suciu: So in addition to starting first with thinking about how do we align these things, there was also this discovery and epiphany of – wow, the development team works in Jira to get things executed. But product managers should be strategic thinkers and be thinking about building roadmaps and coming up with ideas and being ideally more six to 12 months forward-looking versus day to day.

Long Suciu: And senior leadership in the organization isn’t gonna want to know what the team is doing today. You’re not gonna get a VP to go into Jira to look at a sprint ticket. But how do we have a system of record of objectives that might be a solution – where all these are in a single place, but also to reduce the burden on product managers of having to update things repeatedly by writing deck after deck of repetitive information? It’s all here. So this is the place where we wanted to start thinking about how do we get these things aligned but also help the right people work in the right place, and not just think everyone works in Jira.

Long Suciu: So we had to start small with finding just product managers that were willing to work in Productboard. And getting them to – you’re not gonna do anything in Jira, I have to work in Jira. But what if we were able to solve the problem of: you have ideas about stuff that you don’t wanna throw away, but you also need to build a roadmap of things that you might want to do now and for the next 12 months. And this can be the perfect clean place for you to do that instead of trying to create an endless volume of Jira tickets. And that was the sell.

Long Suciu: And then on the objectives part, this was a very hard sell that we were only able to do after our CTO was bought in. He needed a platform for objectives because he wanted to reduce the complaining from all the product management about editing the same slide decks and things like this, but also have a system of record. So through his advocacy and him working hand in hand with the SLT to use Quantive – going to Quantive to see objectives – we were able to put objectives out there, roadmaps, and continue to improve on execution to have all these things aligned.

Long Suciu: We integrated the tools such that a roadmap item in Productboard was linked directly to the epic in Jira. And the objectives were linked to what are the epics that, when these epics are done, help achieve the objective. And that was the starting point to have this alignment. And what we found over time was we just couldn’t get Quantive to be the place where people wanted to go into.

Long Suciu: And fortunately, Productboard – and this gets into staying on top of the new feature releases on any of these platforms – Productboard introduced OKRs into their platform. So we were able to consolidate objectives and roadmaps into Productboard, which then allowed product managers to easily associate objectives with features. And when it came time to do a feature – great, push a button, it creates the Jira epic. And so we kept Jira much cleaner because Jira became really more representative of the things that we’re actually going to do.

Long Suciu: The things that we could do and possibly do all resided in Productboard. And then when it came time to develop new objectives, they got developed in Productboard. And the ideas that product managers had – okay, great, let’s do this feature, it goes through this objective. And that became much more sustainable because then we were able to generate reporting out of Productboard.

Long Suciu: So instead – we couldn’t get the SLT away from slide decks. Great, fine. Create the slide deck and I’m gonna paste in all the objectives straight from the tool and all the updates from product managers happen in the tool. And then we just inserted those updates into slide decks. And so what this led to for product managers, who are driving the business – it was a much easier task to identify on a weekly basis, hey, this feature is at risk, on track, or off track. And hey, as long as you keep this updated, the monthly reviews on objectives and the roadmap for SLT – as long as you keep this updated, then you don’t need to do anything here other than review it yourself for the slide deck review, or any additional commentary that you may want to provide.

Patrycja Radwanska: That seems like a super streamlined process and obviously I can picture how much time was saved from creating those decks versus just having this one Productboard where people could get the information they needed. It seems like Productboard is something that you’re definitely super passionate about. What would you say if a company just bought Productboard and they don’t really know where to start from? What would be your advice?

Long Suciu: My first question would always be to try to understand, why are you doing it? Because that’s going to greatly inform where to start. Because there’s – the awesome thing about these tools is they are super powerful and they can almost do anything you want. But if you don’t know why you’re doing anything, you put yourself at risk of starting off with a bad experience.

Long Suciu: And if you’re a person that’s not deep into how the teams are working or how product management is being done in your organization, you’re strictly about just understanding these tools – you certainly wanna engage in this case the Productboard client success team to help you with, okay, how do I get this onboarded and how do I get adoption?

Long Suciu: So for myself, how I leveraged them was certainly around help me understand what your other clients that are similar to us are doing. Here are my ideas of how I see things. And just really, I think what’s important as a practitioner is not to be so blind to how you see things and that it’s only gonna work like this, but more leverage the other contacts that you have.

Long Suciu: And especially when you engage other applications, engage with the client support, get an understanding of similar clients. Because if you assume that they’ve talked to hundreds and hundreds of clients – here’s my scenario, here’s my situation. What have you seen others do successfully and unsuccessfully? And collaborate on that approach of how do you onboard and how do you get adoption? Then on top of that, who are your internal stakeholders such that you can get feedback from them as well to understand, are you onto something or do you put yourself at risk of this not being well understood and adopted?

Long Suciu: And as long as you’re doing that, then you’ll come up with a good plan of, in the first month let’s do this and in the second month let’s do that. But until you understand – in certain cases I had to sell the problem that I saw, and that’s what allowed me to then bring Productboard and say, I think Productboard can help us with these certain pain points. But often people – their manager comes and says find something that does this. They go and do an RFP, they send a query, see all these demos, and they’re like, okay, we selected this. I would encourage those people to make sure that they develop a very strong, positive relationship with the client success managers for their application, and then they work closely with stakeholders and especially have those that are deep into it – the ones that are gonna have to use it – to get feedback from them.

Long Suciu: But it’s not easy because there’s the oh my God, it’s not gonna work. But you have to trust that you understand the problem intimately enough to see through the pain. It’s gonna be your pain. You shouldn’t be causing pain for everyone else, ideally. But you have the confidence that this is going to work because you believe these things – but not be so proud where you prevent yourself from pivoting when necessary. And the pivot doesn’t mean you’re always pivoting away from something negative. It means, if I keep on this steady path, it might still be going well, but if I actually do this pivot, it’s going to accelerate.

Long Suciu: And if you can find those points of acceleration instead of the steady path, the acceleration might be the more fulfilling, rewarding, and beneficial thing to the organization than the steady path. But you wanna be able to obsess over keeping your eyes and awareness out for the signals to tell you – wow, this person just heard about this. I wasn’t planning on adding more people into the mix, but let me add that person because I know that once they get their hands into this, they’re gonna champion it. And it’s gonna actually allow me to sell it to more challenging product directors and managers. Because that group of people, they’re much more initiative-focused, don’t wanna hear about outcomes. But if I get that person who’s done OKRs in another organization, who’s all about it, and I show them how they can put their OKRs here –

Patrycja Radwanska: Yeah, that totally sounds like great advice. And I know it’s a lot to digest, but for the ones who are just starting with Productboard, I think it’s a great insight.

Long Suciu: Yeah.

Patrycja Radwanska: If you don’t mind, maybe we could jump now into data and dashboards, because I think that’s also something super important that we would like to unpack here. You built Power BI dashboards using Jira data. What made them actually useful?

Long Suciu: What made them useful is the dashboards that we worked on could be read and interpreted. They were readable, they were accessible, and they were able to be understood. And that’s, I think, key for any type of dashboard – if you’re gonna put effort into building it, the audience that it’s intended for needs to be able to read and understand it.

Long Suciu: One of the key things that we made visible for engineering and product leaders was what were the stated sprint goals of each of the teams? And we previously, as we tried to help the teams better apply Scrum, one of those key foundational things was what’s the stated goal? And we didn’t focus so much on was it worded correctly or was it the right type – just say something. Just say something that you were working towards. And so teams would do that, but it would be just for themselves and no one else got exposure to it.

Long Suciu: But wouldn’t it be great if actually middle management, directors, senior product managers, and engineering managers understood what each team was trying to accomplish in their sprints? And we created a dashboard that had every team’s stated sprint goal on there. And it was a very quick way for engineering folks to just look at what a team’s trying to do that sprint and just have an understanding of what’s going on everywhere.

Long Suciu: And even though there may not be a necessary interaction, what that created was – wow, look at this transparency. I can see all these teams. I can see what they’re saying they’re trying to do. And that just allowed for a conversation starter between anybody. A product director could read what one team might be doing and then start the question – but I need them to do something for me. I thought they were gonna do something for me. And it allows them to proactively go ask a question or – that’s an interesting sprint goal, what’s in your backlog? And then go to that team’s backlog.

Long Suciu: So part of what we were trying to target with the dashboards that would refresh on a daily basis – because it was important to have recent data – was to give engineering managers a way to see what’s going on and then get some type of signal of should they go ask a question somewhere.

Long Suciu: So we created a dashboard for goals and then we created a dashboard that allowed anyone to go into a team’s sprint and see what are the tickets in their sprint, what’s their progress, and the work distribution. And that again allowed us to help people understand – hey, before you go ask this team to drop everything they’re doing, is there something you want to trade off in their sprint? And so what these dashboards allowed was a faster way to get to those questions than having to go to Jira and figure out which Jira project the team works in and then go from there.

Patrycja Radwanska: So just much faster information to the team rather than going into the rabbit hole and finding it themselves.

Long Suciu: Absolutely. And so once we started that, then we just incrementally added new dashboards to introduce new concepts to the teams. What’s the size of every team’s backlog? Because then that allowed us to be like – you’ll have a thousand-ticket backlog. Look at – so for example, when we started to look at the size of all the teams’ backlogs and put it on a dashboard, you could see teams had huge backlogs and teams had tiny backlogs. Some teams were going hand to mouth and some teams had a backlog that, if they stopped creating tickets, it would take them two years to complete.

Long Suciu: So these types of things – when you start to provide much more visibility and transparency into the data of what’s in Jira, it allows you to start to fix things that improved the life of people. Hey, your backlog, if you stop now, would take you a year to finish. Do you believe all those tickets are valid? No. Oh, you don’t. Okay. Let me have a go at identifying tickets that I think we might be able to get rid of. And you come back like, hey, here are tickets that were created over a year ago. It represents 25% of your backlog. Are you okay if I just archive them all?

Long Suciu: And most often not – when you word it in this way, people would struggle to say no. Because it doesn’t make logical sense. So it’s also important, when you’re sharing information with folks, to be very straightforward about what it represents and what your recommendation could be done with it. And if you provide it in a very logical, reasonable manner, it makes it hard for people to refuse or say no. Even though deep down inside they’re like, no, we don’t get rid of tickets. What if that bug comes back? If it comes back, we create a new ticket. Or we unarchive it.

Patrycja Radwanska: I think this goes very closely with your success stories. I think one of the things that you did, you reduced the lead time from 52 to 13 weeks. So is there anything super specific you would wanna mention about what you’ve done that made it such a great success story, apart from what we’ve been already unpacking?

Long Suciu: Yeah. So in this case, I was working as a consultant at the time for this team. They built APIs for the travel industry – basically database, API, client. They sold it and then different airlines could tap into their product. And they typically worked on features that would get deployed a year to two – like between one to two years after they started. That was just normal.

Long Suciu: And I got brought in to just figure out how to help this team work better. And we just wanted to better explore what is the customer journey when they’re using the product. And as we started breaking it down, rather than from a set of requirements – it needs to do this – what’s the journey of how a customer would use your APIs?

Long Suciu: And in working with the development team and the product manager, and then occasionally introducing that product manager’s director into the conversation, the journey started to break down naturally into features. And then from there, when they started to see all these different features rather than a set of requirements that need to be fulfilled, there was this aha moment where the product director recognized – I can use that feature now.

Long Suciu: And so instead of having to get all the features before releasing it as a product, the product director said, I could use that feature now. Can I get that now? And the team just worked on that. And so what led to the need to have a whole bundle of features before a public release – the product director saw a feature that could be immediately used. And we said, okay, let’s just go build that now. Let’s not worry about everything else. And they did that within the quarter.

Long Suciu: And so that incremental delivery started to become like, okay, let’s do things more – let’s do smaller stuff and get it out sooner rather than have to give the whole package. Because also at that time, the way that project team got created was the product director would essentially have to build a use case, it gets funded, okay great, we’re gonna fund it, we’re gonna give you this many people. And so they’d resource the team and it’s great, we’ve got this funding for the next two to three years to build this thing. And that’s how it was. Very much project-oriented.

Long Suciu: And we wanted to introduce, okay, maybe there’s a different way to do development other than the traditional waterfall way. Let’s do this incrementally and see. So let’s talk about the customer journey first. That just led to a natural conversation of breaking features up, of which when you get to see a feature backlog for the first time, and a product director would be like, I can use that feature – say, okay, why don’t you just do that one and not worry about everything else? Work on that feature and build that new API.

Patrycja Radwanska: So it sounds to me like a lot of what we’ve already discussed – the prioritization, step by step, understanding what’s needed, obviously having a conversation not only from a perspective of that’s the final outcome, but actually that’s what we should be doing one, two, three, and so on.

Patrycja Radwanska: That’s a great story, but now let’s revert and think about something that wasn’t that successful. Do you have any stories where maybe a transformation failed or an initiative failed because of certain reasons?

Long Suciu: Yeah, so often people develop new organizations and think we’re gonna split up like this and it’s gonna work out much better. So I can talk about an organizational change which was intended to help with a behavioral change that essentially wound up going back to the way it was.

Long Suciu: I’ve been working with a CRM marketing team that had decided, rather than how they were structured at the moment, which was very much around particular customer segments – they identified through analytics a whole new set of customer segments. And it’s okay, we’re gonna restructure our organization around these particular customer segments. And actually not only reorganize our CRM teams around those customer segments, but actually split into two larger groups and then sub-teams within that.

Long Suciu: So my question was, okay, I understand, the business case makes sense to me. Then we had to essentially change the ways of working such that one side – the more B2B side of it. So they were one customer organization and they split to a B2B CRM and a B2C CRM.

Long Suciu: So we had to split them away from each other. They worked in the same set of tools, actually even splitting the same customer base amongst each other. We actually needed now in the tooling to create two different customer bases for them so that they weren’t cross-marketing. So that they had ownership of their customer bases.

Long Suciu: From a transformational operational standpoint, we were able to get them to where they had their customer splits, they worked on theirs, they were able to work in the tooling in a way that didn’t cross over. But part of why it didn’t actually work out in the end was the split didn’t drive any business differentiation. So we did everything operationally to help support the business value of what they were trying to accomplish. But it didn’t help the business anymore.

Long Suciu: And then operationally, what it did was, when we split these people apart that had actually worked very closely together and collaborated on all sorts of things, it actually created a silo and a wall between these two areas that, when they were together, were tremendously collaborative and actually had a greater flow of ideas. But when they started to split, what adversely happened was they started to collaborate less. And that reduction in collaboration led to people individually relying on themselves to get stuff done versus that shared responsibility.

Long Suciu: After about 18 months, it just got collapsed again. The teamwork and operations were able to recover. And then we just reverted everything back operationally. I think there was a different type of differentiation, which was more of a high-value client versus a prospect versus a low-value customer.

Long Suciu: So from an operations person, what that taught me is there’s only so much you can impact. Your best service to the organization is how to help them try to achieve their business results and strategy. Stay connected to that, but don’t allow it to discourage you too much when the business strategy just doesn’t turn out to be the right business strategy.

Patrycja Radwanska: I think that type of failure always, any kind of failure doesn’t taste well. But there’s always a way of learning from it. And I think this is exactly what we were just unpacking here.

Patrycja Radwanska: We’re coming a little bit towards the end and I have one very practical question. Imagine that you have 30 days to fix a struggling product organization. What would you do in the first week?

Long Suciu: First seven days? It’s all about talking to people, looking at the tools, and understanding how they work and just obsessing about that. Whatever data you can – the collection of data. Talk to people, look at where the tools are, and then observe how people work.

Patrycja Radwanska: That’s perfect. And do you have any go-to diagnostic, anything that helps you assess how healthy or not is the team?

Long Suciu: Yeah. For teams themselves, I look at how big is their backlog and then what’s the frequency of stuff getting done. And if stuff is getting closed often, okay, then I have a whole other set of questions to ask from there. But it’s always about what’s the size of your backlog? How much work do you think you’re saying that you have to do, and then how quickly is stuff getting done? And also, what’s how big is your work in progress? How much stuff do you have currently being worked on?

Patrycja Radwanska: Because there might be a huge bucket of oh, there are all of these tasks that I’m still working on. Of course. Exactly.

Long Suciu: Yeah. Or we have started a hundred things. And how much stuff did you get done too, right? So how big your backlog is, how much stuff is being worked on, and how quickly is that getting done – these tend to be good indicators for the health of the operations of a team.

Patrycja Radwanska: That’s great. Thank you. I think at this point we covered all the main questions I wanted to ask because I’m super appreciative of all your answers and your patience. Thank you for that.

Patrycja Radwanska: But before we end, I would love to have a game, which is called Rapid Fire. So I have a couple of questions and let’s just try to get quick answers to those. Basically sharp in and out. Let’s see how it goes. Are you ready for that?

Long Suciu: Absolutely.

Patrycja Radwanska: Awesome. So one metric that every leader should look at.

Long Suciu: Flow efficiency. It’s the ratio of the time spent doing work versus the time that work spends being worked on. And you can think of this as being busy versus being productive.

Patrycja Radwanska: Great. Love it. Most overrated tool.

Long Suciu: I love tools, but I would say any OKR platform. And the reason I say it’s overrated is because at the current state, people believe we have this OKR platform, we’re doing OKRs.

Patrycja Radwanska: Just having the tool instead of actually doing the proper work.

Long Suciu: Yeah, because doing objectives, doing OKRs, it’s hard work and it’s messy. But oh, if we get the platform, it’s gonna be less messy. No, that’s not true.

Patrycja Radwanska: I love it. And then the opposite. So what would be the most underrated practice or tool out there?

Long Suciu: Yeah. I think the most underrated practice is keeping your backlog clean. It’s very easy to create tickets. It’s a hassle to review what’s there and to toss things out. You’ll always create more tickets than you can complete, therefore your backlog, a team’s backlog, will infinitely grow. But if you keep that clean, then you make things easy to find and easy to say no to and easy to say yes to. So inherently, just like in your house, the less clutter you have, the easier it is for you to find the things that you need and want. As well as find what’s missing.

Patrycja Radwanska: Yeah. That’s – I love the parallel and super true. And we talked about it a lot. Completely agree. Last question for today’s interview. One piece of advice for scaling teams.

Long Suciu: Start with trust and incrementally scale across. Because if you don’t think of those things, you’re at risk of possibly starting from a place of compliance for any type of scaling activity or change. You wanna be in a place of trust to get people to believe and understand and want to come along on your journey. A place of compliance will easily fall apart once no one’s watching.

Patrycja Radwanska: Beautiful. I love it. It’s a great ending. This was a super masterclass in actually making product and engineering teams work at scale, from planning and alignment to tools like Productboard and all the others that we just mentioned, but also the real operational discipline. So if you took one thing away from this episode, I believe it’s that great teams aren’t just agile – they are absolutely operationally excellent. And I think we expressed that, especially you, Long, within today’s episode. So I’m super grateful for having you in our series. And thank you one more time for all the insights and knowledge.

Long Suciu: Oh, thank you so much. And it was an excellent conversation. I loved it.