Good afternoon. I will start a talk today about using agency collaboration and how to grow the pie. It was about six years ago, two years ago, that Dries Bajtard did a call at DrupalCon in London to focus on Drupal marketing. I still remember the reaction from all developers in the room like, oh my god, what is he talking about? Marketing, listen up, developers. And I came to the conclusion that it is difficult for most agencies who are staffed by developers to think from a marketing perspective instead of a development perspective. So in the Netherlands we came to the conclusion that we had to organize ourselves and do Drupal marketing in a professional way. And I will tell you all about it, how to structure it, how to deal with it, and how you can set up a marketing initiative in order to grow the pie. My name is Michel van Velde. I'm the secretary of the Dutch National Foundation of Drupal Service Providers. I also am a member of the Dutch Drupal for Gov initiative, owner and founder of a digital agency of 40 plus people. Yes, I have a marketing background. I'm a business owner and I do not have a development background. Fortunately, my companion is here in the room. He has a development background, so that's my... So if you start asking questions about development, he's the guy, not me. I'm also the organizer of monthly Drupal cafes and I'll tell you all about it and how to organize those events and why we do it. I'm the co-lead organizer of several Drupal gems, which is the biggest Drupal event in the Netherlands. So you can follow me via Twitter or send me messages via Michel van Velde if you have any questions later on or tomorrow. So you can find me and I'll share you all my knowledge with you. So what are we going to talk about? Why Drupal marketing? Why is it important? And what can you do to make a stand against proprietary service providers? And what can you do to make a stand against professional marketing organizations? What are the basics of Drupal marketing and what can you achieve with it? And how to organize your social media and how to organize events. And I will tell you all about that later on. The second part of the presentation is how to set up a local foundation and why it is necessary to set up a foundation. Rules and regulations that come with it, code of conduct, how to work closely with the competition, because that's what it's all about, build a foundation, share profits and there's room for questions afterwards. So why Drupal marketing? Currently there is a fierce and I mean very fierce competition going on the market. We have Sidecore, we have CQ5, that's Hippo, Tridian, GX, Typeo3, do not underestimate the power of WordPress and lots more. And we're all competing in the same market and it is necessary to create, I would say it, to set up a marketing initiative as agencies together. And why is this? When you look at, for example, Sidecore or Tridian, those are proprietary software companies that have a marketing team. Close tools agencies do not have marketing teams at all in general. So may I ask a question? Which of you are agency owners in the room? Who spends marketing budget on promoting Drupal? That's a few. And if I say that on average, and I mean on average, the large organizations spend 5% of their total revenue on marketing. Who is spending 5% or plus on marketing of Drupal? That's what I guessed and that's where the problem lies. We have to make a stand with Drupal and organize ourselves because we came from a developer background. We started building websites and it became a success. Drupal became a success. But then again now we're competing in a market with, and I can tell them again, Sidecore, CQ5, Hippo in the Netherlands. And they have a well-oiled marketing machine and Drupal has not. Well fortunately, currently you have Acquia who is spending a lot of money on Drupal marketing. But it's necessary for us agencies to do more Drupal marketing as well. And I'll tell you later on how we can do that. And I would like to make a connection with, for example, Coca-Cola. If I say the word Coca-Cola, you probably think of a red can with a brown sugary liquid in it. And when Christmas comes, you'll see advertisements with Santa Claus, you know, riding around. And you probably have a vision of that, this whole Christmas feeling. And there's a lot of people say, hey, it's Christmas coming again because I see this Coca-Cola advertisements again. If I tell you that Santa Claus was invented by Coca-Cola, probably a lot of you don't know that. The funny thing is that Coca-Cola created brand values and created their brand around a sugary water. But if you now see that they linked themselves with the birth of Christ and an event that's celebrated all around the world, you can cross over to Drupal. And what do you think of when you think of Drupal? Well, we think of a blue druplicon. We, as shop owners, we think of CMS and all developers think of code. But what are the brand values of Drupal? How does a potential buyer look at Drupal currently? They probably have a lot of doubts. They probably have no idea what Drupal is, and we have to tell them. We have to tell what are the brand values of Drupal? Why are the benefits? And why should you choose Drupal over all those other platforms? And there is a lot of work to be done. The reason why we should focus on Drupal marketing is, in effect, growing the pie. And I can tell you why this is necessary. In the Netherlands, when I started my agency, I was the first one to adopt Drupal on a professional level. Within three or four months, there were five players. And for the first two or three years, there was no competition. Well, that was great. There was a lot of work. And when there was an RFP and they said, yeah, we have two or three other competitors invited, we knew exactly who they were. That was great. Currently, about seven years later, there are over 100 vendors selling Drupal. And now we have no idea who the competition is. So the competition on our local ground has changed. But the competition towards the proprietary vendors has changed as well. I will tell you more about that later on in the Blue and Red Ocean theory. Community building. If you have really strong brand, and Drupal has all the capabilities of becoming a seriously strong brand, and within the Drupal community, it is already a strong brand, there is a lot of work to be done. And what you see, it can grow the talent pool. Because if everybody starts, if every developer in the world starts to know about Drupal and all the brand values that Drupal already has, we can grow the developer pool. And there's a lot of shop owners here, and we're all looking for talent, so Drupal marketing can help creating a bigger talent pool. So more coders also means more code. So that benefits Drupal as well. So now I'm going to tell you about the Blue and Red Ocean theory. Who knows the Blue and Red Ocean theory? Okay, just a couple of them, that's nice. Okay, so we started off, you know, seven years ago as an agency. I started an agency. And the funny thing was, I was swimming in a blue ocean together with my partner. And it was great, you know, no competition whatsoever. But Drupal became successful. And then what we call, you know, more fishes came into this blue ocean, you know, and seven years later, it became crowded, you know. And when there's a lot of fish in the pool, the sharks come in, you know, and they want a bit of the pie as well. And the sharks start competing each other. And that's where it becomes bloody, and a blue ocean becomes a red ocean. What you can do is you can swim out to one of the corners of that blue ocean and become an expert in a field of work. You can choose, like the commerce guys did, and you're going to purely focus on commerce or some other expertise, field of expertise. But you can also start competing on your own on ground. So if you look at here, you can compete in an existing market, because that's what's happening. You can try to beat the competition. And if you want to beat the competition, well, you can get bloody. You've got to be careful. You can look at existing demand, you know, and can tune in on that. And you have to make a value-cost trade-off. You know, are you focusing on price? Are you going to lower your margins? Are you going to stay on top of the field? How are you going to do that? There's discussions you have to make within a red ocean. You can also steer away, as I said, to another blue ocean. Start something completely new. And that's what's happened as well. We also already see that some competition is moving over to a blue ocean, you know, moving away from Drupal. But what if we grow the pie, you know, make it bigger? Then the competition has a lot still to eat. We don't fight each other. And the only thing is, instead of beating and fighting each other, you know, create a red ocean is working closely together to grow the pie. So that's what we're here for today. My goal here today is ignite an idea. I hope that the idea that we've launched in the Netherlands, this professional Drupal foundation, is being copied to other countries. I've been talking to people from Germany already, and I hope this is copied. I hope you find this interesting and see how we can grow the pie, not only in the Netherlands, but also abroad. And we love pie, especially when it's a Drupal pie. So why Drupal marketing? Demand for independent professionals in terms of present PR and support grows.  Less than 5%. Maybe just a little bit to promote yourself on your local market. So present PR is a great necessity. We've done a survey in the Netherlands, and we found out that compared to the closed source vendors, there was a maximum of 5% of articles written about CMSs were about Drupal. 95% were about closed source vendors. That's not good. And so it's a necessity to focus on promoting the brand via present PR. Drupal as a brand also needs to be supported and protected. We know that closed source vendors are trying to, well, how do you say it, debug or attack the brand of Drupal. It's open source. It's not safe. So when there is an exploit found within Drupal, they send out press releases to large government agencies to tell them, look, here, it's not safe. Don't use it.  It is safe. And trying to debunk that again. So professional organization in terms of present PR is a necessity. Drupal promotion by Drupal agencies itself, not just the present PR from agencies like you, is a necessity because you are the experts. You know anything about Drupal. And I mean anything, everything. Not just what is Drupal on a macro level. No, you know it's down to the code. So we need your help to get it done. We have to create brand loyalty. You know, a lot of people, you know Coca-Cola. Think of Christmas. Think of Santa Claus, the Red Can.  So this brand loyalty we can use, you know, to promote Drupal. We need a strategy. We need to conquer and prosper. That's our goal. So there's a lot of international initiatives already on Drupal.org. There's BANAs and community logos available. There's webinars. There's the Drupal Media Kit. There's a lot of case studies already to be found on the internet. And there's awards. Not a lot of them. There's a few awards. But the funny thing is it all stays within the community. Outside the community nobody has ever heard of that because it's somewhere down a thread within the community on Drupal.org. You know, we know it. The internet world doesn't know it. So we have to shout it out and let the people know it's there. I've got some interesting links for you. You don't have to copy them right now because I'll, you know, give the presentation and deliver it later on. So you can click on it and you can find some really interesting links about Drupal marketing, about all the initiatives that are around. For example, by the Association and even Dries Bauthardt who has been in a challenge with Sitecore. So there's some really interesting stuff to be found. And later on I will send out the presentation and you can click on it and find all the details. We have a great community.  You know, and I found some really, really nice stuff. You know, the Drupal pies, you know, the pictures on it.  But now it's found somewhere in what I call the growth of the internet. So if you start by setting up your marketing plan, your marketing plan to promote Drupal in combination with your agency or together with agency as a whole, you need a marketing plan. Every journey starts with a plan. First, what you need is to make a local market description. You know, how does your market look like? The Dutch market is totally different from the Hungarian market or the German market or the French market. You have to look at historical trends. For example, we all know that Type 3 in Germany is big. Why did they choose for Type 3? And why are they now moving over to Drupal slightly? So if you know that trend, if you know what's happening, then you can focus on it within your marketing and communication. Look at the environmental factors. You know, how many agencies are there? Can we work closely together? If you look at Germany, Germany is a very big country and there's a lot of local Drupal, how do you say it? Meetup groups. How can we combine that? How do you do that? And you also have to look at what are the driving forces. If you look at a porter on the internet, what are the driving forces to get your marketing going? And specifically, set your goals and targets. What is your return on the investment? What is it you want to reach? What goals you want to reach? What are your targets? And make them smart. You have to do a market analysis as well. Which segments are you working in? And what's your position within that segment? Competition analysis. If you want to do it yourself, how does the competition look like? Who's focusing on what? What are their strengths and what are their weaknesses? What are the opportunities?  Everybody who saw the keynote of Dries Beldard, he was talking about personas. It's the first time in the Drupal history that he was talking specifically about personas and that is a marketing term. Who is it you're focusing on? What are their buying reasons? Why would this person, this persona you've defined, why would they choose for Drupal? Or why would they choose for another CMS? Are they choosing open source or are they in doubt? So then you can make a SWOT analysis. What are the strengths, the weaknesses, the opportunities and the threats?  The main goal is, that's why I say caution, eliminate doubt. If you have a persona who has doubt, see if you can eliminate that doubt. Why is he in doubt? Is it security? Is it open source? What's the reason when this guy is in doubt? Make a plan beforehand and take away, eliminate that doubt. So look it out, really important. So if you have your marketing mix together, you can prosper with Drupal. So you've got your marketing strategy, content strategy.  Of course, your product services mix should be in order. Your price mix, you know, we've just been discussing the red and blue ocean theory. If it's a red ocean, look at your price strategy. And of course, if you have your personas in place, you can set up your promotional mix. With promotional mix, I mean, are you going to advertise online? Are you going to create flyers, posters? Where is it? Your persona lives, breath, works, and how can you reach him? That's all written down in your promotional mix. So your marketing mix is a combination of instruments an organization can use setting up a marketing strategy. The use of these instruments, and the interchangeability of that, you know, including targets and markets, are based on target audience and the competition. So make sure you have measurable objectives and goals. Kiss principle.  Really important. Don't make it too difficult for you. Do not write books this big. Keep it simple. Evaluate and steer towards success. You will make mistakes along the way. You will choose a channel that does not help you reach your goal. Learn along the way. Really important. And another important thing is that everyone at your company is demarketing.  Because your colleagues are in a pub, in a bar, and people ask them, okay, what are you doing? Where are you working? And I saw this Twitter about Drupal. What's Drupal? And if they cannot tell the story correctly, you've got a problem. They're on your staff as well. They should be telling the same story. I was telling about the channels you can choose. Print versus online. Everybody knows that online has a, well, higher return on investment than print, but you have to look for conversion. Is it branding or is it conversion you want? Is it your agency's name to be known? Or do you really want to convert them into buying? Print and out of home conversion. Look careful. If you have a flyer or a poster, why not put a QR code on it that directly links to your mobile website that's already converting them towards the online world? And then they can contact you or leave a message. Look at new technology versus proven technology. Nobody knows that proven technology has a higher return on investment than new technology. But the funny thing is new technology, and I mean absolutely new, can create a lot of free publicity. And then you have your return on investment. Focus on AdWords and CO, search engine optimization, it works. Social media. What kind of channels you can use? So absolutely Twitter, Twitter still works. It's very good for branding, for conversion, for letting the people know what you're up to and what kind of services you're selling and what the benefits of Drupal are. Facebook, if you like it or not, it works. So I got Pinterest, LinkedIn, blogs. Which agency already has a YouTube channel? There's a few of them. Think of a YouTube channel. Make a small video about your agency. Make a small video about Drupal, you know. And that goes viral if you do it correctly. You can link via Twitter or Facebook to that video. And then there's events. Events work really well as well. In the Netherlands we have CMS events, I don't know if they run them in your country as well. If they don't you can set them up. We have ICT and governmental events. In the Netherlands we have the Drupal Gem, there's Drupal camps all over the world. We have tech talks, Drupal cafes, we have code sprints. Organizing an event is a brilliant way to share knowledge. And it gives publicity as well because all the people who attend will probably Twitter about it.  So think of organizing an event yourself. This is one I came, this is growing the pie. It's all about growing the pie. And this Drupal camp was in Guatemala. And their idea was also growing the pie. And they're being organized all around the world. And I think that's absolutely fantastic. That's great. So how do you organize an event? Well that's fairly simple. And I mean absolutely simple. Who of you is on Meetup already? Well that's good. That's good. On Meetup.com for about I think about 75 euros for half a year. You can organize as many events as you want. And the funny thing is that people who are on Meetup are being notified that there's a new Meetup around in your neighborhood. And that's the viral effect of Meetup. But if you set up an event on Meetup, and we've been doing that already for a while and that works, promote that same event within LinkedIn groups on Facebook. You can organize a Facebook event and link again towards Meetup so they can register there. So you can create your own community within Meetup. About it, promotion via blogs, a necessity. People like to know where the events are and they like to write about it.  Post it of course via Twitter and most definitely offer free drinks, just free beer and a bite and they will come. And the good thing is that talking about present PR, most magazines or websites are in a desperate need of content. So all you have to do is just send out an email or create a list yourself of all the most important blogs and websites you want to have your event promoted on. Send them an email like, hey guys, I've got this really cool event coming up which you like to post and write about it. And send the complete description, the complete text with your email. So most copywriters are absolutely lazy buggers and all they do is just copy it, copy and paste it so you're in charge of what they are going to write about it. So send it out, your own present PR and go from there and work from there. So start small and it can become big. Small events and become big and spread the world about Drupal. And I just checked it out and there were 91,043 meetups only already this week around the globe that is massive. So I urge you, try it, set up a local Drupal event and go from there. What about free versus paid publicity? That's always a challenge. So you have your present PR and then you send out your press release and then this guy calls up, probably an account manager of this magazine that says, yeah, I can write about it but I'll charge you 2,500 euros and then you get a free ad within the magazine as well. Choose yourself if you want to do that, look at your target audience, if they are there and ask this account manager what the return on investment will be of this 2,500 for this article being able to be published in the magazine. So that's a decision I cannot make for you but make a careful decision. There's lots of places where you can get your article published for free. So viral marketing, it's very difficult to create a viral and to be sent out all around the world, VDL works but it's not cheap. If you want to create a good viral, it's expensive. So think about that and if you're being approached by your present PR, let's make a viral, think twice. Use Planet Drupal, Planet Drupal has a big audience but it's also within the Drupal community, not outside the Drupal community. So take care of that. And we were talking about showcases earlier, post your showcase on Drupalshowcases.com. So now part two, organize to grow the pie. How do you organize it? So what are the benefits of a local foundation? All about that later on. What are the rules and regulations, code of conduct, how to create a movement. And how to work closely together with competitors. Build a foundation, share the profits, I'll tell you all about that later on and then there's room for questions. Okay, so the benefits of a local foundation. We started off in the Netherlands setting up a foundation because we wanted to have a independent single point of contact for all. That is basically the single point of contact for all Drupal brand related questions. What you don't want if you share forces with your competition is that one of your competitors is the voice and face of Drupal within the Netherlands. It's like, hey, and you get a lot of questions about, hey, this guy is in front of the camera the whole time, so he's getting a lot of work out of it. Why should I pay a lot of money to this foundation and this one guy, this one competitor stands up and is the face of the foundation and does that work? No. When there's money involved, you will get a lot of questions, believe me. So we came up with the idea to create a independent single point of contact. So we set up a foundation, we got our money in and we're now looking for an independent press NPR person. So if there's a question about Drupal, if the Drupal brand is under attack by the closed source vendors, how can we cope with that?  So this independent professional can also arrange monthly, you give him a target, monthly press releases, so Drupal gets known, you know, and so we can start a competition with the closed source vendors who has a really, really strong marketing machine behind them. So the single point of contact for all present PR related issues is a necessity. But this all requires a professional organization. You know, you have to set up rules, you have to set up a foundation and work really closely together and organize it. So this is not just a few guys sitting around pizza boxes telling, okay, let's start and do something, you know, now organize it professionally. And that means professionalize your finance, professionalize your events, et cetera, et cetera. This is an example of how we did it in the Netherlands. The SDBN, this is the local foundation of Dutch agencies. What's on it? Well, we tell about who we are, what we do, and we all do this independently from the agencies. You know, we do not mention, the board is not mentioning who they are working for. So there's news on it, news about Drupal. There's a list of agencies. If somebody is really interested in Drupal, we hopefully, they come to our website, they learn more about Drupal, and they found a list of agencies who are involved within our foundation. There's events on it and a single point of contact that will lead to our independent, present PR person, you know, and that works as a charm. There are, however, rules and regulations, and those are really important to keep your foundation alive, you know, to make no mistake, there will be discussions, and we've had a lot of discussions, but there's rules and regulations you have to focus on. So the independent, present PR person is required. The board must act on a personal basis, no agency branding whatsoever. It's not based on a commercial basis. We all should know that we do this to grow the pie. Somewhere along the line, down the road, we all benefit. So company branding by board committee is not, is prohibited. So if there's an event and we are there, we tell them we are board members of the foundation, the local foundation, is not allowed to bring your business cards. And I believe me it is tempting because we were at a CMS Congress and I think there are about 25 brilliant, brilliant leads. But we've committed ourselves to grow the pie and we say, okay, if you're interested in Drupal, look on the SDBN website and you can find all agencies there. And people ask you, but which agency are you from? Says, no, we are working for the foundation. And I can tell you it is tempting, but if I would have said at the time or my colleague would have said which agency we're working from, they're undermining the role of the foundation. So we pledged, we made a note not to do so. So lead generation only via the website. We're all partnerships and agencies, participating agencies are to be found. One rule in regulation as well is we have to choose verticals. Are we focusing on the government? Are we focusing on automotive? Are we focusing on media? And we had to look in the Netherlands at all shops and we knew that most of the shops were not working for the government. So we choose not to focus on that vertical, that cooperation, this necessity. So choosing verticals on the basis of the target audience or the majority of the participating agencies is one rule as well. And as I said again, focus on growing the pie and the community. We need a bigger community. Community leads to more professionals working on Drupal and it all leads to more code. And then again, I cannot say this too much, we all benefit. So there's a code of conduct, grow the pie, not your own pie. And we all benefit, not I benefit. Share, share, and share, share knowledge. Share all the knowledge you have within your community. And then we can all taste that pie, because it's a lovely pie. And in the future we can make that pie bigger. And this is a brilliant picture, it's not that sharp, but I found it on the internet about the group of Indians all working closely together and enjoy that pie, we should do so. Funny thing is is that we were presenting the foundation in the Netherlands and I was asked by Acquia to tell about our initiative. And the funny thing is I do not have any sound available here so I can try it, there's a button here. See if it works, I can show you a little video and made by Acquia. And the great thing is is that we were, by this, you know, the whole story about our own foundation went viral via Acquia, thank you Acquia. It's not working, sorry. Let me see if I can press the play button. So, Michel van Verde, you helped co-found the Dutch National Association of Drupal Service Providers, can you tell us what your association does? Well, Stichting Drupal Bedrijven Eland, as we call it in Dutch, is founded to promote Drupal in the Netherlands and help Drupal agencies with the promotion of Drupal as a whole, but also protecting the brand of Drupal and making sure that the complete pie becomes bigger so everybody benefits. Where did the idea to found your professional association come from? Why did you create it? Well, what we notice is that closed source companies are relying on the marketing which is provided by those closed source parties as well. There's no such a thing within the open source community because everybody is working with open source software which doesn't belong to anyone. So we decided to work closely, work together as agencies and combine forces, tip in money together and set up professional marketing and communication services around Drupal. What are your association's goals? What are your plans for the future? Well, the main goal is to grow the market share of Drupal as a whole. And we're going to do this by organising events closely together with our partners like Acquia and we're closely together on present PR, organising events, knowledge sessions, business sessions, etc. That's the goal of the Stichting Drupal company in the Netherlands. And that's how Acquia helped us promoting our own foundation. And that's really working closely together. So again, thank you Acquia. So, we founded our foundation to protect the brand of Drupal. And I'm asking you agencies from around the globe to do the same. I'm asking you to pick up the challenge we have against all the proprietary software because we are, some of you may already know that, we are swimming in a red ocean and competition is fierce. So pick up the glove and start the challenge. Work closely together with your competition. I've told about all the rules and regulations you need and then it becomes fun.  Participate, create business events, organise those events, organise your marketing, present PR activities and more. So I urge you to do so. It was two years ago that Dries Beithard asked us to do so. We picked up the challenge and we've done so far. There's a lot of hurdles to be taken.  There's a difference between that. You know, you have a core team that basically sets out the course as we do. You know, or do you have an association where everybody pitches in their ideas and you have to come to the conclusion, okay, which choices do we have to make? We created a foundation because we believe that a strong team, you know, can lead the way with input from all parties. And it's working so far. So our goal is to increase the market share of Drupal in the Netherlands. I'm asking you to set up an organisation like this and I'm willing to help you. So if you have any questions in doing it yourself, just let me know. I can give you all the details and let's organise ourselves and create the biggest Drupal pie in the world. Thank you very much. Any questions? If you can use the microphone because all questions are being recorded. Thank you. That was a great presentation, thank you very much. I'm based in Ireland, there's only two to three dedicated Drupal companies in Ireland. So it's a bit of a blue-motion situation for us at the moment. That's good. Some bigger agencies are using it but they don't have the expertise that is required sometimes. My question though is, your talk was kind of split two ways, one the business development, one the foundation side, which is great. But when you talk about running your own events, are you ever apprehensive about running a Drupal event yourself without involving your local Drupal community? Yeah, what we do is we organise, well as an agency, we organise local events at our office. We open our doors and all our competition is there. So that's really cool because the funny thing is that when all the competition is there, brilliant ideas are sprung up near the bar when there's beer involved, you get great ideas. If you want to basically do a closed session and invite potential buyers, yeah you should not open your doors. But I urge you to work closely together with your other agencies and pitch in money because when you look at, we have over 20 shops now, they pitched in, it's a small amount, 500 euros, that gives us 10,000 euros to play with, or not really to play with to create actual, to set up events. And events are not really expensive, the event we went to, we had a booth for 2,500 euros and 500 euros to create all material and that's it. But we reached a lot of potential buyers who were, some of them didn't even know Drupal. They said, yeah, what is it? I said, well, it's a great CMS, it's a CMS Congress, but what's Drupal? So there's a lot of work to be done and then if you are just a sole vendor, you're standing there, you're not as strong as, hey, here we are and we represent, or in your case, you're in the Blue Ocean, three vendors, but in the future that will be 20, that will be 100. So that's work to be done. Thank you. Just two questions. Do you have a list by any chance of which countries do have such things? I mean, I'm from Belgium, I don't know what the situation is there. Well, I just found out, because I did some research, I know Germany has a, well, it is a foundation, I think, or an association, I really have to dig into it. But I already found out, talking to some people, that they're not really organized because it's set up by two developers. You know, he came up with an idea and they have no marketing background. So please find somebody who has a marketing background that can help you. I have no idea if Belgium has it, but. Okay, yeah, my second question. How do you actually organize it where maybe you've got one agency with like 50 people and another agency with like five people in terms of making sure that the contributions and the benefits are? Yeah, well, we had a large discussion about that. It was really interesting because in the beginning, everybody said like, okay, we asked the bigger agencies to chip in more.  And I said, well, bollocks to that, that's not working. Because the bigger agencies, yes, they have more money. And then, again, they get a bigger logo on the website. And if there's a large potential buyer pass by, who is he going to choose? Is he going to pick the number one in the market or the number 10?  So we have an equal sized banner on the website. That's it. So no me being bigger or whatever. No, none of that. You should be equal. So there's an equal chance that somebody picks you as an agency. Okay, thank you. Yes. Thank you. It was a great talk. I'm new to Drupal, so I may ask some questions which you will find some too easy. But what I found out dealing with some big customers, that they have no, sometimes a very high level, no idea about Drupal. But what they did know that they wish to have a solution tackles their needs. And what I can see on your presentation, it's focused on Drupal itself. But one good way to promote Drupal by itself is to compete directly with commercial software by developing what I can see on the market. Some are doing some distribution. So why not integrating your plan? Not only the marketing branding and, you know, all the efforts which you were describing, but also a share effort to spend some time or money as agency on some countries doing one distribution on specific needs. I think that would bring up some new, I would say, blue oceans for Drupal as well. Yeah, there are definitely possibilities. We are focusing on marketing and not basically the technical solutions behind it, but the funny thing is they are sprung up, you know, when we create our events, you know, when we have that beer in the bar and they're like, hey, you know, we find, we know what the, but we find out what the possibilities are within the market.  So yes, we're not from an organizational point of view that we start creating solutions for specific markets. We don't do that. We just offer a one solution that's Drupal and all agencies are, you know, themselves are working closely together to create a technical solution. Thank you. Hello. It's not really a question, more a response to the gentleman over here. There is an organization in Belgium. It's called Drupal User Group Belgium. And we organize like the Drupal camps in Leuven a few weeks ago. And one of our goals is promoting the Drupal brand in Belgium. And everybody is more than welcome to join. I think the only big difference here today is we do not allow businesses as such to become members, but more Drupal users, Drupal developers, coders, marketing, everything managers, everyone is allowed to not have the problem you said before of having brands or really the competition of the companies between each other, but really to promote Drupal as such as the Drupal brand and not one company versus the other. But every individual working with Drupal is welcome. And we want to promote some great ideas here. We want to promote Drupal in Belgium more and more. Do you also organize from the Drupal user group your press and PR releases? Do you organize that as well? Not yet. It's still a pretty young organization. It was basically founded to to organize Drupal camp. Gent last year and the board is open for new elections to help people join in and the more the merrier and more things we can do. It's in the plans, but to do more, more stuff like this. But we're not big enough yet. We don't have only a few members at this moment. Yeah. The reason why we set up a foundation is that we wanted to organize our press and PR professionally and that requires money.  And we've overcome that hurdle, you know, because we knew we're in a red ocean. We knew that we're going to have to work together. And now we've chipped in money. We've identified 105 agencies in the Netherlands. So there's a lot more money available there for professional marketing. So it's certainly something we'll have to discuss and think about. All right, thank you very much. If you need any information on that, just you can contact me. OK, thank you very much. Any other questions? Hi, I'm Micah. I'm from the German Association. We've been trying for a while now to get contact people, to get addresses for a common mailing list to bundle national concerns. Thank you very much for pointing out the very important points. Yeah, I would like to ask everybody in the room who doesn't have a national association, foundation, whatever, but has a user group or is always the person who is contacted for central questions. Could you please leave your contact data with me or Michael with Morton DK who's collecting right now addresses for the for the day. And let's just try to together that on the list where everybody says it's OK to publish my email address and just try to to get some close network for what we are all working on. Yes, OK, great. Thanks. Any other questions? Hi, I'm Ken. I'm from Korea. We when you have a meet up, we have like five, you know, less than 10 people and like it's very small, small community. And but, you know, we Drupal shop in Korea, I guess with 10 people and we are the only one so far. Well, that sounds like a blue ocean to me. But, you know, people don't know about Drupal.  Yeah. And as a like just one Drupal shop in Korea, we try to promote Drupal very hard. But the size of the company is not too small. And we try to grow the community. Right. And like we sponsor the community. Like we buy beer and host a meeting.  And however, I would like to, you know, co-promote, right? As you said, our foundation. But in the initial stage, we don't have enough people, you know, companies to do that. So how like I'll be concerned. How can we like start the movement? Yeah, that's the movement. Yeah.  Well, the right approach to my, well, first, I would like to tell everybody that this is really great video on YouTube on how to create a movement, you know, with a dancing guy. I won't give you a spoiler, but just look it up on YouTube. You're the one that will have to start the movement within Korea. And what you can do is, first of all, send out press releases. Those are really an easy way of to help the brand of Drupal grow and to be well known by a larger audience, a larger public. You can write blog posts in which you can compare Drupal versus proprietary systems. Those are picked up really well. You can promote your, if you created your own event, promote it via blogs, et cetera. So start small.  And before you know it, you have 150 people start dancing.  I would say start small, start with present PR releases, start with writing blog posts on well-visited blogs, you know, renowned blogs, try to move yourself in there and approach those blogs and say, hey, I want to write about this awesome CMS. You know, can I do some? So that's where it starts. Okay, thank you very much. Yeah, yeah, yeah, I'll send it out later on today. Thanks for your presentation, Michelle. It was nice. Tom Erickson, I'm from Marquia. To your question, Ken, and to others, we do a lot of creative commons materials and will help you with marketing materials and things if you want for your regions or your companies, actually, around helping Drupal win against other competitors. So contact our marketing department if you don't know where to go there. You can just send me an email, Tom, at aqria.com, and we'll get someone in touch with you, so thanks. Thanks, cheers. Any other questions? I'll be around until Friday afternoon, then I'll be flying back to the Netherlands. So if a question pops up, yes, you can contact me, and otherwise you can visit the, yes, it's a local website, so it's all in Dutch. But you can find my contact details on the website of sdbn.nl. Thank you very much.


Hey guys, right now I'm going to be going over Functions Lab 2, Question 3. So for this question we are asked to write a program that draws a colorful grid. And every time a key is pressed, the colors of the cells should change. So the output should look something like this. And every time we press a key, the colors change. So we'll start out with this one by putting in our setup and our draw. And we'll just set the background in here to white. Although it doesn't matter too much because we're going to cover it up anyways. We'll make a nice big screen. And then we'll put our draw function in. We need our draw function to actually animate the code, but we're not actually going to put anything in the draw function because we know that nothing's going to happen repeatedly. Something's only going to happen when we press our key. So we need a key pressed function. So for this, we are given the hints to write a function to draw a colorful cell and then also to write a separate function that draws the grid. So we will start out by drawing our grid and we know nothing's going to be returned to us. So it's going to be void. We'll call it draw grid. And for this one, it won't take any inputs yet. So now we'll come into here and we'll just go through and do a for loop. So we're going to have a nested for loop for this one. The outer for loop I'm going to use to keep track of each row that we're working with. And then I'm going to use the inner for loop to keep track of the columns. So we'll start with our outer loop and we'll say for into i is equal to zero. So we want to start it at zero. We'll go until i is less than the height. And then we'll say i plus equals whatever the length of our cell is. So for this, I could just put in like 50. But then we don't really know what 50 is doing. So for this, I'm actually going to create a local instance. And it's going to be an integer. I'm going to call it cell height. I'm going to equal it to 50. So now I can clearly see, okay, this value of 50 is the cell height. And then I can come in here and write my inner for loops. I'll say for int j is equal to zero. And I'll say j less than the width. So now we're going through and we're focusing on each cell in the row. And then I'm going to increase j by the cell width. And I will come into here and create a new instance or new variable called cell width. And I'm going to equal it to 50 as well. So now I can come in here and I can actually draw my specific cell. So remember our hints suggested that we create a different function to draw the cell. You could just put your code to draw the cell in here. But that might get a little bit confusing and a little bit jumbled. So we'll create a different function to draw the cell. And we know that each cell that we draw is going to need variables for the x and the y position of that rectangle or of that cell. So I need to give it the j position for the x and the i position for the y. So now I'll come down here and I'll actually write out this function for draw cell. So I know it's not going to return anything to me. We called it draw cell and it's going to take two inputs. But I'm going to call them different things than j and i. I'm going to call them our row, our and our column. So draw cell is going to take the i value and the j value for its x and its y positions. And then we're going to come in here and we're going to insert that j and that i into these local instances of row and column. So for this, we have to randomly set a color. So I'm going to use this variable color. I'll just call it C and it's going to be three random values between 0 and 255. And then we'll just copy and paste this to speed it up a bit. So now we've got another local instance of this variable C. Now we will come in here. We'll set the stroke equal to white. We're going to fill it with our random color and then we're going to draw our cell. So a rectangle and the position is going to be where our j and our i was. And now we've come into here and insert them into these local variables. So it's going to be row at row and column. And then for this one, we came up to here and we set our cell height and our cell width, but now we actually need to access these two variables into here. So now I need to change these variables to be local instances because it needs to be accessed by more than one function. So we're going to create these to be local instances. So now draw grid can use the cell height and the cell width and draw cell can use the cell height and the cell width. So now we can come into here and we haven't actually called. We've used draw grid to call draw cell. So for every y position for every x position we need it to be at, it'll draw the cell. But now we need to actually draw the grid. So we'll come up here and just set up. So when we first set up the program, we need it to draw grid and then also whenever our key pressed, we need to redraw that grid and that's going to set off the whole process of redrawing all those cells of coming into here and then resetting those random values. So now we can check this and it all works. So again, just to summarize what we've done. We have come up here and we've created these local variables of cell height and cell width. So now I can change these to be like 100 and 200 and it comes in and it goes off the screen a bit. But it's there where I could do like 25 and 50 and it still works. So now I can really easily come into here and change my cell height, change my cell width and I know what it's going to be doing. So I've created these local instances because it's going to be used in multiple different functions. So every one of those functions needs to be able to see what those values are. We've come into here, we've used a function that we've written to draw the grid. That's going to go through a nested for loop to keep track of the y position here and the x position here. And then once it's got that i and that j, it's going to call another function that we wrote called draw cell. It's going to insert the j and the i values and we'll come down here into draw cell. And then we create local instances of the row and the column that we can use here in our rectangle. And then we've also created a local instance of the color C to set the random colored fill. And then every time we press our key, it's going to redraw the grid and it'll come through here and it'll set off the whole process for picking new random colors again. So you can have a bit of fun with it, you know, maybe try adding some different things to it or changing the shape around. But the more you work with it, the more you'll get used to it and the more it'll make sense.


Thank you for fixing the power you are so brave to fix the power and your cool bucket truck Yeah, she got a tricked out bucket truck here got some some 20s on it It all fixed up. I Wish I did have my truck looking like this Be the talk of the town last year. We lost power during a hurricane. Thank you for working hard to fix electricity You got a nice drawing With me in the bucket probably on the storm Thank you for keeping our electricity on I like to use it for the lights in my room and to play games on the computer Sincerely Taylor Got a picture of a lineman in a bucket going down the line and Cutting the lights on four. Thank you so much. Your company is the best.  Thank you for your hard work Well, we got light bulbs. We always want to see the light bulbs on and it looks like we got a Bucket truck right here dear lineman. Thank you for making my house warm when our power went out It was so cold that I had four blankets I could even see my breathing daddy had to cook eggs on the grill my dog was cold, too I saw you in the big sky truck and you look so cold. Thank you for helping us Love Brooke. I can imagine how cold it was in the house kind of like probably like a camping trip I'm just make do They're in the house camping out with a little cold weather kids really do appreciate us when we come into neighborhood They want well. They want to hear the horn first Then they want to see us in the buckets and with the hard hats on and on so they They really appreciate what we do Sometimes I think more than the adults do


This paper presents a novel approach to stock price prediction using deep learning techniques. The proposed method combines traditional financial indices with social media text features to create a more accurate prediction model. The result shows that the proposed method outperforms other benchmark models in terms of accuracy and thus provides a promising solution for stock price prediction. This article was authored by Xian Ji, Ji Chen Wang, and Ji Jun Yan.


What's up everybody? Jayce here for JasperJasperCaseBricks.com. This is how I love the mixer. We're giving away the last six bots in the NBA mixer with this 1819 Panini status one fat pack break number three random teams and again guys the way this works is first We randomize customer names and teams distribute the hits out of the fat pack to remember no veteran common shit But everything else will And at the end of the break we're randomized all 30 customer names again are a separate Dicellar randomizer And the top six one through six will win a spot each in the $200 NBA mixer Which will be coming up after this in a separate video So let's do the break first Let's roll the dice and we got ourselves a four to two six times. Good luck One Sean down to Jeremy. All right six times one two four five Hawks down to the Wizards All right, so stick with you guys member big teams in your Dallas Jeremy has them Atlanta Hawks Sean has them up here and then of course other good teams in the 1892 class, but it's quick little fat pack break So let's take what you got Kevin Durant Colin Sexton rookie. We got Yanatana de Compo, Wonder Quarter Junior, Kevin Knox and Mitsu There you go. Now, let's switch seats. Here's a dice roll. Remember top six get in. Let's roll it And it's a full 12 the way it's meant to be Full 12 guys for the last six spots All right, guys, so good luck full 12 top six get in One two three four five six seven eight nine ten 11 and 12 All right 12 top six Victor Mitchell Jeremy So men Jeremy and Jeremy Wow What a randomizer for you after 12 times There you go Top six get in congratulations coming up next is the mixer itself


So I've been in product for a year and a half now. Now, I'm certainly no expert, and that's why I've called this talk 30 product management things I've learned. These aren't lessons, learnings are not lessons. Very important to note that about this talk, being in PM for a year and a half at HubSpot. I've gone through two different product teams. I've gotten a promotion in there. So I've seen like a little bit of the product side of the world, but certainly not all of it. There's so much to learn, and I'm sure next year this will look like 300 product management things I've learned. So these are all learnings that I've gotten in the last 18 months or so in product at HubSpot. I did cross out in 30 minutes, because I was told I had a little bit more time. So I'm not going to hold myself to that. I could if I wanted to, but we're going to be a little more loose than that. So this format will be pretty rapid fire. I basically want to go through line by line, 30 things I've learned as a product manager. Learnings are not lessons. Final reminder. Let's get into it. Product development. This is the first theme that I want to talk about here in the talk. The first thing I've learned in product management is that product management is not a science. It's far from mathematic. It's far from calculated. Everything you do is constantly changing. It's not very scientific in general. That's really the first thing I ever learned about product management. As your day-to-day is super ambiguous, what you're going to do, who you're going to talk to, who you're going to meet with, it's always changing. At the same time, product development is a lot like science. So I'm sure you all, I welcome everyone new to the room also. Product development is a lot like science. So I know that back in second grade, third grade, you learn the scientific method, right?  So while it may not be science, it's a lot like science. Let's keep that in mind. The third thing I learned about product development is that bringing something to market, taking a product and giving it to your very first customer is actually the beginning of a product's life cycle. It's not the end of it. So although there are months, sometimes years that lead up to actually delivering a product to the market, giving that to a customer, getting your first piece of feedback. From what I've experienced, that's where things just are actually getting started. Now, you'll be talking to customers before then, you'll be working on product development things well before you actually reach a customer. But the product itself, it's life doesn't actually start until customers grab hold of it. The next thing, small features for very specific audiences yield really big wins. So one of the earliest things I've learned is like you can't boil the ocean, right? We've all heard that term. The more you try to solve for and the more broad you get with your product development or your product strategy, the more likely it's likely going to flop. You likely have a pretty diverse audience, people, different people who use your product in different ways. Solving for a very specific use case and a very specific feature is usually some of the easiest ways to get the biggest wins. One of those examples that we use at HubSpot I worked on the import tool in our CRM. Now, every object in a CRM has a unique ID. We never let people import using that unique ID as a way to write to existing records. It was just something that we hadn't written in. The explosion, the customer excitement around this very specific, it was legitimately a checkbox when we had spent months on this entire flow. This tiny checkbox had yielded these fantastic customer results, hundreds and hundreds of people using it because it was designed for a very specific use case. It was designed for people who are pulling data out of HubSpot and putting it directly back in, a very specific use case and a very specific audience, and those are some of our biggest wins. The reason why those wins are really big is because they didn't take a lot of time. Big wins aren't as big if they take the team months to work on and it takes a ton of energy. Sometimes the biggest wins take almost no time. The next thing, paying down tech debt is greater than most things. I said most things because not everything, but tech debt is very, very problematic for basically your team first, first and foremost, your team, and then beyond that, everything that you all want to do in the future. So if an engineer is dealing with tech debt, it's always a pain in the side. It's something that's constantly kind of like holding them down, constantly something to think about, but once you can kind of pay that down, it frees up not only the product space to work on new things, but also the mental capacity. If you think about what it's like working on split screens, you're watching a video over here and you're actually doing your work on the main screen, it's really distracting when you've got things like tech debt that are holding you down. So if you can pay down tech debt and you can do that early with your team, so it's usually a pretty good win and that's something I've learned pretty early on. So we try to do that as much as possible. It's to pay down some of that tech debt each and every week before we go out and build new features. So next one's pretty long. And I have a very specific experience around it. It's that things break, they're going to break in software and hardware, no matter where you're developing products, don't panic. You need to give your team the space and autonomy that they need to solve a problem and provide air cover if possible. I think the most important product management learning I found here from the product point of view is to provide air cover. Your engineering team, your product design team, anybody who's solving a problem is going to be focused on that problem and that problem specifically. When things are broken, I found that the best role a product manager could take is just to provide air cover. Run appropriate communications with your customers, make sure that only real problems are getting delivered to engineering and then you're not kind of poisoning the well with consistently adding new things to the fire, kind of asking questions about the status of the updates and things like that, keeping it super clean, letting the teams, giving the teams the autonomy to solve the existing problems will help those problems get solved faster and more effectively. This next one's really similar about the small features but it's more from a macro perspective. It's that if you try to solve for 100% of your customers, you'll end up solving for zero. I tweeted this out one time and I got a very specific request from one of my colleagues and she said, this is funny to me, why wouldn't you wanna solve for all of your customers? Well, I think in very specific use cases you'd wanna solve for your customers or all of them rather. But one of the things I've learned is that you can really get caught in the weeds answering every question for every specific from every single customer. So if you have even two slightly different variables of what a customer believes the solution will be, it could add months, weeks, even years to actually shipping a product and getting it out. If you can meaningfully impact 50, 60% of your customers, in most cases I'd consider that a win. It's going to help your product move faster, it's gonna help your team move faster and in the end that 40% who you were trying to solve for, they'll probably just resolve to use this new thing or you can iterate from that point. You can iterate and keep building and keep building to actually deliver that subset you weren't solving for or deliver them value. This next one's an old favorite of mine and it's deadlines spur action. I try to do this as often as possible. At HubSpot we have real milestones that are built in. We have an inbound conference here in Boston every year. We typically like to deliver a net new product at that conference, but deadlines in general are something that I try to look for in product management as much as possible. And it doesn't always need to be like the inbound conference, right? It can be smaller deadlines, it can be end of month, it can be end of week. It doesn't always need to be something as bland as the end of a sprint or something like that. Building in like seriously meaningful deadlines for your team, for yourself, for your peers, for your leadership to point to and say here's when we're gonna have this thing by, here's why we're gonna have it by then and here's why we think this is a reasonable delivery date. Those types of things will help your team rally around an event, they'll help your team actually get it out the door and they really help everybody center around what's the highest priority, right? If you're behind deadline it's very obvious that you're behind deadline with a product. So boiling those deadlines and putting them into your actual product development and when you're planning things is something I found to be pretty helpful. This next one's a recent edition I found. I was talking to a leader on our team recently. We were debating between which products or which real priority we should solve first. There's basically a debate between two features. He had a very set view, he says we should clearly solve feature A first. Like there's no brainer in my mind that your team should be working on that. And I said, interesting, do you know what else we could be working on? Kind of paused. He's like, no, what else could you be working on? So I turned it over to him and I said, how could we prioritize a single feature if you don't understand everything that we'd be de-prioritizing? So it's very easy to say like, what's at the top of our roadmap? But it's just as important to actually lay out what's low priority on your roadmap because for everything you build you have to sacrifice something else. And that's something I learned really early on I think when I first started in product management I wanted to build every feature. It was really important to me that this got developed as soon as possible. And but there were certain low priority things but we kind of just forgot them. It's really important to illustrate those. You hear them commonly referred to as omissions but they're not always omissions or sometimes just low priorities. Our product leadership loves this one and that speed is a bug and speed is a feature. You never think about speed when you're getting started in product management. You tend or at least I didn't. You tend to think about just getting a product out of the door. You tend to think about stopping for a customer use case. You tend to think about the product marketing that's related to shipping something. But you never really think about speed. It's very rarely top of mind. One of the things I learned really early on is that a slow app or really anything slow is a bug. It's just as painful to a customer as a bug. Sometimes more painful. If page load time is slow. If just like basic interactions are slow. If there's too many clicks in an experience that is just as bad to a customer as a bug. And the worst part about that bug is they don't call in to support and say, this is slow. They don't call in and say this took me too many clicks. They just get frustrated by it. And it just continues to grind down that experience. So speed can be a bug. On the flip side of that speed can be a feature. We've done a ton of research around how making our app faster would benefit the customer. And there's a ton of research out there that say if app load times are instantaneous, if they load almost no time, then customers are much more likely to stick around. And there's entire divisions at companies that focus just on load times of apps and really getting things to the customer faster. And the key to that is no matter where you are. I know a lot of folks are testing their own software locally. They're testing it at hardwired connections. They're testing it close to where their servers are. They're closing it on local connections. Like that is not your ideal or your actual customer experience, especially if you have a global customer base. Connect a JetBlue Wi-Fi and try to load your app and see what happens. That's what people all around the world are experiencing. Try connecting to your mobile phone hotspot and then load your app. Those are different types of things that you don't necessarily think of. And I certainly hadn't thought of until I was loading up HubSpot on a plane and I was seeing all this alt text and these images rendering that were just kind of background images or maybe stale from an old version of an app. That kind of stuff kind of gets thrown by the wayside. And it's important to think of that. Test on all speeds. Make sure you're testing not only your own localized environment but really all of your customer environments. All right, so that's a little bit on product development. The next section I want to run through is things I've learned about your team in product management. And this is potentially, at least in my eyes, one of the most important parts of product management is maintaining a good team, a high performing team. So there's a lot of learnings here. This first one is a little process goes a long way. I know many organizations have many different approaches but at HubSpot we tend to lean on small autonomous teams. That typically means not so much process. And that can get carried away. You think everybody's on the same page, everybody's kind of hip to the beat and everyone knows exactly what you're building in a given day or what you're working on. A little bit of process can carry your team a really long way. And I think the best way to actually feel that from your team is ask them, what's our biggest product priority this month? What are we working on next month? What are we ignoring this month? And if they can't answer those questions, you probably need to build a little bit of process into your process, yeah. You probably need to build a little process in because that's exactly what your team is going to need. It's gonna go a long way. And if you start with a little bit, just kind of check the temperature there because most folks are gonna be resistant to it naturally.  But it can feel really cool to do none of that and that's when you start to get into trouble. So I found that a little process goes a long way. Our team, we started doing some stand-ups more frequently, kind of canceled those, they weren't working so well. Yesterday, today is in Slack. Things like that that really just try to keep the team up to date. Those are the things that actually keep everybody moving. This next one is really near and dear to my heart because it caused a major issue for me is that if your team has even slightly different definitions of what you're building, it's nearly impossible to get shit done. Even slightly different definitions of what you're building. If one person in the team thinks you're building a red car and one person on the team thinks you're building a blue car, it's not going to go very well, right? Even though you both think you're building cars, they're probably built for a different customer for a different reason. Those definitions need to be crystal clear up front down to every single detail because it can get you in a lot of trouble. And it certainly did for me. If you're not actually clearly defining all of that for your team and also the why behind what you're building tends to be problematic. This next one is pure product management tactic. I've had the tendency to do this all the time and I still make this mistake and it's something that I'm consciously trying to get better at. Even reading this slide makes me think of errors that I've made in the past, but passing along bulk customer feedback and just saying like I heard this thing from a customer, it means nothing to your team, to your engineers, to your design team. It needs to be synthesized, bucketed, and it needs to be actually conveyed as to what impact this has for the customer. It's very easy to take notes from a customer call and just dump them in a Slack channel. It's really easy to take a response that you got in-app and kind of send that to your designer and be like, hey, have you thought about this? It's so easy to do and it's so quick, but it doesn't mean a lot. It doesn't mean a lot if you're not tying that customer feedback to milestones that you have already planned. If you're not tying it to previously identified problem buckets in your product, as soon as you start doing that, it starts to take on a whole lot more meaning because it can be easily synthesized and taken back and actually brought into your product in the future. This next one is about product iteration. It probably only works in software, but a team that understands every product is iterative, is emphatically more powerful than one working towards an end game. We ran into this really often on a previous team I worked on. We were working towards a Facebook messenger integration with HubSpot and very early on it was like, okay, what is this going to look like? When are we going to have our own app in HubSpot? When are we going to think about us taking over, having our own hub in HubSpot? That got us into a little bit of trouble, right? Every product, especially in software, that's the beauty of it is iterative. You can build one small thing, you can learn from your customer and keep going. And when a team can fully understand that and grasp that concept, you can build, I mean, this is essentially MVP, right? You build something small, you learn from your customer, you keep going, you keep going, you keep going. It doesn't need to be perfect on your first shipment. It doesn't need to be perfect, really ever. That's the beauty of software. You can keep going, you can keep learning from your customers and making a better and better product every single day. And if you start working towards that end game, you are going to get slowed down to no end.  And it's just a lot of work. And in the end, you're probably going to ship something that's no good for your customer. This one is near and dear to my heart because I had a team that did this and it's a team that literally will sprint at fires and by fires I'm talking about critical situations that cause your customers a ton of pain or accompany a lot of pain is like the most powerful thing on earth. We've had weekend problems, middle of the night problems and when a team can rally around that problem and fix these customer problems like just in the name of doing right by the customer, there's nothing more powerful than that. And anything you can do to inspire to create that culture in your organization is going to be the best thing you've ever done because fires happen. And when you see a team that does this kind of thing, there's nothing more motivating to come to work, say something happened on a Saturday. Midnight, everybody woke up in the middle of the night and solved a major customer problem. There's nothing more empowering than coming in on a Monday morning, recapping what was done and then focusing on the rest of what you need to do because everybody was so impassioned by solving that problem. And when you see this happen across teams, it's even better. I've seen that happen at HubSpot a few times and it's just amazing. Somebody who left that team but still had knowledge of the code base or a product manager who maybe designed the original problem statement will swoop back in, we'll see a problem and spend their nights, their weekends, their extra time half a day solving a very specific customer problem and doing nothing else, sprinting at that problem even though they have nothing to do with it. It creates an incredible culture. This one is pretty recent and it's that an excellent metaphor can be the key to explaining a highly complex problem. So software is complex, product management is complex, metaphors are difficult, but I found that really, really drilling down with the metaphor can be one of the best things you can do. So recently I was back and forth. So HubSpot, the way that we're structured is we have platform teams and I work on a platform team, I make the HubSpot CRM and you have hubs, you have the marketing hub, the sales hub, service hub and they build more specific products for those specific personas, for sales users, for marketing users, et cetera. Now I was going back and forth with a leader in the marketing hub and we were talking about how should marketing problems be brought to the platform and it was a really long winded discussion. It was, you know, we were trying to figure out like should the hub, the marketing team be bringing problems to us, the platform team, should the platform team be in tune with that marketing persona and solving problems for them? And the metaphor that we ended up landing on is pretty interesting. It was that the Hub teams or the platform teams rather, our team, we make pasta. Everyone's really familiar with pasta, right? You can add anything to it. You can add shrimp scampi, you can add pasta sauce, vodka sauce, Alfredo and we decided that the platform teams, they make the pasta. What we do is we serve that pasta to the hubs pretty plain and the hubs, they can add whichever flavor they want. They can create all types of different dishes from this pasta that we created. And from there, that's like a really conveyable message to not only between us, between the platform teams and the hubs but also to other people, people across the organization that don't really get how two product teams work together. That metaphor alone was able to do that. Our CEO, he loves to draw obviously quad boxes but also just timelines, straight lines across the board, beginning and what's it gonna take to get from here to here. Those types of things are really good visual cues but also types of metaphors that can help you get to a really complex problem in a really simple space. This next one is the most recent one I've added here is that team happiness is directly correlated to product success. One of the things I've learned really early on in product management is if your team isn't happy, your product isn't gonna be happy and you're not gonna be happy. It was explained to me once like a three, we run triads. So a product designer, a tech lead and a product manager. It was explained to me once that like you're from the product management perspective, your product designer is your wife for me and the tech lead is also your wife. And you need to keep all of them extremely happy because as the phrase goes, happy wife, happy life. If none of them are happy, your product is going to be no good and you are not going to be happy. So keeping your team motivated, keeping your team excited and everybody on the same page and just playing happy is really what's the key I've found to bring like really, really good product success. So the final section here is about the craft of product management. This is more tactic driven, day in and day out, things that you'll find or that I've found, things that I've learned in product management. Long winded, basically write and do not have sporadic conversations. This is the most effective way to communicate anything. Clicker's a little buggy. The most effective way to communicate anything is to write it down, period. Having 15 hallway conversations, it's good. It helps move things along. You can have those hallway conversations and they can benefit your team. They can inform you but at the end of the day you need to be writing things down.  Don't keep a private notebook, keep something up on the public wiki, pin it to your personal Slack channel, whatever you need to do. Keep things written down and keep them public because that is actually the way that people are going to consume things, be able to reference things back and things don't get lost in translation. You stop playing that game of telephone. This one came to me after a very, very long weekend of kind of getting beat up over the product and it's sometimes you're the hammer and sometimes you're the nail. For those of you not in product management yet or looking to break in, sometimes you will feel like the champion of the world.  Other times you will feel like you just got out of the ring with Mike Tyson and it just plain hurts. It's just the nature of what I've found product management is like. It's just the way it is really. But you got to kind of learn to fight through those ups and downs. One of the things that I've found through a year and a half, a very young year and a half of product management is that in the beginning, one day I was the hammer, one day I was the nail. Towards a few months in, it was maybe weeks. I had a hammer week and I was really, really excited. But now I'm noticing those are more like months or those are quarters of ebbs and flows. So they start to become more spread out. And I think that's largely a play on the emotions you feel. As a product manager, it's such an ambiguous role. And if you start feeling like those really like tenuous, those ups and those downs day in and day out, it happens. This is a very real product problem that we were having today. I was head to head with another product manager. We could not resolve on what we should do. We had a 30 minute meeting schedule. We went for an hour. We couldn't resolve, we just couldn't do it. We walked out of the room and we had a meeting later on, tried again, still could not find a way around this problem. A little bit later in the day, we met with our mutual manager and we explained both sides of the problem. And he said, why don't we do both? It was a very easy solution. Now there's a thought that because we both wanted our way because it was how we entered the conversation. It was the thing that we aimed to get out of this outcome. There was really no downsides to doing both. Perhaps a little bit of team distraction but it was certainly manageable but neither of us thought that the entire time. It was either one way or the other but you can try both sometimes. And I think that's something that can be overlooked especially with cross-team communication or really strong opinions. Strong opinions loosely held are the good way to go here. Again, on communication. This can feel uncomfortable but when you need to communicate something important, write it down, communicate it three times and then when you do it again and then when you're tired of communicating you think you've over communicated a concept and then everybody gets exactly what you're saying. Communicate it more.  I've fallen victim to this trap many times. Walking into a meeting, thinking everyone read the deck that I shared with them on Google Docs which doesn't have the greatest notification system especially in a flooded inbox, right? People need to be force-fed if there's very important communication. I'm not talking about everything you've ever written or every slack you've ever sent, you don't need to follow up on those. But like when something's important, you need to communicate it until you're uncomfortable and this is something I'm still learning every day. It is a really, really tough exercise to do but I find that it's extremely helpful and you're almost never over communicating. I don't think anyone's ever given feedback that you're an over communicator to anyone in any career of all time. So I think it's a really good thing to do. When it comes to getting buy-in, evidence is greater than ideas. This is a bit of a no-brainer but it comes back to that scientific method, right? If you've got hard facts, if you've got hard data, it's going to trump over ideas every single time. In fact, if someone doesn't like your idea, the first thing they're gonna say is, what data do you have to back that up? It's simple. If you don't have that evidence and you don't have that supporting reason to actually convey an idea or to get something done, it's very, very hard to win. Python is the bee's knees. I was a non-technical product manager, still am, pretty non-technical, but I learned a little bit of Python. Why did I do that? Because it helped me self-service. It helped me do things that I was otherwise asking my engineering team for. It helped me do things that to them was a distraction. So I learned how to just basically write a simple script and then I pulled that into Tableau where I'm more comfortable and it's a safe space and I would kind of do the rest of my analysis there. But this learning is less about Python and more about being able to service yourself. Being able to spin up quick mocks, whether it be in Google Slides or anywhere, being able to do that instead of asking your designer to build those simple mocks for you. Simple wireframes, things like that. Really simple Python script, SQL, things like that.  This is a really real example of that. Sitting for lunch with five people who are close to the customer every single day will fill your notebook quicker than 10 customer calls. Mainly because in customer calls, I've found that you're looking for a specific thing and this is just a natural habit that all of us have in research. So you try to direct the conversation there and it's one-on-one, right? You only have a finite amount of time, 30 minutes, an hour if you're lucky and there's only so much communication that can be done. If you bring your notepad and sit at a lunch table with people who work with your customers every single day and just listen, maybe prod a few questions in there, you'll have a more full notebook and a more well-rounded understanding of your customers in half the time. It's incredible how quickly you can start to learn from your team. Now, not everyone has the luxury of having these teams. Maybe you have a two birds and service team. Maybe you have a remote service team. The bottom line here is to get close to them. If you're able to get close to your services team, they have the insight into your customers and they're the ones who can actually provide you with the robust feedback and the best thing is they all double down on each other. So if they say this one part of the app is no good, they'll, oh yeah, and they just really hammer that one problem space and you can see that in a different way than you'd see with a customer who only has their specific point of view into something. Toying around with another potentially unrelated product to your own can be what's standing between you and a breakthrough for your own product. So I try to do this as much as possible, trying apps from the app store, apps that have to do with CRMs and apps that don't have to do with CRMs. Really just getting my experience more well-rounded in different types of software because oftentimes there will be quips in certain things that you'll learn that you can immediately apply to everything that you're thinking about at work. Because obviously you're spending 40, 50, 60 hours a week thinking about a specific problem, a very specific thing you're looking to solve. Sometimes that can be good, but sometimes you can get kind of wrapped in your own head and have a really hard time seeing the forest through the trees. So when you try another app, a lot of times you'll have that light bulb moment. I've had many of these myself of using basic filtering schema in like a gaming app. Play Fortnite and just like pay attention for 30 seconds to the way that they do selectors and the way that they do all of that kind of stuff. It's actually a really, really good way to get yourself out of your own product space, but at the same time, spur some really cool innovation. The DP, this is a bit of a no-brainer, but the deeper you go in a dataset, the more unexpected and surprisingly valuable things that you'll learn. Now that every one of us has a luxury or the time to do this, it's a really hard thing to do to go extremely deep into a set of data, but it's super interesting. When you're asking for a funnel analysis from your analyst or you're running one yourself, cross that funnel by region, cross it by language, cross it by geography, cross it by the age someone has been with your app. When you start doing that kind of stuff, the insights can be fascinating. You're not always gonna find them, but sometimes you can run a 180. For example, we were spending a lot of time thinking about the import flow into HubSpot and bringing data and bringing objects into HubSpot. We were concerned at the macro level about how this happened for everyone. We just thought, okay, how do you get from step A to step Z? It's a funnel, it's pretty simple analysis.  We took a step back. We crossed it by non-English speakers. All of a sudden we had lost 30%. That was super interesting. We started to cross by specific regions of different languages, different languages specifically regions of Spanish, things like that, and we learned a whole lot more. We were able to identify problems in translations, in localization, in internationalization, that we wouldn't have found if we were just looking at the overall funnel. This is certainly something that you can only do if you have the luxury of the time, but it pays dividends if you do.