Fall in Love With The Problem, Not Your Solution

Sean Weisbrot: Welcome back to another episode of the We Lift to Build Podcast. Product Management is something that didn't come naturally to me and is something I've been working on for the last three years since I started my company. Thankfully, I'm at a point now where I recently hired a product manager to take over for my shortcomings.

Sean Weisbrot: In that aspect of running the company, going through this process made it clear to me that we all struggle to manage this part of our business, and so I decided to invite Matt Barnett, founder of Bon Juro, to talk with me about it in this episode. I chose him because he has a background in industrial design and lots of experience managing product development for various companies, including several of his own like Bon Juro, which helps companies customize their onboarding experience for users.

Sean Weisbrot: We spoke specifically about why should a founder focus on their product, why you should start with the problem. Why you should try to consider all possible solutions before taking action. Why is making mistakes an acceptable and constant part of innovation and progress? What are the three stages of feature conceptualization?

Sean Weisbrot: If a founder wants to step back, what are the first steps they should take? What kinds of people should you hire to manage your product and is there a logical order for hiring them and much more.

Sean Weisbrot: I am really excited to talk with you about products. As a person myself who is not trained in design or product, I'm completely self-taught and working with my team, I've learned a lot. I. Uh, hopefully talking with you can help me get better at it and hopefully the audience will understand better why they should focus more on their product as founders of their companies.

Sean Weisbrot: What it is you do now, maybe a little bit of your backstory and how you became interested in product and design.

Matthew Barnett: so I run a company called Bonura. I'm the Papa Bear or CEO, but I also sit as head of products.

Matthew Barnett: We basically do personalized video messaging. So we're a system that works top of your CRM shop mailing lists. And what we found is that when customers perform certain actions, such as a lead comes in when they make a purchase, if you want to improve retention and enable lifetime value, customer service, customer support is at the core of that.

Matthew Barnett: It. So what we do is we'll get you to send personalized video messages to welcome customers on board, thank them for purchasing, get 'em to share, uh, the news and talk about what essentially.

Matthew Barnett: Work myself. I was designed by trade, so I actually changed as an industrial designer, which is, if you say product design, half engineering and half art. It kinda welds those two together.

Matthew Barnett: So I always assumed I would go into building tangible products, things that you can get off the shelf, like I worked in Design NCES as my first job. Did a lot of medical stuff. Did a lot of like, like we worked for like Rolls Royce doing cars and, and kind and stuff. We did mobile phones and devices, and then I moved to Australia from the uk.

Matthew Barnett: And somehow fell into technology. But ultimately it is the same process, both just like building companies and building products. But building products is still about working with users, testing a hypothesis, pulling that back, building the first version, building a second version. You know, obviously if you are in the company as well, you are raising money to like tool up.

Matthew Barnett: So obviously in in products, that's in terms of like engineering capacity versus actually hard tools. But really it's the same process that you go through May. Maybe the main difference is that if you're building real world tangible products, you are more likely to build product suites. So you'll be building new products and new products and new products, and the older products will like ultimately chucked away after a time.

Matthew Barnett: Whereas when you build products online and software. You tend to start to build upon the product that you started with. So you end up building this, this, this monolith over time that ties everything back together. That's probably the primary difference, but the actual online, offline, it's not really that different at all.

Sean Weisbrot: Okay. So I think the most important thing we should start with is why should a founder focus on their product? There's two sides here.

Matthew Barnett: What I'm not gonna say is it's not about build and label come like you need to go out there and market and sell your products. Like regardless. So it's not like just a made product, like it helps.

Matthew Barnett: But when you first start building whatever it is you're building, you have to get product market fit. And so the market side is really important, but the product part is just as important as well. Now, if you understand how products work, if you understand how to build products, if you understand how to build products to go and solve problems and as correct problems, you're going to get more uptake.

Matthew Barnett: You're gonna get customers staying longer, you're gonna get more activation, and you're gonna build a business faster. So ultimately, the more, the more that users use your product. Even if you haven't sourced out your pricing, if you haven't thought about other things, they will stay with you longer and talk about you longer, and start to build your funnel and help you go and solve the next problem.

Matthew Barnett: So if you, if you build great products, the chances of your success are increased multiple fold.

Sean Weisbrot: So let's assume that the audience has never built a product before. They're either wanting to start a company or ha have started a company like myself, but this is the first time building a product. So talk a little bit more about what some of the things that they should be thinking about, some of the mistakes they may make if they're not thinking ahead and things like that.

Matthew Barnett: Yeah, so most businesses start with like obviously the concept of an idea and hopefully you start with a problem. If you haven't got a problem behind the idea, go back and and work out what it really is. 'cause you need to understand the problem fundamentally. Don't start with the solution. Start with what the issue is, get to the solution and think about all the different ways you can solve it.

Matthew Barnett: It, it is one of the reasons why a lot of starts fail. It's not that they've got the problem wrong and the problem is often there, but by jumping to the solution, they've missed more obvious solutions, easier to build solutions and better solutions to really have a look at what it is you're fixing. What it is you're doing.

Matthew Barnett: You know, with us when we built our business, it was about connecting with customers. So how do you connect with customers? On a one-to-one level, but do it in a scalable way. And that was the challenge. Ultimately ended up like video was the way to go here, and the way we built the system was the way to solve that.

Matthew Barnett: But that was a problem that we were trying to solve initially. So really strip back to what the fundamental mental problem is. Then when you start to look at the product, start with an open sketchbook. Solve the problem in every way you can. Whoever you've got on the team, whoever you've got around you bring them in and get the ideas out.

Matthew Barnett: So really start to go quite wide before you go narrow. I think again, you know, we all start to get blinkers, and as your, as your business builds and builds and builds momentum and gets larger and larger, those blinkers actually become narrower. So trying to think and rethink about problems and think outside box again is always, is always something you need to consciously go and do.

Matthew Barnett: So look at this, and this is before you even touch. Don't touch any due design, don't touch anything else. Use a sketch board, use paper. You know, don't start building things before you've really thought about the problem and it's core, stripped it back and then gone wide on solutions. And what you can do now, what you're looking for are the solutions then is what's solves the core problem.

Matthew Barnett: 80% of the, of the way with the least amount of work. Because when you first start something, what you're looking to do is, is to work out if your hypothesis. Is correct as quickly as possible. The other place you see people fail with their products is they go and build the perfect solution. It takes a long time.

Matthew Barnett: It takes a year to build, and then they get to the end and turns out it wasn't the perfect solution. It might look amazing, but, but they've missed something fundamental that they didn't understand. Not because they didn't think through it properly, but because users behave in ways that we don't expect.

Matthew Barnett: The world changes and things happen. So you need to get things out the door quickly when you first start because you need to work out, this is a problem, we think we can solve it with this. Is that a true hypothesis? And we've talked to 10 people. I'm a mom and my auntie, and they all say, yeah, it's a great idea.

Matthew Barnett: You put in their hands to users and then they do some completely different, but you couldn't have expected because human psychology is hard to understand. So. Strip it back, see if you can get to what you think is an 80% solution. Does not need to be a hundred percent. If you can get something out the door as quick as possible.

Matthew Barnett: And this can be use whatever you like. It can be PowerPoint, it can be Excel, it can be Figma. You don't have to code a single thing. you might wanna do a little bit. It's okay if you wanna spend, you know, a couple months or something. but get out the door quickly. And then the next most important part of all of this, and this will stay with evil life, is you then have to get people using it that you don't know, and you have to talk to 'em and watch them.

Matthew Barnett: So don't do this in the isolated box. I think that that's probably like quite a good starting point. So there's a few things in there. I dunno if you wanna dive in and pick some of this apart or.

Sean Weisbrot: I think that's a fantastic starting point for sure. I, I love how you mentioned having people try to sketch out all possible solutions before taking any action.

Sean Weisbrot: Because I think what most people would do is just say, I have an idea. I think this is a solution. I'm gonna go build it. And then people go, eh, and you go, oh, okay, now I need to go and build it again and see what happens. People go, eh, and then you build it again. It's kind of like an inventor, right? An inventor will say, I'm gonna build this, and then it fails.

Sean Weisbrot: But for them, it's not a failure, right? They're like, okay, well, it didn't work this way. Let me try it again. Let me try it again. Let me try it again. But had they tried to tackle it in all of those different ways, they could go and start something with the guests and then figure out and tweak and then eventually all of their pos potential solutions together might actually make sense. And there's parts of all of the different solutions together actually makes something cohesive. Where in the initial stages of thinking about it, they were disparate options. And your

Matthew Barnett: cross partner ideas. You take a little bit from this one, a little bit from this one. If you have different brains, and this is why, why it's support, having a team or, or a co-founder who does not think in the same way as you.

Matthew Barnett: If you are creative and they're an engineer, then you're gonna have very different solutions to any problem. And the beauty of it is, is that the real solution, the unique solutions, probably somewhere in the middle of those, one of the things I would say is give this the time it needs. We are all in a rush to build our businesses.

Matthew Barnett: You know, we're, we're a few years in, we're still in a rush. Every sprint is like, oh my God, how much can we do? But what you find is if you spend more time on the problems initially, and you spend more time scoping and you spend more time researching and investigating, it actually ultimately gets you stuff out, out the door faster.

Matthew Barnett: It means you're not necessarily making mistakes down the line. You're finding easier ways, you're finding different ways, you're finding better solutions. So it's actually worth investing the time up front. I mean, this goes back to like university. I like early studying. Having that time to research gave you great results at the end of it, like you need to be back in that mindset where like, you do not have to solve the problem today.

Matthew Barnett: You might wanna spend two weeks researching everything around there, pulling all the ideas, looking at everything, and, and guarantee It's very, very rare. The first solution you come up with for any problem is, is the one that that ultimately becomes the end one. You might build it and then like you said, it doesn't really work very well, so you have to go and rebuild it anyway.

Matthew Barnett: You wanna try and minimize that. You'll end up doing it to some extent. If you try to minimize the mistakes you make for down the line, and then again, ultimately if you don't have to get me build stuff, you're gonna get stuff out faster.

Sean Weisbrot: Yeah. I definitely found that I made a tremendous amount of mistakes, particularly around planning different sprints where I. I didn't have someone to bounce ideas off of before I planned the sprint before. So in the middle of the sprint, the developers would come to me and be like, Hey, I think you're missing some details from this issue. Like they would find edge cases that I didn't think of or some specific, uh, UI implementation, or they were missing the workflows of different feature sets and things.

Sean Weisbrot: So oftentimes the complexity of the sprint would grow. During the sprint and then it would screw up the the stories or the epics, and then my CTO would get mad at me and my COO would get mad at me. And so eventually they forced me to use ProdPad. I don't know if you've heard of it, but it's a product management software.

Sean Weisbrot: It's like about $1,800 a year. And then we decided to hire a product manager a few weeks ago. Now we're doing like product meetings every week, or if I am preparing something, I can share it with her before it gets slotted in. So that she can help me find problems. And so I, I, I agree. Having a team is forcing me to step my game up because I don't want them to find mistakes.

Sean Weisbrot: I don't want them to come back to me, and then I have to spend more time on this because I forgot about something. And so it's forcing me to get better at design, to get faster, at design, to be more thorough with the different workflows I create, to create more standard in my design. And you know what? Having a design system. Has been extremely helpful in setting a foundation for me in how to do all of that stuff.

Matthew Barnett: We are in the position where, where we have teams, you know, and we we're down the line. This is awesome to have this. When you first start, don't necessarily have those. Don't go build all the processes in day one.

Matthew Barnett: Don't make a product manager your first, your first hire. Muddle through. It's like you don't make your sales guy necessarily the first hire, like so like work out when you can do this and increase processes over time. The other is like you are going to make mistakes and that's actually okay and that's a key part of building great products.

Matthew Barnett: You have to be willing to take risks and to test stuff where you dunno the answer. So what that means ultimately is that mistakes will get made, things will unpack in ways you'd like. Users will behave in a way that no one could have predicted, because who knows, again, that's okay. But, but what you're trying to do is to minimize the time, cost it takes to find out those mistakes.

Matthew Barnett: And when you find that good mistakes, and then you act on them and then dig deeper again and understand, and then fix 'em again. This is the stuff that makes good companies great because you ultimately end up coming solutions that are incredibly hard to get to, that you've had to get through, through some trial and error.

Matthew Barnett: That means that if anyone else wants to copy or do anything else, they're gonna have to go to this process as expensive. Hard to get to that. I guess what you're trying to do is just minimize that time. If every build takes you a quarter to do. And you're gonna have to do four builds to find out what it is that really works.

Matthew Barnett: That, that, that's, that's a year gone. Instead, if every build takes you a sprint, so kind of two weeks, then two months in, you are in that same position and you may be invested less time and you try to find out the mistakes early. So don't be afraid of making mistakes. Build process as you go. But the whole point here is minimize the time it takes because it's the number one thing you, you can't get more of.

Matthew Barnett: You can get more money, you can get more people, like you cannot get more time. That's a finite resource.

Sean Weisbrot: Recently we started doing feature proposal meetings, so it includes, and myself, my CTO, my COO marketing director and product manager, so that we've got all of the different departments understanding, okay, what's the usability, what's the feasibility, what's the marketability, what's. The user friendliness, what's the complexity, et cetera. What I found was when we first had a conversation about a feature that I proposed, they would be like, oh, that sounds great. But then I would go back and I would go, you know what? Actually, I think there's simpler ways to do it. And so I, for one of the feature sets I went through, I spent a day and I redesigned it multiple times in order to make it as simple as possible.

Sean Weisbrot: Why don't you speak to. How people can think about how to make what they're building as simple as possible in order to save time for development and to make it more user friendly. A nice framework for

Matthew Barnett: this is to think about any product you build in car three levels, so you're gonna have necessity. What does this feature have to do?

Matthew Barnett: Like what does the problem. With us. If it, again, being a video platform, we should be not creating a new video. That's the number one thing we're trying to do. The function has to do that. Whatever we design has to have, have that in there. You then have next stage, which is kinda like this is the expanded feature set, so you have the kind of crucial part.

Matthew Barnett: Next part is, is this would be great if it had this. So yeah, we'll help people create video and we'll also help them brand that video. The last part is the delight factor that goes on top of this. Now when you first build features and test features, forget a delight factor. 'cause this is like the icing on the cake when you know it works and it's gonna go ahead, come back and do that as well.

Matthew Barnett: How do you make creating a new video, the most delightful process? And how do you add little things in where people are like, that was enjoyable? You know, it makes 'em feel good about doing it. So when you and you build any feature it has to do the thing you're trying to do, that's actually your goal. And if you just do that, that's okay, because you can work out very quickly if that was right in the first place.

Sean Weisbrot: So let's say you, you mentally go through these three stages, and let's say you mock up all three of these stages. Are you only going to push out the first stage for your test? And if people like it, then you move on to stage two and then to stage three? Or do you leave stage two and three for like a year later? Or like how, how do you prepare for that? It

Matthew Barnett: depends on the stage of the product, the stage of the company, and what it is you're trying to do. So if you are trying to do like quite a small feature, you can probably do, do all three of these. You know, if you're trying to fix a small problem and the whole thing, even at the delight scale is like this day's work, get it in here.

Matthew Barnett: Like, like, you know, if it's an extra 20% time, do do the delight. That 20%, it's a couple of hours, do it. That's a good thing. If this is a product you're trying to build, like a new product you're releasing or your first products and that delight is the next 20% of time, but the first thing's gonna take you three months.

Matthew Barnett: Do you wanna spend the extra, whatever it is, you know, four weeks time building this, or would you be better off utilizing that time to go and build something else? Which is also crucial because we don't have just one product in a historicals and we're not building one thing. We have stuff backed up. And so this is part of the role of getting good at product management is being kind of ruthless around this.

Matthew Barnett: If you're building one thing in isolation, maybe you're gonna do all three, but that's never the case. I mean, if I look at our kind of like upcoming feature list, like it's, it's insanely big once you look at it and I'm like, I'm like, I could spend another four weeks on this, or I could go and build this other thing, which I think also satisfies number one and two, another core part of the issue as well, which is also very important.

Matthew Barnett: So the total value. Be doing stages one and two on two features versus doing stage one three on one is gonna be higher for the end user and therefore they'll stay longer and they'll spend more money and, and we'll grow faster. You might just wanna do the first stage if it's more known. So there's also like risk here as well.

Matthew Barnett: If you build something new and you're like, wouldn't it be cool if we did this? And you talk to some users and they're like, yeah, we'd use that. And you're like, I think they'd use it. I'm not a hundred percent sure if they would use it. Maybe just do step one. You don't necessarily have to. There's the idea about minimal buyer products.

Matthew Barnett: And I heard someone else term it minimal mark marketable products. So kinda like MMP, which is like as the company grows, you wanna get stuff out the door that doesn't look like a dog's dinner. You wanna actually, it actually look good as well. But this is why you also have things like beta users. So you have a core set of users who you can't know and you can use customer success to help you find these and bring them in.

Matthew Barnett: These are like early adopters, your innovators, and you're like, look, we've got this new idea. It looks god damn awful. However, if you want to give it a shot, I'm gonna turn on a toggle and you can go and try it out and just give us some feedback. There'll be a subset of users who are like, hell yeah, like, I, I wanna do that.

Matthew Barnett: And they'll go on board and, uh, and do it for you, and therefore you can't release stuff that doesn't look great. Unlearn early on. So the most of a user base, if you are, you know, Atlassian or or large company, you gonna release something like at that level, probably not. You probably wanna develop it further.

Matthew Barnett: If you are a new startup and you're building your first product, yeah, you wanna make oil releases like that because you don't have any users anyway. So like, you're not, we gonna upset anyone and you'll find your early adopters and in innovat. So look again, like the, the spectrum really is about the size of the thing you're building.

Matthew Barnett: Each step is gonna add on. 20 or 30% of time, where's it worth the benefit versus the time? It depends on the risk stage as well. If it's super unknown, just don't invest too much time into it anyway. it also depends on the stage of the company and where it ats

Sean Weisbrot: we're getting ready to start having people try out the product in about. A month, month and a half, but we feel like we probably won't be able to start charging for the product because there's a competitor. There's enough competitors in the market that we really need to have people just use it and see what they think before we feel comfortable to start charging for it. It's probably 10 months to a year out based on watching how people use the product.

Sean Weisbrot: How can we determine what. Is something we should charge for and what is something that everyone should be able to use for free? I will challenge

Matthew Barnett: your thinking there. Personally, I think you should charge as soon as possible. I've never seen a founder charge too much for product or charge too early. I think like as founders, this is always a surprise in the lesson to learn.

Matthew Barnett: We have only ever put prices up over time. We've obviously increased increased value with it too, but we also got payments on plans Very early on we had a free, we had a free option and the paid play option. We didn't take away the fact that we had free in testing, but we actually put a price tag on it and people paid, and we were surprised.

Matthew Barnett: We were like, oh, that's, that's interesting. And that starts to give you confidence as well. So it's not, it's not necessarily about the revenue, it's about the confidence that you have around the product. So the, what I would say as a base is unless you're doing a large super scale B2C play, if you are in B2B especially, I think you should have a payment metric quite early on.

Matthew Barnett: And you can have a free metric too if you are worried about turning people off. But just put it there. Something on it and you just never know because it, it's also a data point and a learning point. It's also a positioning piece for your company. Back to the question around what you charge for and where you charge.

Matthew Barnett: Again, this is a research piece. You need to understand from your users where the value is in the product. So where's the real value? Most B2B products are not freemium. Most of 'em have a free trial and then paid. So you need to work out again, what kind of model makes sense for you. And sometimes freemium makes sense because you're going after more scale.

Matthew Barnett: Generally, if you're a scale play, that's where you consider freemium. If you're not a scale play free trial's good. You might not get as many sites but gonna be more serious anyway. 'cause then there, there's a payment piece At the end of it, tie your pricing to the real core value in the product. If you're not doing a freemium model, that needs to be value.

Matthew Barnett: They can't, they can't go without. If you're doing a freemium model, tie it to anything that is crucial for scale. So you might have free users that are like little tiny users that are like, you know, single entrepreneurs and that's fine. But as soon as they start to get a bit of a team and start to build a business, you wanna be charging them and they're gonna have revenue that points to do that.

Matthew Barnett: So to give an example with us, we tie revenue to features. We have features. Around branding and around customization and around making it easier for teams to work. Pieces around scale and ability, and we tie our pricing to that. Some platforms do usage-based pricing, so if you look at any CRM mailing list, it's all about the bigger you get as a company and the more you start to use their product, the more they'll charge you.

Matthew Barnett: Those models are wonderful because as the company's growing, that's a positive thing for them. So if they're starting to pay a bit more over time because they're growing, they have more revenue, you actually like align with them as a company. So again, like it works on that scale. There's a million different price models.

Matthew Barnett: Look at them all like, like dig into all of them, but you need to tie and them price into the value how much people will pay. Is a whole another kettle of fish and how you price you will change your pricing. We've changed our pricing I think nine times so far. I chat to a company the other day called Buyable, who are a much bigger video platform.

Matthew Barnett: They said they have 127 different custom plans for all the pricing tests they've done over the last three years. And they're like, we can't calm it down, but, but they would do a new pricing test every single month without fail. Do a lot of pricing testing when you get capacities to do it, and generally, most of the time it comes down to putting new prices up over time, but if your product's building value, that, that also makes sense.

Sean Weisbrot: You said there's a, a feature you have around branding, so would you show the user on the page where they're doing branding or customization, whatever, and go, hey. If you upgrade, then you can unlock this branding feature. Or do you hide that and just show them on the pricing page or the comparison page of like, oh, you'll get a branding thing.

Sean Weisbrot: So how do you entice them? Yeah, never hide

Matthew Barnett: stuff. So this comes down to free trials as well. Like, so if you have a proper free trial, you're doing 14 days or 21 days or seven days or, or whatever it is that you think is gonna make sense, you let them use the paid features, you let them taste it, you might wanna limit that, but you let them utilize it so that you get hooked on those features.

Matthew Barnett: I'll talk to the majority and I'll talk to like B2B players here. Again, things like Dropbox, where it's like mostly free, like a senior models will leave aside for now, but you let 'em try those and at the end of 14 days you're like, guess what? You can't use those anymore. So you take them away. Again, people are, oh, I want that back again.

Matthew Barnett: You might just lock their account and be like, we can't use a product anymore. Walking customers through plans is really important. Yeah, so if especially, so if you do tiered pricing, then the reason we have tiers is 'cause you want customers over time to move on to higher and higher price plans that come with more features.

Matthew Barnett: The first time we launched, we had a single pricing plan, and that was it for all users because it was simple and we were trying to ask, do we have a product and a business here? That's a great way to launch products. As you start to build the features and build the platform out, you then start to bring the second tier and then a third tier, and on you go.

Matthew Barnett: When you build those other tiers, you're trying to move users up. Those tiers always like, like the ideal scenarios, everyone starts on the first plan. They finish on the last plan. So everyone moves out of time. You then tie those upgrades to stuff that people will, will want the more and more that use your product.

Matthew Barnett: So, so the more they get across your products and the more they're getting better into it, which if you're doing good, then this will happen. Then they just start to empower users and then they're like, I want more branding and I want more stuff. And then they go onto that one, have upgrade triggers on the piece.

Matthew Barnett: So with us, we, we say, look, you have three pieces of brand new customization. If you want five, it's next tier. So when they go, when they fill up three and go to the fourth one, there's a modal which says. It's time to upgrade. We don't hide it away. Some features that are completely binary, AKA locked off for free users are not locked for any paid user.

Matthew Barnett: Again, we'll have an upgrade model there and we'll probably gray out as well. Product is one way of tackling this. Customer success should be charged with with this as well, so customer success is. Job is for retention and for expansion revenue. Like that's where they sit. So they're trying to keep customers longer and they're trying to get people to upgrade through tiers and spend more.

Matthew Barnett: And this is how you increase lifetime value of any customer. There's also campaigns they can run. The way that they're doing engagement with, with users is to push this. They're also try and promote features and they're trying to upgrade people to the plan. You can do product walkthrough tools like it.

Matthew Barnett: It's, you can highlight a new feature with like a little hotspot and say, you can use this now, and they gonna go use it. And then there's a paid mechanism on it. But overall, don't hide features away. You have them up. The only caveat is, is you may have some features that are really there for power users.

Matthew Barnett: You wanna make this obvious 'cause they confuse early users. So for instance, we have one where people like custom domains, it's quite complex. It's quite hard. People tend to ask for it off. They've been with us for a long time. We're like, actually we do have it. It's.

Matthew Barnett: It's over here, but we don't put up up at the beginning because it's a brand new user. There's already so much to learn. It's, it's gonna confuse you. So that's, that's I think where you see features hidden is they're not made from new users, they're made of people off. They've been with you six months or, or 12 months.

Sean Weisbrot: Do you have any sort of data on how long? A specific cohort or a specific user is at a certain plan before they upgrade.

Matthew Barnett: This is the other Pandora's box that adds a good product builder you're gonna need to, to get your head around. So we talk about leasing products and the have A LCN, and that's useless if you can't test them. As you get bigger, yes, you've been talking to users, but you'll want quantitative data alongside qualitative.

Matthew Barnett: Yes, talk to users always, but watch what users do and do they click on this button? Do they do this and do they not do this? You need to understand your users and your cohorts as much as you possibly can. You will never understand them enough. Ever, because as you grow, you're like, oh my God, there's, there's like more holes and stuff we're not tracking, and then you'll fill that in.

Matthew Barnett: But then you'll be like, oh no, but then there's a hole here and it's like it's never ending thing. You're always looking for more data. The bigger you get, again, if you have five users, you're not looking for percentages 'cause it's not statistically significant. When you have 10,000 users, then you're looking at that and then you have a hundred thousand users.

Matthew Barnett: It's different. Again, you always be chasing data, but yes, you wanna understand how long people stay in trial. You wanna understand how long people stay in a plan before upgrading. You wanna understand what types of users upgrade. Versus other ones, both from a, I guess a channel perspective, so kinda like what type of user they are in terms of like marketing, but also from a usage behavior.

Matthew Barnett: So we do a lot of like product qualified leads. So we'll be like, oh, based on this behavior, this user is likely to do X. We'll also go, ah, based on the industry this user in is in, they're an eCommerce clients, they're also likely to do X. And then you try and marry these together. So you wanna cut your days different ways.

Sean Weisbrot: I want to change, uh, focus a little bit and talk about building a product team. So if you're a founder, you start off, you're building something like me or you, you're responsible for maybe the product and the project management and the design and the wire framing and the prototyping and the functional specifications and all that.

Sean Weisbrot: At what point should you think about hiring a product team? Is there a specific order of people or positions that you would be looking to hire for? Kind of what's, what would a a good strategy be for that?

Matthew Barnett: So I'll walk you through how we've done it. This does come down to your early founding team as well.

Matthew Barnett: So as a product guy. We always had the product position filled in the early days. Now, like being a founder and and running products as you grow is not a good idea because one side of the business is gonna suffer. You're either gonna get not as much time on product or not as much time on like your stakeholder management and everything else that comes in, but this is, this is the life of startup.

Matthew Barnett: Yeah. Like you'll always be struggling to fill things in in the early days. If you don't have a product person, you can, you, you can get get by to start with your CTO. So someone who's probably more technical, who ends up sitting across products and you know, if you are the sales founder, then you're going and doing the sales and the fundraising and everything else, and that's fine.

Matthew Barnett: We built engineering first. We had a CTO, we hired a couple of engineers, then we took on design. But again, we had design skills. Like in myself, we hired someone who had some product management, like chops as well. And generally the earlier team you hire, you're hiring generalists rather than specialists.

Matthew Barnett: So we hired designer. We could also do tickets, managements. So they did more of that. Now as we've grown that person, that hits capacity, and so we then hired a second designer and a product manager at the same time. So what we actually let's do is we expand that out and then all the time we're doing this, we're hiring engineers underneath at a constant cadence.

Matthew Barnett: The state now where we have engineering roles always open and then we can't build up to capacity. So we find a product manager can probably sit across two engineering teams. A designer can probably sit across. It depends a little bit on the size of 'em, but maybe one, one to two, depending on the size. You have one designer across, two along the side, product manager.

Matthew Barnett: If those are bigger teams, you might have two designers, one in each team. Then you start to get a stage where you have UI versus UX designers and you, you start to get away from generalists and get specialists in those if you don't have products. Person on the company. It comes down to your CTO and how good they are naturally at running products. If there's no design in house, I would advocate for bringing design in earlier. You might even wanna do it before you get more engineering capacity to help your CTO. You might wanna bring on two engineers and then do design product management probably starts to come in when your whole product team starts to get to five plus five plus six plus.

Matthew Barnett: Starts to be a good idea to start to think about this. Product management is one of those roles that has a large range of scope and different people will fill different parts of it. So at the front end, it's a very much a research and scoping based role where you are saying, Hey, this is a good idea.

Matthew Barnett: We're thinking about maybe doing this. And that pm If they're towards the front end, they actually might input on vision strategy, and they might like go out there and start researching with loads of people, loads of customers, loads of potential customers, and start to scope out what is it we actually wanna do in the first place.

Matthew Barnett: And then they will help get that into build and then, and then their role might stop there. You also get PMs who are the other end of the spectr which is like, they're like a, you know, a ninja sprint planner and they're running bigger teams and they, and they're really like hands-on on like managing sprints and prioritization of tickets and what gets built first and what doesn't get built.

Matthew Barnett: You can get people who span that whole piece, but again, as, as any generalist, you will then start to find holes in, in how much they can manage. So depending, again, if your CTO is also running sprints. Very methodical on that side, you probably would wanna get a PM who's more on the visionary and strategy.

Matthew Barnett: A research side, if you find your CTO is great at that, but you might wanna get a PM who's more on the, on the process side of things, data measurement afterwards, and you will find hiring PM is incredibly complex because it, it's one of those roles that covers such a wide remit and it will fit different companies in different ways.

Sean Weisbrot: My CTO is. Very technical, but when it comes to features, he doesn't have much input. He is like, tell me how you want it to act, and I'll document it and I'll make sure that the technical team understands. That's why I've been the one doing the ui, ux and all of that. And we, we, we do have a designer that we work with outsource, but it's a flat rate per month.

Sean Weisbrot: So if I know I have a month's worth of work upfront, then I'll hire them for the month. If not, I'm gonna do it myself using the design system that they've created. So I was doing the product management, the project management, so from the conceptualization of the release down to the epics, to the stories, to the sprint management.

Sean Weisbrot: With my product manager so far, I mean she, she's new with us, so fair enough. Like I'm giving her time to get her head around, you know, what we're doing. 'cause it's a massive system. I'm still the one at the moment going, I have an idea. Here's the mockups, here's the functional specs. Turn it into user stories that could be pushed to Jira. So with

Matthew Barnett: her, if her skill is that like the sprint planning, then maybe that's where you really get out of her. If she is someone who is great at data and great at research. You don't always find these, you know, someone has these two skills, so you might wanna make a call here. So you need to work out which side of the spectrum she is and where her specific skills are, and then, and then fill the gaps around that.

Matthew Barnett: The other thing you mentioned with your CTO O is I understand the type, some people just wanna get and build things. I think, and this depends a little bit on what type of CTO they wanna build be as well, and, and CTOs can span a, if they are very managerial, great with the team, that's great. I would still suggest bringing them into the ideation phase.

Matthew Barnett: Where possible. Getting in a room, being virtually or or come in person. So really when you're building out a new feature, I will always have design product management and engineering in a room. Those are the dream team. And so really your pm, your CTO and your head of design should be able to work together and they should actually have disagreements as well.

Matthew Barnett: They're all quite different mindsets. You actually want your CTO to speak up and be like, I see what you guys are doing, but that's not gonna work. And have some input. And there's a bit that goes beyond just like building better products. Here is also. If they are on the process, they're gonna be more committed.

Matthew Barnett: They're part of that, even if they don't necessarily want to like start to win them in. I think that changes over time because their opinion is like, again, if they're a CTO, you obviously value their opinion. If they come in at the very beginning and say, Hey, I hear what you guys are saying, but this is gonna be such a hectic build.

Matthew Barnett: Why don't we just do this instead? And because they have a different mindset. You're like, yeah, I didn't, didn't think of that. That's a much better idea. You know, like, so I think if you can bring 'em into a room together, and this can take training, I think ideation doesn't come naturally to a lot of people, but this process, again, you can put around this, people like that contribute of the early stages better.

Matthew Barnett: And it's a training thing. It's a muscle they need to build. But it can be trained in anyone. And so with us, we don't let any engineer sit by and just blindly build things because even with us looking at things and going through process, like we still have to be aware that we have blinkers in certain areas, like I definitely do.

Matthew Barnett: And so if an engineer gets something and they're like, this is a dumb idea, tell us, because you might spot something that we never thought about. Well, you might have some experience and you've tried to like this before and it didn't work. So speak up and tell us in the vast journey roles you want people to contribute to what it is you're doing, rather than just doing what you say and game building the thing,

Sean Weisbrot: I'm trying to institute this like once a week kind of a product call where the whole exec team is there, you know, we'll, we'll present something, we'll show the mockups and then, you know, everyone will get their turn to give feedback on these, these future sets.

Matthew Barnett: So if you're already showing the mockups, you're already biased the conversation because like, like here's my thing. So my suggestion is like you need to get 'em in earlier. So like, so we do it here. We didn't use to this that. Well, to be fair, we've worked involved people in earlier gets better results.

Matthew Barnett: 'cause again, more time thinking saves us like mistakes down the line. So we'll bringing them in and not necessarily, by the way, this is not necessarily what the CTO Yeah, we'll bring in like other engineers if we think this is better suit to like problem space and where they work. So doing something on integrations.

Matthew Barnett: We'll bring in the guy that that does that. But before we touch a single bit of design or do any wire framing, bring 'em in the room and be like, here's the problem, whiteboard. Like, this is the flow we're thinking. And this is like, I think we have a problem here and a problem here. And then they'll start jumping and be like, we can have an issue here in an issue here.

Matthew Barnett: So the very fact that he's like, that's gonna screw, screw things up, would actually make you build your mockups potentially in a different way in the very first place. So you need to have that early on the process. And if it's not something that, that, that they want to do, you need to somehow work at how to encourage and train it and get it happening.

Matthew Barnett: And it's not about like hours in a meeting room. 'cause I understand that as well. Like, you don't wanna spend all day doing meetings, but you want to have them in earlier and then by the time you come to, to the mockup, if they're like, we discussed this problem. It's, it's, it has a bit like, did you forget that?

Matthew Barnett: Then they're, then they're already in, it's not, it's not fresh then.

Sean Weisbrot: I guess the reason why I wanted to show them all mockups was for them to understand. Some people they can hear what you're talking about and they get it, and other people need to see your idea. And so I felt like if I did the mockup and I told them about what I wanted to do as I showed them.

Sean Weisbrot: Then they could envision what it would feel like if they were actually using it. But I definitely understand your point of trying to get to the the solution before making the mockups work.

Matthew Barnett: So it's actually about problem escaping. So I actually work in like a high fidelity whenever I do design work, people like you never work in a high fidelity.

Matthew Barnett: I'm like, I can work in high fidelity fast than most people can work in wireframes because of what I do. But by the time I get to that stage, we've already scoped the problem in quite a lot of detail. So we already know where those bounds are, which makes me then work, work faster at design level or anyone else on the team, work faster at the design level and we'll hit other problems at that stage when we hit other snags and other problems.

Matthew Barnett: If we then pull my CTO because he already understands what it is we're doing at a fundamental problem level, he'll be able to give us an answer a lot quicker as well. And so there's no catch up time for him. So it actually, again, makes the whole process a lot faster down the line. It's like, what is the actual problem?

Matthew Barnett: And it's a problem with scoping like the real problem as well, because sometimes you go in for a problem and someone goes. This isn't the real problem, this is the problem. And you're like, oh, oh yeah, let's look into that. So again, like more time, rest upfront. And this is again, with, with the caveat that we are a large team and we probably have a little bit more resource to do that because when we first started, we didn't do this.

Matthew Barnett: We just ran as fast as possible. And as a result, we like, we like, we like rebuilt that platform twice, which I wish we hadn't done. I live back in hindsight, I'm like, that was so much wasted time. So again, trying to help people like not hit that.

Sean Weisbrot: I know that I can show my CTO or I can tell my CTO, Hey, I, I wanna do this thing.

Sean Weisbrot: And you'll go, okay, well just give me a paragraph. What do you want it to do? But I think for me, I like, as you're saying, high fidelity. I have figma, I have a ton of screens that are already done by the, the designer and a standard. And so for me, copying and pasting the elements and just changing the dimensions or changing the, that stuff is decently fast.

Sean Weisbrot: And so what I'll do is I'll say, this is the problem that I have. I need global notifications. And then I'll go, what do I need to build in order to make it work? Well, I need an icon somewhere. I need, you know, is this a popup? Is this a dropdown? What kind of notifications do I need? How should I be filtering them?

Sean Weisbrot: So I'll write out a lot of the details, and then as I go to build it, I'll go, oh crap, I forgot this detail that when I was writing, I missed it. And so I think doing them. Not simultaneously, but almost in tandem with each other, helps me to flesh out things that I would've missed if I hadn't done the mockups first, so that when I give a presentation, it's a far more conceptualized idea that is harder for the team to find problems with.

Matthew Barnett: I think proper idea scoping is extremely valuable. We've seen it, I think it's hard to do. We've pulled ideas that we've had and we placed them with better ideas or better problems, and therefore better solutions. And we started to that more as we brought this process in. And as a result, I can tell you, like right now, we, we don't release features now that don't get used.

Matthew Barnett: If we definitely did the beginning, we're like, oh, here's the new feature. Everyone wanted them was like, we wanted it, but we probably we're not gonna use it. It doesn't really happen anymore. It's all about how much time to invest up upfront to get members up online. It's a really hard balance. The only with a good pm, they should teach you this stuff.

Matthew Barnett: They should come in and be like, this is a good process. This is what we've been through, like this is part of their job as well, is to, you know, one thing a PM does is they are the glue that ties the team together. They don't generally sit above anyone, so they actually have management of any team members under them.

Matthew Barnett: They are the most important influencers, so they should influence design and influence tech and influence like pro ownership. This is the kind of person they ask. They're quite a unique individual again, and they should help you build better process here.

Sean Weisbrot: Oh yeah, definitely. I mean, my COO and her are working together with ProdPad to create processes and so what I said was.

Sean Weisbrot: I don't care what the process is that you create, just tell me what it is so I don't violate it. Like I'm pretty good at a lot of things, but I'm not efficient sometimes. Or I may be willing to break a process because I found something is wrong in the middle of a sprint and I, I need to fix it by trying to remove myself from process.

Sean Weisbrot: Management, then I'm less likely to screw up the team in the middle of a sprint or in the middle of planning for a feature or release. And so I'm trying to learn how to empower her. She needs some time to get used to things. She had founded her own startup before, so I know that she's capable at a far higher level than just product management.

Sean Weisbrot: And so I wanna get the best out of her because I, I think that she could be an exec. And so I want her to be able to shine as much as she can.

Matthew Barnett: And this is the job as a founder is, you know, ultimately you should be able to be hit by a bus and the products in the company carries on. You know, I mean, like you wanna get to a stage as quick as possible where the company does not live and die by you.

Matthew Barnett: The same for your CTO and the same for your CMO as well. Yeah. So the C-suite, you're there for a strategy and vision like, and obviously you're great than this, you know, and you are key, key to keep the product and the company. But if something was to go wrong, you empower the team to go and run their process and make their decisions.

Matthew Barnett: They don't live and die by you, which is extremely hard to do anyway. But if you get that stage again, it's great, and then you start to build other teams and then off you go.

Sean Weisbrot: Two months ago I started going, you know what? I'm done with this thing like, you're the CTO. This is your responsibility. You go do it.

Sean Weisbrot: Or Hey, you're the marketing person. He was like, oh, uh, I did some research and I found that our name wasn't very good. Like, you know, okay, well go do some research and give me some names. If you

Matthew Barnett: handhold, people always expect to handhold, so you need to hand that over and ultimately, like as you grow, your team will change, and so if your team are not the people who can run that and you need to handhold, then maybe they're not the right person in that.

Matthew Barnett: In that seniority of role, this is why teams change as you build.

Sean Weisbrot: So what's something I haven't asked you, you wished I would ask? Or what's something that you think people need to know that'll kind of tie this episode into a nice little bow?

Matthew Barnett: If you invest more time truly understanding a problem, then you'll come up with a better solution down the line.

Matthew Barnett: And it seems like a waste of time at the beginning. I know you wanna go faster, but spend some head space and do some research solving problems. Is the hardest thing you can do in the company. It takes the most brand power. So if you come in in the morning and you get straight into emails and you get straight into stakeholder management, you get straight into hiring and everything else, and then come three o'clock, you're like, oh, great, I've got two hours to spend on thinking about this problem. Your brain's smashed and you're not gonna do a good job. I think one of the hardest things as a founder, especially if you're across products, is actually your best brain should be put towards solving these problems. And it's not, it's not always product. It's the same with marketing, same other areas.

Matthew Barnett: But if you are charged of solving those problems, do it when your brain is at its most alive, like do it when you have the capacity to go and get great solutions. If your team is always on you and, and the company's always on you and you're working in the business, go rent somewhere on Airbnb for a week or three days.

Matthew Barnett: Turn off email, turn on you out, and go and work through the problems. At a much high level, maybe it's you and your CTO and your and your design like the go and do this. You need to spend time on the solutions and you spend your best brains because it is incredibly hard. And if you can get this bit right and you get the best solutions there, then assuming you're solving the other problems, then this is how you build.