This was my first product, and I took it from 0 to 1 adoption in record time. I would like to share my findings about what made it so successful.

Product Strategy: Make Geospatial Intelligence accessible to the rest of the Intel Community

You are reading the Research behind the Product Strategy Stack, Click the button to go read the Case Study

Before working on the Geospatial Intel Tool, I was on the Anti-Corruption Layer team.

An anti-corruption layer is like a translator or middleman who sits between two different software systems to ensure they can work together without one system’s problems or confusing ways of working “infecting” the other.

The assumption we had with creating the Anti-Corruption Layer: Exponential Adoption

Logically, it made sense. We had over 40+ at the time back in December 2024, and we built a brand new Operating Suite. Instead of each team trying to connect to third-party databases securely, we wanted to connect them all through one Anti-Corruption Layer team with dedicated Subject Matter Expertise. Whenever there were changes to the business rules or new data fields, we would format them properly for the front-end teams.

The idea was that user-facing teams could focus on development work that goes towards the end user(external integrations, feature flags, new feature requirements, etc).

Assumption: We can save XXXX+ hours in database warehousing, data mapping, and back-end development for all these teams. We would not need to pull off Senior Developers to go work in this problem space.

Why I had moved to the Geospatial Intel Tool(GIT) App Team

We mapped all required fields from the database through the ACL for the GIT team, and most of the work on the backend had been completed. However, even with these brand-new features, the team was having trouble getting adoption, so I was moved to the frontlines.

Onboarding over the Geospatial Intel Team(GIT): Impromptu Meetings

Picture this: Three days into my new role, I was asked to lead our first monthly sync demo while still learning everyone’s names and figuring out where all the design components were. This wasn’t just any meeting; it was a chance to hear direct feedback from users and stakeholders. I’ve always maintained a can-do attitude but never thought I’d have so little time to prepare. I created my slides, recorded my demos, and got ready for the week ahead.

Demo Day

The monthly sync lasted roughly 90 minutes, and by the end of it, it all started to make sense. I sat there, silently watching as the screen went from one unit to the next, and I recorded a few things:

Who was talking? Why were they talking? How did they say it? Is this an actual concern? Do we have a solution for their request? Why is this a problem?

Then, it was my turn to present. I presented the new features and used users' comments to include them in the discussion, hopefully eliciting a response in Q&A.

That's when I realized that we were delinquent in several factors: Psychological Safety for User Feedback, Product Market Fit, Usability, & User Awareness of New Features.

Because we aren’t allowed to take sensitive materials outside of a Sensitive Compartmented Information Facility(SCIF), I would often draw non-sensitive moments of things I needed to remember after the meeting.
After the meeting, I started jotting down my notes for the team to understand the bigger issue.

Identifying the Landscape

Immediately after the meeting, I started a spreadsheet to identify the landscape and determine user adoption. We had one pressing task: Validate Product Market Fit In-Person.

$5,500 to validate several misconceptions

“I have a family to feed, and [I worry] your software is going to replace me””

— Experienced Analyst (16+ years)

This feedback floored me since our purpose was to eliminate stress in his position significantly. While it was a small unit, they were all very talented. I realized that this veteran unit was so good at their jobs that they didn’t worry about being audited by Quality Assurance. So for the next few days, we spitballed and worked with them on identifying capability gaps and found several interesting lines of work that not only served them but served the greater Intel Community: building a feature outside of our legally required scope.

It cost us $5,500 to send four people on government travel. We were able to gain the adoption of 2 out of the 16 units that week and create a weekly cadence for them.

Building Trust: Design through Commitee

We were done with building in an ivory tower. While we are able to build based on stakeholder requirements, it has given us zero adoption. With those two original units that agreed to give us their undivided attention, we started working with them closely to make the product usable.

Open Collaboration development

We started working directly with our users to brainstorm and build new features. This was particularly risky because the feature we were building first was out of scope, yet we built it because it provided immense user value.

Thanks to the users at those two units, word had spread to the Intel Community that we were going after a highly requested feature ask from the US European Command(EUCOM).

Building out of scope: A Risky Feature

This was a risky feature because we would no longer be building towards PRDs and a complete user need. It would require a lot of handholding and support from our users.

I discovered buzz had spread to all the units because the first Training Session I led was attended by one-third of the entire user base.

“Are you building out for the European Use Case?”

My users wasted no time explaining why they had attended. We had finally struck a chord that they seemed to resonate with. During that meeting, I aligned expectations on when the feature could be delivered and said that for this to be built, everyone needs to be an active partner in development.

We came to several agreements.

We will build towards the US European Command use case.
I will train all new analysts in our software every Wednesday for overall help.
We will offer a Pizza Party to the Intel Squadron that correctly publishes a report using our new features.

WRITING AID CHALLENGE

〰️

WIN A MILLENIUM FALCON TROPHY AND PIZZA

〰️

WRITING AID CHALLENGE 〰️ WIN A MILLENIUM FALCON TROPHY AND PIZZA 〰️

With the challenge artificially boosting our adoption number, we got a record number of users, which bought us time to build the EUCOM feature. Our stakeholders and leadership were content with our progress. With all the pieces in their place, I put back on my designer hat and started working as the third designer on the team to deliver download options, drag features to format the report, and a linking info feature.

Within a week, we had a winner for our challenge. We wrote our findings to all the units and thanked them for their hard work in trying out the new features.

Sept 18th: Training Session, Announcing the Winner, Presenting the EUCOM Prototype

By the second training session, attendance was growing exponentially. We had representation from our stakeholders, two representatives from non-adopted units, and special guests from European Command.

We covered the new features that will be in the app next week. After announcing the Writing Aid Winner, we talked about the elephant in the room: the EUCOM feature. I demoed the prototype and opened the room for a Q&A. After recording the minor feedback, we said the feature would be live in the app next week.

Before I concluded the meeting, my stakeholders asked if I could hang back. I said that with this new feature and its high visibility, it would be worth scheduling a trip to Langley, the most extensive user base. What would change about the adoption this time is 3-fold:

I would be on-site training them
Our stakeholders would attend
Forward momentum from our Guard and Reserve Units

Langley Stakeholder Meet <> On-site User Demo

The Langley Trip was going to be difficult because I had heard through multiple product teams that that unit had some of the most opinionated users. Hence, we put their status as an Edge Case.

At this unit were two of the largest user bases, with two Active Duty Intel Squadrons and the Guard Unit attached. Our three-person team, along with our stakeholders, walked through each unit, and after watching faces while I made conversation with users, I started noticing that we had to reframe our position quickly.

Cognitive Biases at Play: Win hearts and minds

There were a couple of cognitive biases that I started picking up on at the on-site.

Excentric Incentive Bias: This bias is the tendency to attribute others’ motivations to external rewards like compensation. Our users are intuitive, brainy, mission-driven individuals. Many users assumed that we were contractors, many of whom were motivated by compensation.

This was a common misconception because we were built on Pivotal Labs’ practices. We were funded like contractors, moved like contractors, all on a government salary.

Reframing Sessions that I did with the users:

User: “Are you guys contractors?”

Woody: No, but that’s a good question. We are all government civilians[Correct the bias], and some of us have prior military experience. I get why you would think that, we’re not only a detachment in the Air Force, but we’re also built on industry practices, so we look, walk, and talk like contractors, but we still drive Hondas, not Maseratis.[Explain that we are on a government salary like the rest of them]

Woody: “Hey, we’re pretty light on features this week.[Encouraging them to suggest feature work] Was there anything you didn’t like in the app? We’re paid to work regardless of 3 features coming down or 15, I don’t mind the work [Enforcing the behavior that we are here to solve problems]. At the end of the day, this is a tool for you. You guys are the foundation of what makes this app useful or not so if you can’t think of something, here’s my card and you just toss me an email.”[Our mission is the same]

Power Distance Bias/Psychological Safety: This bias relates to the environment where individuals feel safe expressing concerns, ideas, or criticism without fear of negative consequences for self-image, status, or career.

Kessel Run was created as a detachment, with its autonomy and four key pillars:

Ideas over Rank
Bias for Action
Intense Customer Focus
Continuous Evolution

Reframing Sessions to Increase Psychological Safety:
Woody: "So, how did you like the Writing Aid Feature? We just noticed that your unit wasn’t using it very much. You won’t hurt my feelings, I didn’t work on the feature haha.”[I did, it eases the user not to have to give feedback directly without psychological safety first]

Woody: “You wanna hear something funny? I worked [X] feature and [Tom, Production Manager] hated it!”

User: “Haha yeah Tom’s very my way or the highway”

Woody: “Difficult man to please, what do you think he’s looking for?”

User: “Well, it’s just who he is. He used to teach at the schoolhouse, so he’s probably disappointed that he can’t add his checklist.” [Understanding the problem]

Woody: “He wants to add more to the checklist??? There’s already like 40 things on there!”

User: “Dude, it’s bad during exercises because he’s like a different person, try 80, he's practically hovering over you.” [Psychological Safety to explain the issue further]

Woody: “Hey, just spitballing, but I don’t think this will be hard to build. If you’ve got time, I think we can get this to Tom’s level of approval, and I can get him off your back. You down to work on it, I think we get it reformatted in the app soon.” [Small Time Commitment, Solves Direct User Problem]

User: “You’re pretty close, I think you get to Tom’s QC Checklist standard, and everyone will be okay with it.

Even trained individuals make mistakes: Assumptions Kill

Since the start of August and now 2 months into this team, we’ve scaled to reach 60% of our users. Our success came from delivering the EUCOM feature, which got us in the door. What kept our team agile was the feedback loops that we created. To make sure that everyone was in the loop regarding development. I then created the GIT Newsletter: You Said, We Listened.

You Said, We Listened Newsletter

October - First Edition (Example)

The first edition contained 3 key pieces of information: You Said, We Listened, Training Schedule, and Contact Information

You Said: “We need a way to comment on a report

We Listened: That’s a fantastic point! By mid-October, you should be able to see the new comment section on the right panel shortly. Join the Wednesday Sync on Oct. 9th to get a glimpse into the prototype.

Contact Section: Have a question for us? Reach out at:

Top Secret: [Email]
Secret: [Email]
Unclassed: [Email]

TBTF: Too Big To Fail - November

What started as a fight to stay alive and adopt was no longer our problem. We needed to build for scale and do it for several different audiences. In November, we started to cut down on feature requests and focused on hardening the features we currently had in the app. If the features no longer served for global adoption, we put it on the back burner.

We wanted to become the premier report builder for the US and its allies.

GIT reaching Product Market Fit: Going to the Liaison Position

With the Geospatial Intel Tool reaching adoption, my stakeholders and leadership told me to start packing my bags. With the Product Team in a good place, they wanted me to be on site to work on deploying our 700MM+ Operating Suite starting December 2024.