Discover the power of integrating product management and discovery-driven practices in transforming federal procurement.

Learn how agile-at-scale methodologies, fueled by product management principles, enhance resilience, mitigate risks, and maximize outcomes in government initiatives. 

Let’s explore why so many public-sector projects fail and how changing the way government buys and builds work can dramatically improve outcomes, especially for project management professionals.

Project managers operate inside a flawed system and that real progress requires objective-based procurement, empowered product teams, and a shift from outputs to outcomes.

Why Failure is Baked into the Current System

We often “ fool ourselves” about project success.

John Johnson cites a recent CHAOS report indicating that only about 31% of projects actually achieve all three core goals of scope, schedule, and budget.

Traditional approaches tend to miss schedule targets, while in agile, the pressure often shows up in cost. The underlying pattern is the same: failure is common, not exceptional.

Drawing on Nassim Nicholas Taleb’s ideas, John highlights that mild success can be linked to skill, but wild success is usually due to variance.

In that context, organizations hide behind committees or rely on individual leaders willing to take personal reputational risk to lead fragile projects.

His core point for project managers is that they are often “trapped in a bad system” that structurally encourages failure rather than managing risk intelligently.

What Really Drives Project Risk

John turns to sources of risk and why projects fail. The audience helped name familiar issues—poor or changing requirements, lack of stakeholder engagement, weak leadership, and having the wrong people on the team, which can trap a project in a “loop of learning” instead of progress.

Politics and contentious stakeholders add another layer, making it difficult for project managers to move work forward when key players are unhappy or misaligned.

He refers to lists like those used in PMI contexts, where changing organizational priorities and inaccurate requirements rank at the top, followed by weak vision and poor change management.

Lower down are issues such as weak sponsor support, lack of needed resources, and complex task dependencies.

These are broken into two big buckets:

• “how we buy” (Leadership, Strategy, & Funding)
• “how we build” (Frameworks, Lifecycles, Data and Decision Making)

Customer‑centric Government and Value Flow

A major theme is the need for a truly customer-centric government, organized around the beneficiaries of government work rather than internal structures. For project managers, John acknowledges this is challenging because in government it is often unclear who the “customer” really is, but he argues it is still necessary to focus on the flow of value to those end beneficiaries.

Despite mandates to adopt agile and modular acquisition, John says these ways of working are still not fully embraced. Techniques like scope buffer, which help manage work in fixed time and budget, are underused, and alternative acquisition pathways are either unknown or mistrusted by those who control procurement.

Project Teams Versus Product Teams

John contrasts the project structures most Project managers live in with more modern product structures. Project teams are temporary, funded to deliver a defined set of outputs, and typically measured by whether they deliver a capability on time and on budget, often in terms of feature parity and output volume.

This structure requires repeated starting and stopping, heavy mapping, and frequent handoffs, which erode knowledge and slow progress.

Product teams, by contrast, are long-lived, cross-functional groups that are funded as a capacity rather than a project line item. They are measured on outcomes and customer experience improvements rather than just outputs.

John stresses that construction and other industries already use hybrid and integrated approaches rather than pure waterfall; integrated project delivery, design-build, pull planning, Kanban boards, and building information models are now common.

The movement in those sectors is toward integrated, cross-functional teams with high transparency and fewer handoffs, which parallels what is needed in government technology and is directly relevant to PMs.

The Missing Function: Product Management

John argues that many government organizations are missing a crucial role that complements project management: product management. Product managers sit at the intersection of user experience, technology, and organizational realities. They understand the true customer needs, know how to navigate internal politics and constraints, and maintain focus on value flow and beneficiaries.

He describes a “triad” of product manager, designer, and tech lead leading product work, and notes that in regulated or highly specialized environments this can become a “quad” by adding another domain expert.

Some government entities, such as parts of NIH, already have product management functions; John presents them as a pattern for others, stressing that these roles keep the voice of the customer at the table and anchored in the organization’s hierarchy, something project managers can leverage.

 

Mapping Value Streams to Improve Flow

To make value visible for PMs and leadership, John introduces value stream mapping. A value stream maps work from initial request to service delivery—he uses a loan origination example to show how operational steps and development value streams intersect. Development streams provide systems (like loan origination platforms) that support operational teams in serving the public.

 

He explains that the same concept applies in defense, public health, and enforcement. In defense, the F2T2EA chain (find, fix, track, target, engage, assess) describes how inbound threats are addressed.

During COVID-19, government value streams for testing and vaccine development—design, exploration, development, trials, production—showed how quickly systems could move when aligned. For project managers, the goal is always to shorten these streams so more value is delivered faster.

Reducing Handoffs and Building Quality In

John emphasizes that handoffs are the number one source of knowledge waste. When one group throws documents over the wall to another, context, reasoning, and emphasis are lost.

He points out that putting everyone on the same team—developers, testers, security, operations, domain experts—cuts down handoffs and lets downstream experts inform upstream decisions early, including on security, regulations, and testing needs.

This integrated team structure makes it easier to build quality in from the start instead of trying to bolt it on at the end. For project managers, that means designing team structures and cadences that favor conversations and shared demos over document-only handoffs, especially at the beginning.

Escaping the Build Trap

John introduces Melissa Perri’s concept of “the build trap,” which is especially relevant to PMs measured on output. In the build trap, organizations define success as building and releasing more features, regardless of whether those features solve real problems or create value. Requirements lists grow, systems bloat, and teams keep adding to products that are not really working for users.

He draws on Stephen Bungay’s “Art of Action” to describe three reinforcing gaps behind this: the knowledge gap (not knowing how to get from current state to desired outcomes), the alignment gap (plans not matching actual actions), and the effects gap (actions not producing expected results.

Leadership often responds by demanding more detailed plans, instructions, and controls, which increases overhead and makes the gaps worse.

John’s alternative for project management professionals is to provide clear strategic intent—where the organization is going and why—and let teams decide how to get there. That means orienting around outcomes instead of outputs, ruthlessly focusing on solving real user problems, and allowing teams to experiment and adjust their own plans.

Using OKRs and Flywheels to Align Strategy

To operationalize outcome focus, John recommends OKRs—objectives and key results. OKRs were developed at Intel, evangelized by John Doerr, and made famous by Google. Objectives state what you want to achieve; key results are the measurable indicators that show whether you’re achieving it.

John explains three types of OKRs: committed (we will do this), aspirational (stretch goals that may be missed but remain worthwhile), and learning (focused on gaining knowledge). He ties OKRs to the idea of a “flywheel”—a simple, explicit model of how an organization creates and compounds value.

For example, he describes Amazon’s flywheel linking low prices and fast delivery to more customers, more sellers, better asset returns, and further improvements in price and convenience

He then shows that government entities can have flywheels too. John cites an example from the CMS Innovation Center, where improving care leads to healthier people and better outcomes, which then lowers costs and prices, enabling further improvements in care.

He notes that CMS has effectively documented this logic in its own mission materials, but stresses that it must be translated into aligned actions and OKRs, not just statements. For project managers, this means tying project work directly to clear agency flywheels rather than to isolated feature lists.

From KPIs to Outcome-Focused OKRs

John distinguishes between KPIs and OKRs in a way directly useful to PMs. KPIs are metrics of health or performance; OKRs are KPIs you are deliberately trying to change within a timeframe. The process starts by picking a KPI that matters to the mission, setting a target line to define the objective, and then generating hypotheses and experiments about how to move that KPI.

He frames this as a lean analytics cycle: choose a KPI, set a goal, hypothesize how to improve it, run an experiment (such as a prototype or small change), measure results, and then either double down, raise the bar, pivot, or rethink your approach. This cycle connects higher-level OKRs directly to team-level experiments and backlog items, mixing features with learning tasks.

Done well, it shifts organizations from output-driven to outcome-driven behavior, which is a shift project managers can lead.

Why Prototypes and Options Beat Big-bang Bets

To explain why experimentation is so powerful, John uses a lottery thought experiment. One option is a simple three-digit lottery ticket that costs three dollars and pays three thousand if you guess correctly—a fair but unattractive game. The second option is a staged ticket where you pay a small amount to reveal each digit and can quit at each stage.

Mathematically, the second option has positive expected value because you pay the larger amounts only when early digits match; most of the time you quit early and save money on losing paths.

This illustrates “options theory”: paying a bit up front for information and the right to stop lets you avoid wasting resources on bad ideas while reserving the chance to invest more heavily in good ones.

John connects this back to product development and project work: instead of placing one big bet with a detailed upfront plan, organizations should invest in prototypes and small experiments that reveal information early, reducing the knowledge gap when changes are cheap and influence is high. For PMs, that means explicitly budgeting and scheduling for experiments rather than trying to design everything upfront.

Objective-based Procurement in Practice

John then describes objective-based procurement, using NOAA’s Radio Frequency Interference Monitoring System (RFIMS) as a case. NOAA needed a system to detect and classify radio frequency interference as it reallocated bandwidth. Instead of writing a detailed specification and selecting a single vendor, they defined clear objectives and brought in multiple contractors under cost-plus arrangements to develop proofs of concept and prototypes.

By staggering work and evaluating prototypes against objectives before making a larger commitment, NOAA was able to identify which solution worked best in practice. The upfront cost was somewhat higher because multiple options were explored, but the overall outcome was much better. For project managers, this demonstrates how structuring contracts around objectives and staged learning can reduce risk and support better delivery.

A Navy Energy Program with Huge ROI

Another case John presents comes from a Navy energy efficiency program where the goal was to cut facility energy use by 50% from a 2005 baseline and have half of remaining usage come from green power. Initially, bases were selecting and funding their own energy projects, but many of these had negative net present value.

The Navy brought in a contractor on a small, flexible time-and-materials contract with options to renew annually.

The scope description was short, but the expectation was clear: show value quickly, or the Navy would exercise its option to quit.

The contractor mapped the value stream—identify projects, evaluate, select, and track performance—and found major data quality and selection issues.

By improving data quality and selection criteria, the team avoided funding bad projects and redirected investments toward high‑value ones, generating tens of millions of dollars in net present value on a contract that cost about one million. For PMs, this case shows that small, option‑rich contracts tied to clear objectives and value-stream thinking can massively outperform large, rigid projects.

How Project Managers can Buy Differently—and Win More Often

John closes by arguing that government can avoid decade‑long “boondoggle” projects by changing how it buys. Key elements include defining clear objectives instead of rigid feature lists, using contracts and funding structures that allow for experimentation and early exit, and putting modest competition in place so teams must demonstrate actual results rather than just compelling presentations.

Combined with empowered product teams, outcome-focused OKRs, and continuous experimentation, this kind of objective-based procurement can reduce waste, improve learning, and significantly increase the likelihood that public projects deliver the value they are meant to provide. For project management professionals, the message is that while they cannot control the entire system, they can champion these patterns in how they frame work, structure teams, and shape procurement conversations.