Balancing Product Vision and Technical Execution in Tech Growth with Benjy Meyer

Welcome back everyone to another awesome episode of Mastering Tech Growth. Today we're going to Benjamin Meyer, we're going to be talking about B2B, B2C module complexity around that, and as well, if time allows, we'll check on the CPTO role. Welcome, Benji.

Hi, great to meet you, Mike.

Good to have you here. Let us know who Benji is.

So, uh, I'm a Chief Product and Technology Officer, uh, working in the startup scale-up space. I work for a company called Commonplace, which is a B2B2C platform. We support, uh, real estate developers and local government with engaging and consulting their communities in co-design to help build and design better places help accelerate their planning applications and ultimately increase valuation of their properties and design and build places that people want to live, buy homes, and be happier. So it's quite a unique product and one that we're going to get into. Prior to this, I founded my own B2B2C marketplaces— marketplace called Commonplace— sorry, called Venue Scanner, which is an online marketplace for venue hire. And previous to that, worked in various retail and other B2C businesses running their products and digital and online businesses.

So it's a strong background in B2B to C products.

I'd say so. That's where I'm carving out my niche.

Your niche. Okay. So it's lovely to have you, Benji. And, uh, I'm sure everyone tried B2C. It seems to be the most common way of people kicking off tech ventures. They always go like, I'm going to create an app or a service. I'm going to have, you know, hundreds or thousands of customers, and B2C seems to be what sits at the top. Interestingly though, if you try to raise money, venture capital money, they don't really like B2C that well, and they always like, we should convert your idea to B2B. What's your take in general? What do you think is more favorable module to go with?

I mean, if you're looking for funding, you're right, it's super hard now to get VCs to listen to the B2C opportunity and to take that level of risk and reality VCs have reduced their risk. Um, and, and we, we're a really interesting example of that with the platform Commonplace. Um, we're, we're funded like a SaaS business, um, but arguably, um, you could say we have more traction in the B2C side of the business. Um, we've reached over 10% of the UK population, so that's like a really important and exciting statistic. But getting investors who are like keen to take a punt on those kinds of stats is less likely than those that are looking at churn rates and acquisition cost and LTV, CAC, etc. So yeah, like ultimately we all need businesses that are viable. I think if you've got a B2C model where you can charge in the early days, that's a good option. I'm also— maybe we'll get onto it later— quite interested in the whole prosumer space, which is how do we develop B2B products but that are chargeable, not on a kind of enterprise cost level? And I think that's quite an interesting way to get into, um, the B2B2C space and monetize from an early stage, um, without necessarily needing to go to a big VC and getting, getting multi-millions in, in funding.

That's interesting. You mentioned you're getting more traction as, um, so you are B2B2C with the Commonplace, but you mentioned you're getting more traction with actually with the customers. What is that traction? Is that like engagement? They're logging in, they're having conversations? Like, how do you find that traction?

Yeah, so we're a platform where, let's say, you're redeveloping an area of London or a rail station or a new highway. Um, you'll use our platform to engage and discuss and consult with the community. And, um, we have lots and lots of customers presenting lots and lots of projects on the platform, which is all really good. Um, but actually, the thing that's kind of super interesting to me as the product and tech guy is our long-term growth. And our long-term growth is, is dependent on getting a high quality of response to those engagements and those consultations. And what does high quality mean? So volume is important, but our customers, they don't really understand why volume is important. Um, so we have to get a little bit beneath that. And the thing that actually matters to them is getting positivity and support for their plans. That's what they need out of a platform like Commonplace. But we know from all the research that we've done is that the broader your audience, the more positivity that you get, because you're getting away from a traditional space where people are sitting in town halls eating cucumber sandwiches and drinking cups of tea, which is kind of a one demographic type of response. But we know that the bigger the volume, the broader the audience, and therefore the greater level of positivity. And that's a really important kind of product metric. That we've developed some IP around, and, and our customers ultimately value that. They value the level of support that they get above everything else.

Okay, that's good to know. So that's what I mean by traction, that, uh, that positivity which comes out.

Yeah. Um, so we have 68% of all comments, uh, gathered on Commonplace are supportive of the proposals that have been presented to them, and that's, um, much more positive than you would get in that kind of face-to-face scenario, and much, much more positive than you get if you just talk about these things on a social network, um, you know, a traditional Facebook or X, for example. Um, so it's, it's, you know, it's a strategy to ultimately gain that support that our clients need. Um, yeah.

Okay, so, um, let's take a step back to B2B, B2C. Let's, um, let's define it a little bit. Um, I'm sure everybody knows, but in your mind, what do you think are the main characteristical differences between B2B and B2C business model?

Yeah, I mean, I think that they're ultimately very, very different and more different than most of us perceive. Like, oh, you know, I've been an engineer in this, I'll be an engineer in that, or I've been a product manager in this, I can do it in that. They're very different environments, they're very different skill sets. It depends, I think, quite a lot if you're a B2B on the level of revenue concentration that you have. So do you have all of your revenue coming from 3 customers or is it split equally across 300 customers? That, that will define quite a lot about how you run and prioritize for that business because functionality is really important to customers who are paying you a monthly fee. And if you've got, you know, just a couple of really big enterprise customers, it's like, how do you prioritize for them versus your own deliverables that you're trying to target to grow your business? And that compromise is a really important one and one that I think slows a lot of products and tech teams down in the B2B space. And in the B2C space, you know, we're working more in a mass market space. It's about the overall user experience. It's about ultimately looking at data on a big volume level analyzing and understanding that data so that you can acquire and grow retention with those users on a mass level, much more transactional. Whereas in the B2B space, of course, we've got the longer sales cycle, we've got the constant kind of discussions and trying to get people through their quarterly business reviews and into renewal and learning what their kind of gripes are, I guess, is probably what comes across in most of those conversations between customer success and sales and then into the product and tech team. So yeah, it's like a completely different mode of operating because ultimately you're dealing with different volumes of data and evidence about what you should do.

Yeah, you mentioned long sales cycle and just came back screaming to me because we had a startup with B2C as well. And it would take around like 6 months to close a deal. But of course, you know, the deal sizes, you know, from like 60K to a quarter million. So it makes sense that it takes a long, much longer than a simple transaction of £9 for someone to, you know, to test the platform. And you're absolutely right, that's two different planets. Do you think, or what's your take on who actually feels the differences, you know, around these environments much more? Like, if I'm a developer, do I actually care that much? You know, if I'm an infrastructural engineer, like DevOps, do I care that much? If I'm a product person, probably care a little bit. If I'm a salesperson, I probably care a lot, right? So when you think about these different departments, let's call them, within the business, and because we are a tech podcast, you know, leaning towards like product and tech, um, who you think are impacted a lot more and who are a lot less?

I think it's very easy to kind of say, well, yeah, the product team are the guys who are going to get impacted more than, say, the engineers. But like, if you think about feature flags, for example, and feature flag documentation and management, and also subscription management. So let's say you got a feature, and you want this to be available to those who have paid for it, and those who haven't paid for it, you want that feature to be visible, but not actionable, you know, you want it kind of grayed out, you want to lead the customer, the B2B customer, down a journey of using that thing. Um, there's a lot more of that in the B2B space than in, say, the B2C space, and that requires a different level of understanding as to how you abstract and configure your code. Um, there's just such a level of customization that you do need to think quite differently, and that does feed into DevOps and infrastructure as well. Like, we, we run a business that is based on subdomains. So all of our customers, they buy a group of subdomains. Sometimes they want a custom domain. And so there's a whole load of customization again that you're doing on a customer basis. It's not just about keeping this one version of the code live. You've actually got like, I don't know, 20,000 probably versions of the code live across our customer base. And that also is quite a big problem for testing. and in particular across product and tech teams, end-to-end tests. What are all the different versions of our app that exist and how do we make sure that they're always on and always working? Much, you know, that's a really big challenge, whereas in the B2C space, not always, but most of the time people are on the same code base, they've got the same experience, and so you're maintaining more of one thing. So I think it is a completely different ball game. For everybody ultimately. And yeah, like sales, for me, sales is just an enterprise salesperson doesn't become like a B2C marketing person. They're just kind of different jobs. An engineer or product person can skip across, but they're very different types of environments and very different pressures.

Okay. I love you mentioned that customization piece. I mean, I hate it. I honestly did. I really did not like big lines coming out, and part of the sales cycle would go like, we'll need these things because that's how we do it. And you suddenly, you fork out, you get another branch, or you get another feature flag, and it was just challenging to manage all of that well. And you mentioned the testing, end-to-end testing, and how do you guys do this? Like, how do you actually approach customization development lifecycle where you, you know, have that not acquiring technical depth, if that makes sense, of doing that like ad hoc, but having an actual process around that?

We've got really good documentation around all of the configurations and customizations. We've got, you know, we rely on the human side as well, which is people who have been here for a while and know and understand all of this stuff. And that feeds right through to the support and the success teams as well, because they're the guys getting hit by all the questions and getting confused why it works over here and doesn't work over there. So having good documentation is important. And then back to the end-to-end testing piece, you know, if you're delivering a new feature or a new feature flag, whatever it might be, do we need end-to-end tests to be built for this? And we, we use a tool called Ghostinspector to ultimately manage that. We run a few hundred tests across the entire estate multiple times a day. And that's what the reason why there's so many is because of those different configurations and different experiences. We couldn't catch them all, but we try and, you know, live by the 80/20 principles and we run those same tests on a deploy. So into our pre-prod environment, if any of those tests failing, then we'll obviously get, get an alert and be able to handle those and deal with those. So just building that into your software development, you know, lifecycle is important. Ensuring that you don't build something that's so complex that a human couldn't figure it out or remember it. If you're making it more complex than your best support guy or girl can handle, you're probably making it too complex. And there's another way around it. And I think quite a lot of the time, the reason why too many feature flags are ultimately built is because there's an suboptimal relationship between, let's say, the customer and the product and tech team, or the sales and customer success team and the product and tech teams. Um, and, and the reason it comes through is because somebody comes back from a sales meeting, or a customer sends an email and saying, we need this, a solution-based, uh, view on what we as a business should build. Um, and When you said I get really frustrated by all this configuration of feature flags, I get frustrated by people saying we need a pink button on a blue page. Like, nobody needs a pink button on a blue page. I want to know what your problems are. If we can understand what our customers' problems are, then we've got these 5 different customers, 5 different problems, one feature flag can handle all of them rather than building out kind of like 5 feature flags and different versions of pretty much the same thing. So It's really important to get enterprise clients talking in problems rather than solutions. Not to say it's easy though.

Is that a coaching piece? Because I feel like, at least in my experience, enterprise clients feel that they know more. So they're like, you know, I'll tell you what to do. And you're like, give me your problem, let me chip in. It's okay, just get that done for me. Like, how do you navigate that relationship? Do you go like, you know, We're working together.

100%, it's a coaching thing, and it's not just a coaching thing externally. It's constantly reminding our colleagues working in sales and support and success, um, to do the same thing and to turn it on its head and to really do that. Um, you know, some of the best conversations we have are when our colleagues bring a few of us into those meetings and we just open it up into more of a workshop or brainstorm and, and can do that. If you're doing it back and forth on email or tickets, it's actually quite hard, to be honest, you know, especially at scale, you know, to coach somebody on email because ultimately, you know, it's going to end up in a request turning into 4 or 5 emails that you could probably do without having to handle. So it's a bit chicken and egg as to how much you want to open the floodgates, but it's really important if you've got like a small group of really heavy customers who are being quite demanding is to convert that demand into insight and say, hang on, okay, let's sit down, let's talk, let's figure out, let's understand what actually is going on here. Um, and that's partly because they've got things that they would like the, the, the product to do in the future, but also I think, um, there's a lot of complexity in decision-making that you can't read When somebody says, can I have a blue button on a pink page or a pink button on a blue page? Can't remember which way around it was. Is it the view of that person that you're talking to that that's what they need? Is it their boss's view? Is it the guy paying the bills? Is it their end user or end customer? She came on a call and she wasn't happy, so they're just kind of finding someone to blame and shifting it across to you. You really have to kind of understand what, where is this coming from? Like, what is this thing? Why? Just understand the why. And then maybe we've already got a feature flag that can handle it. But until we understood the problem, we're then going to go and burn a load of development time to go and build something out that we've already got.

That makes perfect sense. This is a healthy process, by the way. I don't think it happens so often as people would think. Or maybe as you're saying, it sounds like, okay, yeah, that's cool. But actually put it in place and make it work well, that's an uphill battle.

Um, it's not easy. Yeah, it's not easy.

Yeah. Um, so you did mention a documentation, Benji, so I just want to sort of take it back. So this is where all of it happens, isn't it? Like, you, you have these goals, you start feeding back in into some type of documentation. It's like a product documentation, so you can track decision making. It's like what How does that documentation look like so you can come back and deal with, you know, these customizations you have at scale?

We keep it pretty simple, to be honest. So each feature flag is available to be switched on or off in the database and it's got a human-readable name and the UI for our admin team accesses that, that UI. And then we have a Confluence document which ultimately relates and provides a description of what each of these features does and also describes how those features evolve through their lifecycle. Because some feature flags, you develop them and in the beginning it might be in beta, you might have that feature flag on, on 3 customer sites, for example, and then, you know, maybe like 3 months later it's on 50% of sites and then 3 months later, you don't want that feature flag anymore, you want to integrate it into your core code. So it's not actually available as a feature flag anymore. So having good status management around that, in the way that we document that in a table, it's just a table, basically, in a Confluence doc. And that's good enough at our kind of stage to give us sanity and give access to the information really quickly.

And who owns updating the document? And is it like a team responsibility? As part of acceptance criteria for the work you're doing, or is it more like a product person, like a product owner who runs that page?

So we have two processes. So if a new feature's being developed, then it's on the combination of the product owner and the engineer doing that technical design before we start building to think, okay, is there a feature flag? If yes, let's add a little tick on our Jira ticket that we need to go and update the documentation at the end of this ticket. Getting through its lifecycle. But then we also have a quarterly feature flag review, which I lead, and it's got our product, our head of product, our head of support, and an engineer on the same call. And we're just like literally going through the whole list, especially the ones that we created some actions on last time to review and make sure that we're moving things into the core code, that we're just, you know, it's that technical debt piece that you mentioned earlier. We don't want things hanging around the code unless we absolutely need them and depend on them. So constantly pruning and reworking that list.

So this will be an interesting one, and I'm not sure if you guys have it. So you have integrations with other systems?

Yeah.

Yeah. So do you do like feature flags on these integrations? Like, you know, you do. Did it ever happen so that it, you know, someone clicks something and, you know, it opens up some integrations, or maybe some features appears, and, you know, like a human error in the sense of like, you should not have this feature, but you have because someone just misclicked the button.

An external integration, because they usually need an API key or something to go with the feature flag, so there's like an extra lock step, if that makes sense. But okay, we've definitely been in a situation where we, we thought someone, someone didn't have feature and they have got it or they did have it and they didn't have it. And it's, you know, once you develop a feature flag, you get it live in the code, in the database, you don't get around to making the UI work because there's just not time. Someone from the support team comes in and makes a switch in the database. There's not an audit trail on that, etc., etc. So you can't really figure out what happened, who did it. So yeah, of course there's challenges around all that version control as ever.

We had very, very often that taking place, especially with more go-to type of like commercial people where they would just package up, you know, a deal and they would start showing some features on like a demo call. Something wouldn't work and they would go do some clicks over there and it's just like, and it's always, it was, you know, like a a gift which keeps giving. You know, it's like a trade-off. Like, there's a, there's absolutely a value in these feature flags, but on the other side, there's some unique challenges.

Some feature flags you can't use together with others, right? So they bump, they bump into each other and break each other. So you need to have good documentation around that. It's like, never use this feature flag with this one, with this one.

Yeah, some manual labor around actually managing all of that. Would the AI help? It's like, can we put some generative AI around your documentation so you can, you know, use it as a bot? Can I enable the feature A without breaking feature B? Would that—

that would be lovely. Yeah, if anyone listening on the call could land that in my inbox tomorrow, that would be fantastic.

Whoever is building software for feature flags, please look into AI. That would be helpful. Right, so, um, jokes aside, um, which one, which, which one of these would you recommend to people starting their own journey, you know, journey in a tech venture? They say, you know, say they have ideas, they have a product, they, they just developed the product. Would you say, you know, go after B2C because potentially you can iterate quicker, you know, you can get your customers on a call, have a conversation Would you say B2C because, you know, you don't need the volume, you don't need to make hundreds of sales to have a revenue, you know, you get 2 flagship clients and off you go. It's like your own preference towards, um, success of personal journey, which one would that be?

It would be B2C, and the reason for that is that I'm, uh, in my DNA is like, if I can use quantitative data to make decisions about what features and products to build and in what order, I feel more confident than if I'm listening to opinions, if that makes sense. And so especially at the early stage of the business, if I'm an entrepreneur and I'm willing to go that far to kind of go on the entrepreneurial journey, it's likely I'm going to have some really good product intuition. I can, I can manage the first little bit, and then from there I've got some data, I've got I've got people clicking on things, I've got people not clicking on things, I've got people dropping off the journey, etc. Really understanding that. And as we grow on the B2C side, we get so much data and we can ask for quick CSAT kind of questionnaires as well. There's so much data at high volume that you can then really make interesting decisions with and have really good products and tech debates internally as well. Whereas when you're working in the B2B space, it is normally, you know, like a lot in corporates, people talk about the hippo, the highest paid something or other in the room. It's like the highest paying customer is the one that kind of like wins. And I feel like we're pretty good in my business at resisting that urge. But I have spoken to quite a lot of other people who work in B2B and I'm like, your life must be really hard because basically the CEO is really opinionated, the top 5 customers are really opinionated. The customer success people don't agree with the CEO, and, you know, you're like in a complete, like, well, all I'm doing is managing stakeholders. I don't really have any data that I can have a grown-up conversation with.

Data-driven decisions. Okay, I love that. What about commercial aspect though? It's like, uh, you know, the, the J-curve, uh, piece, uh, meaning that you're gonna go deep into a minus financially speaking, because you'll need to fund the whole operation. Maybe it's your time, maybe you're hiring people, so you'll have the trough which goes out and you need a really good volume to actually start scaling as a B2C. But compared to B2B, in theory, you could land like a couple of clients. So effectively, your sales OKRs are like 2 new clients every month, where with B2C, it's like hundreds of new customers. Maybe different marketing approach, but financially speaking, uh, who gives a better beginning?

Well, I— there's definitely something in, in, in what you're saying, but what's the point in getting to like, I don't know, 100K or a million of revenue if you can't scale it? In my mind, like, it doesn't mean you have to build a unicorn every time. You can, you know, have a business that's turning over 10 or 50 million, and that's really, really nice.

That's amazing.

But yeah, but I think like going, oh, we've got 2 customers. Was that lucky? Was that based on relationships? Was it based on someone who knows someone? Or is it really based on the quality of the product that we built and how scalable and sustainable is that going to be? How do I know? Can I predict what my revenue is going to be next year? No, not really. Can I predict when they're going to run out of cash or when their year end is, or if the guy's going to change job or his boss is going to change her job. So there's a lot of unpredictable, small volume things. I would rather fail in a B2C where I've got a lot more data that teaches me, gives me learnings about why I failed so that I can apply those to the next iteration, if that makes sense.

It does make sense. And I love how you put it at the beginning that you have a couple of clients and, you know, you have, uh, you said it like managing stakeholders. So you have like 5 big clients with their opinions, CEO with his own opinion, and it's still a very like low volume of, of, of opinions. It's just opinions. And then you're trying to serve all of these opinions and you almost become like a, like a digital agency, right? Because everything is customization. And you know, you have your core product, but then you're working out that and you're like, you know, I'm just like agency now, I'm serving that. So you don't have real direction where you're going. With the data in B2C, you know, you probably can look at that data-driven decisions much better, but you still need to accumulate that data, right? So you still need that volume to happen. So that beginning, can we have this? Can I go to the market as B2B and get myself in a position where I close a couple of clients, so I have some revenue to go with, and then slowly sort of start, you know, scaling that and maybe offering something to B2C and then becoming B2B2C. Is that like a valid journey in your mind?

I possibly— I, I'm not like thinking of any at the moment. I think most of them happen the other way, if I'm honest. So If I think back to my Venue Scanner days, we created a business that was ultimately commission-based as a revenue model. And so we were helping people find venues for their events, whatever they were. And we moved more into the B2B space in order to drive greater loyalty from the B2B side, because once you pay for something, you give it more attention. And so we were able to more than 2x our revenue by moving from B2C to B2B. And one of the companies we admired quite a lot at the time was Design My Night, who you may have used. And they, again, they started as a business of people wanting to find a place to have a party or a pub or book a table or a darts board or something. But then they built this entire SaaS suite for the B2B clients, and that's where they made all their revenue and what they were able to exit on. So I think I see it more in the other direction, if I'm honest. But that might just be what I've seen. Commonplace is maybe a little bit the reverse. You know, we, we, we, we have these, uh, B2B clients who have been funding us, and we're looking at ways in which we could extend some of that revenue into possibly the B2C space. That's where there's a big, maybe untapped market. Um, but it's such a new space, no one really knows. I think, again, an area that's interesting to me is this prosumer space. So We have enterprise clients and that's great, but I think there's this really interesting opportunity for our product to be used by, you know, thousands of small-time B2B-style customers. And that's kind of an in-between step, right, between the B and the C in a way. But it does require you to think in a more sort of product-led growth style approach rather than a sales-led growth, and therefore the, the, the products and the features that you're building are much more in line with B2C. So I've seen it probably more the other way, but okay.

So you start as B2C and then, and then you evolve into B2B. So yeah, that, that scale makes sense, right? You go from taking £10 a month to taking thousands with B2B, so you learn a lot more. Is that, um, so is that like a natural then that, you know, you start small, you talk with people You work out your features and then you go after bigger fishes instead of, you know, going after bigger fishes first and then going to smaller fishes. It's just a natural way of scaling things.

Yeah, I think so. And also in the marketplace, uh, type business, you're, you're dependent on kind of this idea of network effects. Okay. And so until you've got an audience, until I've got a group of people who are interested in booking venues for their events, no venues interested. And until I've got enough venues for people who want to book it, they're not interested. So you've got this real sort of marketplace matching that needs to happen. And there's tons of marketplaces out there, and it's a very common conversation in that space about how do you get the supply side and demand side to match. But ultimately, yeah, until you've got enough of an audience, who's going to buy?

And if no one's buying, you got no business. Simple as that. So how do you get that audience to happen? Is that— so let's say I am B2C, I think I have something, you know, I created something. For the sake of argument, let's say I have some type of service online, it's a SaaS platform. How do I get the audience? How do I get that volume? Is that purely marketing? Do you buy ads? How commonplace does that?

Yeah, so with, with Commonplace, we, um, we've been building up our audience over time, and whenever you use Commonplace, we ask if you'd be interested in hearing about future Commonplaces in your area. So we have a foundation audience for every single Commonplace that goes live that we can tap into, and that's again a kind of key differentiator for us and really helps our customers to get to that baseline of initial audience. And then a good chunk of it comes organically through two, what I'd say are organic channels. One is SEO. So we've done a lot of work to optimize the platform for SEO, and I think that's a really, really important piece in the marketplace space, is using your supply to ultimately drive your organic search. And then organic social. You know, this is a— this once you can get in the school mum's WhatsApp group talking about a commonplace, it will take off. And you can take that analogy and put it on, you know, into Facebook, into Twitter. And those are our most powerful audiences. We also do some paid search where clients would like us to, but it's mainly paid social. That's the highest converting for us. And it was also the one where we can tune our ads to get the greatest diversity in audience. So if you think back to what I was saying earlier, we want high sentiment. High sentiment comes from diversity of audience. So if we've got gaps in our audience base, we can use paid social to fill it.

Hmm. I love that. It's actually very strong channels. So when it comes to organic search, do you guys have like particular strategies where you have potentially like a writer who writes content and generates content all the time? Or is it that you get the content just purely from community talking and, you know, projects being submitted? It's like, how do you actually package what you have or what you create into that? Whatever is the driving—

yep, we're quite, we're quite fortunate. We don't need to do very much other than make sure that technically everything's set up correctly with the right, um, you know, um, Google-based setup and, um, all the canonicalization, etc. But effectively the way the platform works is the customers come and build their own websites on Commonplace. So that's the starting point. So, you know, I want to develop this new development with housing and retail and school or whatever. So there's the baseline of all the content and then you get all the user-generated feedback from the community. Sometimes that's 30,000 responses, sometimes it's 300, but in both cases, the, you know, the indexer, Google loves all that kind of stuff. And then we can summarize it in the proportion of people that were positive, that were negative, that did it this way, that did it that way, that talked about cars, that talked about green space. So all these kind of summary stats, Google loves that as well. So yeah, we're in a good spot for that and it's pretty unique content. It's not like I'm selling a red dress that 14 other platforms have got the same red dress with the same product information.

Okay, that's good on you. That's good on you because other businesses, you know, they really need to put in either real capital or real effort to constantly produce content. And I remember with my startup back in the day, we literally were paying professional writers to just write about ideas because we didn't have like in-house writers just to compete in that space. And The organic search traffic is, yeah, it's very strong asset to any business. So you mentioned the organic social. So I imagine that you mean, you know, people just organically finding you and following your social channels. But you mentioned as well a paid social. So do you have like a social platform which is just performing better for you guys for whatever reason? Maybe it's Facebook, maybe it's Twitter. Any insights into that?

It's, it's Meta, so it's Facebook and Instagram for us. Most, most of the time it's Facebook, to be honest. So that's our strongest performing.

Yeah, we should, we should get in the habit calling it Meta, but I think it's going to take years. It's still a Facebook, right? It's been like— all right, so, so Meta, is there— is it because it's the whole planet on Meta? Is like, what's your take? Why it's Meta?

I think it's probably something around the demographics of the people who are enthusiastic about joining conversations about their place. So we have a very big following in the 35 to 55 space and a pretty good following in the 25 to 35, 18 to 25 less so. Right. So we're not going to start sticking videos on TikTok and doing funny dances.

You should, though, just for the gigs, just for a chuckle. Sorry.

It's the demographics, I suspect.

Okay. Yeah, we had an episode with a Facebook marketer and she effectively said, like, look, regardless of what people think, Facebook still has the majority of online capital. It's basically, you know, the biggest number of people being online is still on Facebook. You know, it might look different because you see TikTok everywhere, something like that, or maybe Instagram. But if you look at the raw numbers, The majority of people are still on Facebook. Like there's no real competition over there. Okay.

So on the social side, the social, the social organic side, the non-paid, because Facebook's quite place-based and locality-based, you get groups that, you know, streets and bits of towns and cities. And then most of the local government customers that we work with, they will have Facebook accounts or multiple Facebook accounts. So they're seeding a lot of the traffic as well for us.

And running ads as well is quite healthy because Facebook gives, I mean, you can go so granular on targeting your ads that it's just ridiculous. Like the most surprised I was, which is not Facebook or Meta, but it was actually Twitter or X. You can actually target audience in such a way that you can say, I wanna show this ad to people who have Teslas or Hondas, like a type of car. And I was like, how do you know that? Like, where do you get this data from? Because it's not like in your profile form that, yes, I own a Tesla, you know, that's— I'm gonna say it. So it's just maybe it's a wrong question to ask, but yeah, things have changed.

Like, there's a lot more restrictions now on— I mean, I don't suspect that they actually have factual data on that. They're probably inferring it and predicting it from your other browsing behavior today, um, because they're not really able to anymore like they could. So I think it's the interest groups become a little bit less solid, but you can definitely diversify your audience.

Okay, so we've got this one, which you put you, um, on a map, let's say. Uh, you mentioned these foundational audiences, which I think it's— that's where that importance of, uh, you know, your, your true first fans comes in play, right? It's, it's, it's your foundation. How, like, do you remember how you guys got this? Is, is it like, you know, your angel list is, uh, their families and friends? Was it maybe on LinkedIn? It's like, how, how did you get your 100, like, first 100 fans of the, of the Commonplace?

Yeah, I mean, Commonplace, I wasn't here right at the beginning, so I would be making something up. Um, if I think back to Venue Scanner days and, and other startups and scale-ups that I've advised, um, I would always recommend to everybody to build anticipation through your own network because you can get some really high-quality feedback from the people that you trust. If you ask them the questions the right way, they're going to give you stuff that will stop you looking silly in front of the real public ultimately. And by trust, first and foremost, there's maybe your friends and family, but other people that you trust could be people that have joined your waitlist. So always having this kind of notion of there's something coming and we're not going to tell you too much about it. So you've got this waitlist, you've got this audience, and you can use that audience to ask them why they're interested, what brought them here, what do they see about the competitive space right now, what's missing. So you can use that and they will pay you back big time if you give them a sense that they're helping you shape their product. You can do that on quite a big number. I worked for a while with Majestic Wine and Naked Wine, and Naked Wine is very good at this notion of putting you in a waitlist and getting information from you while you're in that waitlist to understand whether you're going to end up being a really loyal user or just a kind of a passer-through.

I do remember Naked Wines. I had a box from them. It was like 60 quid for 12 bottles, something like that. I can't remember how I got hooked, but I do remember them. They're probably still around, isn't it? It's not like the business disappeared.

Still around.

Yes, yeah, still doing well. Probably these waiting lists worked well, quite, quite well. All right, so come back to our B2C, B2C discussion. So we now in this space, you know, we started as B2C, we now became B2B. So suddenly we found ourselves in a business which is B2B 2C. So that of course adds another level of complexities. With that being said, what comes in your mind, Benji, as a main thing that happens or the complexities that appear once you start running B2B to C?

Yeah, um, so, you know, touching back on what we said earlier, that you, you have therefore got two different disciplines in your team, in your company, right? So Who you hire and who you put in what positions is really, really important. Don't assume that if someone was an amazing, you know, product engineer working in a high-growth B2C that they're going to do anything useful in a B2B environment. They might be very poorly tuned from a velocity-quality balance to work in that space. Similar for product people. And like I said, we've got that sort of prosumer bit in the middle. Um, but ultimately I think the challenge for someone in a leadership position is dealing with the opposing forces from different sides of the marketplace. Who wants what? What are they trying to get out of this platform? And are their motivations aligned? Um, and therefore, how do you build a product that delivers sufficient value to both sides of the marketplace that they want to stick around? Um, so if, if, if we take Commonplace as an example, We want built-in— built environment professionals, real estate developers, local government to come use the platform to talk to communities so that they can get their planning applications through faster, build better places that are better designed. But they don't really want to talk to communities. We're kind of their enemy. They don't want to talk to anyone. They just want to get through with the least hassle the least cost and with the least amount of change to their plans, right? So they don't really want to use us. And communities, they're desperate to talk. They want to have a conversation. They want to come and meet and talk. And traditionally, the view, the reason why the developers and the local government don't want to talk is because they perceive that there's this negativity, that they're just going to get a lot of negative vibes back. And so there's a complete misalignment in their motivations, right, around using the platform. We're using the platform because we have to, because someone told us to. We don't really want it. We don't want a high volume of responses because all those responses are going to be negative. So we had to work really hard to find this kind of galvanizing OKR, if you like, that everybody in the business can get behind. And that galvanizing OKR is around sentiment. The more positive the sentiment, the quality of the conversations happening on the platform, the better we're going to perform. And there's lots and lots of features that you can build in that delivers that sentiment. It's not just a hope. It's like, you know, we don't have a button that does that on the platform. We have a button that does that. So for those people who can't see me, it's a thumbs up. Uh, no thumbs down on the platform. Um, we look to encourage and nudge people who are being very negative in another direction. Um, so you really have to understand in detail the user problems and motivations on both sides of that marketplace to come up with the right OKRs so that you don't like build this spurious motivation for your teams that imbalances and goes, okay, we've got this amazing supply-side feature or product, but no one's coming on the demand side. It was a complete waste of time. You've got to really focus on understanding objections from both sides of the market, which is just about proximity to users, proximity to customers, and internal teams in support and CS. So it kind of accentuates that need to listen and process and sit and discuss and debate and then come up with the right metrics and go for it. Like I mentioned a bit earlier on as well, we've got the network effects and the flywheel effects. If you can get it right, That's where you really start to power up because everybody else is going, positive sentiment, I get it. That's why I want it. Now the local authorities are asking the developers to use the platform Commonplace because they know that that helps their chances to get through planning permission. And some, all of a sudden we've got everybody motivating everybody to use a platform like Commonplace. We've got the public starting to ask developers and expect of developers that use a platform like ours. Where they can express their views and have a grown-up conversation rather than kind of shaming each other on, on X or Facebook.

Um, would it make sense to all the businesses eventually go B2B2C, or is there a real question you can ask and, and, and go like, nope, I will remain B2B forever, or I will remain B2B or B2C forever because, you know, B2B2C doesn't make sense to me? I mean, we sort of implied with your answers over there what you could ask, but from your perspective, do you think it's a viable option for pretty much anybody, or, or there's some real checks you should be aware of before even considering that?

I think there's definitely some products which are just not necessarily going to be relevant to a B2C audience in the form that they are today. So, uh, I don't know, if you take like accounting software, for example, or software to help you manage, um, mobile device management, for example, you know, they're quite B2B, like specialist products. They're around compliance, they're around regulation, the stuff that, you know, as a procurer you have to do. So you, you take the hit and you buy it. Having said that, they can pivot and they can develop stuff, right? So if you take mobile device management, we're all trying to manage what our kids are watching on their devices. So maybe there is a B2C version to everything. And I think it's a really, really good question. And I would love to challenge anyone who is sitting there struggling with this notion of, I've got a load of requests and solutions sitting on my desk and no one's having a sensible conversation. Can you get more data by pivoting to talk to that B2C audience and understanding actually at scale what's going to solve this problem? So yes, it's a fascinating question. Love to think more about it.

Yeah, not all the businesses, you know, do it. I mean, we, again, I'm just coming back to my own startup, which was, you know, B2B. It took some time and we always thought about B2C because we did B2C, but it was through the umbrella of B2B. So you sell the product to the business and then all the employees of the business use the product. So effectively, you know, it's like you got B2B as a sales cycle, but at the end of the day, the product was being used by customers as well. But of course, the scale wasn't even as close as what you could get if you actually go public as B2C company and you go like, hey everybody, you know, here's a free trial, or, you know, whatever is the business. Pricing modules. And we always discussed about, you know, maybe we should because we're going to get, you know, so much more exposure. But the answer always was like, what's the return of investment over here? Like, how much capital, money, and effort should we— we should be putting in? You know, what's the potential out of this? And it just never fully made sense, uh, because we had enough as a B2B business. Like, the plate was full, if that makes sense. Yep, right. Uh, so, um, so how does the CPTO slot in, Benji? So it's just, um, it's interesting to me because I feel like it's a role which is a little bit, uh, like two-in-one. I mean, maybe not a little bit, I mean, it is a two-in-one role. So you're doing a product and technology at the same time. But would it make sense to have this, uh, as a big company? Like, do you see CPTO role being something which applies to maybe medium and larger enterprises than just smaller or startup-ish type of companies?

Yeah, um, good question. Um, I'm, I'm not 100% sure that it's sort of size that matters. Um, I think it's more kind of type of company. And the extent to which it's truly a tech company or not, and the types of discussions that need to happen at the board table. Because I think what a lot of boards aren't that interested in is watching the P and the T person, like, debate technical stuff, because they don't know how to contribute to that discussion. It's alien to them. And you could argue that everybody should sit there and learn about it, but I think having one person that can bring this joined-up, uh, thinking is, is quite helpful. So, you know, I, in my view, having done kind of all of these different roles, um, the P role is ultimately responsible for the strategy, more strategy-oriented. Yeah, they've got loads of data to fix, sprints to drive, quality assurance to do, but ultimately they're decision makers, right? And the T role is a more execution-oriented Yes, they've got technical design to do, they've got architectural discussions every now and again to get into and have big debates about and whiteboard. But we really need them to keep the lights on, to manage performance, to manage what I've coined in my own head as expensiveness, um, and security and all that. We need, we need them in that like executional role, um, and so I think one is better suited to the kind of strategic lens operating board, and one is, you know, or board, and one is more in the kind of like we're executing mode. And it just depends a bit on what like mode you're in. But I don't think you, no matter how big or small your organization is, need both. Um, it could be a size thing, but, um, I think it's more, like I said, about the types of conversations. If you're a sales-led growth organization, then you're going to be having loads of discussions at the board around brand, lead generation, deal pipeline, sales. Lesser— there'll be lots of decisions and discussions around both product and technology. But, you know, at the end of the day, there does have to be one decision maker. There has to be someone who says, this is where we're going next, and I'm responsible for balancing the amount of time we spend on tech debt versus building new stuff and trying to get that kind of level right. Um, and I think also trust from the CEO as well as the board is critical, um, much more important than the structure. So is there good trust? Um, and is that person a really good critical thinker that can think across P&T? And like, definitely nobody— not everybody can do it. I couldn't have done it like 10 years ago, no way. So I've grown into the role and I've learned about the weaknesses that I had, and I have great people to fill those spots, and I know how to sit and ask the stupid questions, to be the critical thinker. Um, so yeah, I don't think size matters. I think you can have both on the board, but it can be a big distraction from like what actually needs to be discussed depending on the environment and the board.

So there is a value which we're leaning towards. So what's the trade-off then? If I have one person who does both of these, P and T, um, can I say that maybe that person will not be as skilled as two people, and, uh, you know, as a result they will not have the, the depth with the product or the depth with the technology which potentially is needed? Maybe not. Maybe it's a startup and we don't need that. But maybe at the, you know, bigger enterprises, maybe that product vision requires a lot more time than one person can give to do market research, you know, talk with people or whatnot. Is there effectively not as— thinking how can I phrase this— but effectively, you know, where I'm going is that one person having P&T will likely have less depth than two people, which is product and technology. Specifically?

Yeah, I mean, I think you can ask the same question around a lot of areas, you know, sales and marketing or account management and CS and stuff. What matters most at that level is the structure that's underneath those leaders. And like, in theory, let's say I'm working in a company of 300 people or something, I don't need to be that deep, right? I've got a team of 20, 30, 50 people working in products and technology. I need them to be amazing, and I need to be in good shape to be able to ask searching questions, get the right conversations happening, and motivating everybody, and recruiting the right people, and attracting the right talent. They're the sorts of things which the board care about, not whether I know how to, like, do a code review or know how to run a customer interview. Um, that's what I have other people to do. Um, so I— yeah, again, I I, I, I don't think that at this kind of level it matters too much.

Okay, um, I love that.

I think it matters more at that kind of head of sort of level.

Yeah, you're absolutely right. It's, um, you need to have enough to be able to hold a conversation and ask the right questions, and then hopefully you're attracting a good talent and you're actually hiring people which are clever than you. And you know, you have that leadership position to utilize others. Okay, so, and it becomes better, you know, financially speaking, to business as well. You have one executive instead of two doing very important function. So from, from that perspective, as, um, as, as you see it, do you think the CPTO will become a lot more popular way of moving forward in technology businesses?

I think it requires a lot of bravery. You have to be brave because what it's doing is it's ultimately making your organization more commercial and more strategic. And while that sounds like a really easy thing to do, it's like, oh, I need to keep the lights on, I need to worry about security, I've got all these regulatory things like chirping away in my ear as a board, and I, I've got to keep on top of all of those other things. But, um, yeah. Like there's a big theme and topic, right, about driving greater autonomy into teams. So let's flatten the organization, let's reduce the number of hippos in the room, let's reduce the number of leadership roles down so that we can invest more in, in people and that autonomy to do things. So I don't know, I think it's, it's, it's something that's emerged, um, and I think a lot of people are a little bit, um, unsure about it and anxious around it. Um, but I do think it requires bravery. Um, I, I think back to actually working in some of the biggest retail organizations, and we had a situation like 12, 15 years ago where the tail was wagging the dog. So we had the CIO, the CTO, these huge companies owning all of the CapEx budget, running all of the capital, and they're making decisions about customer experience, but these people are mainly supplier management professionals. They're vendor management, they're procurement guys. They know how to buy from IBM and Oracle and whoever else is new that's coming along. They're not ultimately people who should be making decisions around the customer experience without the business owners or the strategy owners supporting and making those decisions. So I think it really started to crumble quite a long time ago in these big companies that the CTO is the person with all the money, because it's the business that needs to learn how to deploy technology correctly. Otherwise, you end up building technology for technology's sake, because you got a shiny new checkout that they found at some, you know, exhibition they went to, but it doesn't deliver an improved customer experience. So who cares? So, you know, I think, again, depends on the context, but there's definitely evidence that You've got to have the right people making the decisions and then the right people deploying and executing on those decisions.

Yep. I love, I love how market is innovating. You know, we, we do see a very big rise in fractional CTOs. It's just like if you look around LinkedIn, yeah, where all the professionals are, the, the fractional/consultancy CTOs is definitely on the rise. I don't know, is that because we, you know, we went remote, or what's the real cause of it. But it seems that a lot of professionals are starting to choose, you know, that approach where they can give a day or two a week for multiple companies. And for companies, that's actually a value exchange, because again, if it's a startup, if it's a smaller company, maybe they don't need a full-fledged CTO, uh, but at the same time, they could just benefit from someone much, much bigger for the company, you know, giving them a day or so than having a full-time you know, senior developer being promoted to CTO, right? And then, you know, these CPTOs roles, that was new to me. I actually got stumbled upon this in a conference where, you know, someone introduced them as CPTO, and I was like, how does that work? So it does seem to be on the rise as well. So it's just market doing its own thing, finding better ways to move forward, which is great to see. Um, so we have this one question, Benji, which is in the spirit of the show, and it goes like this: What is the main one factor for any tech venture growth, in your opinion?

Not something that we've necessarily spent a lot of time on, but getting the DNA of your first engineers right, or engineer right. Let's assume you've got one. Is she or he someone who's gonna go gangbusters and take a few risks, or is she or he somebody who's trying to build the perfect infrastructure for landing rockets on the moon. And that's a hard thing to figure out, but you've got to get that right. Because I— one thing I've learned is that the varieties of DNA of engineers is very— is a huge scale, huge spectrum.

I agree. It's like everybody has different approach. Which one you think is the most important at the, at the very beginning? When you're kicking off.

Entrepreneurial doesn't really care about the infrastructure, doesn't know much about the infrastructure, is just hungry for more data to help them make decisions and help you have good conversations together about what to build next and to explain why you built the thing that you built and learn from it and go, well, that was a waste of time, let's not do that again, let's pivot, let's iterate, let's go here. And if you get stuck in trying to optimize CI/CD or trying to build too much alerting and monitoring, you're going to stagnate. You have to take a risk on that stuff and sort it out later. Not too much later. Maybe engineer number 3 has got a bit more of that, but not waiting till engineer number 100, right?

Okay, I love that. So effectively, if we're choosing one thing, we want to make sure that our first engineers who are actually going to build the product hands-on they have approach and a mindset which is entrepreneurial in the sense that they don't care about technology choices that much, but they care about the solution they're building and making sure that the solution is actually what the market and client needs so you can actually go and sell that. Is that a good—

yeah, they probably, you know, they probably care about what language, what framework, but you don't want to be having long discussions about whether to use AWS or GCP or Vercel just crack on, right?

Like, let's go, let's go, let's do that. All right, I love that, Benji. It's a very good shout. So, uh, got no more questions, Benji. Thanks for coming. It was a lovely chat. Uh, thanks for all the inputs regarding B2B, B2C, the complexities, how you guys do that at the Commonplace. And thank you for shedding light on the CPTO role, uh, which for me personally is still a role I wouldn't know how to hire for, by the way. So thanks for all of that. Hopefully it was enjoyable to you.

It was. Thanks for having me. Really good fun.

Thanks, Benji.