Disruption Alert: Product Management in Transit Tech

I’m old enough to remember when the term “agile” was reserved for creatures of instinct—the cheetah sprinting across African plains or the hummingbird suspended in flight like a jewel in midair—software projects were thought to be less majestic. And yet, on each well-planned expedition, we faced shifting landscapes and unforeseen pitfalls. When “Big-A” Agile showed up, it made practical sense, and in a wave, Project Managers became Agile Project Managers, and eventually, some of them were called Product Managers. However, the transition to true product management was not as smooth.

Agile, with its manifesto, rituals, and certifications, was easy to grasp and even easier to implement—at least superficially. It offered a structure that management could quickly adopt. Product management, on the other hand, required a more significant shift. It’s not just about running sprints and collecting unreliable estimates; it’s about continuous discovery, understanding customer needs, and delivering real value. Unfortunately, many organizations stopped short. They defined product management by their immediate tactical needs, missing out on its more profound, strategic role in transforming how we build products to achieve our most important outcomes through innovation.

One of the reasons for this is that Agile fits comfortably within a top-down, solution-driven culture. It gives leaders the illusion of control while allowing them to co-opt the language of modern development practices. Product management, by contrast, is more radical by fundamentally challenging this way of thinking. It’s about empowering teams, not just managing processes. It requires organizations to prioritize learning over certainty, which can feel risky for those who cling to traditional command-and-control approaches. This is why we often see organizations practicing a version of product management that’s just Agile in disguise—focused on execution rather than discovery.

Now, fast-forward 20 years, and the same struggles persist. After spending much of my career helping software teams and organizations achieve tangible product outcomes, it’s clear to me that product management isn’t just a role or a title. It’s a discipline that involves the entire team, from engineers to designers to product leaders. True product management happens when a team aligns around a compelling customer vision, iterates quickly based on credible feedback, and constantly refines its solution to drive meaningful impact.

What I’ve learned along the way is that the most successful product teams share a common set of traits: curiosity, humility, and a willingness to embrace diverse perspectives. Without these qualities, no amount of processes, tools, or frameworks will make product management work. In this essay, we’ll dive into how to make product management work in the public sector, where the challenges can be even greater, but the potential for impact is profound.

To give some color to the experience of working in transit tech, imagine being on a capable cross-functional team, entrusted to improve the software that helps move millions of public transit riders from point A to point B, ensuring the experience is as seamless as possible—or at least, less frustrating. Then, just as you’ve finished an opportunity map for streamlining bus detour communications, an unexpected bus electrification project takes precedence, and your plans get shelved. Welcome to transit tech, where we try to find a balance between agency priorities, innovation, and public accountability.

Unlike the startup world, where bold moves are often rewarded, transit tech teams operate under a magnifying glass of public scrutiny. Every misstep is amplified, fueling a culture of caution at odds with the creativity needed to solve the complex problems of urban mobility. The stakes are high, and the constraints are many: the needs of a diverse rider base that can shift overnight—think COVID-19—legacy systems refuse to be tamed, and bureaucratic hurdles can make the simplest task a test of diplomacy.

In this environment, technical abilities are only part of the equation. Success also demands leadership skills, deep knowledge of transit operations, an understanding of rider expectations, and the awareness of how policy dictates what’s possible—and what’s not. It’s no wonder that product management is both highly relevant and misunderstood inside public transit agencies.

In the tech sector, product management is a discipline software teams use to orchestrate their work cross-functionally while integrating subject matter expertise to solve complex problems that profoundly align with user needs and business goals. Essentially, it is a way of guiding the creative effort of experts to innovate for customers.

For product management to work in a public transit agency setting, there are a few conditions:

1. The organization must identify which software initiatives will benefit from this approach.

2. All software team members need a clear understanding of the discipline and how their roles contribute and interact during the discovery and development phases.

3. Stakeholders must grasp the benefits and limitations of product management to set realistic expectations.

4. Agency leaders need to be involved every step of the way, updating policies bit by bit—just like software—so the services keep up with what riders and staff actually need.

Product management should lead to novel solutions centered on the public’s needs. However, misapplying it is a risk for transit agencies and a frustration for everyone involved.

Mary Parker Follett, a name that may not ring a bell for most, was a woman whose ideas were revolutionary in her time and still resonate today. In the early 20th century, when management theory viewed workers as mere cogs in a machine, subject to rigid top-down control, Follett introduced a concept both simple and unsettling: real power doesn’t come from issuing orders but from collaboration—from what she termed “power-with” instead of “power-over.”

Follett was critical of the command-and-control management style of the time, observing how it stifled the conditions necessary for innovation: initiative, creativity, and a sense of ownership among employees. In her 1927 essay, Leader and Expert, she considers who is really in charge when company leaders must act on the directives from the experts they manage.

Long before anyone talked about empowered teams, Follett was advocating for them. As we’ll see, it’s no coincidence that one of today’s leading thinkers on product management, Marty Cagan, explores this very topic in his book EMPOWERED: Ordinary People, Extraordinary Products.

A fascinating intellectual thread connects Follett to Cagan, tracing nearly a century.

In 1954, Peter Drucker, often considered the father of modern management, referenced Follett’s theories in his seminal work The Practice of Management, specifically in the section What it Means to Be a Manager. Drucker adapted Follett’s concept of “power-with” into what he called “Management by Objectives”—a framework that reimagined managers not as commanders but as facilitators. At the same time, Drucker was consulting for Bill Hewlett and Dave Packard, who were so moved by these ideas they worked them into the “HP Way,” the guiding principles forming their groundbreaking culture that went on to define the company where product management principles would first be applied to software.

The HP Way includes several compelling objectives, including: “To foster initiative and creativity by allowing the individual great freedom of action in attaining well-defined objectives.” These ideals must have shaped the young Marty Cagan, who lived the HP Way for ten years in his first job as a software engineer at HP Labs in the 1980s, before later writing his seminal works on modern product management, starting with Inspired: How To Create Products Customers Love.

In studying product management, I realized most histories leave out Follett and Drucker—but they shouldn’t. The heart of product management is about guiding creativity and expertise to serve customers. Yet, in practice, especially in places like government agencies where top-down management is common, leaders often fall back on command-and-control tactics. They push product managers to manage over their teams instead of working with them, and they ignore expert insights that don’t fit assumptions. This misunderstanding of both the discipline and human nature weakens product management by valuing control over collaboration, authority over autonomy, and process over people.

Product management practices in software have been around for a long time, but they took off in the Internet era, particularly among startups building digital products by helping companies find “product-market fit”—providing a product people will choose and not want to give up. The focus on retaining customers is a compelling reason for companies to apply product management because the software rental model, fueled by renewals, requires a stable and loyal customer base, so companies must keep wowing customers; otherwise, a competitor will snatch them up.

For product management to work in transit tech, it must be adapted to focus on broader societal goals and the public good rather than conventional metrics like revenue and market share. In public transit, traditional product management metrics can seem silly when software users are operations staff with no option but to use specialized in-house developed software, who might feel uncomfortable expressing dissatisfaction with it. While it might seem like I’m cherry-picking using an operations example, rider-facing tools like apps and websites are secondary systems supporting a core product, in this case, the public transit service itself. So, while people could hypothetically recommend a transit agency’s website to a friend, it doesn’t matter if they recommend it; we want them to recommend the service.

We use product management to bring together a diverse team of experts to solve problems no one person can handle alone. It’s about integrating insights from all areas. We choose product management when the risk of making the wrong decisions could jeopardize key public transit goals—and this is why it’s so important to get it right.

Product management is sometimes frustratingly misunderstood as merely anything a product manager does. The reality is far more nuanced—and inconvenient. High-performing cross-functional teams without a designated product manager can sometimes manage to apply product management principles more effectively than those with one, highlighting how the job title itself can’t guarantee competence. And, of course, it can’t: product management is a complicated discipline to master. It demands a broad spectrum of leadership, technical and subject matter knowledge, skills, sound judgment, and personal attributes that are, quite frankly, hard to find in one person, a problem only magnified in government, which is often outmatched when competing with the private sector’s enticing benefits for top-tier talent.

To make sure we fully understand product management, let’s look at the core principles everyone agrees on—plus a few that are specific to the civic tech world:

Policy-Informed Innovation: Product management needs to balance innovation with regulatory rules. This means thinking about policy at every step, ensuring new ideas fit within current regulations or lead to necessary changes. By using data to guide policy tweaks and working with policy officers from the start, a product team can create solutions that work for users and meet regulatory demands. This approach avoids obstacles and ensures that innovations are practical, scalable, and built to last within the existing or evolving policy framework.

Rider and Operations Focus: Product management relies on credible user research to understand the diverse needs of both public transit riders and internal operations staff.

Honest Integration of Expertise: Public transit demands deep and varied expertise. Solutions must be informed by the industry’s unique requirements, considering both the depth of transit topics and the wide range of interrelated subjects, policies, and constraints that affect potential solutions.

Cross-Functional Collaboration: Product teams work closely with functional experts across various dimensions, from legacy system integration to policy adherence and accessibility requirements. Unlike an assembly line, this collaboration is dynamic, resembling a swarm, as teams work together to solve complex problems that defy silos.

Outcome-Focused Development: The focus is on creating value, not just features. Instead of loading software with as many features as possible, the aim is to invest efforts in the most impactful areas, using continuous discovery and delivery to enhance product value to users, the agency, and stakeholders. This iterative approach is deliberate and measured, based on vetted and transparent hypotheses rather than scattershot attempts to see what works.

Informed Decision-Making: Product teams prioritize decisions grounded in accurate, relevant, and timely data, avoiding the pitfalls of intuition, assumptions, or incomplete information. However, when information is lacking, they must construct a well-founded hypothesis, drawing on the available data and collective expertise. This approach ensures that no single authority figure’s biases unduly influence decision-making.

Ownership and Accountability: In teams with a designated product manager, this person is ultimately responsible for the success or failure of the product and for maintaining the collective’s product vision and strategy over the near and long term. Product management involves making tough decisions about what to build (and what not to build) and prioritizing based on customer value and business impact, which is challenging as diverse perspectives must be integrated.

Product management, unlike Agile, does not have a single manifesto or universally accepted set of principles. However, several authoritative texts are regarded as foundational in the field, reinforcing the concepts above. These texts serve as guiding frameworks for many product managers with frequent industry references:

• Inspired: How To Create Products Customers Love by Marty Cagan - 2008 (first edition), 2017 (second edition)

• The Lean Product Playbook by Dan Olsen - 2015

• Escaping the Build Trap by Melissa Perri - 2018

• Product Leadership by Richard Banfield, Martin Eriksson, and Nate Walkingshaw - 2017

• The Four Steps to the Epiphany by Steve Blank - 2005

That said, each book carves out its niche:

• Cagan believes in the power of visionary product management to lead customers to new, unexpected solutions they didn’t know they needed.

• Olsen prescribes the Lean Product Process, a step-by-step approach for achieving product-market.

• Perri warns companies about becoming “feature factories,” too focused on output rather than outcomes, grinding out many features that eventually make their product hard to use.

• Banfield, Eriksson, and Walkingshaw emphasize leadership in product managers, notably their ability to inspire, align, and drive cross-functional teams toward a shared vision.

• Blank advocates for a rigorous, scientific approach to testing hypotheses about customer needs and market viability before committing to product development.

Beyond the core text, in civic tech, the book Recoding America by Jennifer Pahlka highlights a crucial point: product managers need to work closely with policy architects. This collaboration ensures that insights from product discovery lead to actual policy changes so government services can be upgraded just as seamlessly as software.

Before diving deep into product management, let’s address a widespread and understandable misconception. In Recoding America, Pahlka argues persuasively for the government to prioritize building and maintaining software products, where appropriate, rather than pursuing their typical approach to developing software as one-off projects. Historically, government funding models have encouraged a cycle of building software, declaring it “finished” and neglecting it, then, later paying for expensive and risky rebuilds when new user needs arise. Pahlka is correct: this ongoing commitment to continuously improving software as products, not projects, is a critical distinction that, if ignored, disrupts the public services that rely on inadequately maintained software.

While that makes perfect sense, the similarity in terminology and concept between digital product and product management has led many people to assume that product management is the only modern approach to building software and, therefore, project management is an outmoded way of doing things. While product management may certainly be the recommended approach, the software development approach depends on several factors that might call for a product, project, or combined approach.

One way to look at this is to probe the relationship between the Agile methodology and Product Management; for example, the following are all factual statements:

• Product management is a discipline. A discipline is about consistently applying principles to achieve a desired outcome. Disciplines are expansive. Arguably, product management has three sub-disciplines within it: product discovery, product strategy, and product development (Agile framework).

• Agile is a framework. A framework is like a blueprint—it gives you the structure but leaves room for you to fill in the details based on the situation.

• Product management includes Agile methods to build and launch software.

• You can use Agile methods without doing product management.

• Just doing Agile methods without any other aspect of product management doesn’t count as real product management.

• Waterfall doesn’t work well because it’s too rigid and lacks real transparency.

• Nobody recommends waterfall anymore. When we say project management, we mean using Agile methods.

• Sometimes product managers take on project management too, but if all they do is project management, they’re really just project managers with the wrong title.

• In government, we sometimes blend Agile and waterfall into “Wagile”—a fixed plan that tries to use Agile methods to manage risk.

• Be careful with “Wagile,” or you’ll end up with a risky process that just pretends to be Agile.

Product management is a powerful tool, but only when it truly adds value. It’s not a one-size-fits-all solution, and using it unnecessarily can actually create more risks. To help decide whether product management or Agile alone is the better fit, here are a few simple guidelines.

While we’ll consider the perspectives of leading product management thinkers, it is notable that policies play a unique role in government. Some are flexible, while others are set in stone. The key is to assess them honestly. Whether a policy can change or not often determines which approach makes sense.

Marty Cagan’s Four Big Risks offers a clear framework for when to use product management. He breaks it down into four risk categories:

• Value risk: Does it deliver the outcome riders or staff need?

• Usability risk: Can people figure out how to use it?

• Feasibility risk: Is it even possible to build this?

• Business viability risk: Does this solution also work for the agency as a whole?

While Cagan’s insights are spot on, the language can feel a bit technical. So here are some additional thoughts, laid out in plain language.

When you need product management:

• High uncertainty: There might not be any viable solution, so we need to convene experts to find out.

• Discovery is essential. The team needs to explore and iterate to find the right solution.

• Responsibility runs deep. The product team owns the long-term success and is focused on achieving or progressing towards a meaningful outcome.

• Timelines are somewhat flexible. There's room to experiment and refine the approach.

• The market is a moving target. User needs and expectations are shifting fast, demanding continuous discovery and adaptability.

• Outcomes matter. Success is measured by the impact on the end goal, not just by checking off tasks.

• Stakeholders get it: Stakeholders understand product management and know it the right choice.

• Truly user-centric: The project puts users first, and policymakers are open to improvements.

When to apply Agile methods alone:

• Low uncertainty: We got this, we’ve done this, or people do this all the time.

• It’s all about delivery. An external party has requested a specific output.

• The solution is a no-brainer. You know what needs to be done from the start; everybody does.

• It’s all about the business. Business analysis and stakeholders provide all the answers because the project is policy-driven based on good or unchangeable policies.

• The outcome is set. The task is to deliver what someone already decided without deviation.

• Routine work. You’re following a well-trodden solution to a common problem.

• Limited accountability. The product team isn’t tied to the long-term success of the project.

• Deadlines are non-negotiable. The main focus is to hit the target date, the only risk people seem concerned about.

• Stability reigns. User expectations aren’t changing or prioritized, so ongoing tweaks are unlikely.

• No need to dig deep. No one is tracking outcomes; if they are, the software team is not informed.

Choosing Agile alone might feel unsettling for those passionate about customer-centricity. But in some cases, like when there’s an obvious solution, it’s easy to see why a straightforward project plan might work better than gathering experts to solve a problem that’s already been solved and just needs to be implemented. In situations like this, teams should use Agile alone—it’s excellent for reducing delivery risks.

Here is a list of common scenarios where Agile methods alone are a great fit:

• Best practice implementation: A team is making a website mobile-friendly. The experts should follow the established best practices of their field—no need for innovation, just getting it done right using proven methods.

• Business innovation, not technology innovation: Sometimes, a team is asked to do something new for their industry but common elsewhere. Take contactless payment in public transit. It’s a big deal for riders, but companies in other industries have been doing it for years. The focus here should be on applying the right solution, not inventing something new.

• Implementing sub-optimal policies: If a lousy policy forces the team to adopt a poor tech solution, the goal should be to improve the policy. But if the policy can’t change, the team’s hands are tied—they’ll have to build software within it, with the solution dictated by policy, not product discovery.

• Building a faithful clone: Sometimes, cloning an existing system makes strategic sense. If the original system is mature and has been refined over time, recreating it is more about following a plan than reinventing the wheel. This is where a long-term project plan makes more sense than starting from scratch.

In public transit, business leaders are excited about innovation—synonymous with progress and modernization—but tend to shy away from its unruly cousin, creativity. Creativity might sound more like chaos to some, triggering fears of an embarrassing, high-profile agency blunder. Yet, as Harvard Business School’s Linda Hill points out, you can’t have one without the other. According to Hill, innovation emerges from the interplay of ideas, and creativity is the raw material that leaders must harness to drive innovation.

Hill describes three essential capabilities for organizations that wish to harness creativity to enable innovation, aligned with Mary Parker Follett’s leadership theories and Marty Cagan’s description of product discovery, iteratively exploring and validating ideas before committing to building them. Hill emphasizes:

• Creative Abrasion: Deliberately allowing divergent perspectives to collide.

• Creative Agility: Finding quick ways to test concepts and share findings.

• Creative Resolution: Integrating credible opposing perspectives into more durable solutions.

Even with all that, artists and folks who study creativity know that even in the most supportive setting, creativity doesn’t just happen. Twyla Tharp, the author of The Creative Habit, argues that creativity is a response to limitations. Having endless possibilities can actually be stifling to the creative process, but defining some constraints—time, resources, and goals—gets the creative juices flowing.

In government, user research is the factor that catalyzes creativity for product teams working in transit tech because it illuminates real constraints based on evidence.

Transit operations are more complex than many other government services, and product management demands a focus on users. Product teams need credible insights to make intelligent decisions. Without ongoing, high-quality research, they’re left guessing—likely to rely too much on leadership opinions or focus on safe, easy-to-ship features that give the illusion of progress without ambitiously targeting important outcomes.

Product management is about solving real problems, but that doesn’t happen without research-driven insights or always operating in the safe, shallow areas of the field that don’t require a product management approach at all.

One day, an engineer said to me, “I’m ready for leadership.” I thought, great! I won’t stand in your way. But then they clarified, “No, I want a promotion.” So I asked, “Do you mean you want more authority on your team?” They nodded.

That’s when I clarified that authority isn’t what we need more of here. On our teams—engineers, designers, researchers, product managers—they’re all equals. If you want to lead, help your team succeed, and the influence will follow. For example: prioritizing the needs of others, being a good listener, spotting risks early, helping out when someone’s stuck, and understanding the bigger picture to support better decisions. If fancy titles imparted leadership qualities, I would be handing them out like Girl Scout cookies, but it doesn’t work that way.

This is the reality, on software teams; too many people don’t want to lead through their actions and character. They choose politics, ego, the need to be right, or convenient excuses. These are counterproductive for any team member, but it’s more damaging when a product manager severely lacks genuine leadership qualities because of their position on the team, which can allow them to gatekeep stakeholders, obstruct discovery initiatives, and even curtail team discussions.

It’s a tough truth, but since there’s usually only one product manager on a team and they have so much responsibility, they can either be a major strength or a serious liability, which means that the case for a product manager on a team is only a case for an excellent product manager on a team. On a team with helpful cross-functional experts, they might hit their stride without a product manager and naturally gravitate to applying great product management without even considering it. In most cases, we do benefit from product managers, so we have to ensure that they get the training and support to excel at the most critical aspects of their role: product discovery, product strategy, and Agile methods. If they can’t lead in those areas, the team can find someone else to manage stakeholders and coordinate releases.

Product managers should never find themselves dictating decisions or competing with experts to dabble in user research, design, and technical planning. Instead, their power comes from their ability to empower others, like a conductor who doesn’t play an instrument but ensures that every musician in the orchestra performs their best, in harmony, with a shared purpose. That’s the product manager—the person who brings out the collective intelligence of the team.

In transit tech, decisions can feel like a high-stakes gamble, drawing leaders to the allure of control. When faced with uncertainty, it’s a natural impulse to tighten the reins, centralize power, dictate every move from the top, and misapply product management.

When this goes on long enough, learned helplessness sets in as team members cope with lost autonomy.

Think about it: there is always something to do on a product team. Innovative solutions aren’t going to find themselves, so there is always some research, some experiments, some data to review, etc. Nonetheless, people who depend on the commander will find themselves, at times, without available tasks. If they just sit idly by, awaiting orders, they are like robots with zero percent battery.

We don’t need genius leaders with a team of helpers; we need something we see in nature everywhere: an ant colony. Ant colonies exhibit efficiency, adaptability, and resilience that many product teams can only dream of.

As Deborah M. Gordon describes in Ant Encounters, there is no central leader in an ant colony. Instead, each ant follows simple rules based on local interactions and the immediate environment. If an ant finds food, it leaves a pheromone trail for others to follow. If it encounters a problem, it changes direction, and others quickly adjust. This decentralized, self-organizing system allows the colony to solve complex problems—finding the shortest route to food, defending against predators, and even relocating the entire colony when necessary—all without a single directive from above.

The qualities that make ant colonies so successful—decentralization, adaptability, and collective problem-solving—are the same qualities many software teams lack when relying on top-down control.

When we release our grip, we may discover the truest form reaching our goal—one that emerges not from authority, but from a team that is inventive, resilient, and perpetually prepared for whatever challenge lies ahead.