467: Strategic product planning – with Yaroslav Lazor

Unpacking the BRIDGeS framework for product managers Today we are talking about strategic product planning, which involves decision-making, problem-solving, feature prioritization, and product vision creation. Our guest is Yaroslav Lazor, Founder and CEO of Railsware. He created the strategic product planning tools and frameworks that Railsware continues to apply on projects for customers as well as their own products. I first heard of Railsware when the founder of Calendly talked about the group that developed Calendly for him, which was Railsware. Railsware is a product studio focused on creating services and products that is on a path to becoming a $10B firm. Summary of some concepts discussed for product managers [2:25] To what do you credit your success in going from a developer to a product creator to a CEO? I was never just a developer. I was always a product developer. In the early days, I had no product managers over me, so I had to build products myself. This is one of our secret ingredients at Railsware—everyone is thinking about product. In many organizations, there is a big gap in communication between product managers and engineers. There’s pressure from product managers for developers to develop faster or cut technical depth. For engineers and product managers to work together in harmony, their skills have to overlap, and they have to understand each others’ disciplines. [4:49] What does it look like to have product people and engineers integrated? It depends on whether we’re talking about having this integration in-house with our own products or when we consult clients, but the one thing in common is our BRIDGeS Framework, which allows everyone to get on the same pages. When you start a project, often the founder has thought about it for years and is thinking 3D thoughts in their head. Their thoughts include a massive amount of data that you cannot display in a straightforward way. We map out these data with BRIDGeS. We map the roles of the people who are going to use this product and their problems. How someone who deeply understands the problem would describe it is completely different from how someone who just heard about it would perceive it. When you hear all the details about the problem, you start rewiring your brain to think about it like someone who has been thinking about it for years. However, the founder, who has been thinking about the problem for years cannot tell you all their thoughts because there are too many. We take cards, each representing one thought, and align them on a board. Everyone in the room looking at the cards starts to see this much bigger picture, and they remember little stories about each card. We have two boards, one to describe the problem space and one to describe the solution space. We go back and forth, sharing ideas, until we are all on the same page. Then, the product managers and engineers understand what we’re building in a much deeper manner. [11:40] What do you put down on the cards? Bigger cards are personas. For example, if we were doing a project for a school, one persona would be the school district administrator, which is a user role that needs something from the product. Other cards would be the school director and the teacher. Other cards are for their issues. The school administrator might have an issue of wanting to use the same template for all the schools’ websites, and copying the template takes a lot of work. As you dive deeper into each role and their problems, you start creating empathy for each person. It helps you build a product that is tailored to solving problems of real people. You also use cards to describe solutions, benefits, and risks. Typically we write the smallest possible amount of words on each card. We often do this in virtual meetings. [18:31] What framework do you use for executing y...