Outputs vs Outcomes: Agile Project Management for Meeting Complex User Needs

In just a couple of decades, what we’ve come to expect from websites and digital applications has changed profoundly. Where once having a website with some basic information and contact details was more than sufficient, we now expect many organizations to have fully digitized services. Some of these services are truly life-changing: many now access healthcare resources, make important purchases, and interface with our elected representatives online. And as our digital needs have become more critical and complex, so too has the process of meeting them.

Traditional project management styles focus on a single large output determined at the start, but we find that our increasingly critical and complex user expectations need a process built on iteration. 

This is where agile thinking comes in. At Palantir.net, we’ve been using agile techniques for many years—but it wasn’t until we fully adopted an agile mindset that we started fully reaping the benefits of agile thinking. This blog will walk you through some of the principles of agile that have most informed our thinking, and helped us deliver exceptional service design to clients across industries.

You can find out more about the fundamentals of agile in our guide to the U.S. Digital Services Playbook. 

How does agile deliver value?

The core of agile thinking is centering users. By taking the time to deeply understand their needs, we can then deliver value by incrementally building tested solutions that address their issues directly. We’re no longer working off assumptions about what might benefit users—we’re understanding what they need, building it, and then testing and adapting it to make sure it’s the best solution it can possibly be.

Let’s say your organization is looking to modernize a digital portal where students can browse and apply for courses. Traditional project management can help you tick all the basic boxes: up-to-date tech stack, accessibility requirements met, updated look and feel. But this modernization is also a huge opportunity to increase student sign ups, and improve student satisfaction at the first step of their learning journey. A faster, sleeker site might help—but that’s an assumption, not a certainty. 

Changing the goalposts

Agile thinking encourages us to prioritize outcomes over outputs. In the example above, that means the project’s goal isn’t delivering a piece of software. It’s the outcome: more site visitors successfully completing applications through the portal.

Now, our subtasks aren’t “rewrite/rebuild this part of the website”—they’re “interview users to understand why they click away from the application process”, “test if improved site navigation improves clickthrough rates to the portal”, and so on. Rather than building a whole site before testing to see if it helps us reach our goal, we’re making incremental improvements throughout the development process.

Some people think an agile approach means having no end goal. This is inaccurate. Agile means the end goal is satisfying user requirements, and the steps to get there are flexible and determined along the way. As new information and considerations arise, your priority becomes adapting to that data instead of shoehorning findings into your pre-existing plan. 

The benefit of outcome-focused project management

How does this help meet complex user needs? Simple: It relieves you of the burden of having to perfectly understand what’s needed on day one. Agile approaches assume your understanding of site visitors will improve over time, and information will emerge that challenges your presumptions and early hypotheses. Agile treats these moments of discovery and adaptation as part of the process, not a hindrance to it—and helps us deliver richer, better-tailored digital experiences as a result. 

Cycles and sprints: a chance to change direction

Perhaps the most well-known facet of agile project management is the technique of working in cycles (or “sprints”). Rather than monolithic phases—research, then design, then development, then testing—agile suggests working in smaller cycles, typically between 1-4 weeks. Each cycle has its own goal that advances the project toward its user-centered outcome, and prioritizes getting as much software in front of your end users as possible along the way.

In our student application example, traditional project management would have you spending the initial weeks planning out the entire project and maybe starting some preliminary design tasks (the results of which no one outside your team would ever see). A more agile approach would start with a hypothesis and test it out before the next step. Maybe you noticed in your analytics dashboard that a lot of people open the application information but not the application portal. A sprint might aim to understand why. You’d conduct student and stakeholder interviews, map user journeys, and redesign certain components based on that feedback. 

Pinpointing issues and changing course

The main benefit of this approach is that you can identify incorrect assumptions about what your site visitors want, need, or understand much more quickly. You may have assumed students aren’t applying because the information on your landing pages was unclear, or not making your courses sound attractive—and embarked on a whole content governance project to change this. But during your agile sprint, you discovered that students simply couldn’t find the “apply now” link on your site. Instead of spending months rewriting all of your content, you added a big “Apply Now” button in an eye-catching colour to the top of the page and dramatically improved application numbers for a fraction of the cost.

You might spot such issues using more traditional project management frameworks; but if you don’t test until the end of the project, you leave your team very little time to course correct. Agile approaches prioritize testing and user feedback in regular cycles during the project, giving you many more opportunities to discover these issues and more time to adapt to feedback.

Deciding how to measure quality collaboratively

The “definition of done”, or standard that each piece of work must meet, is another key project management approach we’ve adopted from the Scrum methodology of agile. Rather than assuming work is completed when it’s live, your team might agree that work is only done when it’s live, tested, compliant with relevant security and accessibility frameworks, and any reusable components it is based on have been added or updated in your internal design system.

Agreeing on certain standards in advance means you design and build with these requirements in mind. For example, if your team agrees that work is only done when it meets WCAG 2.2 AA compliance, you can build with that standard in mind. That way, you avoid tacking on key elements like accessibility and security at the end of the development process—a time-intensive approach that can often lead to missed steps. Rather than trying to raise the quality standard right at the end of the project, your team embarks on each project phase with a shared idea of acceptable quality. 

Agile in action: ADRC Wisconsin case study

In 2024, Wisconsin’s Department of Health Services (DHS) and Bureau of Aging and Disability Resources (BADR) tasked Palantir with creating the first centralized directory of all of the Aging and Disability Resource Centers (ADRCs) in the state.

Providing one centralized directory could be game-changing for Wisconsin’s aging and disabled communities—but only if it was accessible to the people it aimed to serve, and provided the services they needed. Following an agile approach, we set our project north star as opening up these resources to the aging and disabled communities of Wisconsin and their loved ones. From there, our key question was: how do people actually interface with the existing ADRC portals, and how can we improve that journey?

“What I loved most about working in agile was being able to work in the moment and see it all come together, and see our piece in it as well,” says Jennifer Getter, Resource Directory Integration Specialist Lead at BADR. “It’s such a welcome change from an agency building something based on what they thought we wanted, and not being able to change it much after the fact. Their style of asking: ‘What do you need? How can we make that work? Then how can we make that better?’ has been fantastic”.  

Understanding what visitors need from the site

Following an agile mindset, the first task was to understand what people actually needed the portal to do. We interviewed Wisconsin citizens and BADR staff, and discovered that many people using the ADRCs didn’t have internet access in their homes. They relied on take-home hard copies of the site’s information, often provided by loved ones or ADRC staff members. Additionally, most weren’t just printing one page since they needed copies of several different resources and service providers from the directory.

For these visitors, we created a feature called “My Resource List”. It functions almost like an online shopping basket—visitors can add items to their list as they navigate around the site, then see them displayed on one page when they’re ready. From there, they can collate multiple resources, ready for printing, saving service users valuable time and hassle.

We then put this new feature in front of actual site visitors to gauge feedback. “One gentleman was so excited,” Jennifer recalls. “He gave us his contact information and asked us to reach out when the site goes live. He told us he’s going to notify all of his friends when the directory is available.”

Understanding the benefits of agile requires shifting your perspective

Agile thinking shifts your project management focus: from ticking boxes and shipping code, to truly helping your site visitors make the most out of your websites. You still end up ticking the boxes of traditional project management—but each step of the process is infused with a deeper understanding of what your site visitors need, and how to help them. You’re also primed to handle the obstacles, challenges, and misconceptions that will inevitably emerge along the way.

Every community is different and deserves more than a cookie-cutter approach to building online experiences. Let’s talk about how we can build adaptive, collaborative workflows to support the people you work with.