Delivering on 21st Century IDEA: A case study from the GSA SmartPay team (Part 2)
This is Part 2 in a three-part series with the U.S. General Services Administration (GSA) Center for Charge Card Management (CCCM) about building their new, open-source program and training websites, and the new Section 889 web app.
For this post, Jessica Marine, a product manager on the GSA Service Delivery team, chatted with product owner, Andrew Lee. Andrew is a business management specialist with CCCM.
Jessica Marine: So, thanks for taking the time to chat with us, Andrew. Let’s jump right in. How did you find yourself in the role of product owner at CCCM to lead the GSA SmartPay modernization effort?
Andrew Lee: I’ve been a project manager for more than a decade. I worked on non-technology projects such as acquisitions and policy development. Since joining the GSA SmartPay team, I’ve had several different roles, including the project lead and contracting officer’s representative for the GSA SmartPay website. I had never led a technology project before, and it was like a new world.
In early 2023, it was time to recompete the contract. The program assessed the existing solution and decided to explore different development and even contracting options, based on the needs of our customers and our program. We met with GSA IT’s Service Delivery team and agreed to work together as an integrated team for a full custom rebuild of the GSA SmartPay program and training sites, as well as a procurement for agile software development support.
Given my background and role on the website project, it seemed like a natural fit to take on a product owner role.
Jessica Marine: Let’s zoom back to the start of the project. What were some of your initial reactions to building an open source product using user-centered design and agile development?
Andrew Lee: Pure terror. I was excited to learn, but I had heard about many challenging technology development projects in the course of my career. I’d seen many agile development projects suffer from pitfalls such as scope creep, cost overruns, insufficient requirements definition, and excessive rework.
These pitfalls aren’t unique to agile, but not having done it before, it seemed like, from the outside, that the flexibility of agile made it more risky. My instinct was to mitigate these risks through things like rigid scopes of work, constant project schedule tracking, and firm fixed price contracts. I learned later, that wasn’t true. I’ve come to believe that this may have been because developers did not engage with users enough throughout the development process. The very definition of agile project management is focusing on continuous releases and incorporating customer feedback with every iteration.
I was also nervous about learning a new skill set. Everything I knew about project management depended on project charters, schedules, and well-defined technical requirements. I definitely needed to change my mindset.
Jessica Marine: How did those changes work out for you?
Andrew Lee: Initially, I may have had some buyer’s remorse. It was work to retrain my brain and to learn a new process and vocabulary. Also, there’s a lot of what I used to call “magic” that happens in agile. There’s flexibility built into the process, but in the beginning – and especially for someone trained in classic project management – it felt like chaos. Typically, the product owner defines the goals of functionality and relies on the development team to come up with the solution. This was extremely uncomfortable, because I felt like I couldn’t control the solution.
But, it worked. I was amazed at the end of development sprints that functionality worked. It didn’t always work the way I thought it should, but the team’s usability testing confirmed that it made sense to the users, our cardholders and agency program coordinators. It didn’t matter what I thought, as long as it met the users’ needs. I learned quickly that the “magic” in agile happens because of repetition, team discipline, trust, user engagement, constant feedback, and continuous process refinement.
Jessica Marine: This was your first time acting as a product owner. What was your experience like?
Andrew Lee: It was like trying to keep 100 balloons that were dropped from the ceiling at different times from touching the floor. Several things happened at the same time and many tasks were either very urgent or extremely urgent. I consider myself an efficient task manager but this process was incredibly challenging, as I had to track and navigate multiple priorities and stakeholders and hold everything in my head. I was very fortunate to have such strong partners, team members, and supportive management to keep track of all moving pieces.
“ It was like trying to keep 100 balloons that were dropped from the ceiling at different times from touching the floor. ”
Jessica Marine: Because the sites had to launch by a certain date, you had to protect scope creep. How did you do that? How did you decide what was included in the minimally viable product (MVP) versus post-MVP?
Andrew Lee: I thought I had an idea of what the system should look like in my head, at the very beginning. Very quickly, I had to throw that out as I began to understand the agile development process better and the focus on the voice of the user. This came through research, content audit work, and analytics. Once we started creating roadmaps based on user needs, the user-focused framework became even more clear.
The team created roadmaps to represent user value and drive stories for system functionality, which helped us keep on track and review progress. We regularly discussed and made decisions about development priorities for the MVP. Hard decisions were made, and honestly, some of them seemed counterintuitive at the time. But keeping customers’ needs at the front of development, I think we made the right decisions. The closer we were to launch, the harder those decisions were because time is a finite resource.
Prioritization was so important, especially for preventing scope creep for the MVP. If I thought a function was “nice to have,” even if the level of effort was low, I had to learn to deprioritize it.
Jessica Marine: You really embraced the need for an accessible site. What are some of the most important things that you learned in this space?
Andrew Lee: In the past, I thought accessibility started and stopped with conforming with Section 508 of the Rehabilitation Act. Working with subject matter experts on the team, I came to understand that true accessibility is not just about choosing colors and layouts, but understanding how design decisions, navigation decisions, and accessible content impacts users.
We didn’t want to achieve 508 conformance just to say our website systems are accessible. We wanted a truly accessible site. It required a change in mindset. I have come to understand that Section 508 is a law, but accessibility is an experience, and our website delivers well beyond Section 508.
“ Section 508 is a law, but accessibility is an experience, and our website delivers well beyond Section 508. ”
Jessica Marine: What has been your most rewarding experience on the project?
Andrew Lee: Working with talented team members and feeling we had full management support. Our partnership with the GSA Service Delivery team demonstrated we can work effectively and innovatively in a government setting with the right approach, process, and organizational buy-in. Even though the process felt hectic, I was energized working with the right integrated team to deliver value to our customers.
I also want to thank our management team. As much as the team had to pivot and reprioritize issues, our Directors were right there with us, being patient and giving us the resources to deliver. They communicated the value of this process to leadership and our customers. This showed me the importance of buy-in and empowered me to make the right decisions.
Jessica Marine: What new skills have you developed as a result of being product owner on this project?
Andrew Lee: Obviously, I learned to manage an agile project and the importance of engaging customers early in the development process. But the most valuable skill I learned was prioritization. As a traditional project manager, I was used to identifying, mitigating, and reducing risk. In my career, the way I did that was to anticipate risk and act early, regardless of when the risk would be realized.
This experience has taught me that it’s still important to identify and track risk early, but with an effective team and well-defined goals, acting early isn’t always the right move. Oftentimes, having patience pays off. I saw big problems become much smaller over time or disappear as we tackled priority items and when we received feedback from users. It wasn’t about procrastination or avoiding problems. It was about timely action based on managing multiple priorities. As a side note, this has been a good lesson for me outside of work, too, to reduce stress.
Jessica Marine: What has been the reaction to the product?
Andrew Lee: To paraphrase a colleague, this has been a boring launch, and we mean this in the best way possible! With any transition, the team had to manage change and fix some bugs, but reports of issues were unexpectedly manageable. We braced for an overwhelming flood of negative feedback or bug reports, and it hasn’t happened.
We’ve received a lot of positive feedback from our customers indicating they like the streamlined website content and the innovative way they can access training quizzes and results without an account.
Jessica Marine: Can you offer any advice to someone new in government who is stepping into the role of product owner perhaps for the first time?
Andrew Lee: If you have an open mind, aren’t shy about asking questions, and are ready to put in the work, it might be uncomfortable but as long as the process is done right, it will pay off.
“ It might be uncomfortable but as long as the process is done right, it will pay off. ”
Your priorities should be based on value to users. Each user story that is written for development should be like a mini-business case; the value proposition to the user should be clear. Remember that development should be driven by user need and value, and not only by what internal stakeholders find important.
Also, no two days will look the same. For some, that might be interesting and exciting, but some might not like the unpredictability. As long as you are curious, willing to learn, open to feedback, and willing to communicate often, that’s a really good start.
Lastly, don’t forget to eat lunch! I had lots of consecutive meetings, so I had to make a conscious effort to take breaks.
“ Don’t forget to eat lunch! ”
Lightning round!
Jessica Marine: So, how did you get prepared for taking on this role?
Andrew Lee: Took several deep breaths before each meeting, tried to stay open-minded, and just sort of jumped in. I figured it out as we worked.
Jessica Marine: What’s the No. 1 trait for a product owner to have?
Andrew Lee: The ability to engage with and advocate for the user. The program might find a feature important, but it’s not important to the user. It can be uncomfortable for the product owner to disagree with the program when they know the user wants something else.
Also, the ability to work through different needs and prioritize. When everything is a high priority, the product owner needs to manage priorities and communicate with stakeholders.
Jessica Marine: When’s the last time you had to tell someone “No”?
Andrew Lee: I don’t like saying no to people. But as a product owner, especially shortly before launch and now after launch, I’ve had to find creative ways to give “soft no’s.” I take requests but communicate that we will assess and prioritize all requests based on user feedback and need.
Jessica Marine: How did it feel completing the burndown chart (simple chart used in agile showing work completed and remaining) for MVP?
Andrew Lee: Like I forgot to do something or several somethings.
Jessica Marine: How did you feel the first time that you discovered a bug in production?
Andrew Lee: Totally fine. Bugs are pretty normal, and I had complete confidence in our team and the process to fix the issue.
Jessica Marine: What have you gotten spectacularly wrong recently?
Andrew Lee: The belief that agile only works in tech companies with seemingly unlimited budgets!
Jessica Marine: How were you feeling when the system went live?
Andrew Lee: Anxious before the proverbial switch was flipped, and extremely suspicious when we had a relatively quiet launch.
Jessica Marine: Bravo, Andrew, on all that you’ve accomplished. Thank you so much for sharing your experience.
Andrew Lee: Thank you for having me! I was fortunate to be part of an amazing, patient, and collaborative team with incredibly supportive management and leadership. It was a very busy but rewarding process, and I am happy to have shared my experiences as someone new to agile product ownership.
Read part 1 and part 3 for more information about the GSA SmartPay project.