Transit Tech is Civic Tech
Ryan MahoneyTechnology Thing, Enhanced by AI
Imagine if a transit agency spent two million dollars building technology-thing (enhanced by AI) that doesn’t make public transit easier, isn’t associated with increased ridership, and never motivates a person to take a train instead of a car—but thing was delivered on time and won an innovation award.
In one form or another, technology thing is omnipresent in the shower thoughts and napkin sketches of government decision-makers, soon to be putting their finishing touches on a business justification to fund more cool stuff.
Is this the high-impact work we left the higher-paying private sector for?
Download the Transit Tech is Civic Tech Presentation
Get your own copy of the presentation to review and share with your organization.
What can be done about technology thing? Our suggestion: transit tech teams working in government must adopt rider-centric methods to avoid the threat of initiatives that don’t address the public's concerns.
This essay was prep work for a talk of the same title I did with Kristin Taylor for Transportation Camp NYC 2023. In it, we contrasted two potential ways of building a hypothetical mobile app for public transit riders. In working on this, I’ve become more convinced that only with a civic tech approach can transit tech teams align with the broader agency priorities they reside within and rider goals while making it easier to build technology correctly the first time.
Unfortunately, many transit tech teams are structured, situated, or run like gov tech teams instead of civic tech teams, making it harder to perform rider experience research to inform their work. Without a rider-led structure, these teams drift into technology-first approaches, prioritizing internal strengths and tech interests.
The Migration to Transit Tech
US government agencies with fully staffed, highly competent, in-house civic tech teams have slowly been emerging in public transit over the past ten years. Over time, we have seen many technologists—for example, software engineers like me—join government agencies, leaving the private sector to have a more impactful career. We’ve brought our experience with modern practices such as Agile and DevOps. Additionally, UX Designers, User Researchers, Content Strategists, and Product Managers—essential product team members—have brought their deep industry expertise.
Just like the implementation folks leaving the private sector, at the leadership level, many transit tech directors and chiefs also lack a deep understanding of civic tech methods, especially in the area of discovery, since their backgrounds are usually in government or consulting, which tend to see businesses as the key customer, not the public.
Now, Kristin has been telling me that everyone knows what civic tech is, and everything I have to say about the topic is unoriginal and boring (thanks, Kristin!). Still, in talking to people at various transit agencies, I don’t agree that it is widely understood. So, apologies if you know all this, but civic technology, or civic tech, is technology that is meant to enhance the relationship between the people and government. It is not tech built for internal government stakeholders, that’s gov tech. When a government agency uses civic tech methods, it should align so closely with the needs of the public that it effectively becomes customer-led, or in this case, rider-led.
With so few experienced civic tech folks working in transit tech, theoretical or mismatched approaches fill an operating and strategy gap. Unchecked, this problem leads implementation teams to fail to meet rider needs by building the wrong things.
The Inside-Out Approach
In researching this topic, I was astonished to learn that there is a named strategy that encapsulates many of the concerns I have about transit tech organizations: The Inside-Out Approach. Without a truly rider-centric approach that looks outside for insights, transit tech teams look inside and inadvertently adopt this strategy, which emphasizes the organization’s internal capabilities, knowledge, and expertise. This may not sound so bad—hey, why not play to your strengths—but ultimately, it competes with rider-centrism. The outcome is a product development process guided by what the organization knows and can do well, even when that doesn’t match up with what the public really needs. This approach is easily recognizable as it relies on internal brainstorming sessions and “thought leadership,” with decisions driven by influential team members.
In so many important ways, the Inside Out Approach is lacking, including the following:
- Customer-Centricity: Focuses on internal capabilities and interests.
- Market Alignment: Seeks to promote internal strengths, not align to market.
- Innovation Relevance: Biases toward innovation through technology for technology’s sake.
- Feedback Integration: Customer feedback comes late in the process when it is most difficult to address.
- Value Creation: Value creation may be incidental, secondary, and unmeasured.
The Inside-Out Approach has a place in the world. For example, it is good for a start-up that sells proprietary technology, specialized expertise, or unique internal capabilities. Think of a company like OpenAI employing AI innovators and enabling them to lean into their strengths—sounds like a great idea! Unfortunately, public transit agencies are not start-ups, and innovative solutions must make public transit easier to use, even if they depend on boring old technology and procurement innovation.
Ironically, rider experience research is important in this model. I’m simplifying, but it becomes asking questions like “What do you think of this?” instead of “What are you trying to achieve?” This is a “ready-fire-aim” approach where user research is essentially brought in to support earlier strengths-based or technology-biased assumptions. When researchers identify a gap in addressing rider needs, they are often not positioned within the organization to raise their concerns. In a way, rider experience research may be tokenized on their tech teams as their existence paints a picture of a team being rider-led even when researchers are disempowered.
In the start-up world, there are concepts such as the “Lean Startup” and “Fail Fast,” which relate to the Inside-Out Approach in that they emphasize leader-driven hypothesis and bringing technology thing to market quickly and iterating to achieve product market fit. While they do have innovation potential, they delay customer feedback, depend on costly re-work, and rely on luck as a key factor in product success. This doesn’t seem to be an issue for investors, but it's not a great way to spend the public’s money. Government agencies are not great at building “minimally viable products” (MVP) or rough versions of a software product to get feedback early because they are overly sensitive to negative feedback. Their attempts at MVPs are too polished and laborious to be truly minimal or iterative, so they can’t get to the fast part of “fail fast.” They often can’t even fail properly because they aren’t measuring the right indicators. So, just completing a technology thing that collects metrics about itself may appear successful.
A Rider Experience Research Approach
Instead of the Inside-Out Approach, transit tech teams should bravely charge into the areas in which they are needed most. One framework we can review for systematically gathering customer insights is called Jobs to Be Done (JTBD).
JTBD has been around in the public sector for 30 years, where it is used to match efforts and marketing to customer goals—not what companies think they are or would like them to be. It asserts that people use products to achieve a specific goal they call the customer’s job. JTBD says that people “hire” the product that helps them do what they need to do, and they “fire” a product when they find a better solution.
JTBD can be transformative because it uncovers the customers’ unmet “pain points” with precision, giving transit tech teams a tangible artifact to measure customer needs at a granular and concrete level early, allowing work to get prioritized more clearly to customer impact.
It is also notable that it has an opinion on innovation: teams must first focus on the “job” the customer wants to get done. The technology (or solutions) comes later. In this way, customer insight drives relevant innovation—building products and solutions from the customer-in rather than the product-out.
This post is not a comprehensive guide on the JTBD framework. However, it thoroughly examines parts of the framework to demonstrate their relevance to transit tech.
Job Stories for Public Transit
The most crucial unit of JTBD is the Job Story. These get written from the customer’s perspective, avoiding internal jargon and assumptions. If you are familiar with the Agile framework, they resemble User Stories somewhat.
A common approach is to use:
- When… (situation)
- I want to… (job)
- so I can… (expected outcome)
Let’s create a couple for public transit:
- “When I need to go into the office, I want to get there while I sit and read a book so I can avoid stressing in traffic.”
- “When I am selecting a new doctor, I want to see if there is an inexpensive way to get to them so I can save money since I don’t drive.”
You might feel tempted to include the following:
“When I see an alert about an unplanned service disruption, I want to know immediately so I can tell my boss and avoid getting reprimanded.”
Now, professional user experience researchers may disagree with me on what I’m about to say. In my opinion, there is a difference between foundational job stories that provide customer insights and those that reflect an artificial goal created by the limitation of a company’s own products or services.
For example, nobody aspires to “hire” an alert notification app; people don’t want disruptions at all, so getting notified is a “job” nobody would ever apply for. People who ride public transit want to get to places, and the difficulty of using public transit causes people to “fire” public transit and use alternatives. Public transit itself is always the product we should be paying attention to, not the digital accessories that describe it. Yes, navigating a service alert is a task that is part of the sometimes frustrating experience of using public transit. It is an unfortunate and critical step in many user journeys, but it may be more appropriately expressed as a user story.
When you learn about JTBD, you invariably see a paraphrased quote from Theodore Levitt: “Customers don’t want a drill; they want a hole in the wall.” The spirit of JTBD is to center user concerns away from our perspectives as subject matter experts. For example, suppose your work relates to the digital delivery of disruption notifications. In that case, you might live in a world of data, divorced from the frustrated experience of riders facing a disruption.
Lastly, the drill example also shows that jobs are often enduring, although who or what gets hired changes. For instance, Julius Caesar also had the job of communicating over a long distance; he hired horseriders in his era but would hire email if he were alive today. Knowing rider jobs in transit tech provides enduring guidance on long-term product strategies.
A Mobile App for Riders
I mentioned in the introduction the use case of a mobile app for a transit agency. Since a mobile app could theoretically improve many aspects of a rider’s experience in using public transit, foundational riding-related JTBDs help a transit agency consider precisely if, how, when, and to what degree of impact a mobile app could make public transit easier and increase ridership.
JTBD reinforces the transit agency product is always transit service and apps and websites are accessories. In a way, agency-provided transit tech doesn’t really have competition in any meaningful sense; public transit service does, however.
Oddly, a fact that explains much about the current state of public transit is that it has no direct competitors, as transit agencies typically operate regional service monopolies. For instance, besides the government-run subway system that used eminent domain to carve a straight and mostly uninterrupted path across various stations, no products do the same thing in the same way. So, in Massachusetts, I can ride the Orange, but there is no competitive subway along a similar route running, say, on a Plaid line.
We want our app to make navigating the sometimes extremely problematic obstacle for riders easier, and various co-existing tools already serve a similar purpose, including other apps, websites, digital screens, printed posters, officials, announcements, etc. Some of these are agency-provided, and some are not. Together, they are part of the collective fabric of support that intends to help a disrupted rider.
Public transit definitely gets fired by riders (or ignored) due to many compelling secondary competitors: private driving, ride shares, and cycling, among many options.
We see public transit becoming more vibrant where its leaders think strategically and creatively about getting hired and persuading potential riders to fire the competition.
Rider Goals
In the private sector, many product strategies have a first principle of knowing the target group with elaborate personal descriptions. As such, detailed personas give model customers a face and a personality.
However, public transit riders come in all shapes and sizes, from all countries, all backgrounds, all salaries, all levels of familiarity with a public transit system, and all levels of digital literacy, etc. Without significant characteristic differentiators, these personas are uselessly vague. Age 10-80, no formal education to Ph.D., good or no sense of humor, earns 10k to 300k per year, carnivore, omnivore or vegan, 20-20 to no vision, and so on.
When personas identify everyone, it is because some products are better defined by customer goals than the customers they serve by considering situations and motivations over roles attributes.
This was put together hastily, but let’s consider segmentation criteria based on unmet needs, for example:
- Efficiency & Time-Saving: Riders want to reach their destinations quickly and efficiently.
- Unmet Need: Current transit options may be slow, unreliable, or not direct, leading to longer commute times.
- Segments: Commuters, students, and transit-dependent.
- Convenience: Riders want easy access to transit options without lengthy walks or complicated transfers.
- Unmet Need: Lack of conveniently located stops, stations, or routes.
- Segments: Elderly riders, riders with disabilities, riders with children.
- Affordability: Affordable transit options for various income levels.
- Unmet Need: Current fare structures might need to be more affordable for some population segments.
- Segments: Low-income riders, unemployed individuals, and students.
- Comfort & Safety: Comfortable and safe riding experiences.
- Unmet Need: Overcrowded, unclean, or unsafe transit vehicles and stations.
- Segments: Elderly individuals, parents with young children.
- Accessibility: Transit options that are accessible to individuals with various physical abilities.
- Unmet Need: Stations, stops, or vehicles that are not easily accessible for individuals with disabilities.
- Segments: Riders with disabilities, elderly riders.
Customer goal segments tend to be enduring; as such, an innovative achievement for a transit tech team is one that significantly moves the dial for an entire segment, as it has the most potential to increase ridership.
Agency and Rider Alignment
A surprising aspect of JTBD is that customers can describe the metrics they use to measure success when trying to achieve their goals, and these metrics can become the KPIs that drive the transit agency.
Transit tech metrics can be misleading when they only focus on apps or websites, not their broader impact on public transit utilization. By contrast, let’s consider the Uber app. While an Uber rider's primary job is traveling, the Uber app is the product that mediates many aspects of that experience, and it is significant when a user adds or removes the app as it definitely means that Uber has lost or gained a customer. If someone removes an agency app, it is possible that they are so satisfied with transit service that they found the app was just taking up space on their phone. This same person could even be a transit promoter encouraging others in their community to use public transit. It’s not as clear.
We see similar unclear data on multi-modal transit agency websites that operate commuter rail services. Commuter rail schedule pages get far more views than most other pages, even if those other pages are for modes with significantly more utilization. What does this mean? Is commuter rail trending? This appears to be driven by commuter rail service being infrequent with high schedule adherence, so a webpage with schedules is inherently more useful to that rider population. On the other hand, there are less compelling reasons to go to a website about a mode operating frequent service. You can show up; you probably won’t be waiting long. What do page view comparisons between different modes tell agencies? Perhaps nothing.
On transit tech teams, leaders have a firm grasp on the metrics associated with their products but less clarity on how they feed into the adoption or abandonment of transit service.
From the rider to the CEO, being truly rider-led gets everyone working towards ensuring that public transit stays and increases its vitality in society.
Want to hear more from us?
Stay in touch with TransitOPS thinking and work by joining our mailing list.