You’ve seen them if you’ve spent any time in North America. You likely didn’t know their names.

I sure didn’t.

Not until I watched this video from Not Just Bikes on YouTube.

If you don’t have the time, don’t worry. I’ll summarize:

🚙 Stroads are a street/road hybrid that are dangerous and ineffective.

🚶‍♀️ Stroads are hostile to non-car users and make walking or cycling uncomfortable and dangerous.

💸 Stroads are expensive to maintain and do not provide good value for the space they take up.

🌳 Stroads are ugly and uninviting due to the removal of trees in their clear zone.

🏢 Stroads do not support a sense of community or encourage people to stay and spend time.

NJB pulled from a fantastic word from Strong Towns – the “Stroad”.

"Stroad" is a word we coined in 2013 to explain those dangerous, multi-laned thoroughfares you encounter in nearly every city, town, and suburb in America. They're what happens when a street (a place where people interact with businesses and residences, and where wealth is produced) gets combined with a road (a high-speed route between productive places).
They are enormously expensive to build and, ultimately, financially unproductive. They're also very dangerous.

Stroads are a compromise – in the worst sense. They are an attempt to have the best of both – interaction vs. transit – without the courage to recognize that these are opposing purposes.

The Compromise Conundrum

Just as the stroad attempts to straddle the line between street and road, data products can fall victim to the same compromise conundrum. When we try to create a product that caters to everyone's needs and desires, we end up with an unwieldy, unfocused mess.

A dashboard that attempts to solve everything. A table meant to summarize and store. An API meant to convey differing levels of granularity.

Instead of producing a data product that's flexible and nimble, we end up with a stroad-like monstrosity, a hodgepodge of features and functionality that's neither efficient nor effective. And just like the stroad, this kind of data product is expensive to build, difficult to maintain, and frustrating to use.

Think of it as a zoom level on a map. The difference between a globe and a topographic map. Both opinionated. Both useful. Yet meant for different purposes. When navigating treacherous terrain, a globe does nothing to forge a safe path ahead. When flying high in the air or navigating oceans, what good is the topography of a trail?

Opinionated Data Products

It's time for data products to take a stand. Rather than striving to be all things to all people, data products should be opinionated. An opinionated data product knows what it wants to achieve and isn't afraid to make bold choices in pursuit of its goals.

An opinionated data product might make some users unhappy by not catering to their every whim. However, by focusing on a clear, specific goal, it provides a better experience for its core audience. Instead of trying to be a stroad that pleases no one, an opinionated data product can be a well-designed street or road that serves its purpose with aplomb.

“When you try to be everything to everyone, you accomplish being nothing to anyone” - Bonnie Gillespie

Anatomy of a Data Product

That leaves us still with the need for structure. You can’t refine a product without first understanding it’s components. Let’s revisit a definition

A data product is a collection of data that is designed to meet the specific needs of a user base, providing a range of interfaces through which users can interact with it. These interfaces may include software, visualizations, direct feeds, and more. Ultimately, a data product serves to fulfill certain tasks or "jobs" that the user base requires, making it a purpose-built solution for meeting specific data-related needs.

The components of a data product should be as follows and give us the flexibility to alter each to support purpose-built solutions. A data product is:

• Adaptable: Seamlessly integrates with various inputs and outputs, and effortlessly expands to accommodate new data sources.
• Specialized: Purposefully designed to address a focused set of valuable problems for external customers.
• Discoverable: Easily found and accessible without being hidden or restricted.
• Fortified: Ensures security and stability for reliable data handling.
• Contextual: Maintains a historical record of its purpose and problem-solving context, including a data dictionary and external references.
• Engaging: Captivates the interest of its target audience through relevant and valuable insights.
• Loveable: Exceeds the minimum loveable product standard, making it approachable and user-friendly.

Embracing Purpose

So, how can you avoid the perils of the stroad when creating your next data product? Here are a few principles to guide you:

1. Define a clear purpose: Before you start building your data product, make sure you know exactly what you want it to accomplish. By having a clear purpose, you'll be better able to make focused decisions that serve that goal.
2. Say "no" to feature creep: It's tempting to add more and more features to your data product, but this can lead to a stroad-like morass. Stay focused on your core purpose and be willing to say "no" to features that don't align with it.
3. Prioritize the user experience: Just like the stroad is an unpleasant place to be, a poorly designed data product can be a frustrating experience for users. Keep your users front and center in your design process, ensuring that your data product is easy to use and meets their needs.
4. Iterate and improve: Don't be afraid to make bold choices in your data product. If something isn't working, learn from the feedback and iterate on your design. This iterative process will help you hone in on the perfect balance between form and function.

By embracing these principles and avoiding the trap of the stroad, you can create data products that are focused, efficient, and effective. Remember, it's better to be a great street or a great road than a terrible stroad.