Making Meetings Matter: Project Management Software Ft. Cam Fortin

Cam Fortin:

Planning and executing are very different parts of my brain. And if I have to go back and forth between them multiple times in a day, there’s going to be 30 minutes between those where I have to be like, “Okay, now I actually have to execute. Oh, no. Now I have to plan. I have to get all these things into my head and load them up before I can do that.”

This framework really helps you separate that. You’re like, “Okay, these days of the week are these meetings. I am planning. I am not executing. I am thinking about the future. And then this time, I am fucking doing things. I am executing. I am getting shit done.” Having those separate is, for me, personally, as someone with a lot of ADHD, I could not do my job without it.

Adam Kerpelman:

Hey. This is the Data-Driven Marketer. I’m Adam.

Mark Richardson:

I’m Mark.

Cam Fortin:

I’m Cam.

Adam Kerpelman:

Welcome back for another hang in the data basement. Thanks for joining us, and special thanks to our guest this week, Cam Fortin, who is a mothership guest. A member of the team over here. VP of Product for audience solutions, which I think is technically where we fall also right now.

Mark Richardson:

So I’m told.

Adam Kerpelman:

At least in terms of who approves my payments and stuff. You are also the largest influencer, I think, we have on the team. What do you have, like 15,000 Instagram followers?

Cam Fortin:

Not quite, but it’s not for B2B-

Adam Kerpelman:

It’s nothing to do with… The rocks.

Cam Fortin:

… Subject matter. But it’s important to have hobbies, right? We got to be well rounded. Rock talk, #rocktalk.

Adam Kerpelman:

I’ll throw to you from here for a quick intro, kind of how you ended up at NetWise with us and then how you’ve landed where you are.

Cam Fortin:

One thing we always talk about in Product is there’s not a whole real standard way to get there. Everybody has their own kind of path. And so, it’s always fun to hear how people got into it. For myself, after college, I was in a consulting firm for a couple years, and that’s where I learned all my analysis chops and how to frame a project. And actually, ideas are fine, but execution is more important. So that’s where I learned a lot of those skills.

Then I went over to Wine.com, really fun customer-facing website, where you can actually buy wine and have it shipped to your house. Did a lot of analytics there and paid search and then eventually transitioned over into taking over the product function there. And it was very organic in part of trying to do my analysis that I needed for various things. I just had to go talk to people in different departments and had a lot of questions, et cetera.

And the lead engineer was like, “You know what? This skill set of interrogating things and getting data and making decision on that and cross-team communication. That’s pretty much what product is. We don’t have that. Would you like to do that?” I said, “Sounds interesting. Let’s give it a shot.” And so, that’s how I fell into product in general and absolutely have loved it and enjoy it ever since.

I was there for close to 10 years. And then I got a call from Brian Jones, the now CTO of the joint ring-fenced organization “IWise” that I think we’re calling ourselves these days. We were buddies and his company got acquired to basically be the in-house engineering team for a NetWise data that had historically outsourced their engineering efforts. So they wanted to hire them and they needed someone to wrangle them and put some process around things, develop a product roadmap, and do all those good things. Thought it was a great opportunity to use my skillset, but in a completely different arena. I was there for a bunch of years. It was great. And we got acquired.

Adam Kerpelman:

The part I forgot about that story is that Brian brought you in, and you know Brian because a bunch of friends that he and I share from high school.

Cam Fortin:

Oh yeah.

Adam Kerpelman:

That’s funny. Because you know a bunch of people-

Cam Fortin:

It was pretty amazing that we went from having a couple beers a couple times to realizing, “Oh, this is actually somebody that I could have a good lifelong career with.” Him and Powell both, they stayed at my house before I even joined. So yeah, that was pretty fun. Awesome way to try the company-

Adam Kerpelman:

That’s funny.

Cam Fortin:

One fun tidbit about NetWise. Before we got acquired, there was not a single hire that didn’t know somebody else in the company when they joined. It was probably the closest-knit and best-kept culture of any place I’ve ever been. It was pretty amazing.

Mark Richardson:

That was really the biggest selling point for me when Kirk brought me on. I mean, this is case in point. I think I was the last maybe, or penultimate employee, that fit that pattern before we got acquired. So, that feels really good. That was kind of the biggest thing. When I first talked to Dwight, he was like, “Yeah, it’s a big family. Everyone’s come in from referral.”

And I thought, “Wow, that’s really cool.” I’ve only worked at one startup before in my CV. And that was a pretty intimate shop too, but not anything close to the level of comfort and closeness you have when there’s people that you’ve, like you said, crashed on their couch, had a beer with, talked shop in a less threatening setting than, “Hey, we got to close deals.” And when the pressure does come, then you feel like you can trust these folks that are on your team.

Cam Fortin:

Absolutely.

Adam Kerpelman:

When I first joined NetWise and started to get onboarded into the various teams and technologies and whatever, Ryan I think just hosted a meeting with me, you, and a couple of other people and said, “These are your project management software people. They understand what you and I…” Me and Brian, “talk about all the time in terms of, ‘There’s a better way to work than how all the rest of the world does it.’ I was like, “Okay, I got you.”

So yeah, we’ve worked together on different projects, but also, you’re the one I go to when I’m like, “Okay, what’s happening over here where software hits this world of needing to make projects happen and products to come out and all that kind of stuff?” Because that methodology is eating the world.

Increasingly, marketing looks like that, running in Sprints and Scrum and that kind of stuff. But that’s why I really tapped you to come join us today, was to talk about that aspect of it. And I think you have a very interesting view because you’re coming from consumer into D&B, and now you’re going through this growth of your engineering team and sort of trying to deploy that same methodology into these bigger teams.

I think the question in the middle there, although it might come off kind of broad, is… The way Brian says it is, “There are people who have used project management software, and they all don’t understand how the people who haven’t can live without it.” Why? What did we crack with the idea of, “Hey, you can go to ClickUp every day, you go to Asana, whatever, every day and manage all your stuff and not have to be stressed in the same way that you have historically been.” Like, what’s the change there?

Cam Fortin:

Oh man. I don’t know how I would live without it for a lot of my job. And to be clear, though, there’s a ton of my work that doesn’t fall into issue tracking software, if you will. But I try to decrease that bit over time and track more and more of what I’m doing. When I started out in Product, I had all of these ideas, and I’m just like, “Oh, this is what product is. You have an idea. Great, this is how we’re going to improve this thing.” But ideas shouldn’t even come from the product person all the time or even most of the time. They should come from the customer, or the company, or salespeople, et cetera.

Then Product, you got to figure out which of these are worth doing. And then, more importantly, “How do we get them done, sequence them, turn them from just a vague sentence or two to actual requirements and get them done?” And over tens of years, the Scrum process has been defined and adopted by engineering teams. And it’s just obvious that you need to track things and break them down and assign them and have these views in order to have a good velocity and get things done and have visibility through it. And it’s been very interesting to see that methodology start to creep outside of pure engineering projects into other organizations.

Another very interesting piece of that is traditionally, the planning process was kind of a mess and there’s not great tools for that. And then you get to the engineering world and that’s where it turns into something that’s actually standardized in Jira, and there’s tickets, et cetera. But what we’re really trying to do is even for… Expand the tool usage and how we are actually tracking and logging things outside of the pure engineering process out into the… Before that, it’s like, “Okay, we have an idea. Well, let’s just still go through a flow. We should have non-engineering meetings with business to figure out if that’s something worth doing. And then get the requirements for it. And then figure out if there’s go-to-market stuff needed. And then put it to engineering.”

But we’re starting to have all of that now in a separate app that’s not Jira. It’s pretty exciting to expand projects themselves outwards in terms of how you’re tracking them and also the number of departments that are themselves using this type of software and methodology. So it’s kind of two expansion dimensions.

Mark Richardson:

Right.

Adam Kerpelman:

The way I see it is it doesn’t matter what you’re doing. There are a lot of tasks and subtasks and things like that. And as you scale a team, more of those subtasks are owned by a different person. And if you don’t all have a source of truth as to the status of those tasks, then communication failure is rampant. Coordination failure, I should say, is rampant. Once you’ve experienced the fact that if you get the disciplines right and the settings right inside of bespoke software for this purpose, stuff just stops falling through the cracks. And it feels magical in this way that…

It’s magical in a way that makes it almost hard to pitch to other people, as the evangelists get in there and go… I’ll give you the marketing example. It’s happened with NetWise. I’ve had it happen in contracting roles and stuff like that. You come into a marketing department, and you realize that the marketing department is the dump valve for everyone’s ideas. Nobody expects any of them to actually get done. And then the only ones that do get done are the ones that pick up an eternal evangelist or somebody who’s willing to continue to push that idea forward, which then creates this culture of, “You don’t keep nagging, you don’t get the thing that you asked marketing for.”

So it ends up creating this frustrating thing because I come in and go, “No, we have methodology now, where this is a machine. You put it in the top of the funnel, and I will make content out the other side. Because it’s a machine. You told me the idea. You don’t have to tell me again next week. I told you it’s going to take nine months to complete. It’ll be done in nine months. If it’s slower than that, I’ll tell you.” People don’t believe that that’s possible with marketing materials because they’re not used to functional project. Or they’re not used to the cadence of modern project management possibility.

Cam Fortin:

I’ve seen a little bit of where you’ve expanded this issue tracking outside of engineering. And I think it’s so cool. For marketing specifically, right? And I think why you’ve been so successful is there’s deliverables that you can identify before you put something into place. You’re like, “At the end of the day, these are the things that will exist.” And so, you can work backwards from that and say, “Well, what are the steps, what are the tasks necessary to get to that place?”

So circling back to your question of, “Where’s this going to go? How many departments are going to start adopting this thing?” I think the next place is anywhere where you can define deliverables and actual… Something that will get delivered at the end of the day is a right place for this kind of methodology to take over.

Mark Richardson:

You want to make sure the tool is suiting the need of the team too. Learning a tool just to learn a tool isn’t productive.

Cam Fortin:

Oh, absolutely.

Adam Kerpelman:

Which also happens a lot, which then makes it hard when you’re the one with the new tool going, “No, I promise. This one’s actually going to solve the problem they say it’s going to solve.”

Mark Richardson:

“Yeah. Okay. Great.”

Adam Kerpelman:

I want to back up for a second. You kind of glanced over talking about Agile and Scrum. Can you give us kind of the top level of what those are for people that… Let’s assume that everyone listening’s a marketer and they’re not familiar with engineering and product side management methodologies.

Cam Fortin:

Yeah. My pleasure. Agile is a framework that has a number of different kind of methodologies underneath it. But basically, it’s all about visibility and iteration, and continuous improvement as applied to software. There’s a couple different flavors of it. One is Kanban, where it’s just a never-ending list of things, a backlog, and you kind of move through them, which can be great for… If every task is relatively important and not a lot of dependencies, that can be good.

We use what’s called Scrum, where there’s actually things called Sprints. And you have a timebox. Usually, it’s two weeks. Could be three, four, whatever, where you say, “Okay, in the next couple weeks, this is what we really want to achieve. Outline with the team. What are all the stories, if you will, the subtask to get there? How hard is this going to be?”

But the reason it’s so interesting is, it really gives everybody a goal in a couple weeks. “This is what we are trying to achieve. Everybody agrees to it beforehand.” And you can look back at the end of that, and say, “Did we accomplish what we were trying to or not?” And then, if you haven’t, we actually change how we decide what goes in that next Sprint. So it’s really all about getting better and better at the process of, “How much can I take on in this next chunk and actually complete it?” So, that’s a crappy, short explanation of Agile and Scrum, specifically how we use them.

Adam Kerpelman:

There’s like 12 principles of Agile or something. It’s, for sure, a whole mood. Then the argument about Scrum versus Kanban versus whatever is all the specific tools.

Cam Fortin:

And I do have a couple interesting examples how we’ve used them that I think are maybe not traditional. One thing I always like to say is, “I love process more than anything, but I want the smallest amount of process and red tape as possible.” So I almost always start without software. When you’re getting into something and how does it currently work, don’t just try to slam something in place. Let it organically happen. That’s just something I want to put out there right now. You shouldn’t go try to do this everywhere all at once. That’s just not going to work.

But one really, I think, cool example for NetWise of kind of a Scrum but adapted to business was customer deliveries. So we have our main deliverables files and the process of going from a customer saying, “This is what I want.” To the very detailed, “I want it to be a pipe separated versus comma separated, in these fields, and delivered to this FDP. And here’s the credentials, blah, blah, blah, blah, blah.” We were doing that all in emails. It was completely messy. You couldn’t go anywhere and see what files were where. So we actually adopted Scrum for our file deliveries, which I think might be kind of not what people would normally even think of.

And it’s made it so much… Our throughput is so much better, our visibility. Two weeks in advance, we know, “These are all the files we’re trying to give to a customer.” The engineers know what the requirements are. Look at the tickets and say, “Yes, I can create those.” And we timebox in that two-week thing. And sales knows when things can actually get worked on. They know not to toss something to do tomorrow because we’ve implemented these processes. So it helps tremendously in a number of facets having it for our filed deliveries.

Mark Richardson:

I think visibility is huge. Like you were saying, in terms of bandwidth and throughput and just general team wellbeing, peace of mind to know that, “Hey, I’ve got a forcing function and kind of a reduction of pressure to know that as long as it gets done within the Sprint, we’re good. And sales can say, “Okay, they’re slammed. We’ll save that for the next Sprint. Not going to get done.” So, that reduces friction.

Adam Kerpelman:

You just introduced the practical application that most people, probably, I feel like, would resonate for them. And it’s sort of context is like… There’s incoming demands inside of any collaborative structure. If you don’t have a common language to explain why I can’t do it right now, then you constantly seem like you’re just saying “no.” And it’s no fun. It’s no fun to be saying “no” all the time. But it’s way easier to say, “Look, we could maybe fit that in Sprint eight and we’re on Sprint four.” That gives you a sense, right? It’s like, “We just can’t get to it till September.” But it’s not a “no” feeling answer-

Mark Richardson:

It’s not covering your ass.

Adam Kerpelman:

When you can get the whole team to understand the idea of how you organize getting work done in this timeboxed way, then you have a language for how to say to sales if you’re marketing.

Cam Fortin:

Absolutely.

Adam Kerpelman:

“Look, that’s fine. But when I spin up the template for that task, there are 25 subtasks. They all have to get done. I can start to get that in Sprints around September. It’ll be done by here if it proceeds on course. It probably won’t. Pad that by 20%.” Whatever, right?

Cam Fortin:

100%. And one other thing that I just thought about that I think is very useful for these Agile methodologies, specifically Scrum, is… I don’t know about you guys, but planning and executing are very different parts of my brain. And if I have to go back and forth between them multiple times in a day, there’s going to be 30 minutes between those where I have to be like, “Okay, now I actually have to execute. Oh, no. Now I have to plan. I have to get all these things into my head and load them up before I can do that.”

This framework really helps you separate that. You’re like, “Okay, these days of the week are these meetings. I am planning. I am not executing. I am thinking about the future. And then this time, I am fucking doing things. I am executing. I am getting shit done.” Having those separate is, for me, personally, as someone with a lot of ADHD, I could not do my job without it.

Mark Richardson:

Oh yeah. I’m like throwing emoji hands up there.

Adam Kerpelman:

Doing a little dance.

Mark Richardson:

That is my life. Trying to bounce between the strategic and the execution, it’s gotten so… Maybe it’s because I’m getting old. I don’t know. To bifurcate those two is just so necessary.

Adam Kerpelman:

I like to think I’m pretty good at it, but I’ve realized that it’s only between those two things. If you throw in a third context that I have to switch between, they all fall apart, and I’m completely exhausted by the end of the day. So if there’s a plumber at the house, everything’s ruined. If I don’t then segment and go, “Okay, it’s either planning or execution today because also, plumber.”

So the interesting thing that’s come up in other conversations, particularly with occasional cohost Brian Jones when we talk about this stuff, is when you’re trying… I guess maybe the thing to say first is the nature of a global team using modern tools… You end up with some sort of effort to build asynchronous communication. And it goes to the visibility and transparency you were talking about, right? The notes need to be typed up because there might be people on the opposite side of the globe from you that need to get caught up on them before they can do their task. And so, software or structures for how you leave that in a place is really important.

But then the other part, and I’m kind of curious your experience with this over the years, and then also expanding, then there’s the part where there’s aspects of it, that you might have a voice in the back of your mind that goes, “Okay, we don’t have to do this in a meeting if everyone just gets the discipline down of updating this thing.” And then it never happens. And you’re frustrated because you’re like, “Why can’t you just wake up every day and update the thing?” And it’s like, “Well, because that’s not how people work.”

So there’s an interesting aspect where you still have to have meetings where you might not even talk. Sometimes they call them “silent meetings” where it’s literally like, we all get in one place, and then we go through all the steps. And if there’s questions after that, then we field them. If there aren’t, we can all just leave and say, “Hey, good job everybody.” But that communal aspect of being there and going, “Okay, everybody look at the backlog now. Only look at the tasks assigned to you. Move anything that’s in progress in progress. Anything that’s to do, you’re still going to get to. Anything you’re not going to get to move it to the backlog for next Sprint.”

That’s the thing. I’ve been trying to dance around the most, trying to find that line of, “Okay, how much do those meetings feel like babysitting versus they’re just necessary because human’s good at human…”

Cam Fortin:

Well, one thing specifically about Orthodox Scrum, as we’ve been calling it, that I love is meetings. They’re not called… There are events. So for Scrum specifically, there’s four or five specific types of events. You’ve got your standup. That’s just the engineers and the Scrum master talking quickly each day about, “What’s going on? What are your blockers? What are you working on?” You got your refinement session where the whole purpose of it is to go through the next things in the backlog and make sure they are dialed and ready for the engineers to work on and move them around if you need to.

And then when a Sprint’s done, you have this amazing, gorgeous meeting that’s my favorite thing in the world called the demo, where all the stakeholders are there with the engineers and, “Here’s what we did. And here’s what we’re going to do. Do you guys have any feedback? Should it be course corrected at all?” And then, you’ve got your actual Sprint planning where it’s just the engineering team, the PO again and you, “What are we going to take on this next one?”

So, Scrum makes meetings matter. You don’t have a meeting that doesn’t have a purpose. You get shit done, and you have as little meetings as possible to let the engineers do their thing. Every other type of meeting I have is the exact opposite for the most part. Most people are terrible at meetings. There’s maybe an agenda. Half the time, I’m not sure why I’m a hundred percent there. There’s duplication of meetings and what you’re trying to do across them. And that’s again where this process stuff can, I think, probably help where you start adopting these other processes. And instead of just random meetings, you actually have meetings with a very, very specific focus that actually help versus just bloat things.

Mark Richardson:

And a good PMO helps too.

Cam Fortin:

It’s easy to fall into meetings disguised as productivity.

Adam Kerpelman:

Basically. It’s kind of how I’d say it, right? “Oh. I’m so busy.” “Are you really busy, or is your calendar just full?”

Cam Fortin:

Absolutely.

Mark Richardson:

I think we may have stumbled on a title of the episode too, “Making meetings matter.”

Adam Kerpelman:

“Making meetings matter.” There you go.

Mark Richardson:

Alliteration.

Adam Kerpelman:

Okay. So I want to talk a little bit about how we do that differently for marketing, but first, this is more in the weeds of the project management stuff. Talk about the difference between “asks” and “stories,” and “epics,” and that kind of way of classifying, I guess, the priority or the scale of any given piece you’re moving around inside the system.

Cam Fortin:

It is super fuzzy, and there’s no right answer, that’s for sure. But what we have landed on, which I like, is we have… And this is where, to circle back to the expansion of this kind of process outside of purely engineering to actually the mapping scoping part of it. So, an “epic” is a collection of user stories in Jira. It’s a bigger piece of work. It might not be as big as a release, which could be a bunch of projects that are all dependent that you release it once. But in general, we work on the “epic” level, which is it’s real functionality that once released, does something but not super, super huge. But it’s more than one person, more than one task involved in it. That is usually what we are trying to, on the product and business side, come up with those and prioritize those kind of bigger things. And we do this in this system called “product board.”

And then, once we go from an idea to an actual candidate, to planning, where we’re doing more and more scoping, and refinement, and resource allocation, and stuff at each step there, which is incredibly useful before it actually even gets into Jira, into the engineering flow. So that’s how we’ve done it. The business only has to care about that higher project level stuff. And then, from there, when it gets into the engineering, we break it down further into the “stories” and the subtasks, et cetera. So the engineers can actually distribute the work and complete it.

And it’s a really important thing to define for yourself as a team, “What level do we want to roadmap at? And what level do we want to assign things to engineers at? How do those kind of play together?” And what’s the integration across your system so you can actually track a project through the different software that you’re using? I can get more in-depth on exactly how we use “stories” and subtasks and stuff, because there is a lot there but that’s in general, the kind of level that we’re thinking about.

Mark Richardson:

I will say, anecdotally, it’s interesting to hear… And I’m thinking about the term “stories” was initially confusing to me and my first job where I was interfacing directly with the PO and VP of Product and a Product team. Because as a marketer, we think about storytelling in a very different way. I think about it as an avatar. When I heard “user story” first time, I had to rejigger my thinking into more of an engineering mindset. And I’m not an engineer. I’m an English major, who’s a marketer, and kind of a Moonlight HTML guy. So I understand what’s going on, but if you could break down a little bit more how you define “story” in an Agile context.

Cam Fortin:

I might be a little bit nontraditional here too, because I do not love the “story” idea, but it came about basically as a… A “user story”, traditionally, you frame it in, “As a X, I want Y.” So, you don’t have to know anything about engineering or code to do that. Let’s say I’m a salesperson, I’m like, “As a salesperson, I want a PDF report of an audience that I’m going to sell that has these cool charts in it.” So you can frame it in that way that it makes sense in English, but you’re not going to give that to an engineer because they’re like, “Okay, well, what does that mean?”

So, traditionally, what you do is you have this “user story,” which is this kind of nebulous thing. It’s real, but it’s not something you can hand to an engineer. And then you get with your engineers and say, “Okay, I’m not going to assign this story to you, but approximately how hard do you think that’s going to be for all you guys to do everything in here?” And now let’s create subtasks, that are actually engineering speak, like, “Create this database. Create the API connection to do this and this and this and this.” So it’s a way for you to have a smaller set of “stories” on your board that have English names that make sense. And then, underneath them, the appropriate level of technical detail and subtasks to actually complete that “story.”

Mark Richardson:

So a desired outcome and then a recipe of actions, right?

Adam Kerpelman:

There you go. I like it. And then just calling it a “story” frames it… I mean, it’s the problem across the board of, there’s always going to be lexicon difficulties, especially across departments and stuff. So, we never call them “stories” because it just gets morphed into another thing for marketing, where… For example, the thing I sort of teased before, we don’t do demo meetings in the same way because it’s not like there’s stuff to show off. I mean, we do if we have a longer project, like a research report or something, that’s going to take a long time, but instead, marketing teams have editorial review type meetings.

So our Sprints are two weeks but we have a weekly meeting that’s an hour of, “Look at the analytics for the posts that went out last week. Look at the content for all the posts that went out last week, the blog, the podcast episodes, whatever.” Largely just to force a team effort around incremental improvement of all of those things. So that’s one of those things where it’s less a demo because the demo is we just consume the media that we… We publish this stuff. It’s public once we’re finished. And so, demo is, “Go read the blog and then we’ll talk about it.”

Mark Richardson:

And there’s an element of, “Is it working?” We look at the metrics to go, “Okay. Who shared it? What community did this go to? Are there learnings that we can take and implement in the future for activation of similar pieces of content or similar ad campaigns?”

Adam Kerpelman:

But then it ladders up into the “epics” thing. And so, the “stories,” if they were going to play traditionally, would be more like, “Anyone searching for information about data should be able to find it on our website.” That’s just the forever project because we’re building an encyclopedia. So that story kind of never gets completed.

Cam Fortin:

That’s why you break shit down. So you can. I think maybe an “epic” for you guys could be, “Create an FAQ section on the website.” And then some of the stories could be like, “I would like to know about the privacy implications of the data that you collect.” And things like that we would actually-

Adam Kerpelman:

For us, the stories look a lot more like topics, usually. Questions that people have that we can answer via the marketing products, or whatever. And then it gets weird at the top because then you start trying to align it with all the other stuff that’s happening. And it eventually ladders up to three main goals at the top, which are, “Drive revenue here. Drive revenue here. Drive revenue here.” Or whatever, “Drive traffic here. Drive revenue here. Get user feedback about the product over here.” And then those all turn into their own versions of how we build these machines, which maybe is an interesting place to start to wrap up.

We talked a lot about internal stakeholders and ideas coming into the machine and how you turn them into product or into content. Talk a little bit about the user-guided part of that. On the marketing side, we spend a lot of time paying attention to analytics to see how our content is doing, how our ads are performing, blah, blah, blah. That’s our feedback cycle. You guys have a lot of analytics on what’s actually happening inside the product, but you also go and ask the users how it’s going, which is a thing that’s a little different from marketing.

But I’m always fascinated about how that feedback loop cycles back into the Sprints and how you can know that, “Hey, here’s the system by which we are surfacing the best features that the users want and know that they will get built in on a general cadence. And if you want to tap in faster, hire more people for us.”

Cam Fortin:

User feedback stuff could be a whole series of podcasts, for sure. As a Product person, you want to get as close as you can to the people that are actually consuming or using whatever it is that you’re creating. Because that’s where you’re creating it for, either internal or external users. When I was at Wine.com, it was very interesting. We had people hitting a website and we wanted them to buy stuff. So, it’s pretty easy to set your conversion funnel. And you know the KPIs you’re looking for. You want your AOV to be higher. You want the conversion [inaudible 00:31:41] in the cart to be higher between steps, blah, blah, blah. And then, in terms of new things that people want, you can… And so, any issues with that, you can kind of tell them to chat you or whatever.

But the more interesting thing was for new things that weren’t on the website. We actually had a group of people who I could email at any time and send a poll to ask them about whether they would want a new feature or not. And then we would actually go to people’s houses with fake little paper sheets that replicated going through something we were thinking about building, and just try to be very undirected and be like, “Pretend you’re trying to do X. Show me how you would do it with what I’m presenting to you.” And just try to see how they’re working through it, if they’re fumbling through anything that you thought was obvious.

If there’s a user interface or data or whoever your customer is, how you’re going to go get that feedback is so different. So when I moved over to NetWise, at the beginning, it was, “We send flat files to customers that then combine them with other files, and then create their own product that then gets sold to other customers that we never hear from.” So the closest we can get to the customer is an aggregator, and asking them, “Do you think what we’re doing is okay?” And trying to ask them, “What are your end customers demanding that we can then build into our product?” Because we couldn’t actually talk to the customers.

And now it’s a little different, we actually can talk to some of our customers that are getting data files, and we have the platform now, so we can see usage there. So it’s very different depending on what you do and who your customers are.

Adam Kerpelman:

That’s so hot right now. In a sense, doesn’t that eventually just boil down to user-led growth, if you’re doing it right?

Cam Fortin:

Yes. But gosh, think about us though. It’s so complicated. The number of things that Dun & Bradstreet sells and the number of things that are created that are purely for internal usage, et cetera… Before we got acquired, we were kind of trying to go there and say, “We’re going to be a SAS company. We’re going to sell access to this platform.” And I think that was going to be the plan. We’d be a product-led company that’s really users telling us, “Are we having the right product market fit? What do we need to do to grow?” And now, it’s a lot more complex when you’re relying on salespeople selling your products for you. There’s a bunch of products. You make some of them. Other teams make others of them. It’s a whole different situation.

Mark Richardson:

I’m not sure if they all work in conjunction or work against each other. Try to do the same thing.

Cam Fortin:

Exactly.

Adam Kerpelman:

So my last question, I guess, that’s maybe…

Cam Fortin:

Trying to kick me out? Am I doing this poorly?

Adam Kerpelman:

No, you’re great. I’m just trying to honor your calendar, or if we got eight minutes left to land the plane. Okay. So how many people were at Wine.com when you started?

Cam Fortin:

Oh gosh, I think like 25 or so. And there was probably like a hundred when I left.

Adam Kerpelman:

I’m not really familiar with the influence of Gary Vee. Did you see that coming?

Cam Fortin:

Well, depends what you mean, “I saw that coming.” I saw that he was a squeaky, annoying wheel and certain people liked him, but luckily I didn’t have to do much with him.

Adam Kerpelman:

Works for some subset, to be sure.

Cam Fortin:

He’s one of those old school, “You got to work 27 hours a day and hustle, hustle, hustle, hustle.” I am the opposite. I want to have a bunch of engineers and product people working with me that get shit during the day, and then go hiking or hang out with their family after work. So, Gary Vee was never my paradigm of someone to emulate there.

Adam Kerpelman:

I mean, he’s an influencer for a reason. It works. He’s got his people, to be sure. I rode that mentality into burnout at least twice.

Cam Fortin:

That’s it.

Adam Kerpelman:

So, I learned my lesson. I can’t do it. I can’t do it physically anymore. My body hurts too much for those kind hours.

Mark Richardson:

I’d rather take little chips, little coins of gold day by day by day than searching for a big pot of gold at the end of some mythical rainbow that all the… Hard work. And it seems like the influencer life is trying to do both but again, he’s got a thing. It’s like, “Yeah, it’s easy, and it’s great. And I can just pop it off. But also, it’s a lot of hard work.”

Adam Kerpelman:

Well, to tie it back to the rest of the conversation, I think that mentality and the reptile part of your brain that it scratches goes back to before we had digital tools for how to achieve the things that we want to achieve at a reasoned sustainable pace and still have the outcome be great. I openly admit that part of my success, business across the board, has been bringing more efficient project management everywhere that I go.

And they go, “How could you possibly do four podcasts a week?” And I’m like, “It’s actually pretty easy if you just sort build out the machine and then you all stick to your schedules and you book far enough out.” The answer is this won’t air for nine weeks, even though we’re recording it right now. The point is to have the [inaudible 00:36:55] conversations. So it doesn’t matter. And then, the machine will run, and eventually it’ll get published. And I don’t have to have an answer.

Cam Fortin:

I think one very interesting thing is these type of processes in adopting tools and doing things in more efficient ways… For engineering… It started there because it needs to. They’re your most expensive resources and you don’t want them thinking about things other than coding and you need visibility in which they’re doing. What they’re doing is actually not… They don’t usually decide that. Other people decide that. So, it needed to exist.

But you are expanding that kind of workflow beyond that, to where it doesn’t necessarily need to exist, but by adopting it, you’re actually giving yourself a competitive advantage. You can create more content. You can measure things better. You can have a smaller team and get as much or more done. So I think that’s a pretty cool takeaway from this is taking what product engineering needs to do and deciding to adopt that in other places to actually give yourself an advantage.

Adam Kerpelman:

That’s like the moral of this whole podcast.

Cam Fortin:

I mean the whole-

Adam Kerpelman:

I just figured that out at the end. I should’ve known at the beginning.

Cam Fortin:

… Not just this episode, the whole enterprise.

Adam Kerpelman:

We can shut it down. Season two’s over. No, but really, Cam, thanks for coming on. Do this. Good stuff. Where should people look you up? They want to see your rocks on Instagram or TikTok.

Cam Fortin:

@owyhee_rockhound, if you want some of that agate and petrified wood content.

Mark Richardson:

It’s so good.

Cam Fortin:

So I would move in the bay area where I could go hike in the Redwoods and swim in the ocean to the high desert of Boise, Idaho. And it was kind of a tough transition till I discovered the desert has some amazing things too.

Adam Kerpelman:

I mean the deserts all used to be oceans.

Cam Fortin:

That’s true.

Adam Kerpelman:

So there’s a lot of cool stuff left behind.

Cam Fortin:

Or lakes.

Adam Kerpelman:

And thank you to our listeners for joining us for another jam in the data basement.

Mark Richardson:

Thanks, everybody. Listen, share, subscribe. Wherever you get your podcast.

Adam Kerpelman:

This has been the Data-Driven Marketer. I’m Adam.

Mark Richardson:

I’m Mark.

Adam Kerpelman:

I’m Cam.

Take it easy, everybody.

Mark Richardson:

Thanks for listening to the Data-Driven Marketer. Our show is produced by Jessica Jacobson and Dan Salcius. This episode was edited by Steve Kosh. The Data-Driven marketer is sponsored by NetWise, a Dun & Bradstreet company. Any views or opinions expressed in this episode do not represent the views or opinions of NetWise or Dun & Bradstreet.