Product management at Ad Hoc

Ad Hoc designs and delivers technology that empowers government to better serve people. The role of our product practice is to guide this work by collaborating with our customers to deliver the right things, in the right way.

Product management can be hard to define because it sits at the intersection of many fields, including design, research, and engineering. Product managers themselves come in all shapes and sizes and occupy roles that range from the tactical to the strategic. Despite this variety, product management has never been more important than it is today, as digital products are how most organizations, including government, interact with and serve people. This has placed a greater emphasis on delivering value for users, rather than just features and functionality.

Defining product management in terms of outcomes, not output

At Ad Hoc, we define product management as “the practice of shipping the right things, given business goals, user needs, and constraints." It’s a discipline, not a process, for maximizing value. This is because product management starts with the problem, not the solution, and relies on shaping ideas through learning, rather than building from requirements. In short, product managers need to be able to navigate uncertainty and “discover” what is the highest value solution so they can guide delivery towards the right outcomes.

Product management is also a complement to methodologies like agile software development and human-centered design. Both agile and human-centered design are cornerstones for the delivery of new digital services, but neither is entirely effective on its own. For example, agile is a set of values that informs how we deliver software, while human-centered design helps us understand who and what to solve for. Product management binds these perspectives together, by helping teams look at problems holistically and answer the “who”, “what”, and most importantly, the “why” behind the services they build.

Differentiating “products” from “projects”

Product and project management are sometimes conflated, but are in fact different disciplines. While both are focused on getting things done, products evolve, whereas projects are managed.

Project management is good for efforts with a fixed solution and a distinct beginning and end. For example, think of how you might build a bridge. Yes, it’s a complex feat of engineering, but you know how long it needs to be, and once it’s in place, it’s not going anywhere. Products, on the other hand, are meant to evolve based on changing goals and needs. When it comes to developing new digital services, this means we need to think beyond an initial release and consider how a service might need to evolve over time.

Another key difference is how the two disciplines view success. Product managers are focused on outcomes, whereas project managers are focused on output. This can be the difference between measuring success in terms of how a new feature expands access to benefits and how many story points are delivered in a sprint. The first measure is helpful for assessing the impact of what is delivered, whereas the other helps us understand team velocity, or capacity. Identifying the right measures for success and understanding how a product is performing relative to these goals are foundational elements to effective product management.

Ad Hoc’s product approach

Ad Hoc’s approach to product management consists of four phases — define, explore, build, and evolve. At each stage, we validate with users what we’ve delivered before committing to and scaling ideas. Broadly speaking, this way of working is applicable to both how we guide customers through the product life cycle and how we approach an individual sprint.

Define the problem

The best products serve a validated user need. As a result, we always seek to thoroughly understand the problem we’re trying to solve with our customers before developing solutions. We call this process “discovery” and it involves a variety of activities such as workshops and formative research aimed at understanding the current state. We often find that this work helps reframe problems in subtle, but important ways. For example, an agency may want to redesign a website in order to address a poor user experience, but may learn through discovery that the experience is most impacted by the volume and quality of data supporting it. This reframes the problem to be solved around improving data quality and data reporting, rather than just a “design refresh.” Starting with discovery is an investment in the future success of any technology effort, as it helps focus the team and it’s stakeholders around the right problems to solve.

Explore hypotheses to test

With an improved and shared understanding of the problem space, we can begin exploring potential solutions. We start this phase by generating hypotheses to test and prioritizing those that have the greatest potential for impact and learning. We then evaluate these ideas with users through artifacts like sketches, mockups, and rapid prototypes. This process allows us to explore many ideas quickly, while also helping us narrow in on “what works” and “what’s possible. It also sets the stage for developing our first set of features.

Build an initial release

Based on the vision and goals set by discovery, we’ll start working towards an initial version of our product, otherwise known as a “minimum viable product” (MVP). MVPs typically consist of a small subset of features that are meant to be tested with users in a real-world environment in order to validate core assumptions and inform future iterations of the product. They’re helpful for minimizing risk to programs, surfacing problems early in the development process, and demonstrating value quickly to stakeholders.

To manage this process, we work with a customer-assigned Product Owner, who sets the pace and direction for the team’s work by managing priorities and the product roadmap. The team uses a form of Agile to deliver on that direction and test new features iteratively and the Product Owner may adjust priorities based on what we learn and our progress towards goals. By working in short iterations with frequent feedback loops, the team is constantly learning and honing in on the highest value work.

Evolve the product

Once an MVP is serving users, we evolve it based on user feedback and our customer’s goals. When things change, the team uses the same product-based process to test and release new features. In contrast, project-based teams often launch everything at once with inadequate plans for changing needs, goals, and technology. Their products can become static and fall out of sync with users, the organization, and the systems they support. This is how many organizations become encumbered with legacy technology. At Ad Hoc, we help our customers think through the full lifecycle of software by designing solutions ready for change.

The future of product management in government

Product management is not a new discipline, but it is new to government. As government continues to deliver more of its services digitally, we can expect product roles to become more common and grow in influence. While this evolution is ongoing, it’s important to acknowledge some of the challenges of working this way:

• Despite many reforms, the procurement process still largely encourages teams to start with the solution, in the form of requirements, rather than exploring the problem.
• Agencies are still learning how to embrace a culture of experimentation, which involves techniques like prototyping, that help reduce uncertainty by exposing risks earlier in the development process.
• Strong product ownership is often limited within government agencies due to a lack of training, experience, and autonomy among staff.

Ad Hoc’s product approach is aimed at empowering our clients to fully leverage the value of more iterative and outcome-driven ways of working. As our partners at the U.S. Digital Service have already explained, the value of product management for government is clear. It focuses decision-making around outcomes, rather than output, and shapes solutions based on evidence and learning, rather than managing against a plan.

But for all of its benefits, product management is worth investing in simply because government works on things that matter. The people that depend on these services deserve the right things, not just features and functionality that meet requirements. Government is full of public servants that work hard everyday to solve some of the nation’s most complex problems. A product-based approach will help them deliver digital services that the public not only needs, but expects from a 21st century government.