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 your product plan?

Another principle we use is called Heart. We try to find the most important part of the product we want to deliver. The team has a tendency to deliver things that are less risky. Instead, we want to start from the biggest risk that solves the biggest problems.

When we were working with Calendly, we started by making a calendar page that showed the user’s availability. This is the core of the product. We didn’t know if Google would allow us to do real-time meeting invites. There were a lot of risks with using Google, and a lot of businesses were using Microsoft at the time, but we wanted to be able to skip the log-in. With Google, you can give access to the calendar and the integration is done. We created the core of the product, the booking page, and everything else fell into place because everyone got on the same page.

Action Guide: Put the information Yaroslav shared into action now. Click here to download the Action Guide.
Useful links:

• Learn more about Railsware and the BRIDGeS Framework
  

Innovation Quote

“Those who seek shall find.”– Attribution

Thanks!

Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.