Mega GTM Talk #2: Spencer Tahil, Brian Ragone & Pawel Nical on Where GTM Is Headed

Hello everybody. Welcome to an awesome session with Mr. Pavel Nikko and Brian Ragone. We are going to talk about processes today. And with that, I am running Growth Alliance and I'll let the other gentlemen who I'm very good friends with introduce themselves and we'll just kick off and go from there. Yeah.

Yeah, go for it, Brian.

Cool. Thanks, Spencer. I appreciate you having us. My name is Brian Ragone. I'm the CEO and founder of Puzzle. Puzzle helps organizations see how your operations fits together in a visual canvas so that you can make process optimizations over time. I've been running Puzzle for, wow, 6 and a half years now. I started the company in 2020 and it started off as a consulting company, and slowly I saw an opportunity to improve the way that people work with the big picture in mind, right? Understanding how your people, processes, and tools work together. And, you know, spend a minute on LinkedIn and you'll see how important that topic is these days, making sure that teams are orchestrating their technology in an efficient and effective way, making full use of the investments that they're making in their tools.

Paweł? Yeah, thanks again to Spencer for inviting both of us here. And yeah, I've been— I've known Spencer and both Spencer and Brian for a while. What I'm doing, I'm a founder of RevTech Accelerator. Accelerator. So I'm helping GTM and RevOps professionals to build advisory businesses based on leverage, not adding more hours to it. So also in the accelerator, we are actually partnering with Brian to bring puzzle and process design and design thinking to the students and founders who are joining to scale their agencies, fractional businesses, solo advisory businesses. So before that, I spent nearly 10 years in revenue operations. I used to be head of rev ops in a SaaS company that went from seed stage to private equity acquisition. So I've seen revenue operations and processes break at different stages of growth. And I think that's also a topic that is not that common to discuss, but your process design and in general process transformation can have completely different challenges at different stages while you're growing. So I believe it's a super important topic and happy to dive into it. Together with you both.

Amazing. So I think we were going back and forth on LinkedIn and there was, there was a little snippet that Brian, that we were talking about in the comment section. I found it really hilarious. We were debating what comes first. It's like a chicken and an egg kind of situation in businesses. We've all done consulting here. So explain to me kind of the 6 Ps of Puzzle, if you've got them at the top of your head. And kind of where, where processizing automation comes into play is that, you know, are we looking at the human side of the puzzle first, or are we looking at kind of like the AI side of the puzzle first? Because I know that's a giant conundrum in our industry right now.

Yeah, you know, it, here's the 6 Ps. It's poor process planning leads to piss poor performance. That's, those are the 6 Ps. You know, every day I log on to LinkedIn or see an email or scroll through some of my Instagram, because I get a lot of business content, I see someone preaching, not preaching, but like advocating for process documentation. I don't think anyone would disagree that process documentation is a positive help In making decisions around how to optimize how you're using technology and also how you're organizing your people. The conversation is really about, is it worth the time that it takes to do the process documentation? And it's one of the biggest hurdles that as someone who's selling a product for process documentation and visualizing your operations, it's a hurdle that I commonly have to help organizations get over. Well, when our MCP went live, it made it a whole lot easier because now you can just talk to Claude or talk to ChatGPT or any, you know, AI agent, and it can go to Puzzle and map out your diagrams better than I ever could, to be honest. It does an incredibly thorough job doing that. And so now that we're past the amount of effort that it takes to document your processes, We are now at the point where it's just a habit. It's just a habit that you need to build so that your entire team is just, after you make a change to a system, you just tell Claude what change you made, and then it will go to Puzzle, look for the existing steps. If there are no existing steps, create a new process, and then log that change in the changelog. And so it really becomes a habit change. Now, and whether you do it for your people, human in the loop processes, or you're doing it for AI tech processes, it really doesn't matter. I mean, there's not one that you should prioritize. It's just a really, the prior— prioritization factor is what process is being run the most often and is most confusing. And so that literally, that usually leads you to a place where you're picking like a, a sales process or a customer onboarding process. Start there because those are really like the 2 processes that I won't, well, matter the most, you know, which is you're making sales and you're onboarding your customers so that those customers stick around for a long time. And then from there, you can slowly start to build your processes around in the infinite canvas. Paweł, I'm curious to know though, how did you build out your puzzle? Like, where did you start when you were documenting your processes? Which one did you document first?

Yeah, I think I'd start even, even one, one step earlier, just on the observation, general observation that you've mentioned. I wanted to add something there because, you know, we talk for years, for a long time about data hygiene and the CRMs, for example. And there is a function that owns it. And I had a function within the RevOps team that I've been building who was taking care of data hygiene on a regular basis. No one is talking about process hygiene, almost no one, and almost no one is owning it. So I think that process design and in general, the quality of how your processes are documented is also an ownership problem. Because we talk about, you know, who owns the systems? Is it IT, RevOps? Who manages the system? There is an owner. Who manages the data quality? There is an owner.

Process.

True. You know, okay, like we have some process in marketing and sales and something, someone can glue it together, you know, I think that's, that's one of the biggest problems because change management is arguably one of the most difficult things to do. And if you don't have the owner of that and you cannot do the changes on a regular basis and map when When the things break or need to onboard a new hire, like usually it's just based on impulse. Oh, we have a new hire in this department.

What are our processes? Let's look into Notion.

Oh, okay.

This is 2 years old.

I need to map something out, but we don't think about it as seriously, or we haven't thought about it for a long time as about the data, about managing data, managing systems, or managing people, I would say.

So I think that's, that's one of the core problems that I'm seeing.

Just, just wanted to add to this discussion, maybe we want to hover a a little bit on that. I would love to hear also Spencer's perspective, and then I'm happy to jump into saying what I actually started mapping for myself.

I mean, I think what you guys just said is like really big. It's, uh, when, when I talk to large companies, it's like, who is the owner of the system, right? Like, Pavel, I know like you and I do a lot of talk about like CRM hygiene and, and what it means to own a system and what it means to own documentation. And I think Brian, like, We've gone back in time a long time ago and just said, it's like, what is this living documentation? So, and I, and I think that's a huge issue that continues to persist is that like, who will own this and how many people or hands or eyes or systems does this documentation touch? And the more complex the system or more complex the team, I think it, it, you need to document these things and people, people inherently aren't great at writing things down unless you're a scientist or a journalist, right? So. My opinion here is that the more systems you have, the more architecture you have, the more people you have, it just becomes infinitely more complex. And I think our jobs as process engineers or GTM engineers or revenue operations personnel, or even AI people, whatever you want to call us, I think it's our job to be able to put information there on paper in a way that somebody can digest it. I mean, just today, for instance, You know, I have a friend in the industry. She saw me on Instagram and then she saw me on LinkedIn. She's like, oh, you do like AI stuff? I want to build an app. And, but I'm a visual learner. Can you like get me a proposal, like something I can look at? And I was like, I know it's just the tool for this, but I think that that's a really good point to make as well. It's like, no, not a lot of people, even if they're making the decision to invest in documentation or whatever it's going to take, however you're going to say that, not a lot of people are going to be able to read 60 pages of documentation. They're probably just going to log into Claude or something like that and query their data now. And I think like, that's the age of where we're going now. For the visual learner, I think Puzzle is just amazing. I mean, it's just, you could see everything in a heartbeat, just search for it. But I mean, I think that's the direction of the industry right now. It's like not looking at things all the time, but querying your data and querying your documentation in natural language. I think this is where everybody is going. I don't know if you guys would agree with that or not though.

I, I do agree with it. I do agree with it. It really comes down to what is your, uh, data source for what Claude is referencing to get those answers. And in my opinion, you need a stable database that is not a second brain that has 400,000 files that might be competing in information, especially if you're working with a larger company, right? If everyone's contributing to this second brain and there's competing information and you can't really navigate the information and update it yourself in a reasonably fast and intuitive way, then you're just going to create a bunch of like, I don't know, I guess like knowledge debt. I'll call it knowledge debt inside of your knowledge base for how organizations work. And, and so my, in my opinion, you need a database that has structure that matches how an organization works and is easy enough to hop into and understand and tweak that information if there is inaccurate information. And that's why I think Puzzle is, you know, best in class for this type of use case because it's visual, right? So you're not lost in things. There's a team canvas, there's a tool canvas, there's a process map. And so, you know exactly which parts or components of your organization you need to go tweak or update. Because, um, you could just prompt Puzzle, for instance, for a new hire playbook, and it could write it in a written SOP-like format, even though the database that it's hitting is highly visual. And so, as we're interacting with AI agents and we're starting to manage more systems, What, what becomes curious to me is what does managing systems actually look like? Like the same way that we have one-on-ones and we have ongoing trainings for people, right? What, what are the ongoing maintenance tasks that we do for our systems? And we talked about it, you know, data hygiene. I think documentation hygiene is another thing that should happen because it's a place that everyone goes to. to expand how the system works. And so, as managers start to shift from managing people and managing systems, I think the tasks and time, the tasks that they spend time on are gonna change. And I think one of those things is contributing to a company brain, which in my opinion should be highly visual and an interface that people understand and the AI agent understands for organizational structure. And those are all of the components that are found inside of Puzzle.

Yeah, I would say I would add to this that people consume and digest information and in general company structure across different layers in a kind of in different levels of depth. And if you try to overload them with all the data just in text, as you've mentioned, like I've worked in several companies where I needed to both onboard people or I've been onboarded, and I think the biggest problem for me to understand is how it all connects together. Like, I could read through many pages. I could even go through those percentages on Confluence or other platforms, you know, where there was onboarding prepared by someone, even some custom platforms for onboarding employees. I used to work with a company that had an amazing 2-week onboarding experience, both in person and a platform dedicated for that. But the problem was there was so much information, so much context being added, but I didn't know which one to focus on, on a high level for my role and which one to get deeper into and to deep dive. And if you don't have it visually kind of layered, and if you don't have, I would say, zones into which some people, salespeople need to go deeper, but marketing maybe not necessarily just understands the bridges, like you will get into a lot of confusion. And I believe that's one of the biggest problems with documentation in general, that we are not doing it in a layered way and visually kind of showing how things connect with one another. And I think that's also what revenue operations tried to fix on the operational side of things when it was coined. Earlier, we had sales operations, marketing operations, customer success operations, all kind of, you know, having their own playbooks, their own processes, their own systems, their own data, but then came the time and I actually started my operations journey in sales ops. I didn't know what marketing is doing. I didn't know what customer success is doing. I didn't know what the strategy of the company was. I was just asked, said like, you need to help sales to operate better, but I couldn't kind of place it in the entire company strategy and what's moving. And we ended up overlapping some of the functions and we lost momentum. So what I realized is revenue operations is what's coming next.

It's needed.

You need to look at your entire end-to-end revenue journey from the internal perspective, which is reflected by the end-to-end customer journey from the customer perspective. And if you have friction inside and you have broken processes, it's a friction that the customer feels in the customer journey and you're losing money. There is revenue leakage, there is gaps, there are lost opportunities. So I would say it's no longer a nice to have, to have things documented. It's actually the first step.

Mm-hmm.

To fix the broken parts, to fill the gaps, and to spot new opportunities that are there. But if you don't see it globally and then can go layer deeper into that, each function can actually fix what's not working and can tap into opportunities. I mean, you're losing a lot of competitive advantage. You're losing a lot of internal data insights and handovers between teams that can be experienced by your customers. So you're After all, you're losing your customers or they churn earlier, so you're losing your lifetime value and in general your revenue potential. So I would say it's no longer a thing that you can just say, oh, maybe I'll document it one day. It's something that you need to actually intentionally build and upgrade your revenue engine. So that's how I've been seeing it in companies, the ones that documented it better and that really knew how to speak and connect things with one another.

They were growing faster and they were growing better with leverage.

Those that were messy and get chaos to kind of deal with, those were moving slower and were losing a lot of market opportunity. So yeah, that's my perspective coming maybe from the sales ops Revos background, but I think that's pretty relevant in the times we live today.

So my question is, is people that have worked As consultants, both of you guys own your own practices, have coached, have mentored, did all of that. What's something that a first-time founder would probably miss? You know, uh, when they're trying to do their own documentation, if they're not using a tool like Puzzle, if they're not using AI to help them document something, what's something that you guys see within the first 5 minutes that you help them solve for?

Oh, you want to go first?

Uh, sure, sure.

I can, I can go.

I think for the first-time founders, and, you know, I believe that you should work on foundations early on and not leave it for the time that you say, oh, at some point I'll hire an ops guy or girl or a founder associate who will fix my mess. I would say the first thing is, do you have your key information About running your business in one place, even if it's just a Notion page, where if you are about to hire a person for any type of role the next day, you actually have something to show to them that will have meaning and that will buy back your time as a founder. If you don't have that and it only stays in your head, it means you're not ready to scale.

So I would say like, even on discovery calls as a consultant, with companies, I like to ask a set of questions that help me to diagnose what is the GTM maturity of a person on the other end. And many questions of those are like whether they know their own data, like what, or whether they have strategy or any goals. What are your goals for the next 6 to 12 months? What is your ICP, ideal customer profile? If I just get a response as 2 lines, and do you have any documentation on that? If I just get, oh, we don't have it documented. But here are 2 lines. Those are all tech companies between 500 and 5,000 employees in Europe. And I'm like, okay, if that's your ICP, I know we have an ICP problem. You know, I'm not telling them yet, but I'm discovering further and I can figure out they don't know, like they don't have a playbook they work around, but there are companies that give you, oh, this is the document we had on our leadership strategic offsite, like last quarter. Maybe it's not fully up to date, but here you can read through it. And we believe that we don't have the clear ICP kind of scoring, et cetera. We would like to work with you on that. But this is what we have. I mean, then I'm feeling okay, I'm talking with someone serious on the other side. So I mean, if you're a first-time founder and you want others to take you seriously, not only the people you hire, but also partners you work with, etc., you should have something from which you can give out without spending a weekend to actually try to patch something from your brain and from the stack of emails or Slack threads. So that's my take.

Beautiful, Paul.

That's nice.

As a solo founder of a tech company, one thing that I oftentimes run into is I have a flood of ideas come to me every single day about what I could possibly do, what I could possibly experiment with, whether it's GTM, whether it's features for the product, whether it's email copywriting, whether it's onboarding ideas, I'm constantly thinking about different ways that I can improve my system, right? Which is attracting, closing, and retaining users for Puzzle. And that system right there has so many different things and possibilities of being engineered. And I think my biggest piece of advice for first-time founders is have a store, a database of your operational ideas. So that you can get them out of your head. And so you don't operationalize and over-engineer just because you want to get it out of your head, right? So instead of, you know, building that thing because it's fresh on your mind and you just want it to get live and it takes you completely away from what you planned during that specific day, write it down. Write it down. Spend a few days just thinking about whether or not it's a priority right now, and then implement it when the time is right. I find myself, I commonly, you know, I'm on LinkedIn and I see a new tool and I'm, wow, I feel like this possibilities. I think about the possibilities. It's a shiny new object. I'm ready to implement it, but I have to, I have to learn. I have to learn. I say, hey, pause, I'm gonna put this in my tool canvas, or I'm gonna put this in whatever operational store that you wanna put it in. Mark it as considering. And sit on it for a few days until, you know, your schedule clears up or on a weekend, spend 1, 2 hours on that idea to figure out if it's worth implementing into your system. And so that's been a huge, huge productivity, I'll call it a productivity savior because it's not even a hack. It's saving me from myself in a way. So I would recommend that for first-time founders.

So that also brings me to the loop of bullshit, as I like to say, of you see something shiny online. I mean, I do it all the time. I'm like, oh, Claude code this, you know, Clay that, whatever, you know, we've all succumbed to this sickness that, that is buying software that we don't need. So, you know, when I've gone and consulted with larger enterprise, they see that shiny object, they see their competitors using, let's say, a tool like Claude or Clay or HubSpot. HubSpot's a really good example of This, right? Oh, we need that, that marketing automation software, or we need Zapier. So what I've always tried to do is I've tried to slow down the buying cycle. And I know that sounds kind of a little silly, but I would love your takes on this because if I'm not able to map the process before the tools get implemented, I feel like it costs a lot of companies a lot more to get rid of that bloatware. At the end of the day, right? And I think matching the tool to the solution to the problem is the way to go. So it becomes more of a process and change management focused engagement, at least at the scale that we're working at, rather than kind of just saying like, we need that tool and then not utilizing all of the features. And, and I would love to know, right, really, like, even like firsthand experience, like, at what point in time do you guys start to actually map those processes out? Is it before buying the software? Is it After you guys do an audit of a business software, what are the types of questions that you guys ask before you start to look at the process or even build the process map? Maybe Paweł, if you want to kick off there.

Sure. Yeah, I think one thing that you've mentioned, it kind of stayed with me.

You mentioned slowing down the buying process. It might feel counterintuitive, but I've been doing it myself, like when selling consulting services. Because I realized at some point that I cannot sell a good transformation project for their business that really will drive impact and then eventually upsell if I don't know what's going on and I don't know what the direction is, what the priorities are. And to be honest, like 1-hour discovery call will often not answer this for an enterprise client. And I've had big companies coming. And they said like, oh, we actually are thinking of buying Clay. Exactly the same thing. Like they start from the tool, not from the strategic priority and from the process where there could be these gaps or opportunities that they want to spot. They say like, oh, Clay is a big thing. I saw that you're doing Clay stuff. Like, could you help us to do something with it? Or even, even better, like some people already told me, we already bought Clay Enterprise and Gong Enterprise. But We have only one enrichment flow and we paid for it 6 months ago and we're paying quite a bit of money. Can you help us to find, like, to fix and find some use cases because we want to find, get an ROI from it? And I mean, like, you know, from consulting perspective, you might say, okay, this is a great client. You already have these things there and you just bring, activate something and they're happy.

Yeah.

But I mean, to be really a meaningful trusted advisor to company, you need to first answer, like you need to ask them questions. You need to understand what they actually want to achieve, what's going good, where there are gaps, what's slowing them down, and then to map it out into what I call RevOps roadmaps based on the gaps and opportunities that you spot. So what I mentioned earlier, it's actually a blueprint that I've been using with clients. So after the discovery call, I offered when I was still doing projects before launching the accelerator, I was offering something between the 3-month or 6-month project, which was a deep dive workshop to map your priorities, map the potential processes and initiatives and projects that we can do, then to actually prioritize them on the matrix, which is the effort that is needed and the estimated impact, and then to put them in time on a, for example, 3-month roadmap. And this becomes the scoping of our project. It's a half-day workshop with a pre-discovery framework, then the live workshop, and then the summary and synthesis in which it's done with you, not done for you, in a way that you sit with stakeholders on the other side and you extract information from them. But before the workshop, you also get some async data so we can model Why it works? Because like you add a step, you're slowing the buying cycle by a few weeks, but what you come up with is actually the roadmap that the leaders in that company co-own with you as a consultant.

Wow.

And I will, it's been like the biggest transformation for me. I've been able to sell after such workshops without any negotiation, like $40K+ projects and then to upsell them to another 3 months. Because we actually pointed to the problems that had impact on the business and that stakeholders like CMOs, heads of growth, and others were in the room, VPs of sales, no one was left outside and they were bought in. They brought their budgets, they confirmed it with the leadership and they wanted to be active and actually those engagements were the best one and where the internal stakeholders own the thing together with you and you're not left alone, just fix this chaos for me, fix this mess. But you actually start with something. So you would say like they already wanted to pay you $30K or $40K without you getting this workshop.

Is it needed?

I would say adding that $3K or $4K workshop step and then selling it to a bigger workshop and then having an upsell opportunity on that and having already the trust and momentum. I mean, it's been a much better client engagement for me than going straight into big offer and trying to sell it. Anyhow. Yep.

So I also split my consulting services into 3 offers. The first offer is a current state assessment, and then the second separate offer is a build future state. And the reason why those 2 are separate is because there's a very clear, like, veil that we pass through. And that veil is only passed through if a customer looks at my puzzle scope, which that's how I scope out my consulting services is I show them the process that I'm going to build them out. They need to give green light on that process documentation. And we have a meeting where I walk them through the process documentation. They say, this is what we want to achieve. These are the tools that we are looking at, and these are the outcomes that it's going to produce. And once we get a green light, that's when we start to build out the actual system. The reason why that works is very similar to what Powell says is we have buy-in. We're ready to go. And it also helps with scope creep because sometimes when you're deep into building systems, it's very easy for someone to say, well, I thought we were going to build this workflow. And they're like, well, it's part of MailChimp. Why aren't we building? And so if you define things just through technology, you are in for trouble. You are in for trouble because You can do anything with technology. So, so it's like essentially an infinite scope. So, it's very important that the process is the boundary to what you are building with that technology. So, I believe it helps both parties. I think it helps the organization become very clear or the client become very clear on what impact they're going to be solving with the thing that you're building. It also helps the consultant. To be very clear about what's in scope and what's not in scope.

I love it. Process as a scoping tool.

And also, yeah, and it's something—

PRD, PRD. I call it a PRD, but it's not product requirements document. It's process requirements document. Yeah.

Managing expectations, like the biggest nightmare of every consultant, like early on, like Yeah, let's implement Clay. Let's even like, let's do an, let's build an outbound motion or inbound automation.

And then you even put the bullet points on the contract.

What is scope? And scope creep is like, is unavoidable.

Like even if you have something written down, but it's not very specific.

This is where we are, current state. This is how the process will look like after that. Here where technology comes, here where actually change management on the people side needs to be. I'm doing enablement. We need this data, et cetera. I mean, that makes it so much clearer. And I think what you've, you've mentioned, Brian, is really spot on, like change management and managing expectations with process design and having buy-in and green light on this before you start building.

I think that's an antidote to a lot of problems that consultants have.

I actually really love that, uh, where, where you're actually getting the process approved. I mean, this is like kind of silly to say because we all have to get a, give a scope of work document, but having a visual process diagram that then gets stamped or signed and approved and be like, nope, that's not in scope. Yep, that's in scope. This is, this is something that I know that like large implementation teams and also like legal teams need to get a handle of as well. This is just very interesting that you, you think about this and this is how you pull your engagements, for instance.

Yeah, I'll quickly add to it, Spencer, because obviously, you know, You go through a current state discovery, you start to get in the tools, and sometimes what you promised is possible in a different way, or there is a small little tweak that you'll accept post kind of scoping. And so I also have a test and iterate cycle. So there's current state, build future state, and test and iterate. And I build one test and iterate cycle to kind of handle those gotchas. that you just didn't see, or something did change fundamentally in the 2 or 3 months that you're building. And so I do have a catch for that, but overall, I do think that that veil and having the PRD still makes it very clear what those iterations are and making sure that you're within that one cycle of iteration.

I'll add something here. Like you said about PRD, I have another acronym that I'm using in the process context, but everyone of us know it in the product context. MVP, minimum viable process. Like if you are starting from scratch and you want to start iterating on something and you don't want to say we go from zero to a full process design without any iteration feedback from internal teams or for the, from the clients, whether it works.

Like you need something in between. You need to have a phased process design, but to start somewhere. Think of an MVP, minimum viable process that you can get running even tomorrow, or that you can just get from the interview with a person internally that never got mapped. You map it out, you have it, and maybe some small fixes or kind of like, this is the process. We've done it like in a cowboy style so far. Let's do it, you know, in a structured way. Let's do an MVP and then let's go from that to V1, V2, V3, V4, and at the end of the engagement, I usually work in like biweekly sprints with companies and every biweekly weekly sprints we can do V1, V2, V3, V4 of this process and after we got there, like they feel, oh, we actually improved it 5 times during the engagement. It wasn't just from zero to the process without any feedback, without any iteration. So they see more impact, more value for the team and we are again co-building it. That's why I love to work on done-with-you projects versus done-for-you model. Because there is such a gap in between on context sharing. If you just go and after a month you come with a process that you've designed after observing things, but you've never tried it in real life, you didn't have an MVP and you didn't have the like versioning of it. So I would say versioning, process versioning. I mean, like so much analogies from product development and product iterations in the process world. And I think process should be treated as a product within the company.

Absolutely, Paweł. And it's, it's, you know, we launched our feature in, in Puzzle called changelog. And that feature usually is for product changelogs, but it's true as we're, as organizations become more so run by systems, it's really like a multi-platform product. Right? The only difference between a single product and a multi-platform product is that you just are dealing with off-the-shelf tools that have their own database and fixed features that are evolving over time. And so, operations managers are very much starting to take on more, or GTM engineers are taking on more of a product-like role where documentation is super important for any product team. They understand how important it is. And so, you know, operations teams need to kind of catch up in a way, or, or learn that documentation is super important in order for you to build a minimal viable process, have clear process versioning, and then write up process requirements document. I love those terms, Pawel. We gotta work on a little cheat sheet for operations teams there.

Yeah.

I mean, I mean, we should, because like we're talking about a process layer and even like there are so many product-related kind of best practices getting into GTM and into RevOps. And I think revenue operations was one of the first areas to adopt it, at least when I was building a RevOps team back in 2020. And it's not been yet a very popular term here in Europe. So in the US, it's been there for maybe like 1 year or 2. But people were not calling it this way. I've been head of growth and I called my team growth management because I didn't know the term. I wanted it to be something like business growth, you know, we were working with sales, marketing, something with finance and product, building bridges, et cetera, what it can be. And then I somehow came across the term RevOps and I'm like, oh, 80% of what we're doing is actually revenue operations. So then the next day I pitched it to the CEO and I became head of RevOps and I built a, like renamed it to the RevOps team, but I mean, I loved the term and I I loved the idea of looking at revenue holistically. All of us are contributing to the revenue, all the layers, the human layer, the systems layer, the data layer, the product and everything else, like it all needs to be tied to the business impact and to the customer experience again on different stages of engagement and what I'd like to say here is that the Probably the most impactful kind of tool or the way of working that helped me to align all the people in my team and with the stakeholders was introducing a RevOps roadmapping process, having a quarterly RevOps roadmap to know what we're actually working on, what are the priorities, and to put it in time. Otherwise, nothing has been done and we've been firefighting, and firefighting is the biggest nightmare of anyone in RevOps will tell you, like, you know, those Slack requests everywhere, like CRM, we need to add this field. This is not working. Why does Validation and et cetera, right? But I mean, if you have a roadmap, you can say, okay, like I'll put it in the backlog, like what you, Brian, said, like even from other people, I'll put it in the backlog, we'll revisit it. If this is a higher priority, let's discuss it on our leadership team meeting. But what then we want to move and reprioritize from the thing, even internal kind of team management is super important. Otherwise, you have scope creep also being an internal RevOps person. It's both in consulting and internal world, but roadmaps Classic, like in a classic setup, it was a product thing. Now we got revenue operations roadmaps and we need to have GTM engineering roadmap. We need to have a roadmap for any process and system that we are actually working on. So I would say roadmapping is really great thing. It's kind of like allows you to structure things and to put them in time and I believe that's something that is missing in so many documentations, they don't have these 2 components, like the holistic view and set it in time.

Paweł, can I, or Spencer, Paweł, can I share my screen real quick?

Yeah, absolutely.

I would love to just show you the changelog feature here. So what you're looking at here is my operational blueprint. And right now we're in the revenue operations tab, but there's a ton of other tabs. There's outbound processes, inbound processes. I even have one called GTM Labs, which is all of the ideas that I have for different GTM plays, product support, you name it, right? Finance, strategy, IT. All of these processes, each one of these steps has a sidebar where you can see, let me go to a more interesting step. You can see all of the systematic documentation in this right sidebar. And so this whole workflow canvas is connected to a changelog, and this changelog you can see in a Kanban board. So when we're talking about roadmaps for what we're working on, you can see the different things that I'm working on in terms of improving my processes. For instance, this first build nudge sequence— if I click on this thing, I have my process requirements document, which details out all of the rationale behind the system decision connected to all of the steps in the workflow canvas and all of the tools that it touches. And this has a status, obviously it's in progress, completed. We can do completion date and you have owner, right? So you get a clear view on all of the initiatives that you're doing as you're evolving Evolving your system-led operations over time. And this changelog emulates a lot of those roadmaps, I think, Pawel, that you were talking about to get clear on what are the things that are planned? What are the ideas that we have about what we want to do? For instance, this one is a cargo company enrichment. It has no steps tied to it because it's just an idea. But once it's into plan, the expectation would be is that there's some documentation in the workflow canvas about how that specific tool would be used. And then your whole team can just query this by Claude. What are the initiatives that are recently completed? And you literally have change management orchestration done for you because Claude has all the context of how the processes work and memorializing the rationale behind why that decision was made and who it impacted. I think I just wanted to quickly show that right there.

It's amazing. And actually, I think changelog wasn't there like even 2 weeks ago, right? It's a new product feature. And I think it's been one of the things that, like, I mean, if I would see this product, like, and with this changelog and everything that I've seen in Puzzle and used for last 2 years when I was the head of RevOps back in like 2020 to 2023, like, I mean, this probably would be the first tool that I would buy for my team.

Yeah.

I mean, we had a struggle with this. I had something in Miro and Google Slides and Notion in our internal channels and I mean, I couldn't stick all these things together. It just wasn't possible, but I needed to map somehow people, processes, tools, data, and all of this together and I needed to set it into a roadmap so other stakeholders can see the rationale and to know who is owning what and I mean, I've been doing it in so many different tools and, you know, we introduced Jira, but Jira was super technical and I felt like, no, maybe not. So let's use Notion for that and Notion, it all was breaking because someone added something or deleted, you know, and I mean, I think this is something that many people are still maybe not looking into so seriously yet, but they will need to start doing that because the complexity of the world we live in, of technology, of process complexity, data, all the things, like, I mean, and we're not talking about only humans now, like, we now add agents to that. Like, I mean, we've already had a lot of mess to deal with. Like, I mean, And now AI, it runs on context. So if your context is one big mess, your GTM process context is one big mess, you'll be accelerating at a speed that you can't imagine, but you'll just be accelerating mess. So you'll get to the wrong direction faster while it costs you a lot of money. So it just, you know, it's getting more expensive to do things just on a napkin. And then it will just get you to, to the wrong outcomes. Like we cannot, I believe we cannot ignore it anymore and we need to have some place to centralize it.

So I'm pretty excited about this, like that you can now put roadmap management and change management for client projects also based on, on the changelog that you see within your processes.

Paweł, I just wanna, I wanna share my screen one more time cuz you're jazzing me So I'm redesigning the Puzzle onboarding flow. And you can see here, I actually just chatted with Claude and Claude went ahead and helped me design the new onboarding flow. And the cool thing about Puzzle is like you get this context, this deep documentation here, which goes further than something like Miro, Whimsical, or Lucidchart, because usually this would be a sticky that isn't attached to this particular step. But when you're asking AI to do work for you, this level of documentation becomes very, very useful. Plus you can add attributes, which represent like the fields that get filled out across a particular customer journey. So you can see this one has 6 different fields that get created once the user inputs their company name, and we go and create all of this information in our Postgres database. I went to Claude and I said, hey Claude, I've structured a spec for a new onboarding process. Can you design it in Figma? It took this spec and built me out a high-resolution design on my new onboarding experience that is like mainly putting Nova at the center of building their first map with notes here about everything. Nova's building your first map, and then they get dropped into the product. This together took me 15 minutes to go from an idea about how I wanted my new onboarding to a high, a hi-fi onboarding process inside of Figma. And this is what's possible with deep documentation, documentation that actually can hold systematic information as opposed to dumb diagram. I call them dumb diagrams. In Miro, Whimsical, and Lucidchart because they're just basic. They can't hold the depth of documentation that AI needs to create a phenomenal output. You can see this input right here on the first screen when people create their content, their account. It says, what are you here to do? And it asks them the kind of their use case. This is, uh, us from this select onboarding intent right here where I said, hey, let's go ahead and have them select. Are they here for process procedures? Organize their systems, optimize, automate, or align, for instance. Yeah, sorry, these 4: organize, optimize, automate, and align. So just awesome level of work that AI is able to do when you have that deep of documentation.

That's crazy.

I mean, I even imagine like, I think like I've been working in the past with some web design studios and I'm thinking they're doing wireframing and, you know, and then they are Doing your website, it takes a lot of time, you know, from here, from here, and you could have a design system and other stuff. But now I'm talking to some founders, you know, in web design studios, et cetera. They connect it all together and you can design a brand system. It's connected with Figma, then you can do deployment and using a lot of AI for that in a structured way. Like, we are not doing that in GTM.

Why?

You know, or in RevOps, like we were years behind, but actually this can get you from idea to impact, time to impact can shrink from days or weeks into minutes or hours. And this is just the example. And, you know, I'm just really excited about this coming to actually doing a structured RevOps work, structured GTM engineering from design to execution. It can like, or from idea to execution, it never has been faster, but you don't want to go from your idea to execution, just prompting again without any context in ChatGPT or Claude.

And then you're like, oh no, I need to iterate. And then you iterate for 3 hours, you spend a lot of tokens and you're still not happy with your result.

Why?

Because you don't have systematic context that is recorded somewhere that the next time you do it, you don't need to start from scratch again. And I mean, everyone is talking about context engineering in AI.

We are not talking about process context engineering. In terms of GTM. And I think we should.

But, and I think that's a really good place to start talking about why it only takes you 15 minutes now, where it could take you 15 hours or 15 days, right? The power of, I mean, tools like Claude, Codex, whatever you're going to integrate with. I know, Brian, you've been trying to get me into using your MCP a lot lately, right? This is the, I think this is the age where we see 10x the time And we see 10 times faster deployments. I mean, also shout out, Pavlo, your quote was actually inside of the screen share in the onboarding procedure, Ryan. I peeked it. That was Pavlo's quote. True.

Yeah.

And I think being able to pull systematic context with something like Claude, like I'm a big Claude user, into these deployments and have all of your context spread out, but in a very well-labeled manner. I think this is a lot of the context that a lot of marketers, and dare I even say it, salespeople just lack organization around. I think when we come from the operations side, we know how to micro-label, we know how to put labels and tags and groups and, you know, actually organize the data in a way that makes sense to us. But to us, it makes sense. To a technical guy, it makes sense. But maybe to marketing and sales, it doesn't. And I think that this is where I've used Claude to be able to say, hey, Claude, translate this strategy into something else that, you know, the CRO or the, you know, the associate buyer is going to understand, put it into their own words. And I think this is just as simple as you guys are making it. It's just saying, hey, we've got this context over here, we've got this documentation, help.

Right.

And I'm just amazed at it. Where I see a really big struggle is where I go into teams and their context is in Jira, it's in Notion, it's in all of these different context layers.

Yeah.

Which is an issue by itself entirely. But how are you guys organizing that when you guys go in? I know that you do like an audit. I do the same thing. How is AI actually accelerating this? I know that we don't want to do like a, you know, minimal viable product, but a minimal viable process map of, hey, we need to focus on this P0 item in go-to-market strategy rather than, you know, spending our time looking at HubSpot. Because everybody knows you can't send a bajillion emails without emails or buying the email addresses, right? I know it sounds like really simple, but this is a process and the framework can be translated, but maybe the application layer can't be. Either way, the context has to be there. And I think a lot of marketers miss that. So is there any place— I know, Brian, you're more on the process side, but maybe Pavel, you have some insights here from some of your students. Do you templatize or do you framework a lot of your processes? And, you know, where do you see AI actually like affecting this as far as teaching moments or even documentation for getting started on that?

I can start here because it's actually something we are also doing together with Brian within the program.

So in the accelerator, because it's kind of like we can go deep with people because it's only 6 people per cohort and all of them are building businesses. So those are founders. Fractional people, advisors, or agency founders, like, I mean, we can go pretty deep on workshops or we had some additional sessions, one-on-ones where people are building within the tools and what I believe like is key is that you find some use case that you start with and you're actually starting to document them in a tool like Puzzle. I know that some people still, you know, like some people come and they say, I've been using Miro so far. And that's okay. Like they've been having this and then they see the option, I can upgrade, right? But they at least have something. I'm rooting a little bit like, you know, coming back to the beginning where we told like GTM maturity of a person on the other side of the table. If they don't have anything in their mind or they don't see the problem and they're not aware of that it takes some time to do it, like they will probably not appreciate need it that much and those are usually the users that with AI as well, like they never look into the more powerful features of Claude or, you know, of or other, they just chat within this and they repeat themselves. They never add any kind of skills into Claude and other stuff. They just feel like, okay, I'll just do it, but if there is even a tiny point of thinking, okay, I've been doing it, I've been doing it in bullet points in Notion, I've been doing some roadmap there in I don't know, Trello, or I've been trying to map those things in Miro, but I'm still not super happy. It's too slow, et cetera. And then we're getting deeper into working on their cases with their clients. And I'm saying, oh, you know, like we have this workshop with Brian, so let's wait for that and you'll see like what you can do with Puzzle. And we can take this client case of yours and actually redesign it within the Puzzle maps where you can also add different layers of context and it's It's actually possible to mold it into something else and you can show it to stakeholders and I had people within the program, you know, then working on this, maybe even some have been reaching out to you, Brian, for some questions, you know, you've been joining the workshops and the ideations we had and they're saying, oh, okay, this is now something in a shareable view I can share with stakeholders, they understand it. Oh, we negotiated the upsell based on this, so you can also use it, you know, to then upsell because you have something that justifies it. If you just go on a call, you talk about it, okay, that's Great. It's in a vacuum, but if you can show them something, I've been selling process-based transformation projects with puzzles, so I used it as a sales tool as well. Why? Because sales in a RevOps and GTM space is often about the promise of transformation, but if you cannot see the transformation and it's only the words that you have and you cannot say what is point A that we are here at and what is the point B that we want to get to and how we'll do it, I mean, you're missing the even visual representation or even cognitively, like the other side cannot grasp it. So we'll say discount it or say maybe not now, but if you show it, they're like, oh, this is serious. We can have some improvement. Okay, let me pay for this, you know? So I think at least that's how I've been seeing this. Like it's really an unblock and I think more people should be using it for different parts of the business. Like, of course, good to map all your processes and to optimize them, to know what to optimize. Good to document processes for your clients so that they can, you know, use it better. Good to use it for sales and good to use it as a context engine for your processes and for your client processes so you can actually use AI more advanced and mature way than just having chatbot discussions and I think it's different levels of maturity again, but starting somewhere and having your first process mapped, I think it's a huge unblock to then go to the next phase, minimum viable process, start somewhere, go V1, V2, V3, and go into different levels of process maturity within your GTM team.

Yeah. Yeah. I've, I've realized that I have a co-founder. I just didn't know it. And it's AI because I, I talked to AI about everything, but AI is only as good as the context that it has. Everyone knows that. And when you're connected to Puzzle, which has all your processes, all the tools that you use, all of the roles, all the people on your team, and how all of those things work, the level of conversation that you can have is the difference between talking to a junior analyst skilled person about how to improve your business or the ideas and a co-founder. And so I call it co-founder awareness. That's what Puzzle unlocks for me on the operational side. On the GTM side, something like Octave is that database that I hook into to ask it questions. To be honest, I haven't ran Octave. I ended up canceling it, but I want to get, I desperately want to get back to it to have that GTM because I'm starting to do a lot more just content and GTM I wanna get back to using Octave. That to me is cream of the crop context layer for GTM. For Intercom is my support knowledge base. And so I have Jolly, who's been with me for 7 or 6 years, and she is phenomenal. She owns all of support. 96% of our support tickets are resolved by Finn, Intercom's AI agent. And really her job is maintaining the knowledge base. And so these are my 3 knowledge bases that I focus on is, uh, I have GT— uh, Octave is my kind of prime GTM prospecting. I, I want that to be my GTM layer. And then I have Puzzle for any operational decisions. Then I have Finn for support. Those are the databases that I rely on.

That's honestly amazing. And I, I love, I love that you're a fan of Octave too and Zach's work. So it's really funny. We all know each other. Um, on that note, we have like 2 or 3 minutes left. Where can people find you both other than on LinkedIn? And where do you guys realistically see this industry going? I mean, outside of, you know, your respective You know, teachings.

Okay. Well, you can find me on LinkedIn. You can also find me on Instagram, TikTok, or inside of the Puzzle community, which is completely free. So if you sign up for Puzzle, you'll also get all of the videos that I post there. Puzzle also has a YouTube channel where I post all of my kind of builds that I'm working on, much like the new onboarding experience. There are use cases of how I use Puzzle in my business. To shrink projects down from hours to just a few minutes. Where do I see this industry going? To, like, to be completely frank, I am consistently just have my signals out for what is coming up next. There's no telling, to be honest. Like, I can try to guess where this industry is going, but, but I don't know. I don't know, like, what products, What, you know, how AI's gonna evolve, what's bullshit and what's not bullshit about capabilities of these tools. You know, I'm trying to fight through marketing garbo, you know, marketing garbo and try to get the crux of like what these platforms actually do versus what they're promising that they can do. And it goes back to kind of the first point that we talked about. in this webinar is just taking it slow, taking it really slow, not having a fixed way of like where we think the industry is going, but being adaptable. And for me, it's being adaptable, which it's just an evolutionary thing. It's true for us surviving as a species. It's also true for organizations surviving in a competitive market. Being adaptable is the best way that you can flex on whatever happens in the market. I, you know, obviously AI here is, is to stay. So it's just a matter of like keeping tuned in on what these new use cases are and trying to implement them into your organization as swiftly as possible. That's my best, my best answer to that.

Yeah.

And for, for me, you can find me Yeah, on LinkedIn, I think that's the most common channel where I'm active, but also we just launched our new homepage in rev.tech, so it's easy to remember now. So there's a new website for the accelerator, but there's also this tab on the insights part. So we launched RevTech Insights, a Substack newsletter some time ago where people who are actually in the network, the partners, the alumni, and me as well are sharing the insights and we want to reactivate it. So if you'd like, you can subscribe there to hear from the practitioners in the space and also in the Clay community on Clay Clubs in person across Europe. If you'd like to come and say hi in Poland, you're always welcome to come visit in Warsaw. So when it comes to what I see coming next, I think the interface in which we interact with technology will be changing and that's very much with AI discussion and everything, but the foundations will not be changing. So I would say like still what we talked about on the process, on strategy side and kind of doing things intentionally and putting your brain into things and people relationships, those will stay, but the interface of how you interact with technology and even interact with one another. I believe more async work will be, will get done. Agents will be coming in to take over some things and the interface might move more to chatbots versus moving pieces. You know what we also tap into a little bit today, but again, like if you don't have your foundations done right, your strategy, your process, then technology is the accelerant, but it can accelerate noise or can accelerate chaos. And it will only give you more troubles than benefits. So you should always think first strategy, your direction where you're going. Process is the road on which you're going and technology is a vehicle, but if you accelerate this vehicle on a broken road, it will be expensive and it will not get there faster. If you don't have the right direction, you will just get to the wrong direction faster. So remember about this. This order, strategy first, process next, and then execution with technology, and then it should be right.

I love that. Couldn't have said that more beautifully myself. So I want to thank both of you for joining. A lot of great insights here. I've loved to have both of you guys on. And, um, thank you once again for sharing everything. This has been a great chat also to listen to and also to look at as well. The puzzle diagram I had, I was like, whoa, this is really cool. So thank you both for joining in.

Thank you. Amazing. I appreciate the discussion. Thank you.

Cheers.

Cheers.

Cheers.