How to Develop Successful Product Marketing Workflows and Processes With Sergey Sundukovskiy From Salesmsg [AMP 256]

Great work starts with great workflows. How do the best product marketing teams structure their workflows? Today’s guest is Sergey Sundukovskiy, Co-Founder, CTO, and Chief Product Officer (CPO) at Salesmsg. Sergey talks about how to develop successful product marketing workflows and processes. Some of the highlights of the show include:

• Why product marketers should document & structure defined workflows/processes.
• How Salesmsg views product marketing and management altogether.
• Product Management Stages: Ideation, collaboration, construction, and transition
• Repeatability: Work is always the same; improves orchestration between parties.
• Product Marketing Debt: Things are just simply going to eventually slow down.
• Too many tools? Use depends on purpose and internal/external communication.
• Accountability: CPO is responsible for templates documenting workflow/process.
• Outcome/Result: Software adopted by existing customers should be measured.

  If you liked today’s show, please subscribe on iTunes to The Actionable Content Marketing Podcast! The podcast is also available on SoundCloud, Stitcher, and Google Podcasts. Transcript: Ben: Hey, Sergey. How's it going? Sergey: Hey, Ben. Thank you so much for having me. You guys have a wonderful podcast. I always wanted to come on, so thank you for having me. Ben: Yeah, absolutely. We're glad to have you on the show. A past guest, Justin Zimmerman, had recommended you. That was a fantastic episode, so I'm really excited to have you on the show per his recommendation. For listeners who remember that episode, this episode might be somewhat similar. That one was more about editorial workflows. We're going to talk about your area of expertise though which is more in product marketing workflow and process, looking at a similar topic like how does a team manage processes and workflows rather than thinking about in terms of an editorial team or a content team? What does that look like on the product marketing side? The first question I'd like to open up with is why should product marketers care about having defined processes and defined workflows? What's really the benefit to having those things documented and structured within an actual tool? Sergey: It's a great question. By the way, Justin is a very tough act to follow, but I shall try my utmost to fill the big shoes that he left behind. Before I answer your question, I am going to just talk about how we see product marketing altogether at Salesmsg. If you look at product marketing and management all together, we'll look at product management in four stages. It's the ideation, elaboration, construction, and transition. You can obviously have a single product manager fill in all four spots. You can go through the ideation process, go through the elaboration process where things are prepared for the development team—what we call getting the project shovel-ready for development to execute—then as soon as things are done, talking to the beta customers, and then eventually doing the rollout. Our process is fairly sophisticated. The way we look at how we do the software and whatnot and the actual rollout process is quite significant. If you look at product marketing—where does it fit—it fits mostly at the front end of the process from the ideation point of view as well as the transition because during the ideation point of view, it touches the customer. It has the marketing connotation. Also, as the product gets rolled out, it has quite a few customer touch points, so it also gets into product marketing. At Salesmsg, we split the product into these two disciplines. We could have done it horizontally where we would take multiple products and split all four stages between multiple product managers, but that's not the way we do it. We basically have two product managers either focused on the product marketing side—which is the first stage (ideation stage) and the transition stage—and then have another internally facing technical product manager that's working with the development team. When I'm talking about product marketing, it's the product manager that's externally facing. Now, why would a product marketer think about the process and the workflows? The way we look at the workflows—the key term here is documented and repeatable process. We want to make sure that all the rollouts or any product marketing activities are really repeatable. They are documented as much as possible and they're also repeatable. Every one of our activities' rollouts would be there on a monthly basis or as we roll out the product. It's exactly the same. In other words, all the augmentations that we do to make it better are carried forward, and the improvement, repeatability, as well as the work orchestration between multiple parties is always the same. Ben: That makes sense. I really do appreciate the thorough explanation of how product management and product marketing work at Salesmsg in providing the proper context for the role that product marketing actually plays within the broader organization. I think that's really important for listeners to be aware of in this conversation. What would be some of the potential pitfalls that product marketers could face if they lack sound processes? If they think that they are confident enough on a personal level amongst the team for people to just manage their tasks, their projects, and so forth on their own and if they work that way where you don't have defined repeatable processes, what are some of the problems that tends to give rise to? Sergey: It's also a really good question because what you're going to have is not necessarily the opposite of the benefits that I've listed. Some of the benefits are speed, repeatability, or orchestration. If you have a really small team and you have a single product marketer, you could basically say, well, I don't really need the process. I make it repeatable because it's just me. This is what I am doing and therefore, it's not going to be an issue because I always remember what needs to be done. The problem becomes that as the organization scales, all of a sudden, you don't have a single product marketer. You have multiple product marketers or product managers who are externally focused. It is going to be confusing for the remainder of the team if the process is always different between product managers. The expectation is not set, so it's actually going to take longer, and some things are going to get dropped. You're going to have some activities which are new, and some activities that normally get performed are going to get forgotten. Really, the outcome here as the team is scaling is you're going to have things that are going to slow down more and more. You're going to have what's called an operational debt or product marketing debt. Things are just simply going to slow down. Ben: Which nobody wants, particularly not in a startup or technology industry context especially. Slowdowns can be fatal so we really can't understate the potential impact that those types of issues can cause on a product marketing team. Let's assume that this is an organization that has matured past the point of having a single product marketer. You now have multiple product marketers who are all going to need some platform, [...], or tool to manage that team's work and to keep that team organized. But before we get to that point, first off, what roles do you think a product marketing team needs who are going to live in that tool and manage the work in that tool? Sergey: At the very beginning, we didn't talk about what product marketing is not. From its very name, it implies that product marketing sits somewhere between product and marketing. Again, it's not universal, but at Salesmsg, product marketing is focused on existing customers, and marketing altogether is focused on prospects, leads, and so on and so forth. There's a connotation on the product marketing side that product marketer is servicing, first and foremost, existing customers, letting them know about the features that the development team is developing and also allowing an opportunity for these features to get further adopted and so on and so forth. The coordination is that the primary role of a product marketer is to be externally facing and talking to the customers, and also be internally facing and talking to a technical product manager or the development team just to make sure that things are getting executed properly. The proper role is really a hub. The immediacy and suitability of that role is high. This role really can't be substituted because everybody from marketing, to design, to technical product management goes to a product marketer in order to coordinate this communication to the existing customers. Ben: That makes sense. What types of tools would the team need specifically as it pertains to supporting processes and supporting workflow management? Sergey: From workflow management, it's not coincidental that I mentioned different types of activities—communicating to customers and also internal communication. There could be different tools that are used for each purpose. If I'm talking to the customers, I want to show something to them and show some clickable prototype so I might use Envision or I might use something like UserTesting or TryMyUI. When I'm communicating the final finished product, I might use things like HubSpot or Intercom. For internal communication, we internally use Confluence or Atlassian Suite. For document management systems, we use Confluence. For workflow management, we use Jira. There are many other tools including CoSchedule, ClickUp, Asana, and anything you could think of that other product management professionals and other organizations use. We use Confluence and Jira pretty universally across the entire organization. We just use the same tool for development management, technical product management, as well as the product marketing communication. This always worked for us. But again, as I said, there are many others. Ben: Sure. If a product marketing team (say) doesn't have clear workflows or processes established right now, maybe they have some process that's just verbally communicated or understood, ad hoc workflows where people know generally what they do but none of it is really documented—none of it really exists within one given platform—or a set of tools that have their own place and purpose, what's the first thing that you would recommend they do to get started with first defining what those processes are and then figuring out how to document and manage them? Sergey: One of the things that you could do—something low-tech and requiring very few tools or common tools that are available—is to create a template. Basically, a template is just a set of activities that need to happen in terms of what, who needs to do what, and on what timeline. One of the issues with template is that it's very sequential. It goes from top to bottom, and none of the things are done in parallel, but at the very least, this is going to be a documented, repeatable process with a very sequential workflow where one thing follows from the other, which is not always the case because you can do a lot of things in parallel. In order for you to get to that workflow stage, you need to take that template and really put it into a workflow management tool like Jira, CoSchedule, or anything like that where you can actually shrink the timeline by scheduling a lot of things in parallel because they're independent of each other. Ben: Sure. Once the team has established what tools they're going to use—whether they're using the software that the company uses organization-wide or maybe they have something that is more purpose-built for their team or application—how do you then determine who becomes responsible for overseeing the workflows and managing the processes once they're actually in place? Who should really be managing the execution of those workflows? Sergey: Not all organizations have the same organizational structure. Depending on the size, there might be multiple roles co-located within a single role. For instance, my role is the chief product officer and chief technology officer, but I wear the two hats fairly independently. I would say that the process, template, or workload needs to be a chief product officer because the chief product officer is responsible for both software construction—in the sense of defining the software—and also the software or product rollouts. A chief product officer is responsible for the question of what we are doing? If the chief product officer holds that responsibility, then he or she defines the templates of how we are doing? It’s going to be communicated internally, so it can be developed, and externally, so it can be properly rolled out. I'm calling workflows as operationalized templates. I define the templates and I operationalize them, meaning that we can execute on them consistently. That comes up as workflows. The owner of those workflows is a chief product officer. It could be delegated down to a product marketer or a product manager, but ultimately, it's within the product organization. Sometimes, these templates are being defined at the marketing level and they're being owned in marketing, but again, depending on the different organization and organizational structure, things could sit in different places. Ben: That makes sense. The last question I've got for you. Once a product marketing team has got all these things in place, they have very effective workflows, they have very clear processes, everybody in the team knows what they're doing and when, and they know what everybody around them is doing and how all of those pieces fit into the bigger picture, what are some of the benefits that that team can expect to experience once they get their processes up to a maturity level where things are running pretty smoothly? Sergey: At Salesmsg, just as many other organizations, we're very much outcome-driven. Quite often, you will see processes. Most of the time, what people see as an outcome is time to market gets improved. We don't necessarily look at time to market. We look at value to market—the amount of value that you're going to bring to market in the shortest period of time. That's the measure. With the implementation of templates, workflows, and all the activities that are needed, what we're looking for is value to market. The benefit of bringing the product to market as quickly and as reliably as we possibly can benefits the company. It obviously does. Execution on the product marketing side becomes the competitive advantage. If you look at what companies are doing, some companies are just simply focused on one part of the process. They're either concerned about producing the software to the highest quality as they possibly can or they're focused on bringing that software to market as quickly as they possibly can, but they're not focused on the holistic approach which is measuring, at the end of the day, the software that they produce and get adopted by their existing customers. This is ultimately the outcome or result that should be measured. Ben: Awesome. I really love the way that over the course of this conversation, you've been able to connect why this matters in the first place because sometimes, surprisingly enough, it can be difficult to communicate why we need process, how to actually implement the process, and some pretty clear benefits if you can increase value to market, speed to market, or whatever it is that that organization might be concerned with. That by itself makes a pretty powerful argument for spending time in this area. Thanks so much for taking the time to come on the show. If people want to find you on the web or they want to find Salesmsg, where would you recommend they look? Sergey: Either go to salesmessage.com, or if you want to email me, email me at sergey@salesmessage.com. Or you could find me on LinkedIn. That's the best way to get a hold of me. Ben: Very cool. Thanks again, Sergey, for coming on the show. Sergey: Ben, thank you so much for having me.