Context

The goal of product teams is to add value of their customers through their product or service. A lot of time, money, and resources is put into building them, and so making sure value is consistenly being added not only increases revenue but it also saves costs of building the wrong things. Sometimes the biggest challenge is how to determine whether the right problems are being solved and people are buying the product. When there is no clear strategy, customer value isn’t added; only features.

Healthy product teams question their strategy and their value generation all the time, and they do so by asking these very fundamental questions:

1. What is the most valuable outcome to chase?
2. How do you compare that outcome to other outcomes?
3. How do you get to that outcome?

There is more than one answer these questions, and BRIDGeS is one of them.

What is BRIDGeS

BRIDGeS is an approach to problem solving. It was developed by Railsware and it is mainly used for digital product discovery: the process of finding the best solutions for the most important problems. It has been generalized enough to address other kinds of problems too, meaning it’s useful beyond software products.

Similar to design thinking, BRIDGeS embraces the problem-solution dichotomy where there must be enough space to explore and define the right problems first, and only then the right solutions can emerge. Also, there is a strong possibility of circularity in the sense that thinking about a problem might lead to solutions which in turn might generate more questions that justify going back to exploring new problems.

What problems does it solve?

BRIDGeS answers four specific questions:

1. What problems are there to solve?
2. Which ones are the most important?
3. What are the best solutions for the highest value problems?
4. What is the plan to get there?

Symptoms of dysfunction

Most often, a product team implements the wrong solutions because of at least one of these symptoms:

1. Executives pretend/believe they know what to do, without evidence.
2. They chase metrics instead of solving actual problems.
3. There is barely a product strategy.
4. They stick to chasing competition instead of innovating or not having a strategy.
5. No user research is conducted to guide decisions.
6. The goal is reduced to building features quickly over solving problems effectively.
7. Rhythm is dictated by top-paying customers who threaten revenue.

How to use

BRIDGeS is a thinking aid. It offers basic construction blocks to help frame the way you think together as a team. Therefore, the best option is usually to gather around a table or a whiteboard, some colorful sticky notes (optional), and a marker per person. This does not mean that remote teams cannot perform this exercise, quite the opposite. You can use any whiteboard software with collaborative capabilities in it. Options include FigJam, Miro, or Excalidraw.

Discovery is an ongoing activity, so expect to revisit your problem and solution spaces frequently. The product of discovery becomes organic, meaning whatever is produced at one time should be kept and maintained over time as new feedback comes up.

Step 1: Explore the problem space

What’s the point in coming up with features for a product if there is no visibility to the problems it’s trying to solve? If your team is thinking of solutions in search of a problem, you’re wasting time. BRIDGeS forces you to look at real problems first, they are the source of direction.

Before you get started, you’ll need the following inputs:

• The business’ and product’s vision
• An overarching problem to solve
• Information on users / beneficiaries / subjects of the product
• Any forms of relevant data (e.g. user interviews, customer feedback surveys, analytics data, etc.)

Then, as a team, identify the following kinds of problems (good or bad):

1. Who are the subjects, those who take advantage of the product (e.g. users, suppliers, companies, etc.)
2. What benefits they seek from the product.
3. What risks they might incur and resolve or avoid.
4. What issues they already incur and want resolved.
5. What information is relevant to support the thinking exercise.
6. What goals your core subject wants to achieve.

In the end, you’ll get a big map of ideas around key subjects. Those ideas constitute your problem space. Now you have achieved a significant outcome you otherwise didn’t have: a better understanding of what problems there are to solve.

Step 2: Prioritize the problem space

Now that you have a map of your problem space, it’s time to ask the big question: which of these problems is the most important? That’s the goal of this next step: to look for the best outcomes. They usually fall into more income, less costs, or less risk. There are others, of course; your environment brings specific factors to the table so not every space is the same. It’s up to you to determine what you prioritize.

Keep your business and product visions with you as you move along the exercise. Without them, it will be significantly harder to determine priority. Here is what you need to do to reach a list of priorities:

1. Choose a prioritization framework.

There are a number of them to choose from, and some examples include:

• MoSCoW (Railsware’s official recommendation, I happen to like it too)
• Eisenhower matrix
• Impact-Effort matrix
• RICE scoring model
• Kano model
• …

It’s important that you choose at least one so it guides your decision making process and avoids conflict later. If you don’t have any guidelines, you’ll fall back into the classical “because I say so” problem, and lose the opportunity to properly determine the highest value problem. All of these methods rely heavily on external factors such as technical effort, competition analysis, and user feedback data. The more you can externalize factors of prioritization, the better.

MoSCoW, in particular, is relatively simple to adopt because it categorizes an item’s priority into: must do, should do could do, and won’t do. The immediate reaction to each category is to ask why, and the entire group is engaged in giving a proper answer. For example, if a problem “should be solved”, why should it be solved? What makes it mandatory or optional? What are the consequences for it not being solved at all?

2. Prioritize each item in the map.

Apply the newly made definition of value onto each benefit, issue, and risk. Remember the goal and knowledge items as they are most useful in this very step. Their role is to inform both discovery and prioritization.

For each item, aim to properly define and understand the problem. Ask questions that expose the impact of the problem (as opposed to solution-specific questions) like:

• What is the story behind this benefit / risk / issue?
• What and when are the consequences of it being solved / ignored?
• What other problems come up of it being solved / ignored?
• Who is involved or affected by it?

Depending on the answers you get, you will inevitably reach a conclusion and weigh the item according to your choice of prioritization factors. Mark the item with the respective priority level and move on. If you’re using MoSCoW, the item will marked as must do, should do, could do, or won’t do.

There is a tendency to immediately compare a priority given to one item with another one. My personal advice is to hold onto comparisons until the very end so that the whole review process sheds a broader light onto your choices so far.

3. Review the items you prioritized against each other for one final calibration.

Finally, upon having placed all priority markers into every benefit, risk, and issue, the whole team has the opportunity to take a step back onto the whole board full of ideas around all subjects. Take a moment to analyze carefully how many of each category, how many of each priority level, and search for patterns. If they tell you something, then perhaps there is a strategic insight lying underneath.

At the end of this crucial step, you will get an ordered list of items; it’s effectively a roadmap yet a different kind, one that forces everyone at every level to understand the truly important things being tackled. In the case of building products, it’s about solving customer problems that ultimately add value to the business. Notice you have not focused on solutions yet, and that is by design. It’s not productive to think of solutions for the problems you don’t know nor understand.

Step 3: Explore solutions

Now that the problem space is mostly figured out, it’s time to explore possible solutions. At this point in the exercise, you’re looking to converge on possible plans of action so that you can later choose the one that makes more sense. Only then it will be wise to invest time in preparing all the technical details to execute.

Whereas previously you would brainstorm them out with little to no direction, the context you have now acquired much more accurately points the outputs you will now produce. Do not expect to figure out the definitive solution immediately. Instead, allow you and your team to explore different variations. Ultimately, you will be able to find which of them is the best one.

Start by proposing high-level ideas that solve the problems you have. There’s no point in going too deep too soon. As you go through each of the ideas, ask questions like:

• How much of the problem space does it solve?
• What is the potential additional value that the solution unfolds?
• What could get in the way of realizing value?
• How much change is required at every layer (e.g. business, systems, skills)?

According to thought leader Peter Cagan, solution value is determined by three main factors:

1. Viability, which means whether the customer will experience value-add and choose it, and also whether the business itself sees increased value. This can lead to many questions; for instance, if problem X is solved (through some high-level solution), can marketing and sales channels fit it? Are there potential legal issues? Does it cost more to acquire new customers?
2. Usability, meaning if the solution meets the typical satisfaction criteria when it’s being used. For instance, is the solution fast? Is it ambiguous or leads the user in error? Does the solution get out of the user’s way?
3. Feasibility, which is the set of technical skills and capabilities required to actually implement a solution. For example, does the team have all the skills to do it? Are there limitations to the tech stack being adopted? Is there enough time?

The goal of the task is to define the different parameters that constitute solution value, and all relevant people are equally responsible for discussing and agreeing on that definition. For products, product manager, product designer, and lead engineer are the most relevant people to make those decisions. Not having a framework that helps identifying good solutions hurts judgment and leads you away from the best solution possible.

In the end, you will have a solution plan everyone agrees on, with just enough detail that it clearly connects to the problems being solved.

Step 4: Prioritize solutions

You’re very close to figuring out a more structured plan of action. The strategy is emerging, and the means to accomplish it are taking quite a good shape. Now the final stretch is important to nail right so every bit of effort pays off.

This final step combines two ideas: breaking down all major blocks into small enough pieces, and prioritizing them into a roadmap that is valuable to not just the short term but also the long term. In the end, you will see a list of tasks to perform, sorted by priority.

1. Break down the solution.

Breaking down a solution is not simple at first because it requires context from multiple sources: the product itself, the technology and resources being used, standard practices from the team or company, legal/compliance requirements, etc., which makes it far more challenging at the first few attempts.

There are a couple of principles that can be applied to this task:

1. Incorporate the problem into the solution being broken down. A good solution is always informed by the problem it solves.
2. Leverage Cagan’s three factors when breaking down the solution. Always ask whether the solution component is viable, usable, and technically feasible.
3. The closer you can get to the user’s playing field, the better. A solution is only good if the user understands it and the value it promises is achieved.
4. Explore more than just one solution for the same problem. It’s better to think of multiple solutions so they can be filtered out after new information improves upon them.

2. Prioritize all tasks.

Now that the solution is broken down into much smaller components, the question begs itself: where to start. The good news is that the same prioritization tactic used during the problem space can be used again. If you or your team believe that a different way of prioritizing a solution is more relevant to the exercise, then experiment with it and see where it leads you.

The whole point of prioritization is not to use a technique or another, rather it’s to find which parts of the solution to implement first. Naturally, all relevant roles in the discovery process have a proper contribution to make as they all have expertise in their own domains. For instance, a product designer most certainly understands how to best go about producing an experience that is usable, efficient and gets out of the way. Also, the product engineer knows how to provision the right infrastructure and write the necessary code to materialize the product in ways that cut costs, reduce time and rely on the right technical skills.

It is very likely that the solution you come up with will not be the final one. What’s more, every time you revisit your problem space, more ideas will come to surface.

Conclusion

Solving problems correctly demands transparency, collaboration, and willingness to correct course when necessary. BRIDGeS brings all three to the table.

A problem with no solution is a risk. A solution with no problem is waste. Only by combining the two perspectives in tandem does a team have the full picture to solve the right problem with the right solution.

Depending on the strategy you end up choosing, the solution might be a quick mend or something more dense and effortful. Judging which one is best will depend on how much vision you have about the problem (which is where product leaders thrive) and how much execution power you have (which is where engineers and designers shine).

TODO: offer the whole set of infographics as a PDF.