Geospatial Lessons for Product Managers

Lesson 1. The Map Isn't the Product

I started with the belief that if you have geospatial data, the goal is to put it on a map. It seemed obvious. But I’ve learned the most powerful products don't just show you where something is; they tell you what it means and what to do about it.

A Real-World Example: I learned this lesson during a project with incredibly high stakes. Following a tragic firefighting plane crash, I was part of a team tasked with helping fire agencies make safer flight-tasking decisions. The goal was to shift the immense pressure of the go/no-go call from the pilots to the fire agencies making the tasking request

My first instinct was to put the risks on a map. We started by plotting dangerous weather like wind shear (sudden, violent shifts in wind). But the more we talked to users, the more I realized we were answering the wrong question. They weren't asking, "Where is the wind shear?" but: "Is it safe for this specific helicopter to fly this mission?"

The winning solution felt almost comically simple. It wasn't a map, but a dashboard with a clear, color-coded risk rating. Seeing 'Severe Risk' gave the decision-maker the unambiguous "No-Go" they needed in seconds. It was a powerful reminder: we aren't here to put dots on maps; we’re here to provide clarity.

🗺️ The 'Map-First' Fallacy: This experience now has me asking: When is a map truly the right tool? How many projects are sidetracked by 'map-first' thinking? And what game-changing, non-map visualizations are we failing to imagine?

‍

Lesson 2. Learning to Speak "Geo"

My team helped me build my mental glossary of geospatial terms, from rasters to vectors, GeoJSONs and Shape Files, netCDF, GRIB, LiDAR… the list felt endless. Learning new technical terms is hard, but I realised that I needed to get comfortable with a whole new vocabulary. Essential for understanding how to communicate with my team and deliver customer value.

Unlocking Contribution: Learning to speak this language fundamentally changed how I could contribute. I could finally move from being a spectator to a true partner in technical conversations. I could ask more intelligent questions and better understand the trade-offs. My contribution shifted from 'Can we do this?', to providing more meaningful input like ‘What is the impact of latent data on insight accuracy, and is that an acceptable trade-off for the user?’

🧠 The Power of Specialists: The most valuable asset in this journey has been having great geospatial expertise in the room. Those leaders flattened my learning curve. I learned my role was to be the chief learner and translator—bridging the gap between deep technical expertise and the user's goal. Watching the team sketch ideas that connected abstract concepts to real-world problems didn’t just accelerate my learning; it helped us build better products.

‍

Lesson 3. The Responsibility of Representing Reality

Perhaps the most important lesson is that a map isn't just a picture; it's a source of truth. People inherently trust maps. And since nearly all geospatial data is temporal, it’s a snapshot in time—one with its own expiration date, level of detail, and margin for error. If your product shows a road is open, people will try to drive on it. If it shows a property line, they’ll make financial decisions based on it. As product managers, the trust a user places in our work is a profound responsibility for any product we put out into the world.

Data vs. Perception: This responsibility goes far beyond just having accurate data. A technically correct map can still lead a user to make a wrong decision. I saw this firsthand when experimenting with building an app tying air quality to the safety of outdoor activities. The app used an existing Air Quality Index from 1 to 10+, but I wasn’t even sure what that meant. Is 1 good or bad? If I assume 10/10 is excellent and head out for a run, am I putting myself at risk? Should I stay inside forever, or go for that hike?

🧭 The Guiding Principle: So now, this sense of responsibility shapes the core questions I ask my team. We have to constantly challenge how our data is interpreted. The real test is to ask: Can users make informed decisions based on what we’re showing? Is this a real-time view, a forecast, or a snapshot from the past? How accurate is the data? Are we communicating anything we didn’t mean to? These answers shape user trust, usability, and the product's value.

‍

Lesson 4. Geospatial Isn't that Niche

One of the most common reactions I get when I tell other PMs I work on geospatial products is, 'Wow, that's a cool niche.' For a while, I agreed. But I’ve since learnt this is fundamentally wrong.

It's Everywhere: Geospatial isn't a vertical industry; it's a fundamental, horizontal layer that powers the products we use everyday. Beyond obvious apps like Google Maps, the entire on-demand economy runs on geospatial data. Your Uber ride, your DoorDash delivery, the Amazon package arriving at your door. They are all orchestrated by complex geospatial systems for tracking, routing, and predicting arrival times.

It’s how Strava tracks your 5k or why you can tag a café on Instagram. And it often works invisibly in the background, like the smart thermostats using your phone's location to turn on and off, your banking app flagging fraud, or the complex behavioral models that turn your location history into targeted ads that fund our free apps.

💡 The PM Takeaway: This reframed my entire perspective as a PM. The opportunity isn't just building dedicated 'map products,' but applying core product thinking to a fundamental layer. The real opportunity is for PMs in any domain to ask: 'How can we leverage a location component to make our product smarter, more personalized, or more efficient?'

‍

Your Turn

Every product manager working in a specialized field has that "aha!" moment when the jargon finally starts to click. For me, it was learning to "speak geo." This journey is always ongoing, and the best insights often come from sharing our experiences.

So, let me ask you:

What was the single most confusing concept you had to learn in your domain (geospatial or otherwise), and what made it finally make sense?