 Hello. Thanks for joining today's discussion. My name is Brian Levy and I've been a Product Manager for several years, and I'm currently a Principal Group Manager of PM at Microsoft in the Microsoft Digital Organization. In my current role, I lead PMs in developing technologies and tools at Power Experiences on Microsoft.com. On a personal level, I'm a New York transplant on the West Coast, spent about a decade in California, and another in Washington where I currently live and work. For the last 12 years, I've been at Microsoft where I've been extremely fortunate to have experienced multiple roles. I started out as an hourly associate helping to launch Microsoft's physical retail store business. I later went on to manage worldwide store operations for over 100 locations before switching to a technology program management track. Since then, I've helped transform the technologies and tools, powering end-to-end retail, launched interactive experiences in experience centers and on the web, and I'm now working on transforming the customer journey on Microsoft.com. I've had individual contributor roles and management roles, I've led large teams and small ones, and today I'm just super grateful for the opportunity to chat with you on behalf of the product school. Today's topic is titled Constructive Disruption, using hackathons to break down organizational barriers to innovation. The reason we chose this topic was because in today's enterprise environment with large companies, you can often feel at a disadvantage compared with startups when it comes to trying out new things, especially if the new ideas or projects could be seen as divergent from the current roadmaps and plans or product lines of the existing organizations. We've heard from a lot of PMs that they want to have more opportunities to innovate, and hackathons might very well be that solution for you if you leverage them to their fullest potential. Hackathons are events that bring employees together to create, to innovate, and to hack on ideas that inspire them, but you can also use them for more than just hacking. You can use them to spur energy and excitement for a new idea or project that you take beyond the hack. What I'll be covering today are the three key themes to think about to ensure your hackathon not only results in innovation, but has the best possible chance of success beyond the hack. You'll also be able to apply these three themes to other work you do as PM. Let's jump right in. You know, almost nothing in this world of significance can be done alone, and it requires having a great team alongside you. But what makes a great team when it comes to a hackathon? What kind of skills do you need to recruit for it, and how do you do recruiting for a hackathon? Which areas of the organization should you look to for recruiting? As a leader of a hackathon team, how can you maximize the results of your recruiting efforts and where do you focus? There are really two types of considerations to make when it comes to recruiting for hackathons. The first is organizational positioning, and the second is skills and talents. Organizational positioning is essentially what team the candidates normally work in within the company and their regular role in those teams. As an example, they might be a manager of a design studio in another organization or an individual contributor in a product team that you're part of. And other combinations. The key to leveraging organizational positioning well is to think about that person's regular role and whether or not that role can help the hackathon execute and succeed beyond the hackathon. Based on your project goals as an example, you might be developing a potentially competing technology with something that already exists at the company. If this is the case, you might benefit from having someone from that competing team being on the project with you. Or with your project as another example, you might be looking to increase the ranking of the idea in the normal prioritization process of your organization. If this is the case, you might benefit from having someone from that planning team or from that team's leadership team participate in your project as a fellow team member. The second consideration comes down to the skills and talents of the candidates and the needs of the project. How many of each type of role or discipline do you need on the team to succeed in a hackathon and would the people that you're recruiting be able to help advance the hackathon project during the project and beyond the hack based on their skills and talents as well as their existing organizational position? As an example, a project might likely need software engineers, user experience designers, product marketing and other roles, but you likely don't need all participants to be software engineers and it would be great if those participating software engineers are organizationally positioned in a team that's going to benefit your idea with their leadership bio. You want to have this combo of the two factors, the two considerations of organizational positioning and skills and talents in the people that you target to join your team. Once you identify your targets for recruiting, go ahead and pitch the project to them, win them over and get them to join. In my most recent hackathon experience, we were able to use both organizational positioning and skills and talents to build a team that not only delivered on the hackathon goals, but it also helped our team align some future work with another group that's going to benefit from the work that our team does and drive wider company impact. The second theme we'll cover is seeing is believing. So when I was growing up, I studied saxophone and I'll always remember my music teacher saying that he can play any song as long as he's able to hear it in his mind first. If he can hear it, he can play just about anything. I think the same lesson holds true for creating anything, but people don't need to be professional musicians or artists in order to be able to leverage this skill set. People just need to be able to see it in their minds first for them to believe in it. With a hackathon or with any new idea you have, it's your job as a PM to help people see what's possible and create a shared vision even when nothing exists yet. And so how can you do that and what's worked for me? On the spectrum of fidelity for visualizations, there can be everything from a paper napkin sketch that we create some restaurant all the way up to a high fidelity video trailer with theme music, narration and special effects. As a PM, this concept really isn't new, but what might be new is how you think about leveraging these to fulfill your hackathon objectives. As an example, when you are recruiting team candidates to your hackathon team after you've targeted them, it's extremely helpful to have some kind of visual pitch content to sell them on the idea and wanting to join the team. Low fidelity sketches or high fidelity wireframes are great for attracting that talent to your team and it's even better to co-create that with them. During the hack, sharing inspirational examples with the team and other content is a great way to drive execution and excitement. Is there some kind of movie scene that resonates or a trailer of a sci-fi movie with some futuristic way of doing something that helps galvanize the team on what they are executing towards and helping to create that visual aid for them to envision? Then, when you're wrapping up the hackathon project, pulling together a full motion video with music and narration is a great way to convey the story of what your team built so that it can be easily shared with others. Think about including the background of why the team chose this project, demonstrations of what was built, animated prototypes of what's possible to build with more time and resources and the potential impact the idea can have. The higher fidelity the project summary is and the more compelling the story and vision, the more effective the hackathon will be for driving impact beyond the hack. The third theme that we're going to cover is race to value. There's an old cliche that if you can measure it, you can manage it. Building on that same concept, if you can quantify the potential impact of your idea, you can obtain the right to pursue it. With hackathons, teams often forego the exercise of quantifying the value of the idea and rest solely on the perceived merit of the project. To not only succeed during the hackathon, but also earn the right to continue beyond the hack, let's talk about some best practices. When you get started with a hackathon, you will have many project options to pick from likely. To help level the playing field and help you choose the option that's most likely to succeed, the first tip is to start with measurement and goal setting at the beginning and using it to inform what project to pursue. As an example, if you have the choice between two project ideas, one of which will drive a measurable impact that's important to your leadership team and one that's not, this can be really helpful in deciding which idea to choose. So start by developing a list of targeted metrics that you want to go after, not just product ideas, and forecast the impact the project ideas can have on those metrics. Picking a measurement and a project idea based on the forecasted impact is a good start, but there's more to be done. So how can you then validate the impact potential before you write a line of code or create a PM spec? Can you leverage a paper prototype with potential users? Is there a smaller component of the project idea that would be quicker and easier to construct and faster to measure results with? Don't wait to validate the impact potential. Earlier you can do this, the more confidence you'll have in the idea, but more importantly, the more confidence your team and their leaders will have in the idea. Another tip is to embrace taking shortcuts. Most of us want to do things the right way or the best way, especially when we envision a particular method of execution. But when it comes to proving value, it's okay to take shortcuts to get to the proof point. Is there an existing product that meets 50% of the features you are looking to develop? Even it's another organization's product. Is there a past product that was launched and later shuttered that meets some of the features that you're looking to develop? The point is, if there's a creative way for you to take a shortcut that leads to proving the hypothesized value, even directionally, it's likely worth taking. Proving the value is potentially more important than proving the feasibility. Finally, the last tip is to continuously monitor the impact to the measurable goal and report out on it via regular updates. People's belief and faith in an idea can wane over time, but if the results continue to prove fruitful, this can help keep support alive for your project idea beyond the hackathon. In my most recent experience, despite our hackathon idea being very compelling conceptually, and having aligned measures to success, we took way too long to prove value because we avoided shortcuts. This really put the project in jeopardy of continuing several times and could have been avoided if we laser focused on getting a measurable impact first and not waiting. As we wrap up, these three themes aren't just helpful for hackathons. They are great principles that are going to help you day to day in your role as a PM. Recruiting with leverage ensures that you're being organizationally aware and cognizant of the political landscape around you. Seeing as believing and crystallizing a vision for others to embrace is all about your ability to craft a story and lead a team to a desired outcome. Race to value and keeping measurable impact in front of you and centered with everything you do keeps us honest as PMs and reminds the organization why the work you're doing matters. Even with great work, ideas, and solid execution, sometimes that's not enough and these three themes to succeed just might mean the difference between an idea and a product. On behalf of myself and the product school, thank you for watching and listening. Goodbye.