How to Design a Problem

Suppose you wanted to drive somewhere and decided to create your own navigation tool instead of using an existing app. What do you think it should consider? Here is my starting idea list:

• Transit method

• Map data including distances and roads

• Speed limits

• Current traffic

• Tolls

Some of these elements are straightforward. Others are harder to measure and quantify. However, as a seasoned modeler, I feel confident I could pull together a model that would give me a reasonable route from a starting point to a destination. In order to accomplish that I would need not only the raw data, but also to tell my model how to make tradeoffs between the various factors. Effectively, I would need to tell the model what my goal is, as well as any rules for how to measure a route against that goal.

There are some elements of the model that would be true for everyone - travel distance on a particular route will be the same no matter who is driving it. Other inputs depend on the person in question - I am willing to pay for tolls mostly when pressed for time, or when the cost is somewhat less than $0.50 per minute saved. At times, I have found the recommended route from a navigation tool to not be satisfactory. My biggest gripes tend to be:

• Tolls.

• I prefer city streets vs a highway.

• I prefer closer to a straight-shot vs lots of turns.

The interesting thing about models is that they are always a reflection of the information and opinions of those building the models. People sometimes have the perception that there is a “best” route that simply needs to be discovered. For years, Google chose “fastest” as their default for the recommended route. However, they also provided some options to adjust the model to your specific preferences.

The data and opinions that go into quantifying the best approach is one I like to call “Problem Design.” The end result of a problem design project is a problem definition. For example, a navigation model’s problem definition might look like the following:

We want to create a navigation model which assumes you are driving a car. Users are able to input the starting point and their destination. Users input how much toll / gas money they are willing to spend to get to their destination one minute faster. We define the route with the “minimum travel time less the cost of tolls and gas converted into time” as the recommended route.

It is clear with this problem definition that we would end up with somewhat different routes than if our problem was designed differently. When you set out to design a problem, there are many steps that can help you be successful:

1. Understand the business context of the problem you are designing.

2. Clearly identify any assumptions that you are willing to make to simplify the problem.

3. Specify any inputs and input data that your model should / could consider.

4. Specify any criteria that the final problem definition needs to include.

5. Articulate the perspective behind a “good” solution to the problem.

6. Design the problem intentionally before moving on to building a solution.

7. Revisit the problem design if you discover new information when building the solution.

Step 5 is why I believe in always including higher-level stakeholders into the problem design stage of a project. There are often strong opinions on what a problem should take into account. A design that excludes those factors is unlikely to ever be trusted or used.

Returning to the navigation model, imagine a model that assumed speed limits were the same everywhere. This could be a reasonable approach for a pedestrian navigation app, but car drivers would quickly stop using the tool. These sorts of potential oversights are why good problem design is key to a project’s success.