Hello, good evening. My name is David Gengar. I have a passion for technology, and nothing else matters. The mission of our meetup this evening, why we're coming together, what we're here to do, is to elevate technology standards in our community by bringing great minds together. Thank you for being such an important part of this. A huge thank you to the wonderful people here at Bitbean for providing this venue and enabling us to have such a great event. I'm so happy to see you mixing and mingling. Networking is what this is all about. Each of you represents a company that does tremendous things in this ecosystem. We've got people from B.H., AJ Madison, Aura, my friends at Fabu, at Bitbean, C2P, and a lot of others. Each of you has nailed something in technology that makes you great. Now you don't necessarily have it all figured out, but certainly you've got an edge. Technology is hard, technology is messy. We're all doing great things, but it's not easy. By bringing people together, we can learn, share, and grow our companies. In fact, our tech industry could one day be on the level of Silicon Valley. Our community has done a wonderful job in real estate and Amazon back in the days. Technology is next. There's so much we can do with technology. When we see a great company, the decisions that are made on the path to greatness are hardly seen. We just see results. There are some key people in every company who make it happen. Barry Glick has been doing just that at C2P. Let's give a warm welcome to Barry, the speaker of this evening. My name is... it's going to be a little bit of a... it's going to be a little hard for him to spell it. My name is actually, and my legal name is Barry, so that's where it comes from. It's a conversation opener. So the goal of today's presentation, let's call it, or speech that I'm going to give, it's not really a speech, it's more of a conversation. That was David's vision for this part of the evening. So, everybody to chime in is welcome to chime in. It's not just I'm going to speak and, like I said, we welcome feedback from the crowd. So I would like to start also thanking Bitbean for hosting, opening their hearts and their doors for such a wonderful event for so many talented people to be able to come and congregate. And as well, David had a passion, I think, which will give him a round of applause for getting such a talented crowd together. It took him about two to six months to do it, and he finally got it done. And such a team of really, really professional and busy people is not a small feat to do, to get them together. So my name is Hanani Glick. I have a company called Sail and Anchor, and I'm a fractional CEO. I've been at C2P Group doing operations and business development for the past two years. They have 10 brands under them, so I was doing fractionally for most of their brands. Some of them are startups, some of them are operational. Now I'm sure you guys are thinking, why is an operations guy speaking at a tech conference? So, I can say with confidence that this room over here is filled with talented people that did not go to college. I don't think anybody here has a degree in engineering, right? Any money? Nobody. The PTL doesn't count. So, to be a doctor, or a lawyer, or an accountant, you have to go to college, get a degree. Here, it's a whole bunch of self-taught individuals that have achieved tremendous, tremendous things in the world of technology. So the reason why I am speaking is at the end of the day, technology is very, is a very fine thing, but it's a business and it's got to be profitable. If you can't make money on software, you can't make money on technology, it's never going to work. So that's why we decided to have this conversation regarding from the business perspective. One thing I would say that the leadership community, I think, has over Silicon Valley, and I think that that's going to pan out over time. At the end of the day, in Silicon Valley, their main focus is entertainment value with their products. In the Yiddish community, everything that's out there is all productivity and it's made to make people's lives better or processes better, or improve infrastructures. It's not driven with the addictiveness and the entertainment value. So I think that's why that's one thing that's soon going to be, it's going to be maybe Boulevard of the Americas Valley or something at one point. So, in order to build a to build a software, you have to have a vision. Being a visionary, I would say, is not, that's my opinion, is not going to cut it. Visionaries, a lot of people are visionaries, but you actually, to execute, you have to have a your visionary, the visionary is fine, but you have to have a vision, what am I going to do, where am I going to get to? So being at C2P for the past two years, we have, like, as I've overseen six operational companies and four startups, I have found a new families of, a new understanding of what means vision in software, and what a roadmap, and a roadmap that turns, a vision that turns into a roadmap can actually do to scale a technology company, make it profitable, or venture into other markets of your software. So now, what is a roadmap? All right, everybody sees roadmap, roadmap, roadmap, right? We're on technology, everybody says, what's my roadmap? What does your roadmap look like? Let's distill it down to one thing: a roadmap is a piece of paper with a whole bunch of roads going from one city to the other city. That's the definition of a roadmap. Now, what if somebody wants to go from New York to California, wants to make a road trip, or take a roadmap? He has a vision, he wants to get from New York to California, and on the way he wants to stop in Colorado, he wants to stop in Virginia. That doesn't make maybe sense. So that's how we're going to go to Ohio rather. That's what a roadmap is. Roadmap doesn't mean just one road and I'm just going down this road and there's nothing on the other side. Roadmap is a big landscape. In the world, in the world of technology, services and solution is part of your roadmap, and I'll explain it this way: what is your product going to achieve? What problem are you solving? What solution is your product providing? So let's take roadmap for a second and zoom out to regular business. Every business out there is solving a pain point of a consumer. If you're a lawyer, if you're an accountant, if you're a marketing person, somebody has a pain point. The professional is there to solve his, to solve his problem. Now, if it's going to be a brick-and-mortar store, you're solving the issue that he can come closer, or if it's a big brick-and-mortar store, I can give it for a discount. There's a solution. Somebody has a pain point. He has a solution. If it's a product, he can't make it, right? He can't go and make a can opener. He's just going to go buy the product. So if somebody, somebody has a pain point, he has to open up a can. Somebody provided him a solution, can opener. Software is the same thing. Somebody has a problem, somebody has a pain point, and software is there to solve their problem. One thing what I would say software has an advantage over any other industry would be, it can fix problems very easily, and it's very hard to make. As you all know, software is not an easy thing to build, it's not an easy thing to maintain. So this is why a vision is very important when it comes to software. You're solving somebody's issue, and you, especially you're there to do it in a, make it better for them. It's not that he just has a can opener. Now you're making him, he has a big problem, so often can come in and solve a lot of his issues. So I would like to discuss a bit how the contrast between a vision from a brick-and-mortar or a regular business to a software. So let's take a brick-and-mortar store. A brick-and-mortar store has a vision. What's his vision? His short-term vision is, let's take a grocery for example. The short-term vision is he wants to have a meat department. After two years he wants to have a deli, he'll want to have a bakery and a fish store. After five years, he wants to have a full organic line with, with, uh, vegan products and gluten-free products, for example. And after 10 years he wants to have three stores. That's his vision, that's his roadmap, that's what he wants to get to. He has a very clear vision. When it comes to software, there are three factors that are going to shape your vision. If you're taking a 10-year sample, you have your vision. You have your clients' needs as they're coming in, it's going to change. When you started, now the client needs something else, it can change. The market changes very fast as well. When it comes to software grocery store, brick and mortar took Amazon 20 years to penetrate the market. It didn't happen overnight. ChatGPT came in and just like that. And it's going to accelerate as market changes go, it goes way, way, way faster. So this means that software is a very nuanced roadmap. It's dependent, it's codependent, and it's, and it depends on factors that are really not in your control. So let's take for an example, if somebody has a grocery store and he, after four years, nobody's interested in vegan, organic products. He just cuts it out of his roadmap and just continues going forward. He gets a big cash infusion. He decides, you know what, let's open up three, four stores. And software, who's, who knows if the market is ready for it? There's way more factors and variables when you're deciding what your future is going to look like. So I would like to break it down to three topics that we're going to discuss tonight. Later on we'll have a little bit more of a Q&A about it, but I think there's three main factors when it comes to vision and roadmap. One of them is roadmap agility, the second is less is more, and then the old added question: public roadmaps, client roadmaps, or internal roadmaps only? Conversation that I think everybody has. So now the most important part of having a clear vision, and this is in my opinion, and I've proven fact, I've done it, is to have a mission that encapsulates your vision. The first thing, before, before you build your roadmap, before you build your vision, the first thing is to have a mission. What am I accomplishing? What is, what issue am I solving? What is the market lacking? That's part. What is the mission? What opportunity can I make better? Can I take a legacy product and replace it? To get informed about a mission, the best way how to do it would be, is get your full team on board, meaning from the top to the customer service, that means the CEO, the CTO, your sales director, sales team, sales leader, even customer service. Keep in mind, the lower down the hierarchy, the closer you are to your consumer, right? How many clients does a technology CEO speak to? Hardly ever. The customer service guy or the sales people, they're the ones talking to the clients all the time. So the lower down the hierarchy, the more information you're going to get. And if somebody is a startup, just make, make boxes and think of yourself now, okay, now I'm a salesperson, what do you think the prospective client, client is going to ask me? What do you think the customer service is going to have problems with? Just put yourself in those boxes and get that information and write it down. Now let's crack the thing: crafting a mission, not more than two sentences, and describe what you're doing without saying what you're doing. And I'm going to do an exercise on that. What is Tesla's mission statement? Anybody know? Clean environment. Anybody else? Don't Google it. No. Tesla's a technology. Okay, what's their mission? What's the mission? What's their mission? Okay, make life easier. Okay. Anybody else want to chime in? Their mission is to accelerate the world's transition to sustainable energy. It doesn't say a word about cars, doesn't say what about technology. It's good. Close. Your word. I didn't phrase it. That's what they phrased. It's not corporate. No, I, I, I respectfully disagree. It's not corporate. There's a reason why they're doing it. Think about it. They're transition, they're done. They're not saying anything what they do. They're trans, they're not even talking about moving from one thing to the other. They're saying we're transitioning the world, helping the transition in the world to sustainable energy. That's it. Nothing about cars, nothing about travel, nothing about faster 0-60, none of that stuff. None, computer UX. They don't talk about any of those things. So this is just a good example. It's just a very solid example of a mission without mentioning your solution, your product, your service, nothing. Your mission is what am I going to achieve? What outcome? Yes. Correct. It's a very abstract outcome. You could say that outcome is less emission on the road. That's also now. There's also an outcome, true. But I'm saying when you're trying to build, that's my point. When you're trying to build a mission, so again, some, some, you, you're looking around some mission statements a little more to the thing. I just like using Tesla as an example because it makes you start thinking, wow, everybody says he's ever said car, and he, they don't talk about any of that. They talk about, like you said, the abstract. It's also, it's about user experience. Very interesting. Yeah, it's a good, it's a good point. Apple's about user experience. Nothing but technology. Correct. Now, once you get your mission statement, boil down whatever your mission is to two solutions, max. One or two solutions. That's what you're going to focus on. What is my solution to the mission? How am I going to get there? What's my mission is that? What's my two solutions? Now a key factor to understanding in the technology world what means a solution. I think there's an old added question, and I would like to hear from everybody, who is the client? In technology it's a very complex question and I'll, I'll, you know what, I'll get forward, I'll start with it and let's hear back. So a client can be just a plain client, right? For example, Zoho. Zoho sells a software for people that have companies and they need a CRM, which is very simple. Then there's something called clients and users, for example. Spotify. You have clients that are the artists, and you have users that are also paying you. Who weighs over who? Then you have clients and client users. That's another, that's another category. And if somebody has another category, I would love to hear. For exa, no, but that's not VC is not a, it's not a client. Your own team is your client. That's true. That's true. So I'll tell you another one, let's say Substack, right? Substack is a little different than Spotify because Substack is, they give a platform for creators to write their, um, articles, and people that want to read. So in Spotify, I would say the difference is, it's people want to be entertained. When it comes to Substack, if you think about it, they want to read that guy's article, and they want to read their first provider article, whatever it would be, it's much more specific. So I would call it as those clients and client users versus client and users itself. Again, that's my opinion. Anybody have any other opinion about it? Is and who the client is, who, who is paying it and the end user and the customer. A lot of these times they have to, have to break it apart. Correct. But the license, sometimes you have to write, and then there's a licensed user that is an end user that may be somebody else who is not necessarily your client, who has to be authorized, and you have to protect yourself against what they're going to do. And then you have people fighting over who's going to be responsible for that person. I don't want to be responsible for your guy who's going to come in and use the computer system and upload a virus, and now I'm going to be responsible for what he's going to do. He's some, some person, he's not paying anything. He's just going on to, you know, you know, doing something on, on on your system and doing something bad. So you have to follow all these, all these type of things. Yeah. That's your question. Who's the client? Anyway, I don't know why the client is. There's something in product, there's something called user stories, okay? There's all different types of users. In other words, every single type of user that's using the system is a different user story. Correct. Right? But who is the client? Who's paying? Is whoever gets the vote. I understand. So that's the technically speaking, it's a good, it's a good, it's a really good discussion. Who, in my opinion, who's the client? Client is who's paying, right? No, not always. What? Again, depends. Again, depending. Understand. For the up user first. Who is the user? Whoever is using it. But it's true, but the user, there's a user. If the user is the, is the one that's paying the client, the client user has something that he wants the feature to be, the user does not want it to be. Who are you going to decide on? It very nice. The client's paying, but the end user is not going to use it. Then the client's not back to you after two years and say, why is nobody using this bill? No, no, again, you're going, you let's understand, you're going for a moment, you're going, you're talking it's true what you're saying, but it's a one, that's that's in a one case scenario. For example, let's say QuickBooks, right? QuickBooks, who's the client? He's sending out invoices. Who's the user that's paying the invoice or receiving the invoice? QuickBooks Online, for example, right? Or Adobe, when you're sending out a, uh, attachment to somebody, the user is the one that's receiving it, and the one that's creating it is the client. Now, who are you going to weigh? Who's more important? At the end of the day, if the users don't use it because it's a horrible interface, again, I don't say about the interface. What do you mean? But the user is not using the interface. The user is a receiver of the technology, right? You're right. But who's, who takes come with the priority? It does, has. We're not talking about UX. Sure, you know what, I'll use, I'll, I'll I'll use a different, I'll use a different example, and that, I'll, I'll use another example. Let's try this one. Um, I'll take another example. So, let's say, I work at C2P. They have a product called Madbaya. Okay? Madbaya is a DAF. Fund. Technically speaking, but they are a technology driven DAF. You have a card, you can give money or you can give on, on your portal. You can, you can, you can give like OJC and found the same thing. Yeah, but they're technology driven, they don't have vouchers, everything is tech. Now, the other ones have different fees, right? This, they have to have a, a choice. Or the user pays or the donor pays. They have one thing. The organization always pays 2.9 percent. Okay. Now, who's the client? Is the person using the device, using the card? He's not paying, he's just the user. Or is it the organization that's actually paying 2.9%? They receive the money. Who's the client then? Who's the user? Manual? For. We're not designing anything, we're getting a roadmap. So who is the client and who's the user? Yeah. We're not at the product yet. I'm talking about even before the product. What? It's true. I'm saying we have a product. I got it. I understand. But again, there's all different types. There's people that are deep into their product, that people are just starting up. We're talking about the concept of a roadmap, right? Yeah, but what's, we'll get to it later. What's priority, what's not priority. I mean, it's, it's a good discussion, right? Again, but, I understand that. But again, who is the client? Who's the user? The user, the guy scanning his card? It's true. Again, that is true. But again, who is the user and No problem. Great, great. So that's the thing, it's a discussion to have, who's the user, who's the client? Anyway, so this is a conversation that I guess, I guess it really worked and everybody had their opinions and I'm glad that's what David wanted. So like I said, I'm just giving ideas, what I say is not right. Good question. It's a good question. I got to think about it. All right, so let's move on to the next thing. So now I think there's a, once you do have this figured out, who's the user, who's the client, the next thing I think is priority. I mean, sorry, the next thing that we got we have to break it down, I think, into three different categories as well. Uh, old adage problem, priority. What is priority? Right? The next thing would be, how many, how many clients are affected by what you're going to do or what your roadmap looks like or what your features are going to look like when you do it, when you're doing your vision. And the most important question that sometimes is financial. What is it going to cost me to build? How long is it going to take to build? Is it possible to do? So, I would like to hear from you guys. What makes a decision to make a feature? Is it financial? Is it a priority because let's say sales asked for it or customer service asked for it? Or does it, or is it how many users are going to be affected by it? Anybody have an opinion? So you say it's financial? Okay. The fact that there's a bug is dying. If the whole system's crashing doesn't make a big difference. Again, we're talking about vision. Don't forget, I love it, you guys are tech guys. You're in the product. Let's, we're trying to zoom out. Let's zoom out a second. We're looking, we're talking about vision here for a second. So I think that was, I think that was a little bit of the disconnect there. You guys are all tech guys, okay? How can this work with that? This work with that? No, the mission is there has to be there. Some will take the metric of money. Correctly. Or anything else. Okay, I can discuss that. But again, this is, I think a question I think that everybody grapples with when you're looking at a feature. It comes in from the sales team or it comes from customer service or it comes from the CEO or the CTO. Okay. Came in. So now he says, it's going to cost too much money. This person says, but I need it. And the other guy says, we're affecting so many customers, why should we do it? Or the other way around, we're affecting so many customers, so we have to do it. So again, I'm just here from a vision perspective. These are things I think that you talk about. But you talk about it like you just said in product. Look at, try to associate it with division, with your mission. It'll give you some clarity, that's my point. Now, I want to go through priority, amount of clients used and find, and, and the financial part of it for a second. I want to break it down. So let's talk about priority for a second. What, what can priority look like? Priority can be a lot of different things. Like he said, um, Rabbi, what's his name? It can be bringing in more clients. That can be one thing. It can be more ARR, right? More more recurring revenue. I'm sure there's a couple of SAS model guys here, right? Now, customer retention, right? Market change. Something happened, whatever. If it's the mood, the branding, whatever it is. You want to keep on, you want to get customer attention. You want to reduce churn. Um, strengthen your network effect, right? If that's, if that's your model, um, create more dependency on your product, right? That's also prior, there can also be a priority. Enter into a different enterprise space. That can be another priority. So those, I think, are certain priority things that can be talked about, and it interacts with each other. It's financial. Some of it is mission driven. Some of them is client-based driven. That's from my perspective. I might have any other things that's going to be a priority. The first two hours you're figuring out, you have to see if you really just see you, or somebody's my way or the highway, you're going to have to throw them a bone, right? I'm asking, can I ask you which, which, which industry are you in? Technology. Right, what? Yes. You're not a product owner, right? So so you understand how the conversation is going now. Great. This is what the conversations people have. You're a solutions guy. But let's say I'm the CEO guy, and that's these are the arguments that and right? Correct. Something that the marketing department wants, or maybe there's a part that needs to be fixed. Correct. But again, I'm going to go back, I'm talking about the mission and the vision, and we're talking about road maps. We're talking about from a much higher level. You're coming from the, um, implementation level. I'm talking about to make a decision as a leader from as a CTO leader or whichever department you're in. It's a CEO, investor also. What am I, what is going to be my priority? So anybody that is an actual owner that would like to chime in? What is it? What would be a priority? Is it bringing more clients, overcome more recurring revenue? That's what you would say. Okay. The priorities are going to come from from the bottom up, generally. Then what happens is, you can't decide which one's the priority. The answer to your question is, there's no answer. There, it's true. Therefore, what people have done is they've built what they consider to be mathematical or statistical models where they'll take, here's my, here's my seven priorities. I'm going to weight each one, and they have a committee that gets together to say, it's going to be, it's 10 percent. And then they're going to put it that way. But in terms of where you're trying to get to, which is roadmap, you know, if you're going to get down to that level of granularity for a roadmap, then you're missing the boat because that's that's much, much too low. So the mission has to always be something, an envision mission strategy. The mission has to be what influences everything you do. Correct. When you want to have a roadmap, I've got 10 things, what should I do first? That's when you need that bottom up. Okay, let me figure it out. But not one, not one thing, not one thing is ever going to be, it's true. It's never going to outweigh. But there's everybody has a preference when it comes to a priority. They're very clear. That's true. Good point. Okay, so I had an actual, I wanted to discuss one company in this context. I'll just throw it out there and we'll move on. Adobe, right? Adobe XD and Figma came along. They decided to buy them out, they fell apart. So like what would you, my question would have been, what would you guys do in that situation? Would you go and try to fight Figma, stay in the state market course? Before, yeah, like when Figma came, was coming up, what do we do now? Like, what, what do we do? Again, whatever the case is, I'm talking about before. It's going to be a long conversation. Let's move on to the next thing. So about about user. The next one is how many users or clients is your are you going to affect with your roadmap? So I would like to break it down to two factors. It's a little complicated, it's complex a bit. I think take, take 80% of your clients in general. Don't look at the fringes, even though I know technology people like looking at everything has to be perfect all the way on from the beginning till the end. And everybody knows about Agile and all that stuff. But actually just think about it in just a simple sense, 80/20 rule can be worked out over here as well. 80% of your clients, is it going to affect better MR, MRR? Is it going to affect more dependency? What is my features going to affect features, again, with building vision and roadmap? What are these features going to affect that percent that the criteria of my clients? And also try to get it 80% of your use cases. That's another metric that you use. Right? About inefficiency or making something more efficient in my 80% of my clients. It's a little bit of a complex concept. Um, I actually said it a few times to David till he, until we figured it out. But I'm just going to throw it out there if somebody wants to discuss a little more. It's a little more. Again, just try to stay in your 80% of, of use, use case and 80% of your clients. Now, again, we're talking about vision and not implementation right now. We're not talking about, we're not in the boardroom, we're not in the, in a, uh, in a strategy meeting. We're in a building meeting roadmap. So another good tool is break down all these priorities, take all these by different priorities. Break it down what is going to take me one month to do, two months to do, five months, six months. Break them down into different buckets. How long does it mean for me to get it delivered? Put it down sort of in priority and decide what your priority is. Like this you'll start building your vision or your roadmap. That's basically what my point is. Make sense? Or it's too simple and we have to get down to nitty-gritty about it. Rabbi Shapiro, it makes sense what I'm saying? I hear what you say. Okay, but you disagree. Okay, great. So, um, let me ask which, what's your responsibility now? Yeah, I, I advise companies. Oh, okay. So that's built you see. I'm talking about vision and roadmap. Okay. Right. I got it. No problem. Very good. Thank you. So another thing is financials as we discussed before, is, um, financials can be classified in a few different ways as well. Everybody says financials, what it's going to bring me more sales? Yeah, that's one financial. Less burn is another financial, right? What's the roadmap going to look like regarding to burn? Your burn rate. And sometimes it can be another source of revenue. I'm going to build this feature, I can also borrow it somewhere else to build another to bring another source of everything company or enter a new segment. So financials can also be split up at the different priorities. So, to finally to sum it all up, basically, you, I think I was clear enough. I was trying to distill it down to very basic stuff and not get into the nitty-gritty. Take all these things, discuss it with your teams, from, like I said, from the CEO down to the customer service. Like this you can start getting a grasp, okay, what do I do in two months, what six months? What does my vision look like? Doesn't match up with my vision, my six-month, uh product that I'm going to do, it doesn't match up with my vision. So you want to make a break now? Yeah. Okay, I'm from, do you want to do the second half? We'll just scratch. All right, no problem. All right, so thank you very much guys, and thanks for indulging me. And anybody wants to disagree, I would be happy to discuss. Thank you